How to set up a "DELAY" during a process flow that processes past midnight?

[Anon Anon]

In our UC4 V8 environment, we have an OVERNIGHT BATCH process that begins at 21:00.  This process runs until approximately 10 or 10:30, and then waits until 01:00 to start up again.  At that time, it will run to completion between 02:00 and 04:00, if everything goes smoothly.
We are trying to replicate this same behavior in V10, and I've found that putting an "EARLIEST RUN" setting of 01:00 will make the process flow perform the "wait" behavior we are seeing in V8.  However, since it goes past midnight, I have to set the "earliest" to a "Current date +1", otherwise Automic calculates that "01:00 already happened, so go ahead and run the task."
Here's the problem:
Very rarely, we sometimes end up starting the process after midnight.  If this happens, with the "Earliest" setting of "Current date +1", that means that the process flow will hold until the NEXT night at 01:00, and this would cause the OVERNIGHT BATCH process not to complete for the previous calendar day.

Does anyone have any insight as to how this situation can be fixed?  In V8, we have a separate, stand-alone, job that runs at 1am to simply set a flag in a database to YES, indicating that it is now after 1am, and the job can process any time all of the dependencies are met.  The flag is checked via job conditions.  The only issue there is if the stand-alone job fails for any reason, that flag won't be set and the dependent jobs will never run.  (This is considered an acceptable risk.)  I would like to design our V10 environment so as not to have to set that flag or set up extra job-conditions just for this rare possibility of the OVERNIGHT BATCH process not starting before midnight. 

Any insight or suggestions would be most welcome.

Thank you in advance for any help that you can provide.

[Anon Anon]

I’m assuming that the process that you are describing is a single process flow and the “wait”  is performed by some task’s “Earliest start” Property.  I’d suggest that you consider using a Sync object on this task instead.  The process would go something like this:

1. Set a Sync at the beginning of the overnight process to “wait”.

2. Task that is to start after midnight has a Sync Start Action of “go” Else Wait.

3. Place an object on the Schedule to execute at 1:00 that sets the Sync to “go”.

We do this for a number of processes and it has been quite successful for us.  Some of our processes check statistics, dates/time or other information before setting the Sync to “go” to handle exception process such as late starts, long execution or process failures.  We are on OM V8.

[Anon Anon]

Thank you, Mark... unfortunately, I have no experience with using Synch objects, and as I read through the provided online documentation, it's not helping very much.  Can you perhaps provide some screen shots to better illustrate what you've done?  If not, I understand and will continue to try and figure this out independently.
Again, thanks for your help and direction.  It is appreciated.

[Anon Anon]

I will search out something for you, hopefully today.

[Anon Anon]

Thank you!

[Pete Wirfs]

I'm using quite a few SYNC objects in V9.  Very useful tool.  However in some cases I would also consider just using a static variable;  1AM job sets the contents of a static variable called TIME.TO.RUN.JOB.X to YES.  Job X has a precondition that causes it to wait until this variable says YES.  And when job X runs, a postcondition sets the static variable to NO.

Oops, I just re-read your post and I now see this is exactly how you DON'T want to do it.  However in my mind a SYNC object is just a fancy way to set and check flags, with many of the same risks.  What SYNC can do that a static variable can't, is properly manage multiple concurrent tasks at the same time.

[Anon Anon]

Adrian:

Do you still have a V8 System available?  I could attach or email a XML Export/Import file of a set of objects that demonstrates Sync usage for your situation.  This for me would be much easier than cutting and pasting (and as they say, "it's all about me).   ;)

Pete:

The nice feature of the Sync over a Variable (at least under V8) is that the detection of the changed state is automatic.  If a Variable was used there would have to be some type of periodic reading of the value such as with an Event.

[Pete Wirfs]

In V9 preconditions, you can use "RE-EVALUATE IN # MINUTES" which causes periodic reading.  Makes me curious to know if SYNCs are checked more frequently than every minute?

[Anon Anon]

Mark,
Yes, we are still running a V8 environment here, and will be until we are fully transitioned to V10... it's AM, though, and not OM.  Not sure if that will make a difference or not.

Pete,
Thank you for your information, too.  If we eventually HAVE to go to using variables, it won't be the end of the world, but we are hoping for a solution that's a bit more "out of the box"... the less scripting we have to do, the better... :-)

Thanks!

[Anon Anon]

Pete:

Our experience say that it is.  In most cases, when I'm watching, it is often in mere seconds (and less) that the state change is detected and the waiting tasks start to execute.

[Anon Anon]

Adrian:

I've no experience with AM, so here's the file.  At worst case you can just view the XML to see the various attributes.

I can still do screen prints or answer specific questions it you need additional help.

For testing purposes this was all placed into a single process flow, including the Script that "releases" the waiting tasks.  This Script would normally be added to the schedule to execute at the desired time.

As with most everything in UC4 there are multiple methods to reach a desired result, this just happens to be similar to what we normally when addressing a situation like yours.  (This is my disclaimer and I'm sticking to it!)

Attachment(s)

uc4_export.xml   11 KB 1 version

[Pete Wirfs]

I found this very interesting today and wanted to expand my knowledge of what SYNCs can do, so I built some sample code in V9 of how I would probably do this with a SYNC.  The attached xml file contains three objects;

(1) SYNC.JOB.X
(2) SCRIPT.SET.JOB.X.TO.GO
(3) JOB.X (waits on SYNC state of "GO", and sets to "WAIT" upon successful completion)

Pete

Attachment(s)

uc4_export_from_pete.xml   7 KB 1 version

[Anon Anon]

Thank you both!  I've imported both of these into my V10 environment, and will work with them some more on Monday... will try to understand and let you know how it goes.

Thanks again!

[Anon Anon]

So far, so good.  There's a bit of an issue with this one, in that my scheduled job is supposed to wait past the default "period turnaround", but I think I've managed to work around that.  Will find out tonight when this runs in my dev environment.

Thanks again for all of your help!