Architected processes

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:
  • System message model—for handling messages containing various types of information that needs to be passed between systems (typically, DFS messages from IMS)
  • Scheduler model—for handling scheduling requests
  • Queue model—for handling queuing requests (in CICS terms, temporary-storage or transient-data requests)
  • DL/I model—for handling DL/I requests
  • LU services model—for handling requests between APPC service managers.

Note: With the exception of the APPC LU services model, the architected processes are defined in the LUTYPE6.1 architecture. CICS, however, also uses them for function shipping on APPC links by using APPC migration mode.

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.