Synchronization problem in the processing order between MVSLOG and SOPMVS
Article ID: 55170
Updated On:
Products
Issue/Introduction
Desciption:
There is a synchronization problem in the processing order between MVSLOG and SOPMVS. Some messages are trapped by SOPMVS, coming from MVSLOG, and actions are taken but the messages on SOPMVS log are not synchronized with those on MVSLOG. Therefore, actions are not done in the proper order.
Solution:
Solve:Operations Automation (i.e : SOPMVS) is using a sub-system to trap MVS messages.
In case of heavy traffic, it is possible some messages are processed in random order (i.e : Start message is analyzed after End message). This case is not unusual.
In Eventview, the message group can be used to group all messages before submitting an action.
When the messages are defined as Status Monitor messages (i.e : in Resourceview), there is no such equivalent feature. One of the solutions consists of using an automation process started by the reception of each of messages of the group. The process contains one or more steps. The first step starts an NCL procedure which inserts the message just received in a vartable. Then it scans for all messages of the group. If all messages are found then the NCL proc returns a RC=0 which will be tested by the next step of the process for an action.
For example, $HASP373 (JES2 start message) and $HASP395 (JES2 end message) are required to submit an action. If $HASP395 is received first, then the NCL procedure inserts the message in the vartable and searches for $HASP373 and $HASP395. The RC is set to 8 (condition not met) on the return of the NCL call.
If $HASP373 is received next, then the message is added in the vartable by the NCL procedure which will find both $HASP373 and $HASP395and return RC=0 (condition met). The action can be submitted either by the NCL procedure or by the process.
Environment
Component: SOPMVS
Feedback
