Exspans Systems Inc Logo home
 
Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #1 
I think it would be nice to have a list of commonly automated messages. I think some people might have a "I could of had a V8" moment, when they look through a list of messages and actions that other people have found useful.
__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #2 
I think there are 5 categories of messages to be considered:
1. Ignore or suppress - messages that you do not even want to see.
2. Normal or informational - messages to be displayed, but no response is required.
3. Abnormal - messages that need to be reviewed, but have no pre-planned response.
4. Important - messages that require eventual action.
5. Critical - messages that require immediate attention.

__________________
zboxassist
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #3 
There are also messages that pass in the normal way of operation that need something doing. For example when SMF datasets fill and need offload

MSG=IEE362A SUB(*(OFFLDSMF))
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #4 
I send myself an email when AutoMan license is about to expire:

*---------------------------------------------------------------------*
* AUT0107I Software License Expires in nnnn days
MSG=AUT0107I
/* Enable predefined global variables for substitution */
VAR &MSGDAT /* LEN=8 Message Date */
VAR &MSGDIAG /* LEN=255 Summary diagnostic information */
VAR &MSGSYS /* LEN=8 Message System name */
VAR &MSGTIM /* LEN=8 Message Time of Day */
VAR &MSGTXT /* LEN=255 Message Text (dynamic length) */

/* Capture $$MSGxxx values */
LET &MSGDAT = $$MSGDAT
LET &MSGSYS = $$MSGSYS
LET &MSGTIM = $$MSGTIM
LET &MSGTXT = $$MSGTXT

SET HILITE = REVERSE
LET &MSGDIAG = 'Occurred at &MSGDAT &MSGTIM on System &MSGSYS'
EMAIL SUBJECT 'AMGM1005 &MSGTXT'
'&MSGDIAG'
' '
'&MSGTXT'

__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #5 
The sending of emails in response to events is quite common now. Some events, like this are regular, but happen so far apart in time that no one can reasonably be expected to remember them. Other events may be emergencies and need rapid response. Some are common regular occurrences. In the case of Zamin's SMF example, it happens frequently but at slightly unpredictable intervals, direct action that has been pre-planned is taken. There are AutoMan users who do not have regular operations staff, but have all routine messages coded for planned response, with anything that needs physical action sent out on an email system.
0
Grazillda

Avatar / Picture

Member
Registered:
Posts: 48
Reply with quote  #6 
On a z/OS system there are two major categories. Those messages that are standard for the system and need the same response from all users, and those messages that relate to specific processing for the business enterprise. Both those categories can be divided according to zboxassist's classification. It should be possible to put together a list of all the standard messages and suggested responses. The names of jobs submitted would be different, as in Zamin's example, but the intent of the response would always be the same.
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #7 
We could probably put together a list of the standard messages, but that is kind of distorted now by the use of SSIDs. The messages that indicate the stage of processing of a service are no longer the same as the message intercept processing.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #8 
Good point. Message automation includes not only the messages defined in MSGID, but should also include:
1. RMSGID - Retained Message Processing
2. SYSOUT - SYSOUT Processing
3. SSID - System Services Automation

Hopefully this topic will end up with a list of messages that people may find useful to automate in their environment regardless of the type of processing.

__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #9 
There is also some value in automating some of AutoMan's own status messages, to use them to decide on changes to the environment. A good example is one that came up recently. AutoMan takes a hold of and does not release the console interface during its initialization phase, to prevent commands that could potentially change the environment before it is ready. It issues a message AUT0080I Online and Ready to notify the user that the console interface is ready to use. This can be used to issue the first commands to customize the environment according to current conditions. There is also the shutdown verification message. This is probably the most widely automated message, to enable immediate shutdown, without operator intervention.

On the RMSGID front, messages about components that need action, such as SMF offload, could be up and need action at initialization. But there are others that can potentially clog up the screen. I have found that particularly useful during product testing. The operator want to see the messages, so they are not responded to instantly, but are then processed by running a section.

The SYSOUT processing only has standard messages for specific logging components, and might be more difficult to produce a standard list for. The SSID messages are specific to a given component and I do not think of them in quite the same way as MSGID intercepts.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #10 
While SYSOUT message processing for a CICS application will be very different from a WebSphere application or an IMS application, having a list of messages may be helpful to other customers running the same subsystems or applications.

Of course, SSID message processing is very specific to a particular component. For example, do you count your CICS region as up when you see message $HASP373 cicsname STARTED, or do you wait until you see message DFHSI1517 cicsname CONTROL IS BEING GIVEN TO CICS, or do you use some other message? Having a list of messages that other people use may be helpful. Also when you have multiple CICS regions, you need to ensure that one SSID's message processing ignores CICS messages from the other regions. Therefore the list of messages should include more than just the message id, but other hints or tips about the message that may be useful.

__________________
zboxassist
0
rakesh

Member
Registered:
Posts: 52
Reply with quote  #11 
Hi,

So far i have a\Automan to action below mesages.

1) MSG=IEF099I, reply CANCEL to the job if it is waiting for datasets which are allocated to other users/jobs
2) Log all the users logged on, Jobs submitted and all security failures
3) MSG=IEF238D, reply CANCEL to the job if incorrect volume mentioned in job
4) MSG=IEE362A, dump if SMF dataset fills up
5) If the status of CICS or any other STCs turn Inactive, then start them back.

That is all so far. i knew it's very few but i am still working on it.
0
Grazillda

Avatar / Picture

Member
Registered:
Posts: 48
Reply with quote  #12 
As far as CICS is concerned we only have one region in production and use DFHSI1517 cicsname CONTROL IS BEING GIVEN TO CICS as the SSID UP trigger. We only use SSID state to determine if CICS is to be up or down. In that case we use ONFAIL=RESTART. If I had 2 CICS regions I would use INSTANCE=MULTIPLE.

For IEF099I the response depends on which job was trying to get the dataset. We also trap IEF238D and start an offload job.

We are not using the SYSOUT facility yet, we have not licensed it, but plan to, specifically to monitor WebSphere applications.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!