Waiting for the Weekend

OK, we’re all guilty of waiting for the weekend in our regular working week, but what if we want our daily batch to wait for weekly work?

Well that’s not a problem if your daily and weekly run on the same day, but what if your daily runs on work days of the week, and your weekly runs on Saturday?  With the normal dependency rules we know that we can’t wait for something in the future, so it must be impossible right?  Is your only choice to manually make it wait each week?  Let’s see

You might be surprised to find that it’s actually easy to do, providing you know about the feature needed to do it.  First let’s look at the two applications we want to make wait for each other.   The daily processing has a rule like this –

Assuming Monday to Friday are normally work days, and Saturday and Sunday are free days, this will normally run Monday to Friday.

Then the weekly looks like this –

This will run every Saturday, nice and simple, but not helpful when it comes to making dependencies.

Despite not being widely known it has always been possible to make an operation dependent on an application in the future.  The bit that is not so widely known is that dependencies are resolved FROM the Operation input arrival of the successor TO the Application input arrival of the predecessor.  If the Operation does not have a specific input arrival time, it inherits the input arrival of the Application in which it resides.  So in theory you could set the Operation Input arrival to some time in the future to allow it to connect with an Application that ordinarily it couldn’t.  However this technique can have unwanted side effects with calculating planned start times and from version 9.1 onwards is no longer recommended.

Though, with the advent of dependency resolution criteria, it is no longer recommended to use Operation IA for dependency resolution, it is useful to know that this happens, as setting a time dependency that uses the Operation input arrival on an Operation with External predecessors also can inadvertently impact dependency resolution.  There is now a BATCHOPT keyword called OPIADEP that can be used to turn off the use of Operation Input Arrival for dependency resolution either across the board (OPIADEP(NO)) or just for time dependent operations (OPIADEP(TIME)).

The good news is that from version 9.1 a new feature was added that allows different dependency types.  Now instead of just a single rule for dependency resolution, you can instead choose from 4 different mechanisms for how to resolve a dependency.

The four types are now –

• C – Closest preceding. This is the traditional mechanism that will only recognize an external predecessor if it has the same input arrival or earlier.  Note that an external predecessor to the same application is slightly different as it ONLY looks for earlier input arrival times.
• S – Same day. This is a simple way to look forward in the same day.  It works by looking for predecessors ONLY on the same input arrival day.  It will look for an earlier occurrence first, but if one is not found it can match to an operation later in the same day.
• R – Relative range. This takes the input arrival of the successor operation as the start point for defining a range in which to look for predecessors.  The range can be limited from 167  hours and 59 hours before the operation to 167 hours 59 minutes after.  One really helpful use of relative range is to specify a blank FROM range and a TO range of 1 minute before.  This effectively works like a “closest preceding” but avoids the same time, avoiding accidental dependency loops when trying to wait for previous instances of a group of applications.
• A – Absolute range. This can set an absolute range of input arrival times from 7 days before to 7 days after the input arrival day of the successor operation.

For this particular challenge Absolute range is the best option, but how do you set it?

To add an external dependency you must go to the Predecessors option for the operation, nothing new there, but you might notice some new fields on that display that you might not  recognize.

The three new columns here are –

• Pre Typ – Predecessor Type. This was introduced at version 9.3 and allows dependencies to be made either to Operations (O), which has always been the case, and also to a whole Application (A) which allows 1 operation to wait for everything in an application to complete.
• Dependency Resl – Dependency Resolution type. This was introduced at 9.1 and is the new feature we are discussing in this blog.
• Mand – Mandatory predecessor. Also introduced at 9.1, this is an additional safety mechanism that ensures an operation will not run if the specified predecessor was not found within the criteria.  For planned mandatory predecessors this will flag an error in the current plan extend process, for dynamic mandatory predecessors it will make the operation wait until the predecessor arrives.

To access the new dependency types, enter T next to the dependency to access this panel –

So, to let a job on Friday wait for a job on Saturday that has an IA of 13:00, you could set a range FROM 13:00 for 1 day after, TO 13:00 for 1 day after.  But also consider that in some cases your last working day of the week might be Wednesday e.g. Christmas or Thanksgiving.  So the TO range needs to cover 3 days.

It’s also important to understand that external dependencies are actually resolved on the Long Term plan, so you can make these changes, run a Long Term Plan Modify All and then see the evidence of your changes on the Long Term Plan online.

To illustrate this I have set my calendar like this –

So w/c October 23^rd is a 5 day week, w/c October 30^th is a 4 day week and w/c November 6^th is a 3 day week.

Then a ran a long term modify all to apply my new dependency type to the plan and used option 2.1 to browse the applications I was interested in.  To check which occurrences connect to each other you can Browse the daily application and select option 2 to see the application dependencies (or enter B.2 as a line command).

For Friday 27^th of October I could see it connected to the weekend on the 28^th –

Equally Thursday 2^nd of November is connected to the weekend on the 4^th and Wednesday 8^th of November is connected to the weekend on the 11^th.

However, if you also check on the 25^th and 26^th of October you will find they are also connected to the weekend.  That’s because looking ahead for 3 days to handle holidays on Thursday and Friday can cause all three week days to connect to the weekend if they are all scheduled.  This is NOT what we wanted

So we need something a little smarter to handle the variable number of working days in the week.  We handle this by adding a dummy intermediary application that ONLY runs on the last working day of the week, make the daily dependent on the intermediary using same day dependencies, and then the intermediary has the 3 day Absolute dependency to the weekend.

In a normal week it would look like this.  DEMO#WORKDAYS runs Monday to Friday,

DEMO#LASTWORKDAY runs ONLY on Friday so only Friday’s DEMO#WORKDAYS waits for it, and then DEMO#LASTWORKDAY waits for the a DEMO#WEEKEND following in the next 3 days.

When Friday is a free day, it would look like this.  DEMO#WORKDAYS runs Monday to Thursday, DEMO#LASTWORKDAY runs ONLY on Thursday so only Thursday’s DEMO#WORKDAYS waits for it, and then DEMO#LASTWORKDAY waits for the a DEMO#WEEKEND following in the next 3 days.

And finally when Thursday and Friday are free days, it would look like this.  DEMO#WORKDAYS runs

Monday to Wednesday, DEMO#LASTWORKDAY runs ONLY on Wednesday so only Wednesday’s DEMO#WORKDAYS waits for it, and then DEMO#LASTWORKDAY waits for the DEMO#WEEKEND following in the next 3 days.

Your new intermediary application, DEMO#LASTWORKDAY would have a run cycle rule like this –

All it contains would be a single dummy operation on a non-reporting workstation, which in turn would be dependent on the Saturday job.  It would use an absolute range dependency like this to be able to look ahead 3 days to the weekend –

Finally your daily job would need to be dependent on your new intermediary Last Working Day job, as a Same scheduled date dependency and everything should connect up –

Now when we look at the Long Term Plan for w/c October 23^rd, the 5 day week, we can see that for Monday to Thursday the DEMO#WORKDAYS application is showing no predecessors but Friday is

showing 1, DEMO#LASTWORKDAY is showing 1 predecessor and one successor, and DEMO#WEEKEND is showing 1 successor.   Just as we would expect.

If we then look at the detail for DEMO#LASTWORKDAY we can see that it will wait for the weekend application and the workday application waits for this one, which in turn means that the last instance of the daily job in the week will wait for the weekend job.

We can see the same picture work shorter working weeks.  Here is the 3-day week showing a similar picture with the daily jobs for Monday and Tuesday NOT waiting, but the Wednesday job waits for the Last Working Day intermediary and by implication also the Saturday job.

So not so impossible after all, and you don’t have to work late on Fridays to add all the missing dependencies for the weekend or spend hours with similar issues every month end.  It might take a bit of getting your head around the new concepts, but worth it in the long run.