This specification describes the functionality of the services provided by the Vendor Dependent Mode (VDM) services under WOSA/XFS, by defining the service-specific commands that can be issued, using the WFSGetInfo, WFSAsyncGetInfo, WFSExecute and WFSAsyncExecute functions.
In all device classes there needs to be some method of going into a vendor specific mode to allow for capabilities which go beyond the scope of the current WOSA/XFS specifications. A typical usage of such a mode might be to handle some configuration or diagnostic type of function or perhaps perform some 'off-line' testing of the device. These functions are normally available on Self-Service devices in a mode traditionally referred to as Maintenance Mode or Supervisor Mode and usually require operator intervention. It is those vendor-specific functions not covered by (and not required to be covered by) WOSA/XFS Service Providers that will be available once the device is in Vendor-Dependent mode.
This service provides the mechanism for switching to and from Vendor Dependent Mode. The VDM Service Provider can be seen as the central point through which all Enter and Exit VDM requests are synchronised.
Entry into, or exit from, Vendor Dependent Mode can be initiated either by an application or by the VDM Service Provider itself. If initiated by an application, then this application needs to issue the appropriate command to request entry or exit. If initiated by the VDM Service Provider i.e. some vendor dependent switch, then these request commands are in-appropriate and not issued.
Once the entry request has been made, all registered applications will be notified of the entry request by an event message. These applications must attempt to close all open sessions with WOSA/XFS Service Providers as soon as possible and then issue an acknowledgement command to the VDM Service Provider when ready. Once all applications have acknowledged, the VDM Service Provider will issue event messages to these applications to indicate that the System is in Vendor Dependent Mode.
Similarly, once the exit request has been made all registered applications will be notified of the exit request by an event message. These applications must then issue an acknowledgement command to the VDM Service Provider immediately. Once all applications have acknowledged, the VDM Service Provider will issue event messages to these applications to indicate that the System has exited from Vendor Dependent Mode.
Thus, WOSA/XFS compliant applications that do not need the system to be in Vendor Dependent Mode, must comply with the following:
- Every WOSA/XFS application should open a session with the VDM ServiceProvider passing a valid ApplId and then register for all VDM entry and exit notices.
- Before opening any session with any other WOSA/XFS Service Provider, check the status of the VDM Service Provider. If Vendor Dependent Mode is not “Inactive”, do not open a session.
- When getting a VDM entry notice, close all open sessions with all other WOSA/XFS Service Providers as soon as possible and issue an acknowledgement for the entry to VDM.
- When getting a VDM exit notice, acknowledge at once.
- When getting a VDM exited notice, re-open any required sessions with other WOSA/XFS Service Providers.
VDM Entry triggered by WOSA/XFS Application
At time t0, status is “Inactive” and a request to Enter VDM arises from within the Application system.
At time t1, an Application Process/Thread/Function issues the CMD_ENTER_MODE_REQ Execute cmd.
Status then becomes “Enter Pending”.
At time t2, the VDM Service Provider issues the SRVE_ENTER_MODE_REQ Event to all registered applications.
At time t3, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom a WOSA/XFS Compliant Application
At time t4, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom another WOSA/XFS Compliant Application
At time t5, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom the last WOSA/XFS Compliant Application
At time t6, the VDM Service Provider issues the SYSE_MODEENTERED Event to all registered applications
Status then becomes “Active”.
The system is now in Vendor Dependent Mode and the Vendor Dependent Application can exclusively use the system devices in a Vendor Dependent manner.
VDM Entry triggered by Vendor Dependent Switch
At time t0, status is “Inactive” and a request to Enter VDM arises from within the Vendor System.
Status then becomes “Enter Pending”.
At time t1, the VDM Service Provider issues the SRVE_ENTER_MODE_REQ Event to all registered applications.
At time t2, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom a WOSA/XFS Compliant Application
At time t3, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom another WOSA/XFS Compliant Application
At time t4, the VDM Service Provider receives a CMD_ENTER_MODE_ACK Execute Commandfrom the last WOSA/XFS Compliant Application
At time t5, the VDM Service Provider issues the SYSE_MODEENTERED Event to all registered applications
Status then becomes “Active”.
The system is now in Vendor Dependent Mode and the Vendor Dependent Application can exclusively use the system devices in a Vendor Dependent manner.
VDM Exit triggered by WOSA/XFS Application
At time t0, status is “Active” and a request to Exit VDM arises from within the Application system.
At time t1, an Application Process/Thread/Function issues the CMD_EXIT_MODE_REQ Execute cmd.
Status then becomes “Exit Pending”.
At time t2, the VDM Service Provider issues the SRVE_EXIT_MODE_REQ Event to all registered applications.
At time t3, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom a WOSA/XFS Compliant Application
At time t4, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom another WOSA/XFS Compliant Application
At time t5, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom the last WOSA/XFS Compliant Application
At time t6, the VDM Service Provider issues the SYSE_MODEEXITED Event to all registered applications
Status then becomes “Inactive”.
The system is now no longer in Vendor Dependent Mode and the WOSA/XFS Compliant Applications can re-open any required services with other WOSA/XFS Service Providers.
VDM Exit triggered by Vendor Dependent Switch
At time t0, status is “Active” and a request to Exit VDM arises from within the Vendor System.
Status then becomes “Exit Pending”.
At time t1, the VDM Service Provider issues the SRVE_EXIT_MODE_REQ Event to all registered applications.
At time t2, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom a WOSA/XFS Compliant Application
At time t3, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom another WOSA/XFS Compliant Application
At time t4, the VDM Service Provider receives a CMD_EXIT_MODE_ACK Execute Commandfrom the last WOSA/XFS Compliant Application
At time t5, the VDM Service Provider issues the SYSE_MODEEXITED Event to all registered applications.
Status then becomes “Inactive”.
The system is now no longer in Vendor Dependent Mode and the WOSA/XFS Compliant Applications can re-open any required services with other WOSA/XFS Service Providers.