Has this bug been fixed yet? I am having the same issue in version 2023.1, where setting the CodeTableDetail Code and Description values to $C(34,34) or """""" (e.g.  <Code>""</Code>) in the SDA does NOT clear the value from its HSAA property.

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.