User application programs can run in a CICS® intercommunication environment and use the intercommunication facilities without being aware of the location of the file or other resource being accessed. The location of the resource is specified in the resource definition. (Details are given in Defining remote resources.)
The resource definition can also specify the name of the resource as it is known on the remote system, if it is different from the name by which it is known locally. When the resource is requested by its local name, CICS substitutes the remote name before sending the request. This facility is useful when a particular resource exists with the same name on more than one system but contains data peculiar to the system on which it is located.
Although this may limit program independence, application programs can also name remote systems explicitly on commands that can be function-shipped, by using the SYSID option. If this option is specified, the request is routed directly to the named system, and the resource definition tables on the local system are not used. The local system can be specified in the SYSID option, so that the decision whether to access a local resource or a remote one can be taken at execution time.
Function shipping allows access to VSAM or BDAM files located on a remote CICS system. INQUIRE FILE, INQUIRE DSNAME, SET FILE, and SET DSNAME are not supported. Both read-only and update requests are allowed, and the files can be defined as protected in the system on which they reside. Updates to remote protected files are not committed until the application program issues a syncpoint request or terminates successfully. Linked updates of local and remote files can be performed within the same unit of work, even if the remote files are located on more than one connected CICS system.
Take care when designing systems in which remote file requests using physical record identifier values are employed, such as VSAM RBA, BDAM, or files with keys not embedded in the record. You must ensure that all application programs in remote systems have access to the correct values following addition of records or reorganization of these types of file.
Function shipping allows a CICS transaction to access IMS/ESA® DM and IMS/VS DB databases associated with a remote CICS OS/390 system, or DL/I DOS/VS databases associated with a remote CICS/VSE system. (See Introduction to CICS intercommunication for a list of systems with which CICS Transaction Server for z/OS®, Version 3 Release 1 can communicate.)
The IMS/ESA DM (DL/I) database associated with a remote CICS Transaction Server for z/OS system can be a local database owned by the remote system, or a database accessed using IMS™ database control (DBCTL). To the CICS system that is doing the function shipping, this database is simply remote.
As with file control, updates to remote DL/I databases are not committed until the application reaches a syncpoint. With IMS/ESA DM, it is not possible to schedule more than one program specification block (PSB) for each unit of work, even when the PSBs are defined to be on different remote systems. Hence linked DL/I updates on different systems cannot be made in a single unit of work.
The PSB directory list (PDIR) is used to define a PSB as being on a remote system. The remote system owns the database and the associated program communication block (PCB) definitions.
Function shipping enables application programs to send data to, or retrieve data from, temporary-storage queues located on remote systems. A temporary-storage queue is specified as being remote by an entry in the local temporary-storage table (TST). If the queue is to be protected, its queue name (or remote name) must also be defined as recoverable in the TST of the remote system.
An application program can access intrapartition or extrapartition transient-data queues on remote systems. The definition of the queue in the requesting system defines it as being on the remote system. The definition of the queue in the remote system specifies its recoverability attributes, and whether it has a trigger level and associated terminal. Extrapartition queues can be defined (in the owning system) as having records of fixed or variable length.
Many of the uses currently made of transient-data and temporary-storage queues in a single CICS system can be extended to an interconnected processor system environment. For example, a queue of records can be created in a system for processing overnight. Queues also provide another means of handling requests from other systems while freeing the terminal for other requests. The reply can be returned to the terminal when it is ready, and delivered to the operator when there is a lull in entering transactions.
If a transient-data queue has an associated trigger level transaction, the named transaction must be defined to execute in the system owning the queue; it cannot be defined as remote. If there is a terminal associated with the transaction, it can be connected to another CICS system and used through the transaction routing facility of CICS.
The remote naming capability enables a program to send data to the CICS service destinations, such as CSMT, in both local and remote systems.
Performance problems can occur when function shipping requests awaiting free sessions are queued in the issuing region. Requests that are to be function shipped to a resource-owning region may be queued if all bound contention winner 6 sessions are busy, so that no sessions are immediately available. If the resource-owning region is unresponsive the queue can become so long that the performance of the issuing region is severely impaired. Further, if the issuing region is an application-owning region, its impaired performance can spread back to the terminal-owning region.
The symptoms of this impaired performance are:
In either case, CICS is unable to start any new work.
CICS provides two methods of preventing these problems:
If you already have an XISCONA exit program, you may be able to modify it for use at the XZIQUE exit point.
For further information about controlling intersystem queues, see Intersystem session queue management.