Pre-Ordering Jobs

As a result of differences between time zones, the working day on a specific Control‑M logical date can be a period of up to 48 hours, because the actual length of time between the beginning of the day on a date in the furthest East time zone and the end of that day in the furthest West time zone can reach almost 48 hours. A job in one time zone may be dependent on the outcome of another job in a different time zone. The ODATE of each job appears to the users in two different time zones to be identical, but in the absence of some adjustment to take account of the different time zones, one of the jobs may in fact run on what appears at one site to be a different work day than the work day at the site where the other job runs.

Because of this, it is necessary to pre-order jobs, in order to ensure that they run at the time the user wants.

In the case of a time zone job, the logical date is shifted to the actual date defined in the TIME ZONE parameter of the job, so that the logical date begins at the New Day time in the distant time zone and ends at the next New Day time in that same time zone.

The New Day procedure is executed at the New Day time at the site where Control‑M is running. The New Day procedure orders all pre-ordered jobs for all time zones. However, for the Time Zone feature to operate, the Active Jobs file must contain jobs with ODATES that may start during the next 24 hours. The New Day procedure therefore orders all jobs with Time Zone parameter settings of the next working day. This ensures that those time zone jobs will be in the Active Jobs file, ready to be made eligible when the new ODATE arrives. Jobs without Time Zone parameter settings are ordered for the current ODATE as usual.

All jobs that are pre-ordered have the ODATE attribute RUN, because in all Time Zone jobs Control‑M automatically treats ODATE as a RUN attribute rather than a VALUE attribute. This ensures that they do not run on the wrong date.

Time Zone jobs are pre-ordered according to the following rules:

• If a SMART Table Entity contains a Time Zone parameter setting, all jobs in the SMART Table will be pre-ordered for ODATE+1, even if they do not contain Time Zone parameter settings.
• If the SMART Table Entity does not contain a Time Zone parameter setting, no job in it will be pre-ordered for ODATE+1, even if one of the individual jobs in it contains Time Zone parameter settings.
• If a Time Zone job is not in a SMART Table, it will be pre-ordered for ODATE+1.

The activation of the pre-ordering feature is controlled by the GDFORWRD parameter in the CTMPARM member. The default value for GDFORWRD is Y. When GDFORWRD is set to N, pre-ordering does not occur, and all jobs are ordered for ODATE, even if they are Time Zone jobs.

A user who wants to change the ODATE attribute to RUN can do so, as follows:

• When a job is ordered from the Job List Screen (Screen 2), the confirmation window contains the parameter WAIT FOR ODATE. The default setting for this parameter is N, but if the user changes this to Y, the ODATE of the job has the attribute RUN.
• When a job is ordered using the CTMJOB utility, the ODATEOPT parameter can be changed to RUN. This also changes to RUN the attribute of ODATE in the New Day procedure.