The message scheduling facility of the IMS online environment controls the processing of messages. Because the system handles hundreds of data requests from clients, and the resources available to process these requests is limited, IMS message scheduling uses the concept of message queuing.
When several transaction - oriented messages are received by the IMS control region, it must determine how to process them. An efficient processing sequence is implemented, with the following three factors influencing the behavior:
Class - Determines which region will execute the application program associated with the transaction code.
Priority - Assigns the level of importance with a range of 0 through 14.
Process Limit Count (PLC) - Controls the frequency of the processing selection process. Values range from 0 through 65535. (65535 is the default).
Take a look at each of these factors and see how they affect our transaction-oriented message process.
Each message region and transaction is assigned a class or classes. Once a transaction has been selected for processing, it must wait until an appropriate message region becomes available.
Once a transaction has been selected, and a message region that can process the transaction is available, IMS will bring a copy of the load module into the region to begin executing it.
When a transaction is defined to the IMS environment through the IMS SYSGEN, it is assigned a processing priority. The priority values of a transaction range from 0 through 14.
A priority of 0 means that the transaction cannot be scheduled automatically. The highest priority is 14. If one is not assigned, the default is 1.
The priority is broken down into two parts.
Normal - The most frequently used priority.
Limited - Used during those times a higher priority is needed. To trigger this priority into action, a limit count is assigned.
As messages with the same transaction code accumulate, waiting for processing, IMS keeps track of how many there are. When the number of waiting messages reaches the limit count, IMS assigns a limit priority. The limit count has a maximum value (also the default value) of 65535. Once a transaction has been assigned a limit priority, it remains in effect until the number of waiting messages of that transaction type returns to zero.
The IMS scheduling process looks at all the messages waiting to be processed and selects those with the highest priority. Once a transaction has been selected, a message region must be available that can execute the class to which the transaction has been assigned.
For example: Transaction XYZ has a normal priority of seven. It also has a limit priority of 10, which is assigned when the limit count reaches 100. When the number of messages waiting to be processed reaches 100, IMS reassigns the selection priority to 10. As more XYZ messages are received, they are all reassigned the new priority, which remains until all of the XYZ messages have been processed.
Although the CPUs are getting faster at executing instructions, the physical I/O bringing in a load module from the library to the IMS dependent region is still time consuming. In order to allow an MPP to process more than one message during the scheduling of the load module, IMS provides for the use of the Process Limit Count (PLC). The PLC is a parameter placed on the transaction macro. It is used to define the transaction code that specifies the number of messages that can be processed by an MPP before IMS must free up the region and perform the scheduling process again.
A PLC is important in an IMS environment where many clients are using the same transaction. Because this means the program can process multiple unrelated messages, the program logic must be set up to process each message independently.
All working storage must be reinitialized before a program starts to process a message.
If a loop is used to process more than one message, all working storage must be reinitialized upon reaching the top to the process loop. This method of coding a program so that each message is treated independently is called making the program serially reusable.
If the PLC is ever set to more than one, the program logic must be reusable. Since the PLC can be altered dynamically and in a new system, always code an MPP to be serially reusable.
We have already mentioned several things that must be done in an IMS environment before it can begin processing messages. In addition to defining the transaction codes, you must define to IMS any LTERM codes and databases. All resources used by IMS must be defined prior to their use.
When a message is received in the IMS online environment, it determines the type of message and invokes one of the common services such as MFS. MFS is a facility that reformats messages according to control blocks.
The formatting of messages is done by the MFS of IMS online. Each message must be predefined with its definition stored in a PDS library, commonly called Format Lib. The definition is composed of several parts, each defining device input and output as well as message input and output formats. (This will be discussed in detail in the section on the Message Format Service.)
If you have any doubts or queries related to this chapter, get them clarified from our Mainframe experts on IBMMainframer Community!