Data can be collected automatically through either polled or unsolicited data collection. These options are discussed in the following paragrahs.

3.3.1 Unsolicited Data

Unsolicited data involves a device sending a physical point to BASEstar Classic services or reading a physical point from BASEstar Classic without it being previously requested. In both MMS and SINEC-S7/AP/H1 this function is described as being either an Information Report, a Write Indication a Read Indication, or a Message Exchange Indication (SINEC-AP only).

BASEstar Classic services can accept unsolicited values from any device as long as the device and physical point are defined with unsolicited information. Refer to the BASEstar Classic Command Line Interface User's Guide for more information concerning unsolicited data. Refer to the manufacturer's documentation for your specific device for more information on how it can send or request unsolicited data (Information Report, Write Indication or Read Indication).

3.3.1.1 Information Report

OMNI devices are capable of sending unsolicited data to OpenVMS as Information Reports. The DAS for OMNI software allows you to define BASEstar Classic physical points for collecting unsolicited data. If the device sends up an Information Report the DAS forwards the message to BASEstar Classic. The BASEstar Classic unsolicited ID must equal "I\".

Information reports are supported for named and unnamed variables and for SINCEC-AP messages.

3.3.1.2 Write Indication

OMNI devices are capable of sending unsolicited data to OpenVMS as Write Indications. The DAS for OMNI software allows you to define BASEstar Classic physical points for collecting unsolicited data. If the device sends up a Write Indication the DAS forwards the message to BASEstar Classic. The BASEstar Classic unsolicited ID must equal "W\".

The difference between an Information Report and a Write Indication is in where the variable is defined. For an Information Report, the variable is defined on the Remote VMD. The Information Report sends the value of a variable that exists in the remote VMD. For a Write Indication, the variable is defined on the Local VMD. The Write Indication sends a value to the Local VMD from the remote peer. For a Write Indication, the variable does not need to exist on the Remote VMD.

Write indications are supported for named and unnamed variables and for SINEC-AP messages.

3.3.1.3 Read Indication

OMNI devices are capable of requesting unsolicited data from OpenVMS as Read Indications. The DAS for OMNI software allows you to define BASEstar Classic physical points for responding to unsolicited read requests.

It is possible to configure the physical point such that replies are automatically returned to the device, or to configure it such that an explicit write request must be sent to the device to complete the read indication. These two options are discussed below.

Read indications are supported for named and unnamed variables and for SINEC-AP messages.

3.3.1.3.1 Automatic Reply to Read Indication

To automatically send a reply, a BASEstar Classic logical point must be associated with the physical point. If the device sends a Read Indication the DAS reads the associated BASEstar Classic logical point and returns the result to the device. If the BASEstar Classic logical point does not exist or has a bad status, then an error is returned to the device. The BASEstar Classic unsolicited ID must equal "R\LOGICAL_POINT_NAME", where LOGICAL_POINT_NAME is the name of the logical point to read to get the value to return to the device. The size of the format of the logical point must match the size of the data defined by the variable being requested by the Remote VMD.

The user can also request that a second point be updated when a BASEstar Classic logical point is read through a Read Indication. This capability allows an application to be notified when the Remote VMD has read a value from the OpenVMS system. The second point must have the same address as the Read Indication point with the addition of a "T\" prefix on the address and an unsolicited ID of "\T". The format of this physical point must be a "BIT". When a Read Indication occurs for the corresponding Read Indication point, the DAS forwards a message to BASEstar Classic with a value of "1". "Trigger" physical points are used only by the DAS and cannot be used to read or write values to a device.

3.3.1.3.2 Manual Reply to Read Indication

There may be cases where the user wants to be notified of a read indication, and then send the reply to the device. In this case a "Trigger" physical point must be set up as described above for the automatic case. A physical point must also be configured with an unsolicited ID of "\R". Note that in this case there is no BASEstar Classic logical point name configured in the unsolicited ID. When a read indication is detected by the DAS, the corresponding trigger point for that physical point is updated. The user is then responsible for sending a write request to the DAS for the corresponding physical point associated with the trigger physical point. No further read indications for that physical point will be accepted until the previous read indication has been completed by writing back down to the device.

3.3.1.4 Message Exchange Indication

SINEC-AP devices are capable of exchanging unsolicited data with OpenVMS as Message Exchange Indications. The DAS for OMNI software allows you to define BASEstar Classic physical points for exchanging unsolicited data.

It is possible to configure the physical point such that replies are automatically returned to the device, or to configure it such that an explicit write request must be sent to the device to complete a the message exchange indication. These two options are discussed below.

Message exchange indications are supported for SINEC-AP messages only.

3.3.1.4.1 Automatic Reply to Exchange Message Indication

To automatically send a reply, a BASEstar Classic logical point must be associated with the physical point. If the device sends up a Message Exchange Indication the DAS reads the associated BASEstar Classic logical point and returns the result to the device. If the BASEstar Classic logical point does not exist or has a bad status, then an error is returned to the device. The BASEstar Classic unsolicited ID must equal "X\LOGICAL_POINT_NAME", where LOGICAL_POINT_NAME is the name of the logical point to read to get the value to return to the device. The size of the format of the logical point must match the size of the data defined by the message being requested by the Remote VMD. The data sent by the device is used to update the associated physical point.

There may be cases where the user wants to examine the message sent in a message exchange indication, and then send the reply to the device. In this case the physical point must be configured with an unsolicited ID of "\X". Note that in this case there is no BASEstar Classic logical point name configured in the unsolicited ID. When a message exchange indication is detected by the DAS, the corresponding physical point is updated. The user is then responsible for sending a write request to the DAS for the physical point. No further message exchange indications for that physical point will be accepted until the previous messge exchange indication has been completed by writing back down to the device.

Table 3-7 summarizes unsolicited ID values and their meanings:

Table 3-7 Unsolicited ID Values

Unsolicited ID	Description
I\	Information Report
W\	Write Indication
R\LOGICAL_POINT_NAME	Read Indication (Automatic Reply)
R\	Read Indication (Manual Reply) 1
X\LOGICAL_POINT_NAME	Message Exchange Indication (Automatic Reply)
X\	Message Exchange Indication (Manual Reply)
T\	Trigger

Information Report and solicited variables and messages are defined on the Remote VMD only. Read and Write Indication variables and messages are defined on the Local VMD only. A Remote VMD is created in OMNI software for each BASEstar Classic device. A Local VMD is created for each BASEstar Classic path definition. To force creation of a unique Local VMD for each Remote VMD, create a separate path for each device.

Example 3-12 shows an example of creating unsolicited physical point definitions.

Example 3-12 Unsolicited Point Definition

DCM> create phy U1/dev=TEST_PLC/addr="N\U1"/form=long/unsol="I\" DCM> show phy U1/dev=TEST_PLC/FULL Physical Point : U1 Device : TEST_PLC Description : Address : N\U1 Data Format : S_LONGWORD Write Enabled : No Collection : Unsolicited ID : I\ Collection Enabled : No Distribution Destination Log : No BASEstar Classic Data Mgt : Number of Connections : 0 Defined on .... Definition last updated on .... DCM> DCM> create phy U2/dev=TEST_PLC/addr="N\U2"/form=long/unsol="R\P1" DCM> show phy U2/dev=TEST_PLC/FULL Physical Point : U2 Device : TEST_PLC Description : Address : N\U2 Data Format : S_LONGWORD Write Enabled : No Collection : Unsolicited ID : R\P1 Collection Enabled : No Distribution Destination Log : No BASEstar Classic Data Mgt : Number of Connections : 0 Defined on .... Definition last updated on .... DCM> DCM> create phy T2/dev=TEST_PLC/addr="T\N\U2"/form=BIT/unsol="T\" DCM> show phy T2/dev=TEST_PLC/FULL Physical Point : U2 Device : TEST_PLC Description : Address : T\N\U2 Data Format : S_LONGWORD Write Enabled : No Collection : Unsolicited ID : T\ Collection Enabled : No Distribution Destination Log : No BASEstar Classic Data Mgt : Number of Connections : 0 Defined on .... Definition last updated on .... DCM> DCM> create phy M1/dev=TEST_PLC/addr="M\M1" - _DCM> /form=struct"(array[10]:WORD)"/unsol="W\" DCM> show phy M1/dev=TEST_PLC/FULL Physical Point : M1 Device : TEST_PLC Description : Address : M\M1 Data Format : S_LONGWORD Write Enabled : No Collection : Unsolicited ID : W\ Collection Enabled : No Distribution Destination Log : No BASEstar Classic Data Mgt : Number of Connections : 0 Defined on .... Definition last updated on .... DCM>