A conversational example

The following example shows how to use conversational processing to find out if a customer can qualify for a car loan.

This inquiry contains two parts. First, you give the name and address of the person requesting the loan and the number of years for which the person wants the loan. After you provide this information, IMS TM asks you for the information on the car: model, year, and cost. You enter this information, IMS TM invokes the program that processes this information, and the program tells you whether the loan can be granted.

If you use MFS, the process involves these steps:

Enter the format command (/FORMAT) and the MOD name. This tells IMS to format the screen in the way defined by this message output descriptor (MOD).
If the MOD name is CL, the command is:
```
/FORMAT CL
```
IMS TM then takes that MOD from the MFS library and formats your screen in the way defined by the MOD. When the MOD for the car loan application formats your screen, it looks like this:
```
CARLOAN
NAME:
ADDRESS:
YEARS:
```
The word CARLOAN is the transaction code for this application. Each transaction code is associated with an application program, so when IMS TM receives the transaction code CARLOAN, IMS TM knows what application program to schedule for this request.
Enter the customer's name and address, and the length of the loan. When you enter this information, your screen looks like this:
```
CARLOAN
NAME:    JOHN EDWARDS
ADDRESS: 463 PINEWOOD
YEARS:   5
```
IMS TM reads the transaction code, CARLOAN, and invokes the program that handles that transaction code. MFS formats the information from the screen for the MPP's I/O area by using the DIF and the MID.
When the MPP issues its first call, which is usually a GU for the SPA, IMS TM clears the SPA to binary zeros and passes it to the application program.
Next, the MPP processes the input data from the terminal and does two things. It moves the data that it will need to save to the SPA, and it builds the output message for the terminal in the I/O area. The information that the MPP saves in the SPA is the information the MPP will need when the second part of the request comes in from the terminal. You do not save information in the SPA that you can get from the database. In this example, you save the name of the customer applying for the loan, because if the customer is granted the loan, the program uses the customer name to locate the information to be updated in the database.
The program then issues an ISRT call to return the SPA to IMS, and another ISRT call to send the output message to the terminal.
The response that the MPP sends to the terminal gives IMS TM the name of the MOD to format the screen for the next cycle of the conversation. In that cycle, you need to supply the model, year, and cost of the car that John Edwards wants to buy. Your screen looks like this:
```
MODEL:
YEAR:
COST:
```
IMS TM again uses the device input format (DIF) and message input descriptor (MID) associated with the transaction code, and sends the information back to the MPP. The MPP has not been running all this time. when IMS TM receives the terminal input with the transaction code CARLOAN, IMS TM invokes the MPP that processes that transaction again for this cycle of the conversation.
IMS TM returns the updated SPA to the MPP when the MPP issues a GU, then returns the message to the MPP when the MPP issues a GN. The MPP does the required processing (in this case, determining whether the loan can be granted and updating the database if necessary), and is then ready to end the conversation. To do this, the MPP blanks out the transaction code in the SPA, inserts it back to IMS, then sends a message to the terminal saying whether the loan can be granted.