Synchronization problem in the processing order between MVSLOG and SOPMVS
search cancel

Synchronization problem in the processing order between MVSLOG and SOPMVS

book

Article ID: 55170

calendar_today

Updated On:

Products

CMDB for z/OS NetSpy Network Performance NetMaster Network Automation SOLVE NetMaster Network Management for SNA NetMaster Network Management for TCP/IP NetMaster File Transfer Management SOLVE:Operations Automation SOLVE:Access Session Management SOLVE:FTS

Issue/Introduction

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.

 

Environment

Release:
Component: SOPMVS

Resolution

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.