This is helpful to see how the scheduler is working. I foudn this because I was having issues with my scheduler. 

However, it does not address this cryptic statemet in the documentation for version 2019:

"There are some limitations to scheduling abilities. For example, if a business host is started by the scheduler but cannot be stopped by the scheduler, this is because the business host is in the middle of a synchronous call. The business host must wait for a response to the call before it can be stopped."

Essentially, the scheduler is useful only for known downtimes. If any job can't be stopped within a timeout period (10 seconds) of the Ens.AlarmResponse -- say it's reading a large file -- then the AlarmResponse is missed, and the ScheduleService doesn't try again.  The job stays alive, and the next file/message is processed, even after the STOP time. It's like an alarm clock with no snooze button, that is shut off by your roommate after 10 seconds.  Who then leaves.

The documentation also says "Use of the schedule setting is not intended or designed as an event signaling device (ok, so it's not a trigger). It is intended to accommodate planned outages and scheduled intervals of activity or inactivity." But if you're not alreay inactive, then it won't successfully schedule the inactivity.  If you're not in the room when the alarm sounds, it won't successfully schedule the activity.

I'd like to see it keep trying until it hears back from all hosts that use a schedule, or have some parameters that can be set to check every n seconds for a response, try m times, until a certain time; perhaps per business host.

For future readers; I ran into this problem as well, and even setting up my rule carefully exactly as indicated, and with the constraint: msgClass=Ens.StreamContainer, it did not work.  I continued to get Error#5005 Cannot open file.

I found that it was the Operation that was not able to open the file in the Service's File Path.  

I ensured the file service sent the file synchronously to the routing rule by keeping the Archive and Work paths blank.

The final step necessary was to set the Force Sync Send on the RouteRXPFile RULE, to force the rule to send synchronously as well.  That allowed the Operation time to read the file before it was deleted, and send the file on to some other service on a different server / path.

Ah, I should mention that this is happening in code that I can't access.  I can't really tel what's going on except by looking in the database after it's all "said and done". I can try that with one particular row in the database, but it's happening upstream, in othercode, and I'm wondering now if it's because the other code is possibly saving the Claim object differentlly.

However, this is a good idea.  I'll play arond with a couple of objects that are already in the database, and se if I can save them to be "right side up", and then "upside down" again.