On Sun, 1 Jul 2007 15:28:21 +0200, Chris Mason <[EMAIL PROTECTED]> wrote:
>Kevin > >Pat covered the possibility that some of the actions you may eventually >decide to take may not need actually to use NetView. KK: What Pat meant to say is that the message doesn't have to go into the NetView address space and be processed through the Automation Table (AT). If you use the Message Revision Table (MRT) function, this occurs directly on the Subsystem Interface (SSI) before a copy of the message is sent to NetView. Since the MRT runs on the SSI, it is also operational even if the NetView address space is down. >From my experience with NetView automation of more than 15 years ago - and >it seems inconceivable that any of the functions could have been lost in the >meantime - all of the actions you propose are, in principle, possible. I'm >pretty sure that if you use the techniques I used to use, you would need to >create an entirely new message of your own invention from within the message >automation table or a Clist which could then have the attributes you wanted. KK: Yes, all of the old functions are still there and still work and yes you'd have to create a new message to get the attributes that you want. But, that is not the case if you use the MRT -- you can change almost all of the messages attributes, and then just let the message continue on. And the altered message will be seen by NetView and all of the z/OS consoles (something you couldn't do before without creating a new message). >Probably more flexibility has been introduced since I played with console >messages but I seem to remember that messages were coloured by type rather >than by individual message. KK: z/OS had a mapping of message type to color, but we've had the ability (in an MPF exit) to re-color individual messages for a long time. The MRT can do this very easily. >I noticed specifically your desire to create a "retained" message. In my >automation of system startup, system shutdown, and, for very special >reasons, change of JES2 environment, I identified particular key events and >placed a retained message[1] on the console in order to show that the event >was pending. When the event had happened, say, JES2 had started, VTAM had >started or CICS had started, the message was also "deleted" by the >automation so that it disappeared off the console. You didn't say you wanted >to do that but there's no reason why you shouldn't amaze your colleagues! KK: You can certainly change a message's descriptor code in the MRT so that it will be retained on the screen. But you need to be careful about that since the message is then considered an action message. And as you point out, its usually a good idea to automatically delete such messages from the screen when the action they have requested has been taken. >Why did I go to the trouble of creating these status messages? I was >teaching hands-on classes - which explains the JES2 environment issue by the >way - and I was assisted by some colleagues. I have always delighted in >getting rid of essentially useless messages, especially during system >startup, and I had achieved total elimination with this fully automated >environment - hurrah! > >Except that my colleagues now asked how the **** were they supposed to know >what - if anything - was going on and whether my automation was actually >doing what it should - given that there were probably four MVS systems >starting up and relying on an underlying VM system which might be a bit - or >more than a bit - overloaded because of activity from simultaneous classes. KK: The classic automation "blackbox" problem. We had a similar problem with the automation for the S/390 Parallel Query Server. It essentially had an "ON" and an "OFF" but we found that people started meddling with it if they didn't think it was doing what it was suppose to be doing. So we added a simple operator interface that provided some update-in-place status every so often, to give them that warm fuzzy feeling that the machine was doing what it was supposed to do, and we found that the amount of meddling dropped significantly. >Since I happen still to have some presentation text which covers the logic >for creating and deleting these messages and it's not too large, I've >appended it to the post. > >Incidentally, the LCWTO Clist shrouds a mystery. Perhaps a wise man - or >woman - who remembers NetView automation around 1990 has an explanation. > >Finally, NetView automation does cover the possibility to create a WTOR as >well as a WTO (and a DOM) but, when I covered this topic teaching NetView >automation facilities, I rather discouraged using WTOR. It seemed to me >possible to achieve the same results simply using messages, commands and >retaining status in global variables. Is it not significant that those >products which used to run with outstanding WTORs - I believe IMS was one - >or was it CICS, perhaps both - eventually got the option to use a MODIFY (F) >(and probably STOP (P)) command as an alternative? That way the operator >didn't need to go searching for the WTOR reply number. I remember that once >I had found the QEDIT macro (the interface for F and P commands) for my >trivial long-running programs, I never looked back. KK: I think you are referring to IMS. But the worse example that I can think of was CADAM which at one time had an outstanding WTOR for every CADAM workstation that was attached to MVS. Since we had only 99 reply IDs back then, this tended to cause a problem. I was able to convince them to use the MODIFY command instead. >[1] Strictly a message which had the necessary bits set to ensure that it >was a retained message. > >Chris Mason > W. Kevin Kelley -- IBM POK Lab - z/OS Core Technical Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
