An architected process is an IBM®-defined method of allowing dissimilar products to exchange intercommunication requests in a way that is understood by both products. For example, a typical requirement of intersystem communication is that one system should be able to schedule a transaction for execution on another system. Both CICS® and IMS™ have transaction schedulers, but their implementation differs considerably. The intercommunication architecture overcomes this problem by defining a model of a "universal" transaction scheduling process. Both products implement this architected process, by mapping it to their own internal process, and are therefore able to exchange scheduling requests.
The architected processes implemented by CICS are:
The appropriate models are also used for CICS-to-CICS communication. The exceptions are CICS file control requests, which are handled by a CICS-defined file control model, and CICS transaction routing, which uses protocols that are private to CICS.
During resource definition, your only involvement with architected processes is to ensure that the relevant transactions and programs are included in your CICS system, and possibly to change their priorities.
Architected process names are one through four bytes long, and have a first byte value that is less than X'40'.
In CICS, the names are specified as four-byte hexadecimal transaction identifiers. If CICS receives an architected process name that is less than four bytes long, it pads the name with null characters (X'00') before searching for the transaction identifier.
CICS supplies the processes shown in Figure 71.
XTRANID TRANSID PROGRAM DESCRIPTION
For CICS file control
- CSMI DFHMIRS File control model
For LUTYPE6.1 architected processes
01000000 CSM1 DFHMIRS System message model
02000000 CSM2 DFHMIRS Scheduler model
03000000 CSM3 DFHMIRS Queue model
05000000 CSM5 DFHMIRS DL/I model
For APPC architected processes
06F10000 CLS1 DFHZLS1 LU services model
06F20000 CLS2 DFHLUP LU services model
- CLS3 DFHLUP LU services model
The previous list shows that the CICS file control model and the architected processes for function shipping all map to program DFHMIRS, the CICS mirror program. The inclusion of different transaction names for the various models enables you to modify some of the transaction attributes. You must not, however, change the XTRANID, TRANSID, or PROGRAM values.
You can modify any of the definitions by means of the CEDA transaction. In particular, you may want to change the DTIMOUT value on the mirror transactions.
The definitions for the mirror transactions are supplied with DTIMOUT(NO) specified. If you are uncomfortable with this situation, you should change the definitions to specify a value other than NO on the DTIMOUT option. However, before changing these definitions, you first have to copy them to a new group.
Function shipping over MRO links can employ long-running mirror tasks and the short-path transformer program. (See MRO function shipping.)
If you modify one or more of the mirror transaction definitions, you must evaluate the effect that this may have on interregion function shipping.
The short-path transformer always specifies transaction CSMI. It is not, however, used for DL/I requests; they arrive as requests for process X'05000000', corresponding to transaction CSM5.