IBM i QuickTip: Understanding the Non-Exclusive OR in Robot/SCHEDULE Reactive Jobs

If you’re setting up IBM i reactive jobs in Robot/SCHEDULE, there’s one thing you must know about an entry’s Reactive Jobs’ list.

Robot/SCHEDULE Or conditions are not exclusive Ors

Here’s why it’s important to understand this fact and how it can mess up a Robot job stream, if you don’t understand it.

Robot/SCHEDULE reactive jobs are great tools. You use them to insure jobs run in order and that one job doesn’t complete before another, some examples of how they are used include:

• Insuring Job C doesn’t start until Job A completes
• Insuring Job C doesn’t start until Job A and Job B complete (an And condition)
• Insuring Job C doesn’t start until either Job A or Job B completes (an Or condition)

The first two conditions are easy to understand and set up. But in order to set up the third reactive job, you again have to understand this fact.

Robot/SCHEDULE Or conditions are not exclusive Ors

This is something I hadn’t thought about until it recently bit me, so let me go through an example to show how it affects your SCHEDULE processing

Suppose I have a SCHEDULE job entry whose reactive jobs list looks like this.

If this case, I’m telling SCHEDULE not to launch TESTJOE4 until either TESTJOE3 or TESTJOE2 completes normally (React to Sts = C). So far, so good. TESTJOE4 is dependent on one of these two jobs completing. If either one finishes, the job starts up. I want to insure that TESTJOE4 runs only once in my job stream, using TESTJOE2 or TESTJOE3 as the trigger.

A computer pro familiar with using nested IF statements might think that SCHEDULE first checks TESTJOE2 to see if it ran and if TESTJOE2 hasn’t run, it then checks TESTJOE3 to see if it ran. Many computer pros might assume this reactive job setup is an exclusive OR situation. TESTJOE4 runs if either TESTJOE2 or TESTJOE3 runs, not both.

The reality is Robot/SCHEDULE is that using an OR in a reactive job setup is really a non-exclusive OR situation. That is in a setup like this, Robot/SCHEDULE performs the following logic to determine whether to run TESTJOE4.

1. Check to see if TESTJOE2 has completed. If so, run TESTJOE4.
2. Regardless of whether TESTJOE2 has completed, check to see if TESTJOE3 has completed. If it has, run TESTJOE4.

In a scenario where both TESTJOE2 and TESTJOE3 have run, SCHEDULE will run TESTJOE4 twice. So rather than this scenario being an exclusive OR (TESTJOE4 runs only once if either TESTJOE2 or TESTJOE3 completes), it becomes a non-exclusive OR (TESTJOE4 runs whenever TESTJOE2 or TESTJOE3 completes, regardless of whether it ran before). So if you set up a job stream using an OR statement, you can easily run multiple copies of jobs if the reactive list isn’t set up right. 

This is a subtle nuance in SCHEDULE and one you need to be aware when scheduling jobs. Currently, Robot/SCHEDULE doesn’t have the ability to create both exclusive and non-exclusive reactive jobs in its Reactive Jobs’ lists. It can only create non-exclusive OR situations. There is currently no way to schedule exclusive OR situations using the Reactive Jobs list. You would need to set up a different reactive jobs list to create the exclusive Or scenario. The reactive job list shown here won’t do it.

AFAIK, Help/Systems is not planning on implementing exclusive ORs in Robot/SCHEDULE (an XOR code, perhaps). I might humbly suggest that would be a great enhancement to add to a future release.

Note: if anyone at Help/Systems or anywhere knows of a way around this scenario, please post or email me at mailto:joe@joehertvik.com and I’ll evaluate and post a solution in another blog post.

**************************************************

Follow Joe Hertvik on Twitter @JoeHertvik. You can also add Joe to your professional network on LinkedIn by clicking here.