Re: Re: Wait State 00050064

Excellent.  Thanks for the clarification to what MVS is doing. 
Nonetheless, my use of LPARNUM 01 was incorrect and was ultimately the 
cause of the wait state. Just to be clear here this is a user error and 
NOT a Hercules bug. Perhaps it might have been nice for Hercules to flag 
the LPARNUM 01 since its inconsistent with ARCHLEVEL S/370?



On 9/20/2019 12:48 PM, Tony Harminc [email protected] [H390-MVS] wrote:
> On Fri, 20 Sep 2019 at 11:44, Robert Schreiber [email protected] wrote:
>
>> I did a lot of tracing, etc and found that NIP (Nucleus Initialization Program) was
>> getting an 80A abend by asking for a huge amount of memory. What was going on is that
>> bytes 6-7 in the result of an STIDP instruction was being used to calculate the amount of
>> memory get. I have no idea what MVS is try to accomplish here--this has to be an MVS bug.
> It's not.
>
>> Referring to SA22-7201-08, Pages 10-90/91:
> That's your problem. You're looking at a post S/370 architecture PofO.
> If you look at the S/370 Principles of Operation (e.g. the -10 at
> Bitsavers), you'll see that the rightmost two bytes from STIDP contain
> the maximum length of the Machine Check Extended Logout (MCEL) for
> this machine. A perfectly reasonable thing to do a GETMAIN for.
>
>> "The format bit (F) in bit position 48 specifies the format of the first two
>> digits of the CPU identification number."
> Not in S/370.
>
> Tony H.
>