RE: Re: Wait State 00050064

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