These are some of my old notes on where things occur in the 
life of a step, at a fairly high level.  I believe they
are all still valid, and may help understand some of the
various issues raised in this thread, but I'm certainly
open for updates, especially if there is anything other
than DSENQ that occurs between INITTIME and ALOCTIME. 

There are four timestamps in the life of a step that are
relevant, and three delta durations between them.

INITTIME to ALOCTIME  - For JES2 First Step, Data Set Enqueue
                        Usually short, unless you have a conflict.
                        Called DSENQTM in MXG.
                        If the job is cancelled here, the ALOCTIME
                        will not be populated.
                        CPU Time is recorded in the Initiator CPU 
                        time fields (CPITCBTM/CPISRBTM).

ALOCTIME to LOADTIME  - When Catalog Search (no VOLSER in your JCL)
                        and/or Volume Search (for the DSNAME),
                        and the allocation of datasets occurs.
                        Long during an allocation recovery, or
                        during an HSM recall, can be long if you
                        have lots of new datasets and poor logic
                        in your ACS rules. 
                        CPU Time is recorded in the Initiator CPU 
                        time fields (CPITCBTM/CPISRBTM).
                        

LOADTIME to TERMTIME  - Your program is finally swapped in and you
                        get to execute your first statement, i.e.,
                        OPENs don't occur until after LOADTIME.
                        CPU Time is recorded in the program CPU time
                        fields (CPUTCBTM/CPUSRBTM/CPURCTTM/CPUIPTTM/CPUHPTTM).

TERMTIME              - Your program ends.
                        Now the step termination SMF record(s) must be prepared
                        and written.  If DDCONS(YES) is still specified in your
                        SMFPRMxx member, for steps with thousands of DDs, there
                        can be significant CPU time burned here, and it is also
                        recorded in the Initiator CPU time fields 
(CPITCBTM/CPISRBTM).
                       


The class of "Execution JCL Errors" that fail (or are cancelled) during DSENQ 
processing will have both their ALOCTIME and LOADTIME fields unpopulated;
steps that fail during Allocation will have an ALOCTIME but their LOADTIME
will be unpopulated in their SMF 30 records.

The other class of JCL errors, that occur prior to the job inititation,
are found in the Reader/Interpreter or (more common) in the JES Converter
where JCL syntax errors are found.  For those jobs, the job was never even
initiated, so there is no type 30 records, but the JES Type 26 record will
have its STARTIME missing (nulls), so you can track "Pre-Execution JCL Errors".
 (These ABEND='JCL' errors have instantaneous turnaround to the user, 
  and thus should not be included in your Job service statistics.
  Jobs that had an "Execution JCL Error" did wait for scheduling, 
  and were initiated, so they should be included in your job service 
statistics.)



Now, with regard to postings in this track, the "Execution JCL Errors" that
failed during allocation that will have an SMF record with ALOCTIME populated 
and
with LOADTIME missing (nulls), but the OPEN ABENDs can only happen after the
allocation of all DDs in the step, and only after the program began to execute.
 
 
Barry Merrill

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to