Cross-posted to IBM-MAing and JES2-L A while ago I was seeking for help regarding jobs being re-queued at an EOM situation. I did not get the desired insight here, so we asked IBM for details.
We got below explanation, which IBM support found in internal documents, only, but not in any FM. I thought I'd post it here so it will be available in the archives. Q:We have a DB2 batch job that suffers from several S878-10 and finally the initiator fails completely. At the end of that a JES2 message $HASP311 appears and the job sits in the hold queue from then. Why is the job re-queued and where is that documented? Answer from IBM support (19/02/15 13:25): $HASP311 with the associated message text is always issued by JES2 in response to a request by the Initiator to requeue the job that has gone though EOM processing. This is normal behavior and is not new and not a defect. >From a JES2 perspective this has always worked this way. It is the Initiator >that is requesting the requeue of the job <AND> if there was an EOM involved >before job completion $HASP311 is issued with the corresponding text. ... and a bit more and better explanation: There are a few reasons why a job could be marked for re-execution, but the most common cause is that the initiator (where the job executes in), AND NOT THE JOB ITSELF, experiences an error, like an End-of-Memory condition which appears to be your case (the 40D indicates an out-of-storage condition during RTM processing, usually following ABEND80A or ABEND878). In that case, we turn on a flag in the control block structure to indicate that the job is eligible for restart (this is the same flag that would be set if $EJOB command was used to restart a job). JES2 requeues the job for warmstart and puts it in operator hold to prevent the job from failing recursively. During warmstart processing, JES2 will decide whether this job needs to be automatically restarted based on the setting of JOURNAL and RESTART option. The JES2 Init and Tuning Guide has more details about this under topic 1.13.2.6 titled 'Warm start considerations'. Here is an excerpt: "...If a job in execution was journaled, it is updated to indicate warmstart, and the job is queued for re-execution. If a job in execution has no journal, it is tested to determine whether restart was indicated for the job. If restart was indicated, the job is updated to remove any warmstart indications, and the job is queued for re-execution. If restart was not indicated, the job is queued for output processing." So, the action taken at next warmstart will be determined by the setting of JOURNAL and RESTART on JOBCLASS. However, you could decide to release the job ($AJ) or cancel it ($PJ) immediately. ... And an additional hint: The job is requeued back for execution (per the $HASP311 message) since JOURNALing is active. You can confirm this by issuing a $DJOBCLASS(y),LONG where y is the respective jobclass of DB2A7417 and I would expect you find JOURNAL=YES. This is working as expected. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
