WE received a S0C4 abed in PKWTRot a JMR ABEND on a 0C4 when trying to load an output from JES2. It is now back up running, but, was wondering if you could have a look at the DUMP file.
z/OS Team support had put in these following JES2 maintenance on the weekend.
UJ02874
UJ03238
UJ03249
UJ03630
UJ03635
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000000
TIME=00.30.49 SEQ=06463 CPU=0000 ASID=0056
PSW AT TIME OF ERROR 478D1000 00017BC6 ILC 2 INTC 0D
ACTIVE MODULE ADDRESS=00000000_000163A8 OFFSET=0000181E
NAME=PKRWTR
DATA AT PSW 00017BC0 - 00181610 0A0D1170 58F0F004
Release : 4.6
Component : JMR - JOBLOG Management & Retrieval
OA58718 from IBM
ANALYSIS: On the original print, the dataset is obtained via GETDS and GETRECs are done until all data is obtained and printed. However for any copy a POINT is done to reorient back to the start. Then GETs, POINTs, and CHECKs are done to fill the FSSM RPL chain. This occurs in routine HGSPEC in HASCPHAM. There is an error in this sequence that erroneously skips buffers causing the resulting print output to be truncated/incomplete.
The customer has the User Exit PKTXLMT applied in JMR which manages the number of lines of output to be spooled. The exit does not fail but the output is not spooled as expected. Once JMR is restarted all is good until another bad output is discovered.