When sending a global condition with an order date reference to Control-Ms in different time zones, a problem can arise when target Control-M installations have an earlier current working date than the source Control-M (as a result of the time zone changes). Such a situation can be problematic due to the following:
A global condition with Order as its date reference is assigned a date according to the Control-M that triggers its creation.
During New Day processing cleanup, when Control-M detects an already existing condition having the new working date (month and day), it logically assumes that the condition is a holdover from the previous year because the production jobs that might create this condition during the new working date have not yet been run, and it deletes the condition. In the event of a temporary communication failure between Control-M/EM and a Control-M installation, global conditions are accumulated and transmitted when communication is resumed.
EXAMPLE
Assume the following:
New day processing in both Rome and San Francisco runs at 6:00 AM local time.
At 8:00 AM in Rome, a job creates Global Condition: Glo1-RecReady with an order date and sends it to San Francisco.
At 9:00 AM in San Francisco, a job requiring that condition awaits submission.
The following occurs at new day in Rome on August 4th.
August 4th at 6:00 AM in Rome: New day processing runs.
August 4th at 8:00 AM in Rome: Global condition Glo1-RecReady is added with the date 0804. This global condition is then sent to San Francisco with a date of 0804 (the date the condition was created). However, the current working date and time in San Francisco when it receives the global condition is August 3rd, 23:00.
August 4th 6:00 AM in San Francisco — New Day processing runs. During maintenance, it assumes that the Glo1-RecReady condition dated 0804 was added last year (because jobs that might have added the condition today did not run yet), and it deletes the condition.
August 4th at 9:00 AM in San Francisco— a job in San Francisco waiting for the condition Glo1-RecReady dated 0804 is not submitted because the condition is already deleted.
The following examples illustrate how global conditions behave in a complex Control-M network. They are based on information the following table.
Prefix
From Control-Ms
To Control-Ms
GL1
ROME
NY,LA,SF
GLALL
*
PARIS, SYDNEY
GLNY
NY
*
GL2WAY
HQ,CENTER1
HQ,CENTER1
If the GL1_JOB_END prerequisite condition is added in Control-M ROME, the same condition is automatically added in Control-M installations NY, LA, and SF. The Prerequisite Conditions window displays four different conditions called GL1_JOB_END, each belonging to a different Control-M (ROME, NY, LA, and SF).
However, if this condition is added in any Control-M other than ROME, it is not automatically duplicated in other Control-M installations. If Control-M NY adds the condition GL1_JOB_END, it will not be automatically added in ROME (or anywhere else). If the GL1_JOB_END prerequisite condition is deleted in Control-M ROME, Control-M/EM deletes the GL1_JOB_END prerequisite condition in Control-M installations NY, LA, and SF (if the condition exists there).
If the GL1_JOB_END prerequisite condition is created in Control-M ROME but Control-M SF is disconnected or downloading, Control-M/EM creates this condition in NY and LA only, and sends the change to SF when SF is able to receive updates.
If the GLALL_OK prerequisite condition is added or deleted in any Control-M, the condition is automatically added or deleted in Control-M installations PARIS and SYDNEY. The asterisk (*) in the From Control-M field indicates all Control-M installations.
If the GLNY_OK prerequisite condition is added or deleted in Control-M NY, the condition is automatically added or deleted in all other Control-M installations.
If a prerequisite condition beginning with the GL2WAY prefix is added or deleted in either Control-M HQ or CENTER1, the same operation is performed on the corresponding condition in the other Control-M.
