>My colleagues were unable to determine *what* caused the wait state, for the >simple reason that the accompanying message wasn't visible anymore. In this, I >also blame IBM who apparently do all their testing under VM (where the NIP >messages stay on the console) and have no clue about the real world that >actually uses 'real' consoles NOT under VM for a NIP console. A 'real' console >is these days attached somehow to an IP network. The second the wait state >hits, that console is released to the network. Which means that the 'IP >network' puts its welcome message back onto that console, effectively wiping >out any messages that might have been visible there. And believe me, that is so >fast that you have no chance of seeing any preceding message, much less >comprehend it.
>IBM should really test their systems on real consoles (not VM, and not on the >HMC, either), because IBM doesn't even understand how hard it is to see NIP >messages preceding a problem. In addition, *EVERY* NIP message explaining a >wait state should be *in the wait state message*, not some preceding 'for your >info' thing. Especially when the component loading the wait state wasn't the >culprit. While most unit testing and component testing is done under VM, plenty of testing (System Test, Integration Test, Performance Test, Consolidated Service Test, Engineering System Test, to name a few) is done not under VM, using "real consoles". We are certainly well aware of the issue you are describing. In the old days, MVS loaded a disabled wait state by simply loading the wait state PSW on all CPs. Any DASD reserves held at the time the wait state was loaded continued to be held, blocking any sharing systems from accessing the reserved devices, until the operator did something to initiate a system reset. This problem was exacerbated by the increased use of shared DASD when Sysplex came along. So, about 20 years ago, APAR OY36587 implemented a different method for loading a disabled wait state. Instead of doing a LPSW in the last CP, we issue a DIAGNOSE instruction, passing the desired wait state PSW as a parameter. The machine initiates a system reset to cause the reserves to be released, and loads the wait state PSW. The system reset drives a reset to each channel path (which is what causes a DASD control unit to release the reserves). The terminal/console control units of that era (3174) did not change the current display of its terminals in response to the reset. When the 2074 control unit came along, it responded to the reset by clearing the screens of its terminals/consoles and displaying some kind of link message. For the cases where z/OS is loading a disabled wait state, and one of these consoles is the SYNCHDEST console or the NIP console, this behavior is unfortunate (to say it politely. When it happens to me, I say it using more colorful language). But there isn't anything z/OS can do about this. We really do want the system reset done to release the DASD reserves. For this reason (among others), I recommend using the System Console (aka Operating System Messages on the HMC) as the SYNCHDEST and NIP console. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
