JMR U0221 Abend - JMR026W FUNCTION OF SUBSYSTEM REQUEST FAILED - PKRWTR ABORTED

Products

• JMR

Issue/Introduction

07.52.53 STC35879  PKXTCLCT - T14722  , JOB41729............                             
07.52.53 STC35879  JMR012I ** WAITING FOR WORK: CLASS=B,DEST=LOCAL,AUTOSTOP=N            
09.20.48 STC35879  JMR026W FUNCTION OF SUBSYSTEM REQUEST FAILED - PKRWTR ABORTED         
09.20.48 STC35879  JMR060I ** ESTAE ENTERED IN MODULE PKRWTR   LOADED AT 0001D5C0        
09.20.48 STC35879  JMR061I ** PROGRAM COMPLETION CODE -- SYSTEM: 000 USER: 0221          
09.20.48 STC35879  JMR062I ** PSW AT ENTRY TO ABEND: 078D1000 0001C850                   
09.20.48 STC35879  JMR063I ** GPR 0-3  C0000000 C00000DD  000028ED 0002B830              
09.20.48 STC35879  JMR063I ** GPR 4-7  00000010 0002B84C  00000000 00015D28              
09.20.48 STC35879  JMR063I ** GPR 8-B  0002B830 00000033  00000038 0001CA58              
09.20.48 STC35879  JMR063I ** GPR C-F  0001BA58 000068C0  6001C086 00000000              
09.20.48 STC35879  IEA995I SYMPTOM DUMP OUTPUT  695                                      
   695               USER COMPLETION CODE=0221                                           
   695              TIME=09.20.48  SEQ=25787  CPU=0000  ASID=014B                        
   695              PSW AT TIME OF ERROR  478D1000   0001E746  ILC 2  INTC 0D            
   695                ACTIVE MODULE           ADDRESS=00000000_00016D18  OFFSET=00007A2E 
   695                NAME=PKRWTR                                                        
   695                DATA AT PSW  0001E740 - 00181610  0A0D1170  58F0F004    

There are two JMR address spaces in this plex for batch output processing.  The other address space, on a different LPAR,  continued to collect output without interruption.  As you can see above there's a time gap from 07.52.53 to 09.20.48 in the failed JMR address space, where there was no activity in the JESMSGLG.  

Environment

Release : 4.6

Component : JMR - JOBLOG Management & Retrieval

z/OS 2.3 and above

JES2

Cause

The customer experiences the following error condition generated by JES2

$J14

JOE CHANGED WHILE JOA ACTIVE

JES2 detected an update to a real JOE while an artificial JOE (JOA) was locked by the $DOGJOE macro. JOE cannot be updated without $DOGJOE serialization.

This results in the JMR started task failing with a U0221 when attempting to write a job to the JMR HOLD file.

Resolution

Circumvention is to set your JES parms with PRYORATE=0

Looks like new IBM JES apars are causing the problem, they have an IBM set of apars (documented in issue ) to apply to resolve issue

OA57457: $HASP497 ISSUED AT STARTUP WHEN OUTPUT PRIORITY AGING IS ACTIVE

and

OA58595: IN SUPPORT OF OA57457

 

APAR OA57457 prereq's (and sup's) for FMID HJE77C0:

Pre's: CA58595

Fix information

Fixed component name JES2

Fixed component ID5752SC1BH

Applicable component levels

R7A0 PSY UJ02013   UP20/02/12 P F002

R7B0 PSY UJ02011   UP20/02/12 P F002

R7C0 PSY UJ02012