The Terminal Control Listener (CTLL) process is a standard Oracle Tuxedo server that runs in the ARTICTL subsystem. It starts when ARTICTL is initiated.

The CTLL performs the role of a terminal listener server. It listens at a public address that connects the application with a 3270. For each incoming connection request, it transmits this connection to one of its handler processes. Detailed functions are as follows:

• The CTLL process establishes a network port that connects to the 3270 terminal emulators. The port is “well-known”, that is, its address is available to any end user of a terminal emulator.
• The CTLL process spawns CTLH processes which listen on the well-known port for incoming connection requests. The CTLL process manages the number of CTLH processes dynamically, based on system load.
• The CTLL communicates with the CTLH processes utilizing various inter-process communication (IPC) mechanisms, such as shared memory and dedicated TCP/IP connections. Each CTLH can handle numerous terminal emulator clients and the CTLL tracks the number of connections each handler is servicing.

Terminal Control handler (CTLH) process manages multiple connections including terminal I/O, user authentication, calling the requested transactions on behalf of the user and etc. Each time a user requests a transaction, CTLH transmits (via tpacall()) this transaction request to the Messaging Processing Region (ARTIMPP). Detailed functions are as below:

• Terminal I/O
  
• Session Management
  
• 3270 Data Stream Transform
  
• IMS Message Formatting
  
• Terminal Type Support
  

The Message Format Service library (LIBMFS) is delivered as libraries linked by CTLH and run in each CTLH process, it also handles the control blocks management. It searches the correct Control Blocks and loads them into the cache when they are requested, and maintains them in the cache. When the request terminates, Control Blocks are cleared from the cache.

IMS System Commands, such as/FORMAT, /SIGN and /EXIT, are also handled in TCP handler.

Tuxedo ART for IMS supports four types of Oracle Tuxedo security mechanisms: none security, APP_PW, user-level authentication (USER_AUTH) and Access Control List (ACL or Mandatory ACL).

If authentication:

• Succeeds, a success screen is returned to the terminal.
• Fails, return to the Sign-on screen until authentication succeeds

  If authorization fails, it will display some error message in terminal, But you still could clear the terminal and do any other transaction.

• Using system command “/Sign off” to sign off the current user.

  When the user signs off from Tuxedo ART for IMS runtime, the sign on screen appears, which the users can use to re-sign directly; the users could also clear the screen and then use system command "/Sign", "/Sign on", "/Sign on username password" to re-sign the Tuxedo ART for IMS runtime.

The maximal length of Username and Password is 8 (Chars) just as Mainframe.

For more information, see Using Security in ATMI Applications, in the Oracle Tuxedo Users Guide.

ARTICTL provides access to 3270 terminals through TCP/IP and message formatting services. ARTICTL formats screen based on the user input, receives input from 3270 terminal, converts the messages received from 3270 terminal to Oracle Tuxedo requests, sends the requests to ARTIMPP for processing, receives responses from ARTIMPP formats the response, and sends back to the originating terminal.

Tuxedo ART for IMS also support encryption and certificate authentication over network links between ARTICTL Handler and 3270 terminal. Currently the supported SSL version is TLS 1.2.

ARTIMPP, in normal mode, dynamically advertises a set of services based on a set of configuration files while starting. All the services (transaction codes) to be contained in ARTIMPP servers are defined in imstrans.desc, each transaction code defined in it corresponds to a service with same name to be advertised. imsapps.desc defines all the COBOL/C application programs to be called by ARTIMPP. Each $appname.psb defines the alternate PCBs required by that application. For information, see Oracle Tuxedo Application Runtime for IMS Users Configuration. If the configuration files are changed, ARTIMPP can only accept the changes while restarting. In addition, ARTIMPP only supports applications with type of TP.

Each service (transaction code) advertised by ARTIMPP has a defined COBOL application name to handle the service. While ARTIMPP receives a request to a service, ARTIMPP finds the COBOL application name corresponding to the requested service, and calls the corresponding COBOL program. Each COBOL application is compiled to a .gnt file and put in a directory in COBOL search order. For Micro Focus COBOL environment, the program search order is defined by environment variable $COBPATH. For COBOL-IT COBOL environment, the program search order is defined by $COB_LIBRARY_PATH.

Each Instance of ARTIMPP server can specify which classes of transaction codes are to be advertised by it. This mechanism can be used to adjust the deployment.

If the COBOL application program called for a service does not explicitly commit or roll back the transaction, ARTIMPP server commits the transaction implicitly.

ARTIMPP supports that a request is forwarded by one transaction code to another transaction code, i.e., program switch. Program switch can be accomplished from a non-conversation transaction code to another non-conversation transaction code, from a conversation transaction code to another conversation or non-conversation transaction code. For the program switch between one conversation code and another conversation code, deferred/immediate switch are supported. Deferred program switch means the originating transaction code returns to the terminal with another transaction code (switch target) contained in SPA, when the terminal sends message again, the message will be routed to the switch target. Immediate program switch means the originating forwards a message to another transaction code, which responds to terminal. For program switch between non-conversation transaction codes, only immediate switch is supported. For the program switch from a response mode transaction code to a non-response transaction code, ARTIMPP does not have limitation on it, but users should be careful of designing the program switch like this since response-mode transaction requires a response but non-response mode transaction may not respond to the terminal.

ARTIBMP_SVC retrieves the specified BMP program name and associated PSB name from the message passed from the ARTIBMP client, verifies that the requested program is a valid batch program (configured in imsapps.desc and with type of BATCH) and the specified PSB is valid too, calls the program, and returns the result or completion notification to the client synchronously.