Intercommunication

This chapter describes how user application programs can access and link to file, TSQ, and TDQ resources on remote OSC application servers.

1. Overview

In the OSC system, it is vital for OSC application servers to communicate with each other. It allows them to monitor each other, as well as enable application programs on a server to access resources on remote servers. There are currently three intercommunication methods provided for application servers as follows:

  • Function Shipping

    Allows OSC application programs to access file, TDQ, and TSQ resources of remote application servers.

  • Asynchronous Processing

    Communicates asynchronously with transactions managed by remote OSC application servers.

  • Distributed Program Link (DPL)

    Lets an OSC application program link to a program on a remote OSC application server.

2. Basic Concepts

Each OSC application server is assigned an identifier called the SYSID. This SYSID is used to obtain server connection information by mapping to the SYSID field of the CONNECTION resource definition and that information is used to connect to remote servers.

The SYSID is not a unique identifier in the entire OpenFrame system. The same SYSID can refer to different remote servers on each server. For example, the same SYSID can refer to server OSC00002 on server OSC00001, and server OSC00003 on server OSC00002.

For a server to support intercommunication, it must be given a SYSID. The SYSID is specified as a 4-byte string to the VALUE of the SYSID key in the GENERAL section, from the osc.{servername} subject under OpenFrame. This value is used by the OSC application server to identify a remote system.

For more information about the osc.{servername} subject, refer to OpenFrame Configuration Guide.

An OSC application program can access a remote OSC application server in one of the following ways.

  • For function shipping, asynchronous processing, or DPL, specify the SYSID of the remote application server in the SYSID option of an EXEC CICS command.

  • To enable function shipping for file, TDQ, or TSMODEL resources, specify the SYSID of the remote application server in the REMOTESYSTEM element of that resource’s resource definition. To enable DPL for program resources, specify the SYSID in the same element.

Here, the SYSID is the identifier of a CONNECTION resource definition that contains connection information regarding a remote application server. The NETNAME element of a CONNECTION resource definition identifies the remote server name. These two elements of the connection information facilitate intercommunication requests.

For more information about the CONNECTION resource definition, refer to OpenFrame OSC Resource Definition Guide.

3. Function Shipping

Function Shipping allows OSC application programs to access file, TDQ, and TSQ resources on a remote server and to search, read, delete, or write to them.

There are two ways to enable function shipping for an OSC application program as follows:

  • Specify the SYSID of a remote application in the SYSID option of an EXEC CICS command.

  • Specify the SYSID of the remote application server in the REMOTESYSTEM field of the resource definition on a remote server.

The methods to access remote resources vary according to resource type. For more information about function shipping methods, refer to "Resource Type and Function Shipping".
How Function Shipping Works

The following steps describe intercommunication through function shipping.

  1. An OSC application program requests function shipping through the EXEC CICS interface.

  2. It is checked whether the value specified in the SYSID option or REMOTESYSTEM element matches with the VALUE of the SYSID key in the GENERAL section, from the osc.{servername} subject under the local application server settings. For more information, refer to OpenFrame Configuration Guide.

    If they match, the local resource is used. Otherwise, the CONNECTION resource definition of a remote OSC application server is obtained (this is supported only if the PROTOCOL element is specified in the CONNECTION resource definition).

  3. The resource manager converts the request into a message.

  4. The program invokes the mirror service, with the message, on the conversational server of the remote server specified in the NETNAME field of the CONNECTION resource definition.

  5. The mirror service processes the request by accessing the resource using the CSM* mirror transaction and returns the result back to the application server where the request originated from.

    If a recoverable resource was accessed, or the READ UPDATE function was used in a sequential search, the mirror service is terminated. Otherwise, the mirror transaction waits for the application program to execute RETURN, SYNCPOINT, or SYNCPOINT ROLLBACK. Once the transaction is either committed or rolled back, it is terminated.

The conversational server and mirror services must be registered before using function shipping. For more information about configuration of function shipping, refer to OpenFrame OSC Administrator’s Guide.

Resource Type and Function Shipping

