This is a design problem in the machine. LPAR notifies the SE that a
disabled wait PSW has been loaded, but there is no disabled wait PSW
provided in that interface. At some point later, the SE asks LPAR for the
current PSW, and if a subsequent IPL has already started, it gets
a PSW from that IPLing processor and uses it for disabled wait logging.
0400000080000000000000002000017c is the most common PSW we see in these
incorrect disabled wait logs, because that is the STSCH instruction in a loop
that does an STSCH to
every subchannel during z/OS IPL processing. And STSCH is by far the most
complex (and thus slowest) instruction in that loop, so that is what the PSW is
most likely to be.
This problem has been possible for several generations of machine, but it
seems to have gotten more prevalent in z16 due to some other changes.
Fixing it requires a new interface between LPAR and the SE so that LPAR can
provide the disabled wait PSW when it notifies the SE about a disabled wait.
I think this is implemented in the next generation after z16.
Jim Mulder
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Radoslaw Skorupka
Sent: Tuesday, February 18, 2025 2:40 PM
To: [email protected]
Subject: New WAIT state in z/OS 3.1?
I've got wait state 17c
However it is not documented in System Codes!
Any clue?
Full PSW
0400000080000000000000002000017c
--
Radoslaw Skorupka
Lodz, Poland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
