Message Format Service

MFS is an IMS facility that formats messages to and from terminals so that IMS application programs need not deal with device-specific characteristics in input or output messages.

MFS formats messages to and from user-written programs in remote controllers and subsystems so that host application programs need not deal with terminal-specific characteristics of the remote controller.

Restriction:

MFS does not support LU 6.2 devices. The LU 6.2 Edit exit routine (DFSLUEE0), which is supplied with IMS, can edit both input and output messages from LU 6.2 devices when the implicit API support is used.

MFS uses control blocks that the user specifies to indicate to IMS how input and output messages are arranged.

• For input messages, MFS control blocks define how the message that is sent by the device to the application program is arranged in the program's I/O area.

• For output messages, MFS control blocks define how the message that is sent by the application program to the device is arranged on the screen or at the printer. Data such as literals that appear on the screen but not in the program's I/O area can also be defined.

In IMS systems, data that is passed between the application program and terminals or remote programs can be edited by MFS or the basic edit function. The facilities provided by MFS depend on the type of terminals or secondary logical units (SLUs) your network uses.

MFS allows application programmers to deal with logical messages instead of device-dependent data; this simplifies application development. The same application program can deal with different device types using a single set of logic, whereas device input and output varies for specific device types.

Figure 17-1 on page 299 shows how MFS can make an application program device-independent by formatting input data from the device or remote program for presentation to IMS, and by formatting the application program data for presentation to the output device or remote program.

Figure 17-1. Message Formatting Using MFS

The presentation of data on the device or operator input can be changed without changing the application program. Full paging capability is provided by IMS for display devices. Input messages can be created from multiple screens of data.

With MFS, you do not need to design your program for the physical characteristics of the device that is used for input and output messages unless the program uses very specific device features. Even when these features are used, the program can request that MFS assist in their presentation to the program or the device.

MFS supports SLU-type devices SLU-1, SLU-2, SLU-P, Finance, and LU 6.1. MFS also supports older devices, including IBM 2740, 2741, 3270, and 3600.

For IBM 3270 or SLU-2 devices, device control characters or orders can be sent directly from or received by the program using the MFS bypass function. This gives the application program more direct control of the data stream. The program uses reserved format names that cause MFS not to edit:

• Output messages

• The next input message that is received from the display terminal

Using MFS bypass is usually confined to special application programs such as those that invoke Graphical Data Display Manager (GDDM) to display graphical data.

Both logical and physical paging facilities are provided for the IBM 3270 and 3604 display stations. These facilities allow the application program to write large quantities of data that MFS can divide into multiple display screens on the terminal. The terminal operator can then page forward and backward to different screens within the message.

MFS Components

MFS has several components:

• MFS Language utility (DFSUPAA0): Executes offline to generate control blocks from user-written control statements and places the control blocks in a format data set named IMS.FORMAT. The control blocks describe the message formatting that is to take place during message input or output operations. The control blocks are generated according to a set of utility control statements.

• MFS message editor: Formats messages according to the control block specifications generated by the MFS Language utility.

• MFS pool manager: Keeps the MFS control blocks that are required by the MFS message editor in the main-storage MFS buffer pool.

• MFS Service utility (DFSUTSA0): Used for maintenance of the control blocks in IMS.FORMAT. The MFS Service utility provides a method for additional control of the format control block data sets. It executes offline and is able to create and maintain an index of control blocks for online use by the MFS pool manager.

• MFSTEST pool manager: Replaces the MFS pool manager when the MFS Language utility is being used in test mode. The /TEST command with the MFS keyword places a logical terminal into MFSTEST mode. For each terminal in MFSTEST mode, combining temporary format blocks with the use of other blocks that are already in production mode allows new applications and modifications to existing applications to be tested without disrupting production activity.

• MFS Device Characteristics Table (MFSDCT) utility (DFSUTB00): Defines new screen sizes in a descriptor member of the IMS.PROCLIB library without performing an IMS system definition. These new screen size definitions are added to the screen sizes that were previously defined.

IMS online change also plays an important part in updating the MFS libraries, even though it is not part of MFS. Briefly, online change allows the control block libraries to be modified while the IMS control region is running.

Related Reading: For a complete description of online change, see IMS Version 9: Administration Guide: System.

Figure 17-2 on page 301 shows an overview of the MFS utilities and their output. For information about these utilities, see IMS Version 9: Utilities Reference: Database and Transaction Manager.

Figure 17-2. MFS Utilities and Their Output

Figure 17-3 shows the MFS online environment. The steps that follow correspond to the numbers in Figure 17-3.

Figure 17-3. Overview of the MFS Online Environment

