CICS Runtime Servers

The CICS Runtime Servers

This section describes the different servers and the role they play in the overall handling of transactions. The configuration of the servers is described in Server Configuration.

3270 Terminals and User Session Management (ARTTCPL/ARTTCPH)

Description

The role of these servers is to accept and manage user connections made thru a 3270 terminal emulator and manage the resulting user session and related 3270 inputs and outputs until the end of the user session.

Functionally, this role resembles the one played by the Terminal Owning Region in a CICS MRO configuration.

These 3270 user session management tasks are managed by a couple of server types: ARTTCPL and ARTTCPH, where the final ‘L’ stands for listener and the final ‘H’ stands for handler.

•	ARTTCPL — Performs the role of a listener server. ARTTCPL listens to a public address – the address to which users wanting to connect to this application with a 3270 emulator will connect – then for each incoming connection request, it transmits this connection to one of its handler processes.

•	ARTTCPH — Each handler process manages multiple connections including terminal I/O, user authentication, and calling the requested transactions on behalf of the user.

It is the role of the ARTTCPL to launch and manage the requested number of handler processes (ARTTCPH).

Each time a user requests a transaction, ARTTCPH transmits (via tpconnect) this transaction request to the transaction server.

This functionality resembles that provided by T.O.R. in a CICS MRO configuration when it routes a transaction to an A.O.R (Application owning Region).

Connection Server (ARTCNX)

This server offers technical services needed by terminal handlers during user connection and disconnection phases.

The technical services are offered using internal message oriented services like connect and disconnect:

•	connect performs various initialization tasks such as attributing the user Session ID and Terminal_ID.

•	disconnect manages final tasks during disconnection.

The connection server also provides a few classical CICS transactions:

•	CESN: the Sign oN transaction

•	CESF: the Sign ofF transaction

•	CSGM: the Good Morning transaction (default Good Morning transaction)

See Authentication Transactions for more information.

Synchronous Transactions and Program Management

Description

The task of these servers (ARTSTRN and ARTSTR1) is to offer application transactions and process the corresponding programs.

This server provides a similar functionality to that provided by an Application Owning Region in a CICS MRO configuration. ARTSTRN/ARTSTR1 servers present application transactions as Tuxedo services and when receiving a transaction request execute the corresponding programs. Theses servers are conversational in order to be able to manage true conversational CICS transactions.

Processing

1.	When starting, a ARTSTRN/ARTSTR1 server publishes one service per transaction it offers.

2.	When a user transmits a transaction request, the ARTTCPH performs a tpconnect to the corresponding transaction (service).

3.	One ARTSTRN/ARTSTR1 server offering this service receives the request with the associated commarea and screen, then processes the transaction.

4.

Then:

•	In the case of a normal pseudo-conversational CICS transaction; on the RETURN {TRANSID} the server replies to the client, finishing the conversation by a tpreturn() returning the new 3270 screen, and the commarea.

Non Concurrent Synchronous transaction Servers (MAXACTIVE = 1 (ARTSTR1))

•

On CICS:

•	Transactions that are defined as belonging to a transaction class are subject to scheduling constraints before they are allowed to execute.

•	If transactions belonging to an active transaction class are already running, any new transactions are queued.

•	The MAXACTIVE attribute is used to specify the maximum number of transactions that you want to run.

•	By putting your transactions into transaction classes, you can control how CICS dispatches tasks.

•	In CICS Runtime:

•	The scheduling of transactions and the affectations of resources to group of transactions is performed differently. The number of servers offering transactions determines the scheduling of transactions, and the relative amount of resources affected to a group of transactions.

•	The special case of MAXACTIVE 1:

•	This case is very specific, because it impacts the functional characteristics of the application.

•	It ensures that two transactions of the same class will never execute concurrently. It defines a mutually exclusive behavior that is preserved on the target platform to guarantee correct behavior of the application.

The transactions belonging to a tranclass with a maxactive =1, will not be offered by ARTSTRN servers, because several such servers can automatically be started to manage parallel processing.

Instead, a dedicated type of server—ARTSTR1—is allocated to this role. An ARTSTR1 server publishes the transactions belonging to one TRANCLASS with MAXACTIVE = 1, guaranteeing that two transactions of the same tranclass with maxactive =1, will not execute concurrently. In Tuxedo terms, guaranteeing than two such transactions are not published by two different servers.

To summarize the differences:

•	ARTSTR1: Publishes only once transactions belonging to a MAXACTIVE 1 tranclass.

•	ARTSTRN: Publish as many times as needed, transactions with MAXACTIVE >1.

Temporary Storage Management (ARTTSQ)

Description

The role of the ARTTSQ servers is to centralise the management the TS Queue operations which are requested by applications. These tasks are managed by ARTTSQ servers.

Depending on the workload expected on the TS queue, a single server or many ARTTSQ servers are configured.

ARTTSQ servers publish technical services:

•	TSQUEUE to service operations on queues not matching any TS Queue Model.

•	{MODEL}_TSQUEUE to service operations on queues matching a specific model, one such service must be published using one ARTTSQ server for each model.

In a simple configuration, a single ARTTSQ server will treat all the TS operations, offering the TSQUEUE service, and all {MODEL}_TSQUEUE services.

In a more complex configuration, one ARTTSQ server may offer the TSQUEUE and some {MODEL}_TSQUEUE services, while other ARTTSQ servers will each offer different {MODEL}_TSQUEUE services.

DPL servers (ARTDPL)

In complex configurations an application may need to make distributed program calls. In this case another kind of server is needed to manage DPL. These tasks are managed by ARTDPL servers.

ARTDPL servers publish programs that are callable by EXEC CICS LINK as services, and manage the execution of these services.

Asynchronous transaction servers (ARTATRN/ARTATR1)

An application may request an asynchronous transaction launch using 'EXEC CICS START TRANSID' requests. In this case the request needs to be treated asynchronously by another server. These tasks are managed by ARTATRN/ARTATR1 servers.

These servers publish transactions callable by EXEC CICS START TRANSID as services named ASYNC_{Transaction_Name}, and manage execution of these services.

Conversation server (ARTCTRN/ARTCTR1)

An application may request an a conversation launch using 'EXEC CICS CONVERSE' requests. In this case, the request needs to be treated by another server. These tasks are managed by ARTCTRN/ARTCTR1 servers.

These servers publish transactions callable by EXEC CICS CONVERSE as services named {SysId}_{Transaction_Name}, and manage execution of these services.

Delayed Asynchronous transaction (/Q Part)

Asynchronous transactions are launched using 'EXEC CICS START TRANSID' requests that may also by launched with a delay set to an interval or to a fixed time.

In this case the transaction request is deposited into a Tuxedo /Q Queue, and when the time is ready, the transaction will be automatically invoked.

For this feature to be available, a few extra components must be activated:

•	A Tuxedo /Q Queue Space named ASYNC_QSPACE must be created.

•	A Tuxedo /Q Queue named ASYNC_QUEUE must be created in the queue space.

•	A TMQFORWARD server must be configured to receive messages from this queue and invoke the application transaction corresponding to the request.

Tip:

TMQFORWARD will always call the same technical transaction called ASYNC_QUEUE (the name of the queue). This transaction will extract the field CX_TRANSID, which will contain the name of the real application transaction to call and will perform a TPACALL(NOREPLY, ) of this transaction and tpreturn immediately.

Administration server (ARTADM)

The administration server is responsible for the administration of CICS Runtime.

In a distributed target environment, this server can be configured on each node in order to propagate the configuration. The configuration files only need to be configured on the master node; the administration servers propagate the configuration files to each slave node.