On Thursday, 04/22/2010 at 12:27 EDT, Sergio Lima <sergiovm...@hotmail.com> wrote: > Another words, this data is the result of another thing. > > Do you seee some mistake here ? > > I understand, that the WAKEUP (IUCVMSG receive the RC = 5 all times that my > virtual machine receive one messagem from VTAM machine correct? > > If this is ok, why the result of my DISPLAY don't run ?
Back in 1990 I wrote a VTAM CTC PU monitoring program. (For some reason, VTAM CTCs tend to stalling in PCTD2 state. (Deactivate PU, reset virtual CTC, reactivate PU.) The temptation is just to use WAKEUP/SECUSER/OBSERVER/SCIF/SEND to monitor the VTAM console for responses to "CP SEND VTAM VTAM ...." commands. It works, but unreliably. VTAM too often has other things to talk about and you can't (reliably) tease the response from CP SEND VTAM VTAM D NET,ID=xxxxx,E from other command responses or async console traffic. My solution ca. 1993 was based on a VTAM application called "VTAM Operator" (VTAMOP), originally written by Bob Pesner prior to 1993. I ended up rewriting it to fix some bugs, but the nice things is that it doesn't require access to the VTAM console via SCIF (SECUSER/OBSERVER) and lets multiple people use it at the same time. It uses VTAM's "secondary programmed operator" (SPO) application programming interface, routing messages received via SMSG to VTAM and then using MSGNOH to send the responses back. You can even add RACROUTE calls to do dynamic authorization stuff. My front-end exec would issue the command and then intercept messages until it got IST314I, indicating end-of-command. Prior to IST314I would be all the Really Interesting Stuff, and I knew that it contained *only* the response to the command I issued. No noise. If I had to do it all over again, I would have built a VTAM MODULE that runs in CMS, connecting to the VTAMOP application in VTAM via IUCV (instead of using SMSG/MSGNOH) and then I could have just PIPEd the output without any need for WAKEUP. Ah, well, it was uphill both ways in the snow back then. :-) Alan Altmark z/VM Development IBM Endicott