1.	An input message is sent to the MFS message editor from the terminal.
2.	The MFS message editor requests a pointer (the address) to the MFS control blocks from the MFS pool manager.
3.	The MFS pool manager checks the message format buffer pool to see if the control blocks exist in the pool. If the control blocks are not in the buffer pool, the MFS pool manager reads the control blocks from IMS.FORMAT and places them in the buffer pool.
4.	The MFS pool manager sends the address of the MFS control blocks to the MFS message editor.
5.	The MFS message editor formats the input message for the application program.
6.	The MFS message editor sends the formatted input message to the message queue to be processed.
7.	The application program processes the message and sends the output message to the message queue.
8.	The output message is sent from the message queue to the MFS message editor.
9.	MFS processes the output message for the terminal just as it processed the input message (steps 2 through 6).
10.	The formatted output message is sent to the terminal.

Figure 17-4 show the MFS test environment. The steps that follow correspond to the numbers in Figure 17-4.

Figure 17-4. Overview of the MFS Test Environment

1.	The input message is sent to the MFS message editor from the terminal.
2.	The MFS message editor requests a pointer to MFS control blocks from the MFSTEST pool manager.
3.	The MFSTEST pool manager checks the communication-line buffer pool to see if the control blocks exist in the buffer pool. If the blocks are not in the buffer pool, the MFS pool manager reads the blocks from IMS.TFORMAT and places them in the buffer pool.
4.	The MFSTEST pool manager sends the address of the MFS control blocks to the MFS message editor.
5.	The MFS message editor formats the input message for the application program.
6.	The MFS message editor sends the formatted input message to the message queue to be processed.
7.	The application program processes the message and sends the output message to the message queue.
8.	The output message is sent from the message queue to the MFS message editor.
9.	MFS processes the output message for the terminal just as it processed the input message (steps 2 through 6).
10.	The formatted output message is sent to the terminal.

The MFS message editor and MFS pool manager operate online during the normal production mode of operation. The MFS message editor performs the actual message formatting operations using the control block specifications.

In MFS test mode, the MFS Language utility can run at the same time as the online IMS control region. However, you must use the online change procedure to modify MFS formats when not in IMS test mode.

Administering MFS

To take full advantage of the flexible message formatting options offered by MFS and to ensure efficient MFS operation, you should appoint an MFS administrator. The MFS administrator is responsible for MFS implementation and administration and should coordinate MFS application design and programming for the installation.

The responsibilities of an MFS administrator include:

• Establishing procedures for the submission of MFS control block requests by application development personnel.

• Establishing procedures and controls for the application of changes to the IMS.TFORMAT library.

• Defining MFS control blocks most efficiently in keeping with the requirements of the specific application and the overall system.

• Minimizing device character transmission, sharing MFS control blocks, and ensuring the most efficient use of MFS without jeopardizing application requirements or operator considerations.

• Establishing and documenting operator guidelines and system standards for MFS. The many options that MFS offers can result in confusing practices, unless you establish and follow standard procedures. Be sure to standardize certain aspects of format design in order to minimize terminal operator training and error rates.

• Deciding if and how the optional index directory should be used and determining buffer pool requirements.

• Monitoring the use of the MFS control blocks and of the MFS buffer pool with the IMS /DISPLAY command and IMS Monitor report output, and modifying MFS parameters as required.

• Making end users aware of the operating characteristics of the different device types and terminal subsystems.

• Informing others about the differences between the various partition formats.

• Establishing and informing others about naming conventions and guidelines. In particular, the MFS administrator should be able to discuss naming conventions for the partition descriptor blocks and the sizes of the display screen, the viewports, and the display characters.

• Communicating information about conventions for and restrictions on MFS formats.

• Defining screen sizes and feature combinations that are not included in the IMS stage1 system definition.

• Creating the MFS device characteristics table control statements for processing by the MFSDCT utility (DFSUTB00). The MFS device characteristics table entries and default format control blocks are used for ETO terminals.

• Defining input message field edit routines and segment edit routines. MFS and all MFS-supported devices are able to use message edit routines. You can use these exit routines for such common editing functions as numeric validation or the conversion of blanks to zeros.

  IMS provides a sample of both a field edit and a segment edit routine.

  Related Reading: For information about the timing within the MFS editing processing when these routines are activated, and the coding requirements for the routines, see IMS Version 9: Application Programming: Transaction Manager.

The MFS administrator should be technically competent in all aspects of IMS relative to MFS, including:

• Online transaction processing

• IMS API for message processing

• Operation with remote controllers

• MFS implementation, device characteristics, and capabilities