The following describes function shipping methods for each resource type.

  • Function Shipping for File Resources

    Enable function shipping for the EXEC CICS file access commands, such as DELETE, READ, REWRITE, UNLOCK, WRITE, ENDBR, READNEXT, READPREV, RESETBR, and STARTBR, in one of the following ways.

    • Specify the SYSID of a remote application server in the SYSID option of an EXEC CICS command.

    • Specify the SYSID of a remote application server in the REMOTESYSTEM field of the FILE resource definition. If REMOTENAME is specified, the command is sent to the file specified in the REMOTENAME field.

  • Function Shipping for TDQ Resources

    Enable function shipping for the TDQ access commands DELETEQ TD, READQ TD, and WRITEQ TD in one of the following ways.

    • Specify the SYSID of a remote application server in the SYSID option of an EXEC CICS command.

    • Specify the SYSID of a remote application server in the REMOTESYSTEM field of the TDQUEUE resource definition. If REMOTENAME is specified, the command is sent to the TDQUEUE specified in the REMOTENAME field.

    • Specify the SYSID of a remote application server in the REMOTESYSTEM field of the TDQ resource definition. Do not specify TYPE. Specify the name of the TDQ to access in the REMOTENAME field.

  • Function Shipping for TSQ Resources

    Enable function shipping for the TSQ access commands DELETEQ TS, READQ TS, and WRITEQ TS in one of the following ways.

    • Specify the SYSID of a remote application server in the SYSID option of an EXEC CICS command.

    • Specify the SYSID of a remote application server in the REMOTESYSTEM field of the TSMODEL resource definition.

4. Asynchronous Processing

Asynchronous processing allows an OSC application program to initiate a new task on a remote application server. The new task will then process an application program asynchronously.

The new task is initiated with the START command. The only difference is that the START command of the new task must contain the SYSID of the remote application server. When the program starts, it uses the RETRIEVE command to collect the data passed to the START command.

Requests made to a remote application server can be aborted with the CANCEL command, in the same way as to a local application server.

5. DPL

The Distributed Program Link (DPL) function enables an OSC application program to link to programs on a remote OSC application server. DPL allows an end-user interface that is physically separate from application source code (i.e., the client terminal is on a machine physically separate from the application program) to access an application program from various user interfaces. It can also be used as a higher-performance alternative to function shipping.

There are two ways to enable DPL for an application program as follows:

  • Specify SYSID of the remote application server in the SYSID option of an EXEC CICS LINK command.

  • Specify the SYSID of the remote application server in the REMOTESYSTEM element of the PROGRAM resource definition. The name of the program to link to must be specified in the REMOTENAME element. This name can be different from the program name specified in the PROGRAM option of the EXEC CICS LINK command.

DPL executes in the following order.

  1. The program manager that handles the LINK command compares the value specified in the SYSID option or REMOTESYSTEM element to the SYSID field in the local application server configuration file. If they match, a link to the requested program is made on the local server. Otherwise, the program manager searches for a CONNECTION resource definition.

  2. It is checked whether there is an input value for the PROTOCOL field in the CONNECTION resource definition. Currently, DPL is not supported when the PROTOCOL value is set to APPC.

  3. The request is converted into a message to be processed by the remote server.

  4. A request is made for the mirror service of the remote server specified in the NETNAME field of the CONNECTION resource definition.

  5. The mirror service analyzes the data in the message, passes the data through DFHMIR, and links to the requested program. DFHMIR and the linked program are executed either as the name specified in the TRANSID field of the PROGRAM resource definition or as the transaction name specified in the TRANSID option of the EXEC CICS LINK command. If TRANSID has not been specified, the transaction is executed as the transaction CSMI.

  6. When the linked program terminates, the data it returns is converted into a message that is stored in the COMMAREA. The modified COMMAREA is then returned to the server that originally called DPL.

  7. The server analyzes the message and resumes program control.

The following is a simplified diagram showing application server OSC00001 (SYSID is OSCA) requesting a DPL to server OSC00002 (SYSID is OSCB) through the CSMI transaction.

figure 8 1
DPL Example

An EXEC CICS LINK command that requests DPL supports almost the same functions as a command that links to a local program. It can support different functions when different values are configured for the SYNCSONRETURN option as well as the SYSID and TRANSID options described previously.

The SYNCSONRETURN option links to the program specified by a remote application server and decides how to handle the SYNCPOINT. If this option is specified, the mirror service executes the requested service, immediately handles the SYNCPOINT, returns the COMMAREA, and finally terminates.

If SYNCSONRETURN is not specified, the mirror service does not execute SYNCPOINT after executing the requested program. Instead, it waits for a SYNCPOINT request. If the application program terminates the task with a SYNCPOINT or RETURN command, the mirror service processes the SYNCPOINT and terminates. If the task ends abnormally via a SYNCPOINT ROLLBACK or ABEND command, the mirror service is also be rolled back and terminated.