OPSREQ Command Experiences Delays During Busy Times

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

There are occasional delays that occur, during busy times, up to 90 seconds for OPSREQ requests.   Normally, the requests are handled instantaneously (less than a hundredth of a second).  

02:11:34.9849  JOBID1      OPS0997T   *-*  57:     "opsreq" CICS_RULE JOB
02:11:34.9860  JOBID2      OPS0997T   *-*  57:     "opsreq" CICS_RULE JOB
02:11:34.9865  JOBID3      OPS0997T   *-*  57:     "opsreq" CICS_RULE JOB
02:11:36.1779  JOBID4      OPS0997T   *-*  57:     "opsreq" CICS_RULE JOB
02:12:01.7123 OPSSxxxx   OPS3092H opsreq ruleid   JOBID1
02:12:01.7253 OPSSxxxx   OPS3092H opsreq  ruleid  JOBID2
02:12:01.7511 OPSSxxxx   OPS3092H opsreq ruleid   JOBID3
02:12:01.7634 OPSSxxxx   OPS3092H opsreq ruleid   JOBID4

When this happens it is a cluster of requests and then suddenly they run all at once.  

Cause

In this case the OPSLOG showed that there were 20 OSF servers defined and all were busy processing the EXEC calls from the same rule.  

Resolution

The options to resolve this are to examine the EXEC calls to see if they can be combined to run in the same server or to use TSP (priority servers) to schedule work that needs to run immediately.  

If assistance is needed to correct, open a support case and provide a tersed copy of the archived OPSLOG, along with any involved rules.