DEVICE HOLDOFF

Reese Jacobs

I have a large system in which it is imperative that code in the DEFINE_START section for each module run to completion before any devices for that module come online. This is specifically what the DEVICE HOLDOFF master setting is designed to accommodate. The description of the exact behavior is a little vague and I was hoping someone with experience using DEVICE HOLDOFF ON can provide some insight. The manual indicates that when DEVICE HOLDOFF is in effect, the following is true:

When set to ON, this prevents messages being lost in the master upon startup. The master will not check for devices until the interpreter is running. Any messages to devices in DEFINE_START will be lost.

When OFF, devices can report and be online before the interpreter runs. This has the advantage of letting messages to a device in DEFINE_START be sent, and the disadvantage of potentially overflowing the master's internal communication queues.

Specifically, the statement that messages to a device in DEFINE_START will be lost is is what I was hoping to better understand. I assume this means that SEND_COMMAND and SEND_STRING to a device in DEFINE_START will not work. This is clear but what about actions involving a device which are not covered by a SEND - for example?

- Create buffer / Create level for a physical device that is not ONLINE?
- Are virtual devices affected by DEVICE HOLDOFF?
- Combine/Uncombine levels that include a physical device that is not online yet?
- Set Virtual Level Count for a virtual device?
- Can an IP_CLIENT_OPEN be used in DEFINE_START if nothing is sent to the device until it comes ONLINE?
*** network devices would seem to be associated with the master which is online so this is OK?

I am sure there are some other gray areas but I am trying to make sure that there is no code in any of the DEFINE_START sections that will be ignored thereby causing problems later. Thanks in advance.