ARTICTL handles the remote terminal connection and transfers the 3270 data stream from EBCDIC to ASCII. It then parses the information from the data stream according to DIF, saving the message segments into the memory according to MID for
ARTIMPP.
ARTIMPP initiates and controls a specific program (in COBOL) which uses the request data to perform the remote operator request. It also prepares some data for the remote operator in response to the work request (for example, acknowledgment of work done, answer to a query, etc.).
Unlike ARTIMPP,
ARTIBMP is not activated by the remote terminal, but by an Oracle Tuxedo client specific to
ARTIBMP (for example,
DFSRRC00).
Figure 2 shows how
ARTICTL can make an application program device-independent by formatting input data from the device or remote program for presentation to IMS, and formatting the application program data for presentation to the output device or remote program.
The CTLH performs the session management. When you connect to ARTICTL subsystem via terminal, CTLH establishes a new user session for the connection and handles all subsequent screen I/O for the terminal. As a performance enhancement, each CTLH process can manage multiple sessions simultaneously. When you disconnect the emulator from the port, the CTLH terminates the session.
The CTLH performs the message formatting by invoking Message Format Service Libraries (LIBMFS). When the
CTLH receives data from a terminal, it splits the data stream and extracts the useful information according to the DIF control block, then composes the message to be used by application program according to the MID control block. When the
CTLH receives the message returned from an application program, it splits the message and extracts the useful segments according to the MOD control block. It then composes the data stream to send to terminal according to the DOF control block.
When the ARTICTL subsystem boots up, the CTLH performs TN3270E protocol negotiation, and the type and identity of a terminal are determined through the negotiation (such as “IBM-3278-2-E”), then the CTLH handles the 3270 data stream corresponding to the type of the terminal.
Note:
|
When using tmloadcf, do not fill any application password characters. Leave it NULL by pressing Enter.
|
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.
ARTIMPP in normal mode (without
-p option in
CLOPT) is an Oracle Tuxedo server designed to act as a service container. It advertises a set of services based on configuration file while initializing; calls corresponding COBOL/C application program while receiving a request to a service it advertised; and sends back the response to the requester, normally
ARTICTL server. Service is the counterpart on UNIX to transaction code on Mainframe.
ARTIMPP in persistent mode (with
-p option in
CLOPT), monitors the /Q for every persistent TP transaction (transaction that is defined in
imsresource.desc). Once there is a message in one /Q for one persistent transaction, it gets the message from the /Q and calls corresponding COBOL/C application program and then sends back a response to the requester.
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
ARTIMS 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 function with the support of MicroFocus libraries. Each COBOL application is compiled to a
.gnt file and put in a directory in COBOL search order. For MicroFocus COBOL environment, the program search order is defined by environment variable
$COBPATH.
Note:
|
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.
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.
For immediate program switch via ALT PCB, if the target transaction is persistent transaction(transaction that is defined in imsresource.desc), the message for the target transaction will be put into /Q.
ARTIMPP in persistent mode will handle this transaction. If the target transaction is non persistent transaction,
ARTIMPP will call the transaction service and
ARTIMPP in normal mode will handle this transaction.
ARTIMPP_ORA has all the functionalities of
ARTIMPP. It can support an Oracle database used as an external resource manager (RM). It requires some libraries provided by Oracle database. To use
ARTIMPP_ORA with an Oracle database, the RM section must be configured correctly in the
UBBCONFIG file.
ARTIBMP is an Oracle Tuxedo server that advertises a fixed service
ARTIBMP_SVC so that BMP clients can request this service to call specified BMP program written in COBOL.
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.
ARTIBMPT is a transaction-oriented BMP server. When
DFSRRC00 is called with
IN assigned, the transaction code is passed to
ARTIBMPT with other parameters.
ARTIBMPT processes the transaction by calling a specified BMP program written in COBOL/C. Only BATCH applications are supported.
ARTIBMPT can only process transaction oriented
BMP applications. A transaction oriented BMP application is a application that is defined in
$MBR of parameters list and also defined in
imsapps.desc with
TYPE=BATCH.
Note:
|
Currently, ARTIBMPT does not support client terminal messages. The transaction oriented BMP application/transaction must be a persistent transaction; this requires that the transaction must be defined in imsresources.desc.
|
ARTIBMP_ORA has all the functionalities of
ARTIBMP. It can support an Oracle database used as an external resource manager (RM). It requires some libraries provided by Oracle database. To use
ARTIBMP_ORA with an Oracle database, the RM section must be configured correctly in the
UBBCONFIG file.
In MP mode, ARTIADM can be booted up based on your choice, it downloads the configuration files from the master to the slave node. It is an Oracle Tuxedo server, and each node just needs to be deployed at most one
ARTIADM. If your want to boot
ARTIADM, it should be booted prior to
ARTICTL and the
ART_IMS_CONFIG environment variable should be set on each node.
In cross-domain mode, if ARTICTL and
ARTIMPP are not in the same domain,
ARTITERM is used to pass the response from
ARTIMPP back to
ARTICTL. That is,
ARTITERM acts as an intermediate from
ARTIMPP to
ARTICTL.
ARTIGW is an Oracle Tuxedo server that acts as a bridge between non-terminal clients and the
ARTIMPP server. Its main duties are as follows:
Note:
|
ARTIMS can only be deployed across homogeneous machines since COBOL application programs are called by ARTIMPP and ARTIBMP servers. Messages passed between ARTIMS servers are filled by COBOL programs, but ARTIMS servers are not aware of the copybook defined in the COBOL programs for messages.
|
There are three kinds of deployment environment for ARTIMS: SHM, MP and Domain. SHM means all the
ARTIMS servers are deployed on one single machine. MP means
ARTIMS servers are deployed across multiple machines belonging to a single Tuxedo domain. Domain means
ARTIMS servers are deployed across multiple Tuxedo domains.
In SHM mode, ARTICTL and
ARTIMPP are required;
ARTIBMP is also required if the you need to run BATCH programs. In MP mode (besides the servers required in SHM mode),
ARTIADM is also required. In MP mode, one single machine can contain any combination of
ARTICTL and
ARTIMPP/ARTIBMP. In domain mode, besides the servers required in MP mode,
ARTITERM is also required in each domain where
ARTICTL lives. The deployment of domain mode will be described in specific.
ARTITERM exports a service whose name is composed with the domain id configured in the
UBBCONFIG file for the domain and a hard-coded string “
RPLYSVC” (i.e.,
${DOMAINID}_RPLYSVC). The service name mentioned above should be configured in the
DMCONFIG file *
DM_REMOTE_SERVICES section of every remote domain.
Note:
|
The NO_XA option cannot be configured in each domain where ARTIMPP or ARTIBMP lives.
|
You should set IMSDIR to point to the installation root of Tuxedo ART for IMS product, set
ART_IMS_CONFIG to specify the location of configuration files, set
ART_IMS_FMT to specify the location of control block files, set
ART_IMS_DB to specify the location of GSAM files, and set
COBPATH to specify the location of COBOL
.gnt files.
You should set INTERCODE to encoding type used in open platform, set
EXTERCODE to
EBCDIC encoding type used in z/OS platform.
The USER_AUTH and ACL/Mandatory ACL security mechanism requires that each user must provide a valid username and password to join the Tuxedo ART for IMS runtime. The per-user password must match the password associated with the user name stored in a file named
tpusr. Client name is not used. The checking of per-user password against the password and user name in
tpusr is carried out by the Oracle Tuxedo authentication service
AUTHSVC, which is provided by the Oracle Tuxedo authentication server
AUTHSVR.
ARTIMS uses the following existing UBBCONFIG file parameters to configure information about SSL identification strings and the location of SSL certificate encryption passwords:
DFSRRC00 is used to activate the
ARTIBMP server which is always waiting for the input from
DFSRRC00. The parameter of
DFSRRC00 is a string, which should be passed from the script converted by workbench from JCL.
prepro-ims.pl is used to transfer C program(on z/OS) to proper C program format that chould be invoked by Tuxedo ART for IMS. For details, please refer to Oracle Tuxedo Application Runtime for IMS Reference Guide.
odbastop is a tool on open system and it is used to stop ODBA proxy on z/OS
stoproxy is on z/OS and is used to stop ODBA proxy on z/OS.
The .gnt files should be put under
$COBPATH (MicroFocus) or
$COB_LIBRARY_PATH (COBOL-IT).
From DFSIVAP1.psb, we can conclude that application
DFSIVAP1 requires one I/O PCB and two alternate PCBs as its arguments.
From DFSIVAPX.psb, we can conclude that application
DFSIVAP2 requires one I/O PCB and three GSAM PCBs.
ARTICTL - The server responsible for connection with 3270 terminals
ARTIMPP - The server responsible for executing MPP applications
ARTIBMP - The server responsible for executing BMP applications
To run the MPP program DFSIVAP1, open a 3270 terminal and connect to
ARTICTL server with the hostname and port defined in
UBBCONFIG file, then format the screen and input the transaction code
TRAN1,
DFSIVAP1.gnt is invoked by ARTIMPP server.
To run the BMP program DFSIVAP2, the user need to convert the corresponding JCL on z/OS to shell script by ART Workbench so that it can be run by ART Batch runtime as a JOB. The JOB will invokes a utility
DFSRRC00, which starts a specific advertised by
ARTIBMP server, which in turn invokes the requested COBOL application. For information, see
ART Workbench documentation.
ims.h is the header file supported in IBM IMS.
testmpp.c will be compiled to
libartimstestmpp.so
testbmp.c will be
compiled to libartimstestbmp.so
The APPNAME in configuration file should be the same as application name converted by preprocessor.
That is, <filename> corresponds libartims<filename>.so.
The environment variable LD_LIBRARY_PATH should be redefined by adding the directory containing these library files in the first of its original list.
However, LD_LIBRARY_PATH is only for Linux and Solaris. On AIX,
LIBPATH should be used instead.
For example, libartimstestmpp.so and
libartimstestbmp.so should be under the
LD_LIBRARY_PATH (Linux/Solaris) or
LIBPATH(AIX).
To run the MPP program
testmpp, open a 3270 terminal and connect to
ARTICTL server with the hostname and port defined in
UBBCONFIG file, then format the screen and input the transaction code
TRAN3,
testmpp is invoked by
ARTIMPP server.
To run the BMP program testbmp, the user need to convert the corresponding JCL on z/OS to shell script by ART Workbench so that it can be run by ART Batch runtime as a JOB. The JOB will invokes a utility
DFSRRC00, which starts a specific advertised by
ARTIBMP server, which in turn invokes the requested C application. For information, see ART Workbench documentation.
imsdbs.desc is located under
$ART_IMS_CONFIG. Some fields of
imsdbs.desc configurations are mapped from some DBD statement of IMS on z/OS.
$segname.desc only exists for databases with access type of neither GSAM nor MSDB defined in
imsdbs.desc.
a.
|
Create a PDS (LRECL=80, RECFM=FB) on z/OS to upload JCL files, for example USER.ODBA.JCL.
|
a.
|
Modify USER.ODBA.JCL(CREDS) to make it suitable for user's environment, especially VOL=SER parameter, possibly user may also want to modify the dataset name to be created, for example USER.ODBA.XMI.
|
Upload local file ORACLE.ODBA.BACK.XMI to dataset
USER.ODBA.XMI on z/OS (ftp binary mode).
a.
|
Modify USER.ODBA.JCL(RECEIVE) to make it suitable for user environment, INDSNAME specifies the input dataset of this JCL, it should be identical to the XMI dataset, i.e. USER.ODBA.XMI in step 2; DSNAME is the output file of this JCL, assuming it's changed to USER.ODBA.BAK.
|
a.
|
Modify USER.ODBA.JCL(RESTORE) to make it suitable for user's environment, VOL=SER should be changed to the volume on which the target PDS consisting of the executables will be created, RENAMEU specifies the source name and the target name, the source name must be kept, user can modify the target name, for example USER.ODBASERV.LOAD. Set DSN to the DSNAME value which is set in step 4 (assume it is set to USER.ODBA.BAK).
|
b.
|
Submit RESTORE job and make sure it complete successfully, now the executables have been extracted into a PDS named USER.ODBASERV.LOAD.
|
a.
|
Modify USER.ODBA.JCL (RUNPROXY) to make it suitable for user's environment, especially the DD in STEPLIB to correctly specify USER.ODBASERV.LOAD and the dependent DD
|
b.
|
Submit RUNPROXY job to start the proxy. Ensure that IMS ODBA environment has been set up before starting the proxy.
|
After UBBCONFIG and Tuxedo ART for IMS resources have been defined, compile
UBBCONFIG and run Tuxedo ART for IMS by starting its Oracle Tuxedo Domain using the
tmboot command or controls provided in Oracle Enterprise Manager TSAMPlus plug-in.