Message "Previous request to replace next scheduled time of Event bypassed" on ESP

Products

• ESP Workload Automation

Issue/Introduction

Got message below on the ESP Workload Automation system:
Previous request to replace next scheduled time of Event bypassed.

What does this message mean?

Environment

Component: ESP Workload Automation
Release: ALL

Resolution

When an event is scheduled, a TDR is built to cause the execution to take place at the scheduled time. When the time in the TDR is reached, the event manager will obtain the event record and examine it. The event record contains the next scheduled time for the event. That value is compared to the one in the TDR, and if they are not equal, the execution is bypassed. This behavior protects against unwanted execution in a number of possible situations. Most of these have to do with event sets which are shared among multiple copies of ESP, including, but not limited to, Primary-proxy configurations.

If an event contains wild cards in the system id, each system whose name matches the mask will build a TDR for the event. Of course, only one execution is wanted. The first TDR to be processed will "win" and will cycle and execute the event. The others will find the event already cycled and will bypass further processing (other than queuing a new TDR if the new next time is before the scan time).

If an event is edited and the scheduling criteria are changed, the TDR queue is examined and revised if necessary, but only on the copy of ESP where the transaction takes place. A TDR may still exist on other sharing systems reflecting the old criteria. Again, execution is not wanted and is bypassed.

The cycling of the event, and updating of the event set record, takes place on the main task before the switch to the event initiator subtask. If an abend prevents the successful completion of the process, we can have a situation where the TDR is still in the checkpoint data set, but the event data set has already been cycled. In such a case, the event will not be initiated a second time, and messages will be issued as described. This is a better approach than possibly allowing duplicate execution of the event. If something is missed, it can always be triggered manually. But if an extraneous execution takes place, it may be very difficult (or even impossible) to reverse the effects, assuming you even notice the problem.