Any job can generate messages. When you submit a batch job, this job could generate a message, thus holding the...
other jobs in the job queue. Not a big problem when you can answer this message, but when the processing is done by night it could become quite annoying. When you check the jobs the next morning, and find out the backup didn't run because a job submitted to the same job queue as the backup jobs generated a message and was not cancelled.
You could prevent this from happening by using the System reply list. This is a list containing message ID's and a default answer to the message. By using the command WRKRPYLE you can display and edit the list. When you want a specific job to use the system reply list, you have to change the job attributes when submitting the job, or specify so in the job description. The attribute I mention is INQMSGRPY. You can change this parameter to *SYSRPYL. When the job generates a message, it will first check the reply list. When the generated message is in the system reply list, the job will take the answer ('C'ancel, for example) and proceed. When the generated message is not in the system reply list, the default behavior will take place, in which the job generates a message, to be answered by the system operator.
MORE INFORMATION ON THIS TOPIC
The Best Web Links: Tips, tutorials and more.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Read this Search400 Featured Topic: Managing your iSeries.