Planning considerations for writing clients for the CSL
Planning tasks are decisions that you must make to determine how you use the CSL managers and CSL requests.
Planning tasks are decisions that you must make to determine how you use the CSL managers. These decisions include:
- What authorization level to use
You must decide whether your program needs to run authorized (supervisor state) or non-authorized (problem state). SCI initializes the appropriate environment based on your program's state and PSW key when it registers with SCI.
Note: A non-authorized client cannot register with RM, issue RM requests, register commands with OM, or process requests issued using CSLSCRQS. - Whether to use SCI exit routines
You must decide whether to use the SCI Input and Notify exit routines. An OM command processing client, for example, must have the SCI Input exit to process OM directives; it must have the SCI Notify exit to be notified when new OMs join the IMSplex, so the OM command processing client can register to those OMs.
- TCB association
SCI registration (with the CSLSCREG request) enables an IMSplex member to be associated with a specific, different TCB. The authorization level you use must also be considered regarding TCB association. SCI internally associates the registration with the specified TCB. If no TCB is specified, SCI associates the registration with the TCB from which the registration is issued. If the associated TCB terminates without a deregistration being issued, SCI abnormally terminates the registration and releases the associated storage that SCI allocated in the member address space. If a subsequent SCI request is issued, an abend may occur.
- Whether to use RM services, OM services, or ODBM
services
You can choose to manage your own global resources. However, if you want to access IMS global resources, you must code an RM client.
If you plan to develop your own command set and your own command processing client (which would coordinate its own command registration and security), you can write an OM command processing client. If you plan to develop your own SPOC or AOP to enter your own commands, you can write an OM AOP client. OM's role is to transport commands throughout an IMSplex and to consolidate those command responses, in XML tags, for a SPOC or AOP.
For access to IMS databases managed by IMS DB in either the DBCTL or DB/DC environment, you can write an ODBM client application program that does not use IMS transactions. ODBM manages database connections in an IMSplex, permitting application programs that use either the IMS Universal drivers or the ODBA interface to access databases in an IMSplex. ODBM also protects the IMS control region from the unexpected termination of application programs that use the ODBA interface.
- Whether to use message or request protocol when issuing requests
Use message protocol either when you do not need a synchronous response, or when you want an asynchronous response. IMSplex command responses that are sent with message protocol are sent asynchronously.
- Whether to use the CSL OM audit trail
The CSL OM audit trail contains normal operating messages generated by active CSL address spaces including RM, OM, and SCI, as well as operational messages created by IMS components routing activity through a CSL component. CSL client activity is also captured. The audit trail can be used for audit compliance as well as for diagnostic tasks.
- Whether to use the CSL ODBM
accounting feature
ODBM leverages the z/OS® System Management Facility (SMF) to perform logging of ODBM accounting information, such as CPU usage, and its retrieval. The logging of the ODBM address space is activated when the optional parameter LOGOPT=ACCOUNTING is specified in the ODBM initialization member, CSLDIxxx.