|
•
|
connect performs various initialization tasks such as attributing the user Session ID and Terminal_ID.
|
|
•
|
disconnect manages final tasks during disconnection.
|
Specifically, ARTCNX handles the request from
ARTTCPH and
ARTSTRN/ARTSTR1,
LUNAME validation check, and
TERMID/LUNAME assignment. All services that
ARTCNX publishes and their functionalities are listed as below.
|
•
|
gensess generates a session ID for each terminal; the session ID is maintained internally in ART CICS.
|
|
•
|
delsess frees session ID when its terminal terminates.
|
|
•
|
connect generates a locally unique (unique in each CICS region) TERMID and a globally unique LUNAME (unique in all CICS regions) for auto-install terminal, checks LUNAME validation for the LUNAME specified terminal, and changes TERM status to ACQUIRED.
|
|
•
|
disconnect frees TERMID and LUNAME, and change TERM status to RELEASED.
|
|
•
|
inquire handles INQUIRE NETNAME/TERMID request from ARTSTRN.
|
|
•
|
update handles SET TERMINAL request from ARTSTRN.
|
|
•
|
authfail outputs the error message in terminal if CESN logon fails.
|
|
•
|
CESN specifies the Sign oN transaction
|
|
•
|
CESF specifies the Sign ofF transaction
|
|
•
|
CSGM specifies the Good Morning transaction (default Good Morning transaction)
|
|
Note:
|
If ISC_ENABLE=YES is set, gensess and delsess will be published by ARTLOGN instead.
|
ART_LOGON sends the "ART runtime welcome" panel and asks for APPLID input.
gensess generates a globally unique session ID (unique in all CICS regions) with 16 characters for each terminal.
delsess removes the session ID when the corresponding terminal disconnects.
|
Note:
|
ARTLOGN should be only configured when ISC_ENABLE=YES is specified; otherwise, the server will not boot.
|
|
•
|
System and Resource Management Server (ARTSRM) has three versions: ARTSRM, ARTSRM_ORA (for Oracle), and ARTSRM_UDB (for UDB). ARTSRM uses shared memory. ARTSRM_ORA (for Oracle) and ARTSRM_UDB (for UDB) use shared memory or database to store data; when configured to use database, the server utilizes DB to provide HA capability.
|
|
•
|
When your ARTSRM server uses shared memory and you do not specify SRM_IPCKEY, ARTSRM for the same region must be configured in the same Tuxedo group.
|
|
•
|
ARTSRM for the same region can be only configured on one host in MP environment.
|
|
•
|
ARTSRM does not support "Multiple Servers, Single Queue (MSSQ)" configuration.
|
|
•
|
To use ARTSRM_ORA or ARTSRM_UDB, database tables must be created before startup; ARTSRM_ORA or ARTSRM_UDB from the same region can belong to different Tuxedo groups on different machines (the Tuxedo group must be TMS group which has OPENINFO specified).
|
|
1.
|
When starting, a ARTSTRN/ARTSTR1 server publishes one service per transaction it offers.
|
|
3.
|
One ARTSTRN/ARTSTR1 server offering this service receives the request with the associated commarea and screen, then processes the transaction.
|
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.
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 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 ARTTSQP server is to manage TS queue which is defined in shared TS pool.
ARTTSQP supports Tuxedo EM TSQ monitor interface, detailed TS queue properties, and statistics information that can be retrieved via EM.
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.
This service is called if both <applid> and
<transid> are not specified in EXCI interface request. CSMI and CVMI are two kinds of CICS system mirror transaction.
This service is called if <transid> is not specified but
<applid> is specified in EXCI interface request. <applid> is specified by the
ARTDPL CLOPT "-a" argument or can be specified in the system.desc.
This service is called if <applid> is not specified but
<transid> is specified in EXCI interface request. <transid> is defined as a customized mirror transaction in the
transactions.desc.
This service is called if both <applid> and
<transid> are specified in EXCI interface request.
<transid> is defined as a customized mirror transaction in the
transactions.desc,
<applid> is specified by the the
ARTDPL CLOPT "-a" argument or can be specified in the
system.desc.
|
Note:
|
A request using the EXEC CICS START TRANSID command TERMID option is managed by ARTSTRN/ARTSTR1.
|
When the server boots, it will advertise each transaction defined in transactions.desc as a Tuxedo service. When ARTWTRN/ARTWTR1 receives the request from non-3270s terminals, the server loads corresponding CICS program located at directory
$COBPATH (
$COB_LIBRARY_PATH For COBOL-IT), reorganizes the application data received from FML buffer according to related COPYBOOK, and passes data to loaded CICS program for processing. When CICS program returns by invoking CICS RETURN, the server will insert application data into FML buffer and tpreturn to clients.
|
•
|
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.
|
ARTSHM is used to manage shared memory for
GETMAIN SHARED. It handles shared memory allocation and free request.
Environment variable KIX_SHR_IPCKEY and
KIX_SHR_SIZE specify IPC key and size of shared memory, these two variables must be configured to enable this feature. User can specify shared memory attach address by
KIX_SHR_ATADDR, default 0x300000000000, the specified address must be a page-aligned address. Environment variables must same for
ARTSHM and application servers.
User can configure more than one ARTSHM in a domain. On startup, the first booted
ARTSHM creates/initializes shared memory, following
ARTSHM attaches to the shared memory. On shutdown, the last
ARTSRM destroys shared memory.
ARTSHM must startup before any ART application servers (
ARTSTRN/1,
ARTATRN/1 and
ARTDPL), and shutdown after all ART application servers.
If ARTSHM stops abnormally, the shared memory is not destroyed, when
ARTSHM recovered either by Tuxedo
RESTART feature or manually startup, it attaches to shared memory, the memory management information is kept.
ARTCSKL is the listener of ART for CICS TCP/IP socket and can perform the same functions as CICS TCP/IP listener CSKL. When client request comes, it passes the request to work task for processing, and then waits for another client request.
ARTCSKL can run in standard or enhanced mode; you can set the mode through
FORMAT parameter of ART for CICS TCP/IP socket listener configuration file (
listener.desc).
