Enhancing system performance of MFS-supported devices

Evaluating the message format buffer pool operation

The IMS /DISPLAY POOL command can be used to evaluate the message format buffer pool operation.

I/O+DI    (The sum of the numbers of fetch
 REQ1      I/O operations and directory I/O operations
           divided by the number of block requests from
           the pool.)

Hints and tips for improving performance

To reduce this value, do one or more of the following:

• Reduce format block I/O. The most significant and tunable portions of MFS processing cost are the CPU cycles and channel/device time required to read format blocks. To reduce format block I/O, use the following techniques:
  • Evaluate and implement $$IMSDIR, the optional MFS index directory. Index the selected MFS control blocks based on how frequently they are used. In most cases, using $$IMSDIR eliminates one read per format block during online operation.
  • Increase the size of the MFBP (Message Format Buffer Pool).
  • Increase the number of fetch request elements (FREs).
• Minimize the number of segments. Messages should be segmented for application program convenience or to meet segment size restrictions. Segment processing in MFS and DL/I requires a considerable number of CPU cycles, so do not segment unnecessarily.
• Use option 2 input. In some cases, the application input can be segmented so that no device input can be presented for segments under certain conditions. In such cases, option 2 input messages reduce processing time slightly and reduce IMS message queue space requirements.
• Use option 3 input. Option 3 input can provide better performance than option 1 or 2 if many fields are defined, but only a few fields are received on input. Additional buffer pool space is required during editing, but message queue space requirements are reduced. When most of the defined fields are received on input, option 3 performance is not as good as 1 or 2, either in processing time or in message queue space.
• Combine multiple DFLD literals. When multiple DFLD literals are positioned at adjacent or nearly adjacent device field locations, consideration should be given to combining the literals in fewer DFLD literal definitions. The only limitation to the number of literals combined is the maximum DFLD literal length. Combining DFLD literals reduces block size, reducing MFS processing time and, for 3270 or SLU 2 display devices, reducing transmission time.
• Do not define DFLDs that are not referred to by any MSG descriptor. Such DFLDs occupy block space and, if used extensively, could adversely affect MFS processing time.
• Combine output message fields if appropriate. Where multiple, contiguous, output message fields of a segment map to contiguous device fields of the same relative length, consider combining both the message fields and the device fields so that a single message field maps to a single device field. The greatest potential advantage is in those situations where only one blank separates the displayed fields, and message data is always present and equal to the device field length.

  Combining message fields is not recommended, however, in cases where an additional formatting burden would be placed upon the application program.

• Do not define duplicate formats. If duplicate libraries exist in the concatenated libraries, there is no guarantee that the copy from the first library will be fetched.
• Do not define separate formats for simple input. Most MFS device formats should include some user input fields that allow the operator to enter any simple transaction or command, related or not related to the application for which the format was designed. Any format requires four control blocks, and formats designed specially for simple input should not be defined unnecessarily.