Statically routing DPL requests

Static routing means that the location of the server program is specified at design time, rather than at run-time. DPL requests for a particular remote program are always routed to the same server region. Typically, when static routing is used, the location of the server program is specified in the installed program resource definition. (Details are given in Defining remote resources for DPL.)

The program resource definition can also specify the name of the server program as it is known on the resource system, if it is different from the name by which it is known locally. When the server program is requested by its local name, CICS® substitutes the remote name before sending the request. This facility is particularly useful when a server program exists with the same name on more than one system, but performs different functions depending on the system on which it is located. Consider, for example, a local system CICA and two remote systems CICB and CICC. A program named PG1 resides in both CICB and CICC. These two programs are to be defined in CICA, but they have the same name. Two definitions are needed, so a local alias and a REMOTENAME have to be defined for at least one of the programs. The definitions in CICA could look like this:

DEFINE PROGRAM(PG1) REMOTESYSTEM(CICB) ...
DEFINE PROGRAM(PG99) REMOTENAME(PG1) REMOTESYSTEM(CICC) ...
Note:
Although doing so may limit the client program’s independence, the client program can name the remote system explicitly by using the SYSID option on the LINK command. If this option names a remote system, CICS routes the request to that system unconditionally. If the value of the SYSID option is "hard-coded"--that is, it is not deduced, from a range of possibilities, at run-time--this method is another form of static routing.

The local system can also be specified on the SYSID option. This means that the decision whether to link to a remote server program or a local one can be taken at run-time. This approach is a simple form of dynamic routing.

In the client region (CICA in Figure 27), the command-level EXEC interface program determines that the requested server program is on another system (CICB in the example). It therefore calls the transformer program to transform the request into a form suitable for transmission (in the example, line (2) indicates this). As indicated by line (3) in the example, the EXEC interface program then calls on the intercommunication component to send the transformed request to the appropriate connected system.

Using the mirror transaction

The intercommunication component uses CICS terminal-control facilities to send the request to the mirror transaction. The request to a particular server region causes the communication component in the client region to precede the formatted request with the identifier of the appropriate mirror transaction to be attached in the server system.

Controlling access to resources, accounting for system usage, performance tuning, and establishing an audit trail can all be made easier if you use a user-specified name for the mirror transaction initiated by any given DPL request. This transaction name must be defined in the server region as a transaction that invokes the mirror program DFHMIRS. It is worth noting that defining user transactions to invoke the mirror program gives you the freedom to specify appropriate values for all the other options on the transaction resource definition. To initiate any user-defined mirror transaction, the client program specifies the transaction name on the LINK request. Alternatively, the transaction name can be specified on the TRANSID option of the program resource definition.

Figure 27. The transformer program and the mirror in DPL
 The picture shows the scenario described in the text. It shows two CICS regions, CICA and CICB. On CICA, a program PGA is defined as remote, owned by region CICB. On CICB, PGA is defined as a local program. On CICA, a program issues an EXEC CICS LINK PROGRAM(’PGA’) request. Also shown on CICA are the EXEC interface program, DFHEIP, programs DFHEPC and DFHISP, and the transformer program, DFHXFP. Shown on CICB are the mirror transaction, program PGA, and the transformer program, DFHXFP. The picture shows the data flows described in the text.

As line (4) in Figure 27 shows, a mirror transaction uses the transformer program DFHXFP to decode the formatted link request. The mirror then executes the corresponding command, thereby linking to the server program PGA (5). When the server program issues the RETURN command (6), the mirror transaction uses the transformer program to construct a formatted reply (7). The mirror transaction returns this formatted reply to the client region (8). In that region (CICA in the example), the reply is decoded, again using the transformer program (9), and used to complete the original request made by the client program (10).

The mirror transaction, which is always long-running for DPL, suspends after sending its communications area. The mirror transaction does not terminate until the client program issues a syncpoint request or terminates successfully.

When the client program issues a syncpoint request, or terminates successfully, the intercommunication component sends a message to the mirror transaction that causes it also to issue a syncpoint request and terminate. The successful syncpoint by the mirror transaction is indicated in a response sent back to the client region, which then completes its syncpoint processing, so committing changes to any protected resources.

The client program may link to server programs in any order, without being affected by the location of server programs (they could all be in different server regions, for example). When the client program links to server programs in more than one server region, the intercommunication component invokes a mirror transaction in each server region to execute link requests for the client program. Each mirror transaction follows the above rules for termination, and when the application program reaches a syncpoint, the intercommunication component exchanges syncpoint messages with any mirror transactions that have not yet terminated.

Using global user exits to redirect DPL requests

Two global user exits can be invoked during DPL processing:

XPCREQ and XPCREQC can be used for a variety of purposes. You could, for example, use them to route DPL requests to different CICS regions, thereby providing a simple load balancing mechanism. However, a better way of doing this is to use the CICS dynamic routing program--see Dynamically routing DPL requests.

For programming information about writing XPCREQ and XPCREQC global user exit programs, see the CICS Customization Guide.

Related concepts
Overview of DPL
Intersystem queuing
Examples of DPL
Related tasks
Dynamically routing DPL requests
Daisy-chaining of DPL requests
Defining local resources for DPL
Defining remote resources for DPL
Application programming for CICS DPL
Related reference
Limitations of DPL server programs
Appendix A. Intercommunication rules and restrictions checklist
[[ Contents Previous Page | Next Page Index ]]