TSO-ISPF JCL COBOL VSAM DB2 CICS IMS-DB IMS-DC Tools Articles Forum Quiz Interview Q&A

IMS System Definitions


A APPLCTN macro is coded to define an application , its resources in terms of a PSB name and the application type.


This specifies the PSB and the program name to be DFSIVP2 and it also specifies that the application is a MPP with a class of 1. The class may be omitted and specified in the TRANSACT macro(s).

Other options possible are


GPSB=name generates a PCB with an I/O PCB and an alternate PCB dynamically

PGMTYPE=BATCH for BMP programs

LANG=ASSEM or COBOL or PL/I and is relevant only if GPSB is specified

SCHDTYP=PARALLEL | SERIAL. SERIAL is the default and the application can run in only one region


One or more TRANSACT macros follow an APPLCTN macro and associate a Transaction code (8 characters) with the application. More than one transaction can map to a single application. However one transaction cannot map to more than one application.

The parameters on the transaction definition that will affect the scheduling options are:




  • PRTY

The PARLIM parameter on the TRANSACT macro will determine when a transaction will be scheduled in another region. When the number of messages on the queue for this transaction exceeds the value on the PARLIM, another region will be used. A value of 0 schedules a new region every time a message comes.

The MAXRGN parameter is used to restrict the number of MPR’S that can process a transaction at any one time. A value of 0 sets no limit.

PROCLIM(count,seconds) sets the max iterations as well as the max time that an application can run.

PRTY(normal,limit,limit count). Default is 1,1,65535

SPA=size for a conversational transaction. If coded IMS treats the transaction as a conversational transaction.

The transactions are assigned to classes. The maximum number of transactions classes is set at system generation time by the MAXCLAS parameter of the IMSCTRL macro.

Each dependent MPR can run up to four transaction classes. The order in which they are specified is a priority sequence. That means that the transaction class named first is the highest and the one named last is the lowest. Each MPR can have a different sequence of the same or different transaction combinations. The classes are named on the PROC statement of the JCL running the MPR.

//       PROC SOUT=A,RGN=56K,SYS2=,
//            CL1=001,CL2=000,CL3=000,CL4=000,
//            IMSID=,. . . .
//            TIME=1440,DPRTY=(12,0),
//            PARM=(MSG,&CL1&CL2&CL3&CL4,. . .)

The classes assigned to a dependent region can be changed through the /ASSIGN command.

The /DIS ACTIVE command displays the dependent regions and status.

The following conditions must be met for a successful scheduling:

  1. An MPR region must be available. The termination of a prior transaction running in an MPR region triggers the scheduling process.

  2. There must be a transaction input message in the queue.

  3. The transaction and its program are not in a stopped state.

  4. Enough buffer pool storage is available to load the program specification block (PSB) and the referenced database control blocks if not already in main storage.

  5. The database processing intent does not conflict with an already active application program (a BMP for instance).

The database intent of a program as scheduling time is determined via the PROCOPT= parameters in the PSB. Any conflicting situation during scheduling will only occur if a segment type is declared exclusive use (PROCOPT=E) by the program being scheduled and an already active program references the segment in its PSB (any PROCOPT), or vice versa.


Each database needs to be defined by a DATABASE macro. The level of access is specified as well as the DBD name. The access levels are EX for exclusive, RD which allows only read access to the data base, RO that allows uncommitted reads to the database with PCB’S that have a PROCOPT of GO, and UP for update intent.

IMS normally uses an enqueue on the data base record while an application is processing the record.

There are two situations where the enqueue / dequeue routines of program isolation are not used in processing a database call:

If PROCOPT=GO (read only) is specified for the referenced segment (s) of the call.

If PROCOPT=E (exclusive) is specified for the referenced segment (s) in the call.

Note that possible conflicts with exclusive extent are resolved during scheduling time and, as such, cannot occur at call time.

With the GO option, a program can retrieve data which has been altered or modified by another program still active in another region, and database changes made by that program are subject to being backed out.

Exclusive intent may be required for long-running BMP programs that do not issue checkpoint calls. Otherwise, an excessively large enqueue/dequeue table in main storage may result.

If you have any doubts or queries related to this chapter, get them clarified from our Mainframe experts on IBMMainframer Community!

Are you looking for Job Change? Job Portal