The IMS/DC (Data Communications) system provides users with online "real time" access to information in IMS databases. MPP transaction programs are NOT submitted with OS JCL. The online IMS Control Region automatically schedules the MPP program necessary to process a transaction. This page summarizes how the Mainframe Analyzer handles IMS/DC.
Prototype link between GSAM DBD and JCL dataset
Inside a PSB file, the PCB connects to the database:
Then we have the definition of the DBD IMS file:
This IMS file calls the dataset of the JCL file, that calls the PSB file. The logic dataset name is set as GSAM01 and this is found when creating the JCL dataset:
The Mainframe Analyzer will handle this scenario by linking the IMS file to the JCL dataset via a prototype link:
IMS Transaction Manager file
The Mainframe Analyzer will analyze the IMS Transaction file (*.tra) to resolve two macros:
Call link between Cobol Program and IMS Transaction
In this example, when the TRANSACT macro is created as code, the Mainframe Analyzer will create an IMS transaction object with the code name, then link it to the Cobol program named as PSB = XXX inside the APPLCTN macro.
IMS Transaction Flow
Click to enlarge
The input data from the terminal is read by the data communication modules. After editing by MFS, if appropriate, and verifying that the user is allowed to execute this transaction, this input data is put in the IMS message queue. The messages in the queue are sequenced by destination, which could be either transaction code (TRAN) or logical terminal (LTERM).
- I/O PCB - in a CICS-DBCTL environment, an input/output PCB (I/O PCB) is needed to issue DBCTL service requests. Unlike other types of PCB, it is not defined with PSB generation. If the application program is using an I/O PCB, this has to be indicated in the PSB scheduling request, as explained in Format of a PSB.
- Alternate TP PCB(s) - an alternate TP PCB defines a logical terminal and can be used instead of the I/O PCB when it is necessary to direct a response to a terminal. Alternate TP PCBs appear in PSBs used in a CICS-DBCTL environment, but are used only in an IMS/VS DC or IMS™ TM environment. CICS applications using DBCTL cannot successfully issue requests that specify an alternate TP PCB, an MSDB PCB, or a GSAM PCB, but PSBs that contain this kind of PCB can be scheduled successfully in a CICS-DBCTL environment. Alternate PCBs are included in the PCB address list returned to a call level application program. The existence of alternate PCBs in the PSB can affect the PCB number used in the PCB keyword in an EXEC DLI application program, depending on whether you are using CICS online, batch programs, or BMPs
From a Cobol file, the Alternal-PCB contains the destination code (IMS Trans code or LTERM code). Example ALT-PCB:
Only the CHNG DLI Call could change the value of destination code. The ISRT DLI Call will send the message to LTERM or IMS Transaction:
Click to enlarge
IMS MFS Maps file
The Mainframe Analyzer will analyze the IMS MFS Maps file (*.mfs) so that it is possible to find out which Cobol programs use an MFS Map:
- MFS Maps are contained in files with the extension *.mfs.
- FMT macro defines the map (called "format" in IMS vocabulary).
- MSG macro defines MID and MOD messages. MID are those that have the INPUT type and MOD are those that have the OUTPUT type.
- MID and MOD identifiers are specified in the IO-PCB.
- In the MID/MOD structure, there is a field that contains the name of the transaction. This information allows the analyzer to create links between MFS Maps and transactions
As a result:
- The Mainframe Discoverer will detect a project (and therefore automatically create an Analysis Unit) for each *.mfs file discovered in a folder.
- .mfs files have been added to the list of files that will be automatically analyzed - see for example Mainframe - Analysis configuration
- New object types will be resolved - see Mainframe - Analysis results:
|IMS Message Format Service|
|IMS Message Input Descriptor|
|IMS Message Output Descriptor|