Daylight Savings Time Ending in North America

Document created by Marysue Employee on Oct 31, 2017
Version 1Show Document
  • View in full screen mode

It's THAT time of year again--bit of chill in the air and time to turn the clocks back. Technical document TEC1786752 in Support Online has this information (copied here to save you from clicking a link :-) ):

CA 7 is very flexible in its scheduling abilities. When the CPU clock time is reset (e.g., Daylight Savings Time, "Spring forward Fall backward") there are usually no issues. However, there are possible CA 7 job requirement considerations when resetting the CPU clock time.

Job requirements are checked for initial satisfaction when the dependent job comes into the request queue. The check made is "has the required job run since the dependent job last ran and within the satisfaction lead time (LEADTM) if this is non-zero. The times that are compared are the jobs LAST RUN DATE/TIME which is the start time from the last good run (you can see this date and time by doing an LJOB command).

 

Moving the CPU clock time forward:
If the clock is set forward, you will want to pay close attention to any jobs that run during this time frame with an non-zero LEADTM on the connection. There is a CA 7 command you can use to list any jobs with a job connection that may have been affected by the time change. The LDTM command displays an analysis of outstanding requirements for jobs in the request queue that involve fixed (non-zero) LEADTM:
LDTM,JOB=*,OUTAGE=1
This command should be done after the CPU clock time has been reset and repeated for the timeframe from your longest hard-coded LEADTM. In other words, if the largest LEADTM you have on a job is 12 hours, you will repeat this command every hour for 12 hours. All jobs currently in the request queue will list in the output, but only those that show that the one hour outage could affect them will show the requirement(s). Any job that lists its requirements with this command is a job that you will want to examine to see if a manual posting will be needed.
As an example:
JOBB requires JOBA with a 1 hour LEADTM
- JOBA starts at 01:45 and ends at 01:50
- CPU clock is set ahead at 2:00 to be 3:00
- JOBB enters the queue at 3:05--the 'look-back' time has been exceeded and is not initially posted.

 

Moving the CPU clock time backward:

When the CPU clock time is moved back, there are also possible considerations for job requirements. Any jobs that run during the one hour window after the CPU clock time reset that are requirements for other jobs may need to be noted. Jobs that match the following description will need to be analyzed:
JOBB requires JOBA with a 0 LEADTM
- JOBA starts at 01:15 and ends at 01:20
- CPU clock time is set back at 2:00 to be 1:00
- JOBB enters the queue at 01:05 and runs (as it should)
JOBB's LAST RUN DATE/TIME is now 'before' JOBA's run (after these runs JOBA's LAST RUN DATE/TIME is yyddd at 01:15 and JOBB's LAST RUN DATE/TIME IS same yyddd at 01:05) so the next time into the queue, JOBB says JOBA has run since it last ran therefore it is satisfied when it should not be.
You can use the following command to list any jobs that ran during the timeframe of the CPU clock reset:
LRLOG,SPAN=(yyddd,hhmm,yyddd,hhmm)
with the yyddd being the Julian date of the time reset and the first hhmm being 5 minutes before the time reset and the second hhmm being 1 hour and 5 minutes after the time reset.
The jobs listing in the output of this command should be examined to see if any match the description in the above example. If you find jobs that match the example during this timeframe, you can put a one-time user requirement on the dependent job (in the example it would be JOBB) that is descriptive (e.g., CHECK JOB REQUIREMENT STATUS--TIME CHANGE CONSIDERATIONS).

1 person found this helpful

Attachments

    Outcomes