SDT performs two operations--LOGON and CONNECT--in order to establish a data table for sharing. These operations are described below.
When the first file that is defined as a data table is opened in an FOR, the FOR attempts to register itself as an SDT server. This operation is performed automatically and is known as an SDT LOGON. The opening of the file can be caused by the FOR or by the AOR that first accesses the file.
Regardless of whether the LOGON is successful or not, the file is opened and the data table is loaded. If the LOGON is successful, all other CICS® regions in the MVS™ operating system are notified that the data table is available.
If the LOGON fails because of a permanent condition (such as CICS not being defined as an MVS subsystem), no further LOGON attempts are made during the CICS run.
If the LOGON fails because of a potentially transient condition, another LOGON attempt is made the next time a file defined as a data table is opened. This type of condition includes:
When a region’s LOGON requests are rejected because of a security check failure, security violation messages might be issued each time a file that is defined as a data table is opened.
After an FOR logs on successfully, it remains in that state for the rest of the CICS run; no more LOGON requests are issued.
When an AOR with SDT issues a read request (or starts a browse sequence) for a remote file, SDT attempts to establish a connection to a data table for that file. If the FOR is registered as an SDT server, SDT establishes a cross-memory link from the AOR to the FOR (subject to security checks) and calls the SDT server to ask whether there is an available data table for the file. If there is, a connection is made between the AOR and the data table. This operation is performed automatically, and is known as an SDT CONNECT.
If the CONNECT is successful, cross-memory services are used, whenever possible, to access the file while the connection exists.
If the CONNECT fails, the file request is function shipped exactly as it would have been in the absence of SDT. The action taken for subsequent remote file requests depends on the type of failure as described below.
If the CONNECT fails because of a permanent condition (such as CICS not being defined as an MVS subsystem), no further CONNECT attempts are made during the CICS run.
If the CONNECT fails because of a potentially transient condition that is not under the control of the file owner, another CONNECT attempt is made for the next suitable request after about ten minutes have elapsed. This type of condition includes:
When a region’s CONNECT requests are rejected because of a security check failure, the related security violation messages might be issued at 10-minute intervals.
If the CONNECT fails because of a potentially transient condition that is under the control of the file owner, another CONNECT attempt is made for the next suitable request following notification that at least one new file is available for shared access on the MVS system. This type of condition includes:
After an AOR connects to a remote file successfully, it remains connected unless one of the following events occurs:
In this event, the connection is broken immediately.
In this event, the disconnection is scheduled at the next non-update request and is effected after all current browse sequences have terminated. See Disconnection.
If these events are later reversed, a valid connection is established in the same way as before.
When a data table is opened by an FOR, it becomes available for CONNECT attempts at the start of loading for a CICS-maintained data table, or at the completion of loading of a user-maintained data table. Other CICS regions are notified that a data table has become available. Notification is also made when a data table (or a file that uses a CICS-maintained data table) is enabled, having been previously disabled.
To provide security for a data table when cross-memory services are used, SDT must ensure that:
These security checks are performed by using the system authorization facility (SAF) to invoke the Resource Access Control Facility (RACF®) or an equivalent security manager.
SDT reproduces the main characteristics of function-shipping security that operate at the region level, but the following differences should be noted:
For a description of the steps required to implement SDT security, see CICS RACF Security Guide.