Hi,
How does your home-grown utility currently do this? It would be interesting
to hear.
I see what you're talking about, but the problem with processing old
messages are VERY difficult to handle. For example, the "control given to
CICS" message might have been issued 4 days before the script is launched,
so expecting that message to still be accessable isn't really that
reasonable. But, if you have just started the task with the script, I can
see where it would be handy to have a way to interrogate the console traffic
for specific messages. I have to be ready to see the message before it gets
issued and I have to leave a way out in case I have missed it for some
reason, (or it just doesn't ever come out). What I really need is a LISTEN
or "IF LISTEN" command to handle that second type of request (where the
script is the one doing the start). Currently, the way it can be handled
(although crude) is to issue the START for the task, then follow that by the
IFSTARTED and then a DELAY/PAUSE, but that really isn't very elegant.
i.e. old format:
IFSTOPPED CICS001
S CICS001
STARTED CICS001
DELAY 300 (wait 5 minutes)
ENDIF
F CICS001 CEMT I TAS (or whatever you wanted to do)
The new utility can do it a little less crudely, but not really what you are
asking for.
New Format:
IF STOPPED CICS001
S CICS001
WAIT UNTIL STARTED CICS001
PAUSE 300S/OPER (wait up to 5 min or until operator says continue)
ELSE
PAUSE 300S/OPER (wait just to be sure)
F CICS001 CEMT I TAS (or whatever you wanted to do)
ENDIF
But, I have another idea that might be pretty easy to implement and might
meet your needs a little is to set a "minimum" time that the task has to
have been active.
For instance:
IFSTARTED CICS001 nnnn [/OPER]
or
WAIT UNTIL STARTED CICS001 nnnn wwww[/OPER]
Where nnnn is a number of seconds (or minutes or hours or days) that the
target task (CICS001) has been running and wwww is the max amount of time
that I can wait for the CICS001 task to reach the nnnn time (obviously wwww
has to be greater than nnnn or it would always fail for a newly started
task), the /OPER (just like ont he current PAUSE command) will allow the
operator to override the wait time at their descretion and already exists
for the PAUSE command right now so the logic is easy to implement.
like:
IF STOPPED CICS001
S CICS001
WAIT UNTIL STARTED CICS001 300S 10M/OPER (wait max of 10 minutes)
F CICS001 CEMT I TAS (or whatever you wanted to do)
ELSE
WAIT UNTIL STARTED CICS001 300S 10M/OPER (CICS up for at least 5 min)
F CICS001 CEMT I TAS (or whatever you wanted to do)
ENDIF
If I had a LISTEN command then I could potentially do something like this:
IF STOPPED CICS001
S CICS001
IF LISTEN MSG(DFHnnnnn) CONT("CONTROL IS GIVEN TO CICS") 300S/OPER
F CICS001 CEMT I TAS (or whatever you wanted to do)
ELSE (didn't get message after 5 minutes)
Do somthing here
ENDIF
ELSE
WAIT UNTIL STARTED CICS001 300S 10M/OPER (CICS up for at least 5 min)
F CICS001 CEMT I TAS (or whatever you wanted to do)
ENDIF
What the above would do is check to see if CICS001 is not running, if it is
running it falls through to the ELSE and checks that it has been running for
at least 5 minutes (enough time to have been started and given control
already) before it does the work you want. If it's not already running,
then it would start the CICS task, and "LISTEN" for the DFHnnnn message and
optionally, parse that message for "CONTROL IS GIVEN TO CICS", or for 10
minutes, whichever comes first. If the messge isn't received within the
time limit specified, then the ELSE logic would apply and you could have
some recovery type thing done there. Alternatively, you could leave off the
10M part and it would wait forever for the "DFHnnnn" message to come out.
The message parsing stuff is very simple because I already have that code in
the REPLY part of the utility, establishing myself as a console to get the
messages is also pretty simple, and I think it would be easy to check the
messages as they go by.
Another way to do this, but could get messy overall would be to have the
"LISTEN" task just site around waiting for an external event to be posted,
and have an MPF exit wait for the message to come out, and post the event
handler when it finally happens. I kind of like that way, but it leaves me
open to a failure on the MPF side of things. I would have to be dependent
on something outside of my "sphere of influence", (the MPF exit being active).
One other thing that I forgot to ask peopel was if they think it would be
helpful for theis utility to send EMAIL or PAGEs from within the script. I
was also thinking aobut adding a "DO" facility to get something like "DO
EVERY 300S" logic to do something over and over again (forevr) or until a
certain number of times is reached or for a total amount of time transpires.
What do you think?
Brian
----------------------------------------------------------------------
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
