Re: Re: Wait State 00050064

I suspect that if you were running ES/9000 Hercules would have to be in 
ARCHLVL ESA/390 mode. Now if you were to run a S/370 partition under 
that what happens? Does STIDP act like S/370 or ESA/390? I don't know 
for sure, but its seems that you are arguing that its an ESA/390 
instruction, not an S/370 instruction in that case. You may well be 
right....

GA22-7138 states that all *Problem Programs* will run correctly. Since 
STIDP is a privileged instruction its does not fall under that rule and 
thus it could well be that STIDP in an S/370 LPAR could behave as if its 
in the ESA/390 mode. That would be consistent with the fact that 
GA22-7138 does not list MVS as a supported  Guest Control Program. It 
lists MVS/SP, but that's a different animal.

So, to recap.  Running ES/9000 would be at ARCHLVL ESA/390 and STIDP 
would return the "F" bit to a guest running in an S/370 LPAR.  But, MVS 
is not supported in that configuration. MVS/SP is.

bob



On 9/21/2019 11:29 AM, 'Dave Wade' [email protected] [H390-MVS] wrote:
> Bob,
>
> I don’t think your config is “wrong”. The ES9000 boxes (and I am sure some other earlier boxes) had LPARs for S/370 mode, and so they must have had LPAR numbers.
>
>   
>
> the ES900 functional spec is here :-
>
>   
>
> http://chiclassiccomp.org/docs/content/computing/IBM/Mainframe/Hardware/System/GA22-7138-02_ESystem9000-330-720FunctionalCharConfig_Sep91.pdf
>
>   
>
> and if I have read it properly it says in a 370 mode LPAR a S/370 STDIP is stored. I believe that Hercules should do the same, so allow an LPARNUM to be set but not return it in the STIDP when in 370 mode.
>
>   
>
> Perhaps there should be a warning when this happens…
>
>   
>
> Dave
>
>   
>
>   
>
>   
>
>   
>
>   
>
> From: [email protected] <[email protected]>
> Sent: 21 September 2019 15:20
> To: [email protected]
> Subject: Re: [H390-MVS] Re: Wait State 00050064
>
>   
>
>
>
> S/370 has no idea what an LPAR is. Thus, the fact that its running in one should be shielded so that it cannot be confused. @Tony_Harminc correctly pointed out that the image expects the machine to look/act like GA22-7000-10. The problem that I caused myself was because STIDP did not adhere to the S/370 spec with the configuration that I (wrongly) created.
>
> bob
>
> On 9/21/2019 9:35 AM, 'Dave Wade' [email protected] <mailto:[email protected]>  [H390-MVS] wrote:
>
> Fish,
> It also appears that ES/9000 CPU's allowed multiple S/370 LPARs but how they presented this to the OS I don't know.
>   
> https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP9000.html
>   
> was the LPAR number hidden from the OS....
> ...... do S/370 OS's know about LPARs and how should Hercules behave when one is defined.
>   
> Perhaps Hercules is behaving badly...
>   
> Dave
>   
>
> -----Original Message-----
> From: [email protected] <mailto:[email protected]>   <mailto:[email protected]> <[email protected]>
> Sent: 21 September 2019 13:37
> To: [email protected] <mailto:[email protected]>
> Subject: RE: [H390-MVS] Re: Wait State 00050064
>   
> Robert Schreiber wrote:
>   
>
> Well,  This was "set" using the Hercules X64 GUI.
>
>   
> [...]
>
> Yes, they are in alphabetical order in the cnf. I *assume* that was
> done by the gui when it saved it?
>
>   
> Yes.
>   
>   
>
> Also, why did the gui let me set LPARNUM 01 when I had set S/370?
>
>   
> Because Hercules allows it.
>   
>   
>
> So, it seems that the code for ARCHLVL checks it, but the code for
> LPARNUM does not argue about value of 01 when a prior ARCHLVL S/370
> has been set.
>
>   
> Correct.
>   
>   
>
> In this case, perhaps LPARNUM should refuse to do what I did unless
> something like LPARNUM 01 FORCES370 is specified?
>
>   
> That's actually not a bad idea.
>   
> Given that specifying an LPARNUM *other* than the expected BASIC (for 370)
> is "unusual" (valid but very out of the ordinary), requiring an extra argument to
> confirm that yes, this is indeed what you meant to do, is actually a good idea.  It
> still allows e.g. LPARNUM 01 to be specified even for archlvl 370, but also
> catches/prevents accidental mistakes such as yours (leading to much confusion
> and wasted time, which is not good).
>   
> Let me see what I can do...
>   
>   
> [...]
>
> Clearly this is a user/learning curve error, but the effect was
> "devastating" in that I had an MVS image that I could not IPL and it
> took some pretty expert knowledge to figure out what was wrong.
>
>   
> My apologies.  Let me see what can be done to try and prevent something like
> that from happening in the future.
>   
>   
>
> In the surrounding, older comments, on this thread you can see that a
> lot of guessing was going on and it was never resolved.
> Now we don't know if the original problem was the same issue as here,
> but I just wanted to document at least one thing that I found to cause
> it.
>
>   
> And we appreciate you taking the time to do so.  We all learn from each other
> that way.
>   
>   
>
> It seems to me that the gui is "just" a front-end for configuration
> and running Hercules 4.
>
>   
> Correct.
>   
>   
>
> Now, there's a value add from that, but it would seem that better
> error checking would be appropriate.
>
>   
> I've tried hard to code HercGUI to catch user errors before they reach
> Hercules, but this was one that slipped by (because, as explained, it's VALID to
> Hercules).  I'll try to add code to HercGUI to popup with a
> warning/confirmation dialog in such a situation too (in addition Hercules's
> modified handling of the situation as per your suggestion).  Those two changes
> together should I hope prevent this from ever happening again.
>   
>   
>
> The design question is whether or not Hercules should be doing it
> and/or the gui?
>
>   
> Definitely both.  Not everyone uses the GUI.  Some people prefer running
> Hercules directly from the Command Prompt (although why I'll never know).
>   
>   
> [...]
>
> I am also assuming that ARCHLVL S/370 means that H will not do
> anything that not defined in that architecture. From what I think I've
> read here is that STIDP did something that was not allowed in S/370?
> If so, then that's a bug in mind.
>
>   
> Not necessarily (or so I'm told).
>   
> While I personally don't have any experience with such machines (my
> background is DOS/VSE and VM/SP 5 on 370/158, IBM 4381, etc), I am told
> some systems allowed running System/370 mode within an LPAR.  Hence the
> reason for Hercules supporting it (the code for which I did not personally write).
>   
>   
>
> Now I certainly can see the usefulness of allowing non-standard
> behaviors and relaxing the "rules", but only with proper "overrides"
> in the config file.
>
>   
> Agreed.  As I said, your "FORCES370" suggestion is a good one.  Let me see
> what I can do about implementing it for you.
>   
> Thank you for your feedback, Robert.  It is very much appreciated.
>   
> Take care.
>   
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: [email protected] <mailto:[email protected]>
>   
>   
>   
>   
>   
>   
> ------------------------------------
> Posted by: "\"Fish\" \(David B. Trout\)"  <mailto:[email protected]> <[email protected]>
> ------------------------------------
>   
>   
> ------------------------------------
>   
> Yahoo Groups Links
>   
>   
>   
>
>   
>   
>
>
>
>
>
>
>
>
>
>