Kevin
Pat covered the possibility that some of the actions you may eventually
decide to take may not need actually to use NetView.
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.
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.
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!
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.
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.
[1] Strictly a message which had the necessary bits set to ensure that it
was a retained message.
Chris Mason
---
Flag System
===========
FLAGON Clist
/* REXX FLAGON */
trace e
prefix = 'AUTO'
if msgvar(1) = '?' then
do
'CLEAR'
say 'The FLAGON Clist is used to keep a retained message on the'
say 'system console to indicate the status of vital automated'
say 'procedures. The first parameter is the name of the "flag"'
say 'and the second is the message to be retained.'
say 'The "flag" message ID is kept in common global variable:'
say 'prefix.FLAG.flagname'
exit 0
end
parse arg flagname flagmsg
if flagname = '' then
do
say 'A "flag" name is required as the first parameter.'
exit 0
end
if flagmsg = '' then
do
say 'A "flag" message is required as the second parameter.'
exit 0
end
text = flagname' 'flagmsg
'GLOBALV PUTT TEXT'
'LCWTO'
'GLOBALV GETT WTOID'
name = prefix'.FLAG.'flagname
interpret name'='wtoid
'GLOBALV PUTC 'name
exit 0
FLAGOFF Clist
/* REXX FLAGOFF */
trace e
prefix = 'AUTO'
if msgvar(1) = '?' then
do
'CLEAR'
say 'The FLAGOFF Clist is used to remove a retained message from'
say 'the system console. The retained message indicates the status'
say 'of a vital automated procedure. The first, and only, parameter'
say 'is the name of the "flag".'
say 'The "flag" message ID is kept in common global variable:'
say 'prefix.FLAG.flagname'
exit 0
end
parse arg flagname
if flagname = '' then
do
say 'A "flag" name is required as the first parameter.'
exit 0
end
name = prefix'.FLAG.'flagname
'GLOBALV GETC 'name
interpret 'smsgid='name
'DOM'
exit 0
Notes:
It may be noted in the previous Message Automation Table entries and
automation Clists that, for all the key events, a FLAGON Clist is issued
when the event is pending and a FLAGOFF Clist is issued when the event has
completed.
The 'flag' is a message retained on the MVS master console while the
associated event is still outstanding. The 'flag' consists of a code, used
to record an identifier for the message in a global variable so that it may
subsequently be deleted, and the text of the 'flag'.
Note that the message is actually written with an 'inner' Clist, LCWTO, for
'lower case WTO'. It has been found that this technique, together with
always using a REXX call statement when the FLAGON Clist is invoked, enables
the text to appear in mixed case.
LCWTO Clist
/* REXX LCWTO */
trace e
if msgvar(1) = '?' then
do
'CLEAR'
say 'The LCWTO Clist is called whenever a retained message is to'
say 'be written to the console.'
say 'Ideally the function it performs would be done in the calling'
say 'Clist. However it has been discovered that messages written'
say 'this way are lost, whereas messages written with a sub-Clist'
say 'actually appear!'
exit 0
end
desc = '0000000000100000'
routcde = '0100000000000000'
'GLOBALV GETT TEXT'
'WTO 'text
wtoid = smsgid
'GLOBALV PUTT WTOID'
exit 0
----- Original Message -----
From: "O'Mara, Kevin, ITD" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Friday, June 29, 2007 8:35 PM
Subject: NetView Automation of Console Message
I did try to search the archives, but I may have looked in all the wrong
corners.
Somewhat simple goal.
When System Console, or SYSLOG, receives System Message "DSNX906I" use
NetView Automation Table to do something; maybe run a REXX, or change
message to WTOR in RED. The message currently scrolls off the console,
and the request is to create some form of Alert at this occurrence.
When I go to the Automation Table, I will have the permissions required
to use it or a REXX exec. Should I choose to accept this request
(Mission Impossible theme plays), this will be my first personal attempt
at NetView automation, and any insight, REXX, Automation Table commands,
or other input would be gratefully received. Perhaps there is something
on the CBT "tape" for this.
I usually view the digest of IBM-Main, and my replies may be somewhat
delayed.
Thanks to all,
K.O'Mara
Technical Services
Alameda County ITD
----------------------------------------------------------------------
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