• Interpretation of MFS statistics and related IMS Monitor report output

The administrator should also be familiar with the hardware and remote programs for SLU-P, Finance remote programs, or ISC subsystems if such programs are going to operate with MFS by using distributed presentation management.

In addition, the administrator should be familiar with the terminal hardware characteristics because one administrative responsibility is minimizing device character transmission.

An MFS administrator must communicate with IMS system administrators and application developers, as well as programmable workstation developers and end users. The MFS administrator must be able to enforce installation standards and to modify application specifications for MFS control blocks when necessary to benefit overall system performance. The procedures of related programming groups should recognize this authority of the MFS administrator.

MFS Control Blocks

MFS uses the following four types of control blocks to format input and output messages for application programs, terminals, or remote programs:

• Message output descriptors (MODs): Define the layout of messages that MFS receives from the application program

• Device output formats (DOFs): Describe how MFS formats messages for each of the devices with which the program communicates

• Device input formats (DIFs): Describe the formats of messages MFS receives from each of the devices with which the program communicates

• Message input descriptors (MIDs): Describe how MFS formats messages so that the application program can process them

A MID and MOD that work together as a set are collectively called a message descriptor. A DIF and DOF that work together as a set are collectively called a device format.

Because each MOD, DOF, DIF, and MID deals with a specific message, both a MOD and DOF must exist for each unique message that a program sends, and both a DIF and MID must exist for each unique message that a program receives.

Figure 17-5 shows how the input data from a terminal in formatted mode is mapped by MFS (using a DIF and a MID) to the message format that is presented to the application program.

Figure 17-5. MFS Input Formatting

In Figure 17-5, the DIF contains a list of device descriptor fields (DFLDs) that define what data is expected from which part of the device (that is, the location on the screen). The MID contains a list of message descriptor fields (MFLDs) that define the layout of the input segment as it is presented to the application program. MFS maps the data of the DFLDs into the corresponding MFLDs. The application program is primarily device independent because different physical inputs can be mapped into the same input segment. When the application program finishes its processing, the reverse mapping process occurs to deliver the result back to the device.

MFLD statements define:

• The device fields (DFLDs) defined in the DIF, the contents of which are included in the message presented to the application program.

• Constants, defined as literals to be included in the message: A common use of literals is to specify the transaction code.

In addition, the MFLD statement defines:

• The length of the field expected by the application program

• Left or right justification and the fill character to be used for padding the data received from the device

• A 'nodata' literal for the MFLD if the corresponding DFLD does not contain any input data

Advantages to Using MFS

Two primary advantages to using MFS are that it:

• Simplifies the development and maintenance of terminal-oriented application systems

• Improves online performance

To simplify IMS application development and maintenance, MFS performs many common application program functions and gives application programs a high degree of independence from specific devices or remote programs.

With the device independence (the ability to communicate with different types of terminals without having to change the way it reads and builds messages) offered by MFS, one application program can process data to and from multiple device types while still taking advantage of their different capabilities. Thus, MFS can eliminate or minimize the changes in application programs when new terminal types are added.

When the application program receives a message from a terminal, how the message appears in the program's I/O area is independent of the type of terminal that sent it; the appearance depends on the MFS options specified for that program. If the next message that the application program receives is from a different type of terminal, the user does not need to do anything to the application program. MFS shields the application program from the physical device that is sending the message in the same way that a database program communication block (PCB) shields a program from the data in the database and how it is stored.

Other common functions MFS performs include left or right justification of data, padding, exit routines for validity checking, time and date stamping, page and message numbering, and data sequencing and segmenting. When MFS performs these functions, the application program handles only the actual processing of the message data.

Related Reading: For information on user-written exit routines and how to use them, see IMS Version 9: Customization Guide.

MFS also improves online performance of a terminal-oriented IMS by using control blocks that are designed for online processing. The MFS control blocks are compiled offline, when IMS is not being executed, from source language definitions. MFS can check their validity and make many decisions offline to reduce online processing. In addition, during online processing, MFS uses look-aside buffering of the MFS control blocks in order to reduce CPU usage and the channel costs of input/output activity.

Online storage requirements are also reduced because MFS control blocks are reentrant and can be used for multiple applications. Optional main-storage indexing and anticipatory fetching of the control blocks can also reduce response time. IMS gains additional performance improvements because multiple I/O operations can execute concurrently in loading the format blocks from the MFS format library.

In addition, MFS uses z/OS paging services to reduce page faults by the IMS control region.

Finally, MFS can reduce the volume of data that travels across communication lines. Compressing and transmitting only the required data reduces line load and improves both response time and device performance.