OPS8320O/OPS8300O with RC 48 returned to OPSLOG ARCHIVE job
Article ID: 233438
Updated On:
Products
Issue/Introduction
Sometimes the OPSLOG ARCHIVE job can end with RC=08 getting the below error message:
06.00.01 JOB09118 ---- FRIDAY, 28 JAN 2022 ----
06.00.01 JOB09118 IRR010I USERID OPSOSF IS ASSIGNED TO THIS JOB.
06.00.15 JOB09118 ICH70001I OPSOSF LAST ACCESS AT 04:17:59 ON FRIDAY, JANUARY
06.00.19 JOB09118 ÅHASP373 OPSSARCH STARTED - WLM INIT - SRVCLASS BAT_NORM - S
06.00.19 JOB09118 IEF403I OPSSARCH - STARTED - TIME=06.00.19
06.00.19 JOB09118 +OPS8320O OPSLOG () archive creation completed, MAXRC=48
06.00.20 JOB09118 - --TIMINGS (MINS.)--
06.00.20 JOB09118 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK
06.00.20 JOB09118 -OPSSARCH ARCHJOB ARCHJOB 08 549 .00 .00 .01
06.00.20 JOB09118 IEF404I OPSSARCH - ENDED - TIME=06.00.20
06.00.20 JOB09118 -OPSSARCH ENDED. NAME-GOHOL TOTAL CPU TIME=
06.00.20 JOB09118 ÅHASP395 OPSSARCH ENDED - RC=0008
...
OPS8324I ARCHIVE DSNAME(...dsname...) START(yyyy/mm/dd hh:mm) END(yyyy/mm/dd hh:mm) UNIT(...) SUBSYS(...)
OPS8300O RC=48, The requested message is past the lowest message number
OPS8330I OPSLOG archive creation request processing completed
...
What is the meaning of this RC=48 and how to handle it.
Environment
Release :
Component : OPS/MVS
Resolution
The Error Message :
OPS8300O RC=48, THE REQUESTED MESSAGE IS PAST THE LOWEST MESSAGE NUMBER
indicates that the last message number is greater than the lowest message number. This message is normally related to a bad record or a record with a number sequence out of order.
This problem may occur occasionally when OPSLOG contains an old message and it falls within the scope of the archiving times, which can cause some problems with the archiving process . This is because the ARCHIVE process is attempting to sequentially read the message numbers and one is out of alignment. The problem can sometimes rectify itself whenever the message number scrolls off.
So, if a new achive job is executed and it ends correctly then probably all is fine and nothing should be done.
If the problem is re-occurring again at the next ARCHIVE job, from OPSVIEW option 1 for OPSLOG the command
D MSGNO
can be issued to see the last message number of the online OPSLOG and check the number sequence, if the numbers are in order and also if it's near 2GB. Also the value BROWSECHECKNUM parm in 4.1.1 OPSVIEW can be checked to see if it's higher than 2GB, and this is causing the problem.
In this case a new OPSLOG should be allocated.
Feedback
