Introduction to the RPC Server for CICS

The EntireX RPC Server for z/OS CICS® allows standard RPC clients to communicate with RPC servers on the operating system z/OS under CICS. It supports the programming languages COBOL and PL/I.

This document covers the following topics:


Worker Models

graphics/intro_workerModels-cics.png

RPC requests are worked off inside the RPC server in worker threads, which are controlled by a main thread. Every RPC request occupies during its processing a worker thread. If you are using RPC conversations, each RPC conversation requires its own thread during the lifetime of the conversation. The RPC server provides two worker models:

  • FIXED
    The fixed model creates a fixed number of worker threads. The number of worker threads does not increase or decrease during the lifetime of an RPC server instance.

  • DYNAMIC
    The dynamic model creates worker threads depending on the incoming load of RPC requests.

For configuration and technical details, see ERXMAIN macro parameter ENDW under Administering the RPC Server for CICS.

Inbuilt Services

RPC Server for CICS provides the following service for ease-of-use:

Deployment Service

The Deployment Service allows you to synchronize server-side mapping files (Designer files with extension .svm) interactively using the Server Mapping Deployment Wizard. Synchronizing or undeploying server mapping files from the RPC server is part of Migrating Server Mapping Files. On the RPC server side, the server-side mapping files are stored in a server-side mapping container (VSAM file). See Server-side Mapping Files in the RPC Server and Deployment Service for configuration information.

graphics/intro_inbuilt_deployment-cics.png

User Exit COBUEX02

The RPC Server for CICS provides a user exit COBUEX02to influence/control the RPC logic. The exit is called on the events START-WORKER, START-USER, CALL-START and CALL-END. The following tasks can be performed:

graphics/no1.gif WHICH-VERSION event. Tells the RPC Server for CICS the version to use.
graphics/no3.gif START-WORKER event. Allows you to set the CICS transaction ID.
graphics/no5.gif START-USER event. Apply user ID, CICS transaction ID and CICS terminal ID to impersonated user tasks. See Impersonation.
graphics/no7.gif CALL-START event. Inspect, modify or terminate the RPC request (payload) from the RPC client.
graphics/no8.gif CALL-END event. Inspect or modify the RPC reply (payload) or give an error to the RPC client.

The numbers in the graphic correspond to the event numbers in the user exit.

graphics/intro_userExits-cics.png

See also User Exit COBUEX02 under Administering the RPC Server for CICS.

Impersonation

graphics/intro_impersonation-cics.png

The RPC Server for CICS can be configured to execute the RPC request impersonated under the RPC client user ID. For this, worker tasks start additional impersonated user tasks. This can be useful, for example for accounting. Impersonation is controlled by the ERXMAIN macro parameter IMPS.

  • For IMPS value AUTO, the RPC Server for CICS does not validate RPC passwords, so you have to take care the RPC client is correctly authenticated, either by using a secure EntireX Broker (validation must be against the correct mainframe security repository where CICS user IDs are defined) or with your own security implementation.

  • For IMPS value YES, the RPC Server for CICS uses the RPC user ID and RPC password sent by the calling RPC client for authentication and impersonation of the client. This means that the RPC server validates the RPC password or - if a long RPC password is sent - as a RACF password phrase.

The picture above shows the configuration IMPS=YES.

The lifetime of an impersonated user task starts when an open request for an RPC conversation or a non-conversational RPC request is received. It ends when the RPC conversation stops (after a commit operation or timeout) or when the non-conversational RPC request has been performed.

For worker threads, the slow-shrinking worker model DYNAMIC is used - value TIMEOUT is forced internally - any value given in the ERXMAIN macro parameter ENDW is ignored. The lifetime of worker threads can be controlled with ERXMAIN macro parameter TOUT as well as the number of workers with macro parameters MINW and MAXW.

Usage of Server Mapping Files

Server mapping files contain COBOL-specific mapping information that is not included in the IDL file, but is needed to successfully call the COBOL server program. There are many situations where the RPC Server for CICS requires a server mapping file to correctly support special COBOL syntax such as REDEFINES, SIGN LEADING and OCCURS DEPENDING ON clauses, LEVEL-88 fields, etc.

graphics/intro_useSvm.png

The RPC server marshals the data in a two-step process: the RPC request coming from the RPC client (Step 1) is completed with COBOL-specific mapping information taken from the server mapping file (Step 2). In this way the COBOL server can be called as expected.

The server mapping files (Designer files with extension .cvm) may be retrieved as a result of the IDL Extractor for COBOL extraction process and the COBOL Wrapper if a COBOL server is generated. See Server Mapping Files for COBOL and When is a Server Mapping File Required?

Note:
Server mapping files are used for COBOL only.

Supported Interface Types

The interface types supported by the RPC Server for CICS vary depending on the target programming language. See also Locating and Calling the Target Server.

COBOL

PL/I