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.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.See “Authentication Transactions” in Other Configurations for more information.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.
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.
• 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.
•
•
• The special case of MAXACTIVE 1: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.
• ARTSTR1: Publishes only once transactions belonging to a MAXACTIVE 1 tranclass.
• ARTSTRN: Publish as many times as needed, transactions with MAXACTIVE >1.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.The role of the ARTTDQ servers is to centralise the management the TD Queue operations which are requested by applications. These tasks are managed by one ARTTDQ server.A single ARTTDQ server publishes one service per declared queue in the configuration file.and will treat all the CICS TD operations, offering the TD QUEUE service for each queue.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.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.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.
• 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.