OPSMVS: SVC dumps accompanying Address WTO RC = 96 RC96 and x'54' during system shutdown
search cancel

OPSMVS: SVC dumps accompanying Address WTO RC = 96 RC96 and x'54' during system shutdown

book

Article ID: 186692

calendar_today

Updated On:

Products

OPS/MVS Event Management & Automation

Issue/Introduction

Address WTO commands received RC96 during system shutdown for IPL, accompanied by SVC dumps.

Sample log output:

Time     Job Name OJobname  


10:12:07 OPSS004B OPSOSF   OPS3092H REQUEST JOBID FAILED, RC=X'00000000', FUNCTION RC=X'00000004' 
10:12:07 OPSS004B OPSOSF   OPS3092H OI SYLOG001                                                   
10:12:08 OPSS0054 OPSOSF   OPS3092H REQUEST JOBID FAILED, RC=X'00000000', FUNCTION RC=X'00000004'                          
10:12:09 OPSS004B OPSOSF   £HASP708 OPSOSF   ???????? OPEN FAILED                                 
10:12:09 OPSS004B OPSOSF   RC=13 SDB/IRWD VALIDATION ERROR                                         
10:12:09 CONSOLE  DUMPSRV  IEA045I AN SVC DUMP HAS STARTED AT TIME=10.12.09 DATE=03/12/2020       
10:12:09 CONSOLE  DUMPSRV  FOR ASID (004B)                                                         
10:12:09 CONSOLE  DUMPSRV  ERROR ID = SEQ10934 CPU00 ASID004B TIME10.12.09.2                       
10:12:09 CONSOLE  DUMPSRV  QUIESCE = NO                                                           
10:12:13 CONSOLE  OPSOSF   IEA794I SVC DUMP HAS CAPTURED:                                         
10:12:13 CONSOLE  OPSOSF   DUMPID=001 REQUESTED BY JOB (OPSOSF  )                                 
10:12:13 CONSOLE  OPSOSF   DUMP TITLE=ABEND=S013,RC=00C0,COMPON=SDSF-ESTAE,COMPID=5665-488         
10:12:13 CONSOLE  OPSOSF              01,ISSUER=ISFSTAE,SDSF ABEND ROUTINE                         
10:12:18 DUMPSRV  DUMPSRV  IEA611I COMPLETE DUMP ON hlq.DUMP.nnnn.D200312.T101209.S00001 
10:12:18 DUMPSRV  DUMPSRV  DUMPID=001 REQUESTED BY JOB (OPSOSF  )                               
10:12:18 DUMPSRV  DUMPSRV  FOR ASID (004B)                                                                 
10:12:18 DUMPSRV  DUMPSRV  ERROR ID = SEQ10934 CPU00 ASID004B TIME10.12.09.2                   
10:12:18 OPSS004B OPSOSF   AO00000A hlq.BASE.REXX(SYLOG001) ABORTED: RC = 12, LINE = 65   
10:12:18 OPSS004B OPSOSF   OPS3092H WTO return code = X'54' Not issued from a rule             
10:13:12 JES2     JES2     £HASP715 ADDRESS SPACES WAITING FOR RETURN JOBID       
10:13:12 JES2     JES2              ASID     JOBNAME                               
10:13:12 JES2     JES2              -------- --------                             
       0044     OPSOSF                                                                 
AO00000A RULE QINF.AOPER000 ABORTED: RC = 96, LINE = 365                               
IEA045I AN SVC DUMP HAS STARTED AT TIME=10.13.13 DATE=03/12/2020                       
FOR ASIDS(0051,0024)                                                                   
ERROR ID = SEQ10936 CPU00 ASID0051 TIME10.13.13.4                                       
QUIESCE = NO                                                                           
OPS3092H opsimex SNENQ001                                                               
IEA794I SVC DUMP HAS CAPTURED:                                                         
DUMPID=002 REQUESTED BY JOB (OPSOSF  )                                                 
DUMP TITLE=OPS/MVS SVC DUMP                                                             
OPS3092H ABEND X'00130000' in OPSENQ OPSENQ+X'000006A2' detected at OPSENQ+X'00000810' 

Environment

OPS/MVS

Resolution

For the above customer, the log shows the server still had a JES2 jobid, and JES2 will not end until all of it's resources are down/cleared. In addition, during the shutdown of JES2, some execs or TSO commands that were sent to servers were attempting to use JES services while it was shutting down. A REXX exec was initiated in the server asid while that server still had a JES2 jobid, the exec ran for a period of time, during which JES2 was attempted to be shutdown and couldn't because the server asid still had a JES2 jobid.

The OSFGETJOBID OPS/MVS parameter needs to set to NO before the REXX exec (that will run for a period of time and includes JES2 being shutdown) is invoked.
As far as the rules attempting to use a service that requires JES2, a check needs to be added so that JES2 is in an Active/UP state before issuing commands that require JES services.