Processing Modes in IMS - Batch DL/I , BMP , MPP Data Communication network - Components of a telecommunication network - Host system,

Communication Controller, Modems, Telecommunication Lines, Terminals Basic Components of IMS/DC Environment & their description - IMS Control Region - IMS MPP Region - Terminals - Transactions - Message Queues - Online Log Datasets - Online IMS Databases - IMS/DC Application programs How IMS manages for input messages - Kind of input messages Transactions, Message Switches, IMS Commands - Message Queue, Class, Priority, Limit Priority, Limit Count Message Format Services (MFS) - Control Blocks Explanation of DIF,DOF,MID,MOD with diagrams - An example of designing a plain screen and its interaction with IMS/DC application program(MPP) Concepts of I/O PCB - DL/I function in a IMS/DC call. PCB mask in a IMS/DC call. - How to retrieve single-segment input messages. Alternate Destination Concepts. - ALT PCBS. - How to route output to alternate destinations from your application programs. Different calls associated ISRT,CHNG,PURGE Conversational Application. - Concept of Scratch Pad Area(SPA) - Details of SPA. Error Handling in the IMS/DC Environment.

Logging, Recovery, Checkpointing , IMS/DC Return Codes ***************************

Concepts of Batch DL/I, BMP, MPP ================================== Basically IMS has got three types of processing modes 1. Batch DL/I This is very much similar to a non-IMS program IMS database files as well as non-IMS files may be read, updated and reports may be written IMS application program calls DL/I modules to access IMS database Each DL/I batch job uses its own separate Log to keep track of changes made to IMS database Example : A monthly JOB that prints a roster report of Employees by Dept 2. Batch Message Processing (BMP) These programs can do the same functions of DL/I and even do more. These are also submitted through OS JCL. Difference between BMA programs and DL/I programs : BMPs can access and even update "ON-LINE" databases; DL/I programs cannot do this ! : BMPs use and share "ON-LINE" log datasets; : BMPs can access the "ON-LINE" INPUT MESSAGE QUEUE, and can send messages to the OUTPUT MESSAGE QUEUE.

3. Message Processing Prgram(MPP) This is what we normally refer to as ON-LINE IMS or IMS-DC environment

The IMS/DC (Data Communications) system provides users on-line "real time" access to information in IMS databases. MPP programs use DC calls to access transactions from the input message queues to send output messages back to the user at the terminal device use DB calls to access IMS databases Example : An inquiry transaction to display information about a specific employee or an update transaction to change the address of an employee MPP programs are not submitted through OS JCL rather these are automatically scheduled by online IMS control region that is necessary to process a transaction Basics of Data Communication ======================= Brief description of data communication network which is also called telecommunication networks which permits users at local terminals (remote terminals) to access host computers. Five basic components comprise a typical telecommunication network. 1. Host system 2. Communication controller 3. Modems 4. Telecommunication lines 5. Remote terminals Host system ========= For IMS , the host system is nothing but a System/370-family processor. A telecommunication monitor runs in the host system processor to control

interactive application programs and to manage database& file processing. To control these functions , host system uses a telecommunication access method(Virtual Telecommunication Access Method)VTAM.

Communication Controller ======================== It manages the transmission of data over the communication line. It mainly performs - Data conversion, converting data into a form that modem can process - Data link control which ensures successful transmission of data over communication line, identifying source and destination of transmission detecting and correcting transmission errors, synchronizing the host with the remote terminals. Modems ======= A pair of modems required at each end of telecommunication line. It s function is to convert digital signals into analog and vice versa. Telecommunication Lines ======================= This is nothing but a phone connection which connects the host system with remote terminals. The types of telecommunication lines are 1) Dial-up line(Switched) 2) Dedicated line(Non-switched) This is when high volume of data is to be transmitted over long distances and the connection is always established. Remote terminals ================

These are the terminal systems attached to the host through a communication controller. This is where the users sit and do the interactions with the host. These terminals may be dumb terminals, PCs or special terminals like ATMs. Every terminal is assigned both a physical terminal name and a logical terminal name. Basic Components of IMS/ DC environment = = = = = = = = = = = = = = = = = = = = = = = ===== 1) IMS CONTROL REGION 2) IMS MPP REGION 3) TERMINALS 4) TRANSACTIONS 5) MESSAGE QUEUES 6) ON-LINE LOG DATASETS 7) ON-LINE IMS DATABASES 8) IMS/DC APPLICATION PROGRAM

IMS CONTROL REGION ======================= The "on-line IMS system" is a control program that executes continuously in the IMS CONTROL REGION, usually called IMS CTL. This program can run either as an MVS "started task" or "JOB step". What is owned by IMS CONTROL REGION ? IMS databases

IMS message queues IMS terminals IMS on-line logs IMS transactions What are the major functionalities of IMS CONTROL REGION ? receives TRANSACTIONS from TERMINALS, LOGs the transactions, stores them in messages QUEUES, schedules IMS/DC PROGRAMS to process the TRANSACTIONS.

IMS MPP REGION ================== MPPS, are usually started by the IMS Master Terminal Operator (MTO),and run either as an OS JOB step, or a started task. All IMS/DC application program logic is executed in the MPP region. There are usually multiple MPP regions, depending on the transaction workload. One MPP region may run many application programs, but only one application at a time.

TERMINALS ============= Users enter TRANSACTIONS from TERMINALS. IMS TERMINALS may be dumb terminals, PCs, or special terminals for example ATMs. Every terminal is assigned both a physical terminal name and a logical terminal name. The application programs refer to logical terminals

Thats why the program doesn't need to know if its talking to a dumb terminal or a PC. If a physical terminal breaks, then another terminal can be assigned to the Logical name . TRANSACTIONS ================= Users enter transactions from terminals.A transaction is a unit of work to be performed by the online IMS system for a user... for example, an inquiry or an update of a certain database record. The transaction code consists of 1 to 8 alphanumeric characters. Transaction Codes are one of three types of input messages that the online IMS system can process (the other two message types are switching of programs and IMS system commands. IMS/DC application programs process input message transactions. MESSAGE QUEUES =================== Input message transactions are sent to the IMS CONTROL REGION which places the message on an input message queue. Message queues may reside in main storage and on direct access storage devices. The IMS CONTROL REGION schedules the appropriate application program to process the input message on the input message queue. IMS schedules the transaction with the highest priority. The program may access IMS databases, and prepare an output message (to be sent back to the user requesting service) which is placed on the output message queue. When messages have been processed or received by the user, they are dequeued and the space in the queue is reused. ON-LINE LOG DATASETS ========================= Online log datasets are used to - log information about IMS transactions. - log information about changes made to IMS databases. - recover an IMS system when a failure occurs.

These are kept on direct access storage devices(DASDs). They are periodically archived to tape for storage for a longer period of time.

ON-LINE IMS DATABASES =========================== Online databases are accessed: - by on-line IMS/DC application programs using DL/I calls - to either retrieve data to be displayed on the user terminal, or allow the user to add, update, or delete data in one or more IMS database records. Online IMS databases can be accessed by multiple on-line transactions simultaneously. They cannot be accessed by DL/I batch programs.

IMS/DC APPLICATION PROGRAM ================================= IMS/DC application programs are written to process transactions input messages from the user terminals to access the IMS databases and to format output messages to be sent back to the user terminal. IMS/DC programs requires a PSB just like Batch DL/I programs which defines the logical view of the IMS databases needed for by the application program The Application Control Block is the combination of PSB and DBD for the application program. IMS management for input messages ================================= Kinds of input messages 1) Transactions 2) Terminal to terminal message switches 3) IMS commands

Transactions ============ basic unit of work. If the first eight characters of an input message is the name of an application program,then IMS knows that message is a transaction. Message Switches ================ This is an input message that is directed to another terminal. This is identified by IMS when first eight characters of input message contains a LTERM's(Logical Terminal) name. IMS commands ============ If the message begins with a slash,IMS interpretes it as a command.

When IMS receives a message from a terminal,it isn't passed immediately to the appropriate destination. It undergoes first 1) Basic Editing The communication control characters are stripped off from input messages and added to the output messages. 2) MFS Editing This does extensive editing functions which insulates the application program from the format of data entered from specific kind of terminal devices. It builds the input message that the application program will receive. After the edit procedure, the edited messages are queued in a message queue by queue manager. The transaction are stored in a message queue calles QPOOL which is an area of virtual storage within the IMS control region which can be extended if necessary into overflow datasets on DASD.

Afetr the edited input message beginning with the transaction code queued in Qpool are scheduled depending on several things like class,priority,limit priority,limit count. Wait For Input program(WFI): always loaded into the dependent regions for most frequently accesed input messages.

Information Management System-Data Communication

IMS DC or IMS Data communication is a system that facilitates online transactions. There are 3 components involved in DC programming

1. You code the screen format.(MFS) i.e. what the front end screen should look like - this is analogous to designing a screen in VB 2. Next , u code the application program in a language like COBOL, PLI, or Assemble.(What you wish to do with the data collected from the screen) 3. Within the application program, u code 'CALL' statements to access the database and make use of DC. Notice the bidirectional arrows everywhere. The retrieved data is then passed back the same way i.e.database to program to screen . Now , onto the most important part of IMS/DC - The Message Q and the Q-manager. A queue as you must all have studied is a "first-in-firstout" structure. A transaction, defined very simply , is any unit of work. There exists a utility called IMSGEN which maps the transaction names and the program names. An active transaction causes the corresponding program to run.

Depending on the number of transactions in the DC region of the mainframe, multiple queues may be present. Depending on the transaction code, the message is inserted into the appropriate queue(and retrived upon request) by the queue manager. The queue manager is responsible for maintaining the queue.

MFS What is the need for MFS(Message formatting service)?? Well, What you must understand is that you are sending and receiving data from and onto your screen from a remote mainframe. It is common sense that the whole process gets speeded up if the amount of data that needs to be transmitted gets reduced. That's exactly what an MFS does. It basically sends (and receives) only necessary info (for example, blanks and labels need not be sent to the mainframe for processing). Inorder to coordinate the data that is sent and received, an MFS is used. About MFS(Message Formatting Service) Control Blocks MFS

To process any transaction, IMS uses 4 control blocks as shown in the fig. above.For an input message, MFS uses a block called device input format (DIF) to interpret data as it is received from the terminal.It uses a second block called Message Input Descriptor (MID) to determine how that input data should be formatted for presentation to the application program. For an output message, MFS uses similar blocks. A message output descriptor (MOD) is used to interpret data received from the application program,

and a device output format (DOF) is used to determine how the data should be formatted for transmission to the terminal. A group of related MID, MOD, DIF, DOF is called a format set. Type out the following code in the editor - create a PDS 'name.imsdc.mfs(sample)' . Remember the following

Columns 1-8 make up the label field (Obviously, the max length of a label is 8) The second field i.e. the Operation Field must begin from the 10th col. It contains names of the control statements like FMT, DFLD, MSG, DEV and so on.. The operand field is coded from the 16 col till the 71st col Continuation is indicated by a '*'(or any other character) in the 72 col, followed by beginning the continued line from the 16 th col in the following line.

Please note that all code on mainframe is extremely dependant on positioning and hence follow all the guidelines given above. Program 1 The aim is to create a screen that looks like this..............

Notice the following aspects about any screen from which user input is solicited...

There are labels (Non editable text entries that are just present for giving us information). For ex, in the above screen , text like '**ABC SERVICES LTD.**', **INSERTING EMPLOYEE DETAILS **' are there just for our information

There are text boxes which await input from the user. The dotted lines adjacent to 'EMPLOYEE CODE:', 'EMPLOYEE NAME:', and 'SALARY:' represent just that.

Now, Let's get on with the code...

PRINT ON,NOGEN EMPSCR FMT DEV TYPE=3270-A4,FEAT=IGNORE,DSCA=X'00A0' DIV TYPE=INOUT DPAGE CURSOR=((11,50)),FILL=PT

PRINT ON,NOGEN is a directive to the compiler. When the MFS is generated, by default, the hexadecimal code for each line is also generated. If u want to supress this, use the NOGEN parameter. If u want to supress the print listing altogether, use PRINT OFF. FMT keyword indicates that this is the beginning of the screen format. EMPSCR is the name assigned to this screen format. Please note that the length of this name cannot exceed 6 characters. The next statement is the DEV statement. This indicates the device type. Depending upon the number of rows and columns, terminals are divided into A1, A2 etc.. FEAT=IGNORE means 'ignore the features'. That means your blocks work with any combination of device features. How ever u can code FEAT to specify the exact configuration of optional features on the device for which you are coding the DEV statement. DSCA (Default System Control Area) has a special significance. You are most likely to code this value i.e. hex 00A0; this causes unprotected fields on the screen to be erased before output data is displayed. X'00C0' causes the entire device buffer to be cleared before output is written to the screen. DIV TYPE=INOUT indicates that the same device format specifications should be used to generate both a DIF and a DOF. Actually, a 3270 device must have the input and output fields the same. DPAGE statement lets us handle multiple logical pages (Don't bother about it right now ). But there are 2 other functions provided by the DPAGE statement . They are initial cursor positioning and field fill. DPAGE CURSOR=((11,50)),FILL=PT requests that the cursor be placed at location 11,50 and the fields be filled with Program Tab(PT).
PRINT ON,NOGEN EMPSCR FMT DEV TYPE=3270-A4,FEAT=IGNORE,DSCA=X'00A0' DIV TYPE=INOUT DPAGE CURSOR=((11,50)),FILL=PT

DFLD DFLD DFLD DFLD DFLD ECODE ENAME SALARY VMESG DFLD DFLD DFLD DFLD FMTEND

'**ABC SERVICES LTD.**',POS=(4,23), ATTR=(PROT,ALPHA,HI,NOMOD) '**INSERTING EMPLOYEE DETAILS **',POS=(7,27), ATTR=(PROT,ALPHA,HI,NOMOD) 'EMPLOYEE CODE:',POS=(11,30), ATTR=(PROT,ALPHA,HI,NOMOD) 'EMPLOYEE NAME:',POS=(13,30), ATTR=(PROT,ALPHA,HI,NOMOD) 'SALARY:',POS=(15,30), ATTR=(PROT,ALPHA,HI,NOMOD) POS=(11,50),LTH=4, ATTR=(NOPROT,ALPHA,HI,MOD) POS=(13,50),LTH=25, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(15,50),LTH=7, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(24,28),LTH=40,ATTR=(PROT,HI,ALPHA,NOMOD)

* * * * * * * *

The statement that u will code most often is the DFLD statement. The DFLD statement specifies

Where on the screen a field is located The length of the field (with the LTH parameter) The attributes of the field

You need to code a label on the DFLD statement only when the device field it defines has to be related to a message field (for input, output or both). For example, consider the first DFLD statement ...
DFLD '**ABC SERVICES LTD.**',POS=(4,23), ATTR=(PROT,ALPHA,HI,NOMOD) *

This provides the screen title. There is no need for this to be sent to the program from the screen or back to the screen from the program. As a result, there is no need for me to code a label for this. Now, consider the following DFLD statement...
ECODE DFLD POS=(11,50),LTH=4, ATTR=(NOPROT,ALPHA,HI,MOD)

It defines that the device field will contain the employee code. This is referred to in the message descriptor statements (further down in the code) and so , a label (ECODE in this case) is essential. The LTH parameter specifies the length of the variable. As u would already have noticed, it is not necessary to code this parameter when a literal is being coded. MFS counts the number of characters in the literal and uses that value as the required field length (Phew! thank God!! at least this they thought of!!) The ATTR parameter allows u to specify values for the attributes of the device field.

ATTR= ALPHA ----NUM

NOPROT NORM ------ -----PROT NODISP -----HI

NOMOD ----MOD

Most of the attrib parameters are self explanatory! I will devote some time on MOD and NOMOD. These allow u to set the field's Modified Data Tag(MDT). The MDT indicates whether or not the data in the field has been modified since the last screen was sent to the device. Only fields whose MDT's are 'ON' are transmitted back to the host. Fields that really dont need to be transmitted , like captions and fields into which the operator did not enter data are bypassed. The result is improved telecommunications efficiency. Notice that the FMT statement is ended with an FMTEND. Here is the complete code...
PRINT ON,NOGEN EMPSCR FMT DEV DIV DPAGE DFLD DFLD DFLD DFLD DFLD ECODE ENAME SALARY VMESG SCRI01 DFLD DFLD DFLD TYPE=3270-A4,FEAT=IGNORE,DSCA=X'00A0' TYPE=INOUT CURSOR=((11,50)),FILL=PT '**ABC SERVICES LTD.**',POS=(4,23), ATTR=(PROT,ALPHA,HI,NOMOD) 'RETREIVING EMPLOYEE DETAILS **',POS=(7,27), ATTR=(PROT,ALPHA,HI,NOMOD) 'EMPLOYEE CODE:',POS=(11,30), ATTR=(PROT,ALPHA,HI,NOMOD) 'EMPLOYEE NAME:',POS=(13,30), ATTR=(PROT,ALPHA,HI,NOMOD) 'SALARY:',POS=(15,30), ATTR=(PROT,ALPHA,HI,NOMOD) POS=(11,50),LTH=4, ATTR=(NOPROT,ALPHA,HI,MOD) POS=(13,50),LTH=25, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(15,50),LTH=7, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(24,28),LTH=40,ATTR=(PROT,HI,ALPHA,NOMOD)

* * * * * * * *

SCRO01

DFLD FMTEND MSG TYPE=INPUT,SOR=(EMPSCR,IGNORE),NXT=SCRO01 SEG MFLD 'EMPLOYEE',LTH=8 MFLD ECODE,LTH=4 MSGEND MSG TYPE=OUTPUT,SOR=(EMPSCR,IGNORE),NXT=SCRI01 SEG MFLD ECODE,LTH=4 MFLD ENAME,LTH=25 MFLD SALARY,LTH=7 MFLD VMESG,LTH=40 MSGEND END

What has been added is the MID and MOD area . MSG identifies the beginning of a message descriptor.The TYPE parameter specifies whether the statements that follow generate a MID or a MOD. For example, TYPE=INPUT causes MFS to create a MID , and TYPE=OUTPUT causes MFS to create a MOD. Above SCRI01 is the name of the MID, and SCRO01 is the name of the MOD. The SOR an the NXT parameters are required on each msg statement. Since we dont want to question the syntax, we go ahead and code it as we are supposed to! Please note, EMPSCR is the Format name(or FMT name). The MID area contains (in addition to the fields that have to be transmitted to the program) , an 8 character Transaction code (EMPLOYEE in this case). Remember to end the mfs with an END statement always. So, finally you have coded your first screen layout! go ahead and generate the load module. Use TSO IMSMENU , invoke the 'generate MFS' option, specify the source PDS and the Load PDS. Please use the 'ONLINE' generate option (O). You will get the listing in the default pds. MESSAGE PROCESSING PROGRAMS(MPP) In this section, I shall explain how a COBOL program that can interface with DC and DB is to be written. Proficiency in IMS DB , and COBOL is assumed. Consider a simple program which uses the MFS that we just discussed The user is prompted to enter the 'Employee ID' . (Notice that this is the only non-protected (NOPROT) field). In case the employee ID is '1111', then the employee name ('SHANKAR') and the salary('1000') are displayed in the appropriate locations on the screen, along with a message. In case an ID other than '1111' is entered, an error message 'Invalid ID' is displayed. Just to refresh your memory, Let me rewrite the MFS that we had developed. There are a couple of points on which I want you to pay attention to....
PRINT ON,NOGEN EMPSCR FMT DEV DIV DPAGE DFLD DFLD DFLD TYPE=3270-A4,FEAT=IGNORE,DSCA=X'00A0' TYPE=INOUT CURSOR=((11,50)),FILL=PT '**ABC SERVICES LTD.**',POS=(4,23), ATTR=(PROT,ALPHA,HI,NOMOD) 'RETREIVING EMPLOYEE DETAILS **',POS=(7,27), ATTR=(PROT,ALPHA,HI,NOMOD) 'EMPLOYEE CODE:',POS=(11,30), ATTR=(PROT,ALPHA,HI,NOMOD)

* * *

DFLD DFLD ECODE ENAME SALARY VMESG SCRI01 DFLD DFLD DFLD

SCRO01

DFLD FMTEND MSG TYPE=INPUT,SOR=(EMPSCR,IGNORE),NXT=SCRO01 SEG MFLD 'EMPLOYEE',LTH=8 MFLD ECODE,LTH=4 MSGEND MSG TYPE=OUTPUT,SOR=(EMPSCR,IGNORE),NXT=SCRI01 SEG MFLD ECODE,LTH=4 MFLD ENAME,LTH=25 MFLD SALARY,LTH=7 MFLD VMESG,LTH=40 MSGEND END

'EMPLOYEE NAME:',POS=(13,30), ATTR=(PROT,ALPHA,HI,NOMOD) 'SALARY:',POS=(15,30), ATTR=(PROT,ALPHA,HI,NOMOD) POS=(11,50),LTH=4, ATTR=(NOPROT,ALPHA,HI,MOD) POS=(13,50),LTH=25, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(15,50),LTH=7, ATTR=(PROT,ALPHA,HI,NOMOD) POS=(24,28),LTH=40,ATTR=(PROT,HI,ALPHA,NOMOD)

* * * * *

I have shaded the MID area RED for you to notice certain subtle points.Notice the mandatory 8 character transaction code(EMPLOYEE in this case). Also , note that the only field that will be sent as input to our COBOL program is the ECODE field (Because this is the only field that appears in the MID area. Even if you had 10 other entries on the screen and passed only one of them in the MID, only that is received by the program) The MOD area is shaded GREEN . As you might have already guessed, these are the fields that are received from the COBOL program and passed onto the screen for display. Please ensure that all the fields which have labels (ECODE,ENAME,SALARY,VMESG) appear either in the MID or the MOD area. In case there is a label that does not appear either in the MID or the MOD, then MFSGEN will return an error code of '4'. COBOL code
000100 000200 000300 000400 000500 000600 000700 IDENTIFICATION DIVISION. PROGRAM-ID. SAMPLE. ENVIRONMENT DIVISION. DATA DIVISION.

If you have seen any code that is supposed to be in COBOL, then you must have seen the above sections. So, I am not going to get into the basics of COBOL now. So, we continue..
000100 000200 000300 000400 000500 000600 000700 000900 001000 001100 001200 001300 001400 001500 001600 001700 001800 001900 002000 002100 002200 002300 IDENTIFICATION DIVISION. PROGRAM-ID. SAMPLE. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 INPUT-MESSAGE-AREA. 05 IP-LL PIC S9(3) COMP. 05 IP-ZZ PIC S9(3) COMP VALUE 0. 05 TRANCODE PIC X(8). 05 IP-DATA. 10 EMP-ECODE PIC X(4). 01 OUTPUT-MESSAGE-AREA. 05 OP-LL PIC S9(3) COMP VALUE +80. 05 OP-ZZ PIC S9(3) COMP VALUE 0. 05 OP-DATA. 10 OP-EMP-ECODE PIC X(4). 10 EMP-ENAME PIC X(25). 10 EMP-SALARY PIC X(7). 10 OP-MSG PIC X(40).

Well, Well, Now, things are hotting up! In the working storage area , I have defined 2 group items INPUT-MESSAGEAREA and OUTPUT-MESSAGE-AREA. As I already told you earlier, Programming in DC is nothing. It just requires a couple of calls to transfer messages to and from the variables in the program. I intend to capture the entries made by the user on the screen in the INPUT-MESSAGE-AREA and put the data which I send back to the user into OUTPUTMESSAGE-AREA. Sure enough, the INPUT-MESSAGE-AREA resembles the MID area and the OUTPUT-MESSAGE-AREA resembles the MOD area . Well, IMS requires LL and ZZ fields that we code . Both are S9(3) values. LL represents the length of the message and ZZ is IMS reserved (supposed to be Zero). While IMS automatically computes the length of the Input message and substitutes it for IM-LL, WE are expected to feed it when sending the output .
000100 IDENTIFICATION DIVISION. 000200 000300 PROGRAM-ID. SAMPLE. 000400 000500 ENVIRONMENT DIVISION. 000600

000700 000900 001000 001100 001200 001300 001400 001500 001600 001700 001800 001900 002000 002100 002200 002300 002400 002500 002600 002700 002800 002900 003000 003100 003200 003300 003400 003500

DATA DIVISION. WORKING-STORAGE SECTION. 01 INPUT-MESSAGE-AREA. 05 IP-LL PIC S9(3) COMP. 05 IP-ZZ PIC S9(3) COMP VALUE 0. 05 TRANCODE PIC X(8). 05 IP-DATA. 10 EMP-ECODE PIC X(4). 01 OUTPUT-MESSAGE-AREA. 05 OP-LL PIC S9(3) COMP VALUE +80. 05 OP-ZZ PIC S9(3) COMP VALUE 0. 05 OP-DATA. 10 OP-EMP-ECODE PIC X(4). 10 EMP-ENAME PIC X(25). 10 EMP-SALARY PIC X(7). 10 OP-MSG PIC X(40). 01 DLI-FUNC. 05 DLI-GU PIC X(04) VALUE 05 DLI-GN PIC X(04) VALUE 05 DLI-GNP PIC X(04) VALUE 05 DLI-GHU PIC X(04) VALUE 05 DLI-GHN PIC X(04) VALUE 05 DLI-GHNP PIC X(04) VALUE 05 DLI-ISRT PIC X(04) VALUE 05 DLI-REPL PIC X(04) VALUE 05 DLI-DLET PIC X(04) VALUE 05 DLI-CHNG PIC X(04) VALUE 05 DLI-PURG PIC X(04) VALUE

'GU '. 'GN '. 'GNP '. 'GHU '. 'GHN '. 'GHNP'. 'ISRT'. 'REPL'. 'DLET'. 'CHNG'. 'PURG'.

Well, DLI-FUNC is a group which holds all the valid DLI calls. It is a normal practice to incorporate this as a copybook and use it from within the program. I have coded it here just to enhance the clarity of the program.
000100 000200 000300 000400 000500 000600 000700 000900 001000 001100 001200 001300 001400 001500 001600 001700 001800 001900 002000 002100 002200 002300 IDENTIFICATION DIVISION. PROGRAM-ID. SAMPLE. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 INPUT-MESSAGE-AREA. 05 IP-LL PIC S9(3) COMP. 05 IP-ZZ PIC S9(3) COMP VALUE 0. 05 TRANCODE PIC X(8). 05 IP-DATA. 10 EMP-ECODE PIC X(4). 01 OUTPUT-MESSAGE-AREA. 05 OP-LL PIC S9(3) COMP VALUE +80. 05 OP-ZZ PIC S9(3) COMP VALUE 0. 05 OP-DATA. 10 OP-EMP-ECODE PIC X(4). 10 EMP-ENAME PIC X(25). 10 EMP-SALARY PIC X(7). 10 OP-MSG PIC X(40).

002400 01 DLI-FUNC. 002500 05 DLI-GU PIC X(04) 002600 05 DLI-GN PIC X(04) 002700 05 DLI-GNP PIC X(04) 002800 05 DLI-GHU PIC X(04) 002900 05 DLI-GHN PIC X(04) 003000 05 DLI-GHNP PIC X(04) 003100 05 DLI-ISRT PIC X(04) 003200 05 DLI-REPL PIC X(04) 003300 05 DLI-DLET PIC X(04) 003400 05 DLI-CHNG PIC X(04) 003500 05 DLI-PURG PIC X(04) 003600 003700 LINKAGE SECTION. 003800 003900 01 IO-PCB-MASK. 004000 02 LTERM-NAME PIC 004100 02 DLI-RESERVE PIC 004200 02 STATUS-CODE PIC 004300 02 PREFIX. 004400 03 JULIAN-DATE PIC 004500 03 TIME-OF-DAY-IMS PIC 004600 03 MSG-SEQ PIC 004700 02 MOD-NAME PIC 004800 02 USERID PIC

VALUE VALUE VALUE VALUE VALUE VALUE VALUE VALUE VALUE VALUE VALUE

'GU '. 'GN '. 'GNP '. 'GHU '. 'GHN '. 'GHNP'. 'ISRT'. 'REPL'. 'DLET'. 'CHNG'. 'PURG'.

X(8). X(2). X(2). S9(7) COMP-3. S9(7) COMP-3. S9(7) COMP. X(8). X(8).

The next area which deserves attention is the LINKAGE SECTION. You may recollect that the linkage section basically connects the program to external references. When DC is being used ,it is a must to include what is called the IO-PCB-MASK, and the structure must be similar to what is given above. This is used by IMS. The 'status-code' field is checked after the call to determine if the call was successful. a status-code of ' '(SPACES) indicates that there was no error. The status code is 'QC' or 'QD' in case the message queue is empty . The status-code field is what you will use often in this structure.
000100 000200 000300 000400 000500 000600 000700 000900 001000 001100 001200 001300 001400 001500 001600 001700 IDENTIFICATION DIVISION. PROGRAM-ID. SAMPLE. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 INPUT-MESSAGE-AREA. 05 IP-LL PIC S9(3) COMP. 05 IP-ZZ PIC S9(3) COMP VALUE 0. 05 TRANCODE PIC X(8). 05 IP-DATA. 10 EMP-ECODE PIC X(4). 01 OUTPUT-MESSAGE-AREA. 05 OP-LL PIC S9(3) COMP VALUE +80.

001800 001900 002000 002100 002200 002300 002400 002500 002600 002700 002800 002900 003000 003100 003200 003300 003400 003500 003600 003700 003800 003900 004000 004100 004200 004300 004400 004500 004600 004700 004800 004900 005000 005100 005200 005300 005400 005500 005600 005700 005800 005900 006000 006100 006200 006300 006400 006500 006600 006700 006800 006900 007000 007100 007200 007300 007400

05 OP-ZZ PIC S9(3) COMP VALUE 0. 05 OP-DATA. 10 OP-EMP-ECODE PIC X(4). 10 EMP-ENAME PIC X(25). 10 EMP-SALARY PIC X(7). 10 OP-MSG PIC X(40). 01 DLI-FUNC. 05 DLI-GU PIC X(04) VALUE 05 DLI-GN PIC X(04) VALUE 05 DLI-GNP PIC X(04) VALUE 05 DLI-GHU PIC X(04) VALUE 05 DLI-GHN PIC X(04) VALUE 05 DLI-GHNP PIC X(04) VALUE 05 DLI-ISRT PIC X(04) VALUE 05 DLI-REPL PIC X(04) VALUE 05 DLI-DLET PIC X(04) VALUE 05 DLI-CHNG PIC X(04) VALUE 05 DLI-PURG PIC X(04) VALUE LINKAGE SECTION. 01 IO-PCB-MASK. 02 LTERM-NAME 02 DLI-RESERVE 02 STATUS-CODE 02 PREFIX. 03 JULIAN-DATE 03 TIME-OF-DAY-IMS 03 MSG-SEQ 02 MOD-NAME 02 USERID PROCEDURE DIVISION. PIC X(8). PIC X(2). PIC X(2). PIC PIC PIC PIC PIC

'GU '. 'GN '. 'GNP '. 'GHU '. 'GHN '. 'GHNP'. 'ISRT'. 'REPL'. 'DLET'. 'CHNG'. 'PURG'.

S9(7) COMP-3. S9(7) COMP-3. S9(7) COMP. X(8). X(8).

ENTRY 'DLITCBL' USING IO-PCB-MASK. 1000-MAIN-PARA. CALL 'CBLTDLI' USING DLI-GU IO-PCB-MASK INPUT-MESSAGE-AREA. PERFORM 2000-GET-INPUT THRU 2000-EXIT-PARA UNTIL STATUS-CODE OF IO-PCB-MASK NOT = SPACES. GOBACK. 1000-EXIT-PARA. EXIT. 2000-GET-INPUT. IF EMP-ECODE = '1111' MOVE '1111' TO OP-EMP-ECODE MOVE 'SHANKAR' TO EMP-ENAME MOVE '100' TO EMP-SALARY MOVE 'DATA RETRIEVED' TO OP-MSG ELSE MOVE SPACES TO OP-EMP-ECODE MOVE SPACES TO EMP-ENAME MOVE SPACES TO EMP-SALARY MOVE 'INVALID EMPCODE' TO OP-MSG END-IF. PERFORM 3000-INSERT-SCREEN-PARA THRU 3000-EXIT-PARA.

007500 CALL 'CBLTDLI' USING 007600 007700 007800 2000-EXIT-PARA. 007900 EXIT. 008000 3000-INSERT-SCREEN-PARA. 008100 CALL 'CBLTDLI' USING 008200 008300 008400 3000-EXIT-PARA. 008500 EXIT.

DLI-GU IO-PCB-MASK INPUT-MESSAGE-AREA.

DLI-ISRT IO-PCB-MASK OUTPUT-MESSAGE-AREA.

So, we have finally come to the procedure division. The first statement to be coded is the 'ENTRY' statement-' ENTRY 'DLITCBL' USING IO-PCB-MASK. ' This statement tells the cobol compiler that DLI services are being utilised in the program. In case DC is being used , then the IO-PCB-MASK must be the first parameter to the 'USING' clause.In case other DB-PCB-MASKS are being used, they follow this. Also, note that the order in which these entries appear in the LINKAGE SECTION must match with those in the USING clause, or else, unexpected results will be obtained. After the ENTRY statement, the GU call is issued to retrieve the input message and place it in the INPUTMESSAGE-AREA. After this call, all that has been entered on the screen by the user is received into this area. Now, it is all yours! Do all the manipulation you want using simple cobol statements. Notice that immediately after this call , there is a loop.... PERFORM 2000-GET-INPUT THRU 2000-EXIT-PARA UNTIL STATUS-CODE OF IO-PCB-MASK NOT = SPACES. This checks the status-code returned by the GU call just issued. Since it is a success, it is SPACES. The loop is entered and the necessary manipulation is performed. Then, you are supposed to throw back the screen with data. This is done using the 'ISRT' (Insert) call. Move all the data that you want to be displayed into the OUTPUT-MESSAGEAREA, and issue the ISRT call as shown above. This data is now inserted into the message queue. Now, when the next GU call is encountered , It acts as a checkpoint and the screen is thrown with the output values as desired.

CONCEPTS OF I/O PCB DL/I data base call and a DL/I data communications call both invoke the cobol-dl/i interface module CBLTDLI and both specify a DL/I function, a PCB mask,and an I/O area but in case DC there is no SSA. DL/I function in a DC call. 1)GU get unique 2)GN get next 3)ISRT insert PCB MASK IN A DC CALL. It's different from the DB PCB mask. To provide address ability to it ur program must name its LINKAGE SECTION mask defination on the ENTRY statement at the beginning of the procedure Division. It must be the PCB listed on the ENTRY statement.
01 IO-PCB-MASK. 05 IO-PCB-LOGICAL-TERMINAL 05 FILLER 05 IO-PCB-STATUS-CODE 05 IO-PCB-DATE 05 IO-PCB-TIME 05 IO-PCB-MSG-SEQ-NUMBER 05 IO-PCB-MOD-NAME 05 IO-PCB-USER-ID

PIC X(8). PIC XX. PIC S9(5) COMP. PIC X(8). PIC X(8). PIC XX. PIC S9(7) COMP-3. PIC S9(6)V9 COMP-3.

The first field called IO-PCB-LOGICAL-TERMINAL contains eight byte LTERM name of the terminal that sent the current input message. because the ims keeps track of the terminal that was the source of the input message our pgm does not have to identify the source and specify the destination of the i/O PCB on the isrt call that sends an output message and ims takes care of routing the output message back to the terminal that originated the current input message. It is possible to route an output message to destination other than the terminal that originated the input message.

For this we don't have to change the LTERM name in the I/O PCB. Instead we have to use another data communications PCB, called the alternate PCB. The next two bytes are reserved for IMS and the next two are the status code. In position 13-16 contains the date when IMS queued the message. Its in format YYDDD.17-20 contains the time when IMS queued the message.Its format is HHMMSST.21-24 the input sequence number we never need this. Next in the I/O pcb is an eight-byte alphanumeric field that contains the name of the Message Format Service message defination(MOD) currently in use. Its possible to change the MOD by additional arguement on an isrt call for an output message segment. The last eight byte is an eightbyte alphanumeric field that may contain security information. The field may be blank or it may contain the user id of the operator who sent the input message or the LTERM name of the originating terminal. How to retrieve an input message. To retrieve an input message an application program issues either a single GU call or a GU call followed by one or more GN calls. How to retrieve single-segment input messages.
Call CBLTDLI USING DLI-GU IO-PCB-MASK INPUT-MESSAGE-SEGMENT.

if status-code = 'qc' move 'y' to end-of-message-sw. and if the status code of PCB is 'QC' it knows that there are no more messages for it on the queue and it ends. How to retrieve multiple segment input messages. To retrieve the first segment we issue a 'GU' call and if there are more message and we issue a 'GN' call repeatedly until it encounters a 'QD' status code.

Alternate destination concepts.

An application program thats processing a single input message can send multiple output message to multiple destinations. To send an output to an alternate destination the application program issues an isrt call just as it does for a message that bound for the originating terminal. The difference is that the ISRT call dosen't specify the name of the IOpcb but rather of an alternate PCB. The alternate PCB'S we will use for an application have to be defined in the application PSB GEN JOB. IT is the DATA BASE ADMINISTRATOR who is responsible for PSBGENS. Two types of ALT PCBs. When the system adminstrator defines an application's alternate PCB specifies whether each is a modifiable PCB or a fixed alternate PCB. If a PCB is a MODIFIABLE the application program can change the terminal or program to which associated output messages are sent such a destination is called a modifiable alt destination. 1)MODIFIABLE 2)FIXED PCBS. How to code alternate PCB masks in your application programs. 01 ALT-PCB-MASK. 05 ALT-PCB-DESTINATION PIC x(08). 05 FILLER PIC x(02). 05 ALT-PCB-STATUS-CODE PIC XX.

The ENTRY statement at the beginning of the procedure division lists the names of all the PCBs that the program uses. They are listed on the entry statement in the same sequence that they are coded in the PSBGEN job. How to route output to alternate destinations from your application programs. ISRT call to send a message to an alternate destination:
CALL 'CBLTDLI' USING DLI-ISRT ALT-PCB-MASK OUTPUT-MESSAGE-IO-AREA.

The only difference between this call and a typical DC ISRT call is that it names the alternate PCB instead of the I/O PCB. We should use this technique to route output to both fixed and modifiable alternate destinations. However to send output to a modifiable alternate destination, we have to do some preliminary work. How to route output to modifiable alternate destinations from your application programs. ISRT call is the same as for a fixed alternate PCB but before issuing it we have to be sure the alternate PCB specifies the right destination. To do that we use a call 'CHNG'.

CALL 'CBLTDLI'

USING

DLI-CHNG ALT-PCB-NAME WS-DESTNATION-NAME.

The change call tells IMS to store the name of a destination we supply in a modifiable alternate PCB so we can issue ISRT calls against it and have the message routed properly. The second argument in the call is the name of the mask in your program for the PCB whose destination you want to change. Finally ,the third arguments is the name of an eight-byte working storage field that contains the new destination name field in the alternate PCB mask for this. We should always issue the CHNG call between a "GU" call to the I/O PCB to retrieve a new input message and the first ISRT call that specifies the modifiable alternate PCB for that transaction, even if the destination u specify is the same as for the previous transaction. That's because the GU call can invalidate the destination stored in the alternate PCB we can't be sure that the alternate destination we used for one transaction will be retained for he next. There are case when we want to send same output message to several alternate destination all via the same alternate PCB.

If so we will have to change the alternate destination specified in a PCB after output has been sent via that PCB for the first destination. We do that with the CHNG call, but only after we have told IMS the message that the message to the first alternate destination is complete. The purge call indicates to IMS that the message we have been building through the alternate PCB is complete and we want to build another message for another destination.
CALL 'CBLTDLI' USING DLI-PURG ALT-PCB-MASK.

Sequence of CALLS to send the same output message to three different terminals all vai the same modifiable alternate PCB.
MOVE 'LACCTP01' TO ALTERNATE-DESTINATION-NAME. CALL 'CBLTDLI USING DLI-CHNG ALT-PCB-MASK ALTERNATE-DESTINATION-NAME. CALL 'CBLTDLI' USING DLI-ISRT ALT-PCB-MASK OUTPUT-MESSAGE-IO-AREA. CALL 'CBLTDLI' USING DLI-PURG ALT-PCB-MASK. MOVE 'LRECVP01' TO ALTERNATE-DESTINATION-NAME. CALL CALL CALL 'CBLTDLI USING DLI-CHNG ALT-PCB-MASK ALTERNATE-DESTINATION-NAME. 'CBLTDLI' USING DLI-ISRT ALT-PCB-MASK OUTPUT-MESSAGE-IO-AREA. 'CBLTDLI' USING DLI-PURG ALT-PCB-MASK.

MOVE 'LWH05P01' TO ALTERNATE-DESTINATION-NAME. CALL CALL 'CBLTDLI USING DLI-CHNG ALT-PCB-MASK ALTERNATE-DESTINATION-NAME. 'CBLTDLI' USING DLI-ISRT ALT-PCB-MASK OUTPUT-MESSAGE-IO-AREA.

How to Develop a conversational application Why we need conversational program. Say, for example, you need to add a new employee to the company employee database. You entered several different screens of information. Then a message comes back asking you to re-enter the birth date in the correct format. You correct your mistake and re-enter the birth date. At this time only the birth date is transmitted back . If all the data you entered previously was not saved in memory then u can't retrieve it. This is why you need to use conversational processing. All the data you enter is saved even if you make several mistakes and need to perform several transactions. This way you carry on a conversation with the computer and it remembers every word you say. In other words, every piece of data you enter is safely stored. You can store the data on the terminal screen. 2) store the data in the data base. 3) Store the data in an IMS provided scratch pad area. Storing the data on the terminal screen. The easiest technique is to store data on the user's terminal screen. we do this by transmitting the data to a particular fields on the screen from which it can be retransmitted back to the application program during the next interaction. The fields we use to store the data on the screen should be defined with thei modified data tags set to on. As a result the data in them is always transmitted back to application program. Often the data stored on the screen between interaction is kept in fields that are defined with NODISP and prot attributes, then the terminal user can't see or change the data. We use this technique only when a small amount of data is to be stored and the data is not critical. Storing data in a data base If more than just a little data needs to be stored e might consider using a data base. But here the program becomes more complicated and less efficient.

Storing data in a scratch pad area.(SPA).If u are using SPA it's a conversational program. In other words it's able to carry on a continous conversational with terminal user, even if it process transactions from other users between terminal interactions or is removed entirely from storage. A unique SPA is associated with each terminal thats running a conversational transaction. The SPA is retrieved along with input message. Then the program can use the data in the SPA to process the input. When output message is saved the SPA is saved too so it can be retrieved for the next terminal interaction. How to use the SPA. We just have to know how to define the I/O area that will be used for in our program and we need to know how to code the DL/I calls that will be used to retrieve and the SPA. Defining
01

the I/O area for the SPA

SPA-IO-AREA. 05 SPA-LL 05 SPA-ZZ 05 SPA-CI 05 SPA-TRANSACTION-CODE 05 SPA-USER-DATA

PIC PIC PIC PIC PIC

S9(4) COMP. S9(4) COMP. S9(4) COMP. X(8). X(...).

Its same like a message segment. here the third field SPACI is the conversational identifier which IMS uses to keep track of the SPA. The CI identifies a control block that ims maintains for our conversation. The CCB relates our SPA to our program and to our terminal. You never need to change the data in the CI field, in some program it is define as a filler with PIC X(4). Then comes the transaction code (7-14).IMS stores the transaction code your program does not. After the transaction code, we can define whatever fields we want in the SPA, up to the maximum size specified for it during IMS system generation.

Let's look at a sample flow diagram for a conversational MPP.

+----------------+ +---------------------------------+ C MPP Sample flow P +----------------------------+ U 1. Retrieve SPA input 2. Retrieve input message __ ---------- _ _ 3. Check SPA ____ output ____ ---------- 4. Send SPA to be modified _____ 5. Send output message Terminal +---------------------------------+ +----------------+ Some notes to remember: When a program has been designated to IMS as conversational, the first GU call which references the IOPCB will retrieve the SPA. The subsequent retrieval from the input queue will contain the input message, and should be made with the GN function code. For sending messages, IF the SPA must be changed, it will be inserted first with the ISRT call. all output messages will be inserted with ISRT.

On the following diagram, note the function calls that go with each program step.

+----------------+ +----------------------------+-------+-+ C MPP Sample flow Call P +------- U 1. Retrieve SPA GU 2. Retrieve input message GN 3. Perform application specific logic 4. Send SPA to be modified ISRT 5. Send output message ISRT +---------------------------- -+ +---+-6. Repeat steps 1-5 until-- -+--- no more messages -+-7. End conversation-------- ---8. End program------------- ------------------------------+-------+--

How do you make your IMS/DC conversational MPP terminate a conversation ? Put SPACES in the TRANSACTION CODE in the SPA ISRT the SPA

Do the above two steps and the conversation will terminate. Now, let's apply everything you've learned about conversational processing to an actual IMS/DC COBOL program....

First let's review the WORKING-STORAGE SECTION... +--------------------------------------------------------------------------+

01 INPUT-MSG. 03 03 03 03 LL ZZ PICTURE S999 COMP. PICTURE X(2). PIC X(9). PIC X(??). *** INPUT MESSAGE AREA *** WORKING-STORAGE SECTION.

TRANCODE IN-TEXT

5 *** ***

01

OUTPUT-MSG. 03 03 03 LL ZZ PIC S999 COMP.

*** OUTPUT MESSAGE AREA

PIC S999 COMP VALUE 0. PIC X(??).

OUT-TEXT

01

SPA-AREA. 03 03 LL ZZ PIC S999 COMP. PIC X(4).

*** HERE'S OUR SCRATCH PAD

03 03

TRAN-CODE SPA-DATA

PIC X(8). PIC X(50).

+--------------------------------------------------------------------------+

Next we'll look at the LINKAGE SECTION ... +------------------------------------------------------------------------+ LINKAGE SECTION. 01 IO-PCB. 02 TERMTRAN PICTURE X(8). -logical terminal name or transaction code 02 FILLER PICTURE X(2). -reserved by IMS 02 IO-STATUS PICTURE X(2). -status code after CALL 02 IN-PREFIX. 03 DATE PICTURE S9(7) COMP-3. -date, time, sequence 03 TIME PICTURE S9(7) COMP-3. number of the input 03 SEQNUM PICTURE S9(7) COMP-3. message 02 MFS-MODNAME PICTURE X(8). -MFS MODNAME (if MFS used) +------------------------------------------------------------------------+

the next section is the ...

PROCEDURE DIVISION

The Procedure Division of a conversational MPP is made up of groups of code which can be described as follows: +--------------------------------+ Components of MPP PROCEDURE DIVISION +-------------------------------- A. Entry statement B. 'GU 'to get SPA C. 'GN' to get input messages D. Send SPA to output queue E. Send output message F. End conversation G. End of program +--------------------------------+ The next diagram shows the relationship between the MPP flow diagram shown earlier and the program components. +----------------+ Components of MPP PROCEDURE DIVISION +------------------------------- C MPP Sample flow +++-++-- A. Entry statement P -+ U 1. Retrieve SPA B. 'GU' to get SPA 2. Retrieve input message C. 'GN' to get input messages 3. Perform application-specific logic ----+ 4. Send SPA to be modified-+-+ D. Send SPA to output queue 5. Send output message -+ E. Send output message +-------+-------------------------- -6. Repeat steps 1-5 until--- --- there are no more messages-++

-7. End conversation----------+ conversation -8. End program-------------- program -----------------------------

F. End G. End of

Now we'll look at each piece of code that goes with each component heading. +-------------------------------+ A. Entry statement +-------------------------------+ PROCEDURE DIVISION. ENTRY 'CBLTDLI' USING IO-PCB, ALT-PCB, DB-PCB. +-------------------------------+ B. 'GU' to get SPA +-------------------------------+ GET-SPA. * COMMENT: GU VIA IO-PCB GIVES THE SPA: CALL 'CBLTDLI' USING GU-FUNC, IO-PCB, SPA-AREA. IF IO-PCB-STATUS = 'QC' GO TO END-OF-PROGRAM. IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'. +-------------------------------+ C. 'GN' to get input messages +-------------------------------+ GET-INPUT-MSG. * COMMENT: GN OF IO-PCB GIVES THE INPUT MESSAGE: CALL 'CBLTDLI' USING GN-FUNC, IO-PCB, INPUT-MSG IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'. +-------------------------------+ D. Send SPA to output queue +-------------------------------+ PROCESS-100.

MOVE DATA-ABC TO SPA-DATA. CALL 'CBLTDLI' USING ISRT-FUNC, IO-PCB, SPA-AREA. IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'.

+-------------------------------+ E. Send output message +-------------------------------+ MOVE REPLY-ABC TO OUT-TEXT. CALL 'CBLTDLI' USING ISRT-FUNC, IO-PCB, OUT-AREA. IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'. +-------------------------------+ F. End conversation +-------------------------------+ PROCESS-END. MOVE SPACES TO TRAN-CODE. CALL 'CBLTDLI' USING ISRT-FUNC, IO-PCB, SPA-AREA. IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'. MOVE REPLY-END TO OUT-TEXT. CALL 'CBLTDLI' USING ISRT-FUNC, IO-PCB, OUT-AREA. IF IO-PCB-STATUS NOT = SPACES CALL 'ERROR'. +-------------------------------+ G. End of program +-------------------------------+ END-OF-PROGRAM. +------------------------------+ REMEMBER: NEVER SAY STOP RUN GOBACK. +------------------------------+

+------------------------------------------------+ By now you should be familiar with ... +------------------------------------------------+

_ _ _

the differences between non-conversational and conversational IMS/DC MPP processing. the structure of the SCRATCH PAD AREA (SPA) and the code for processing the SPA. how to code the IMS/DC CALLs required for conversational processing.

How to use program switching in conversational programs. Two kind of program switching 1) Immediate program switching 2) Deferred program switching Immediate program switching. The program that receive the input message is not the same one that responds to the terminal. Instead, the first program passes its SPA and any other necessary data to another program, which does additional processing and responds to the originating terminal. SEQUENCE OF THE CALL THE FIRST PROGRAM INVOVLED IN AN IMMEDIATE SWITCH ISSUES. CALL CBLTDLI USING DLI-GU IO-PCB-MASK SPA-IO-AREA CALL CBLTDLI USING DLI-GN IO-PCB-MASK INPUT-MSG-SEG : : CALL CBLTDLI USING DLI-ISRT ALTERNATE-PCB-MASK SPA-IO-AREA CALL CBLTDLI USING DLI-ISRT ALTERNATE-PCB-MASK SWITCH-MESSAGE-SEGMENT. After the first program has done this it can reply to the originating terminal.

Following are the calls made by the second program to retrieve the data passed by the first program. CALL CBLTDLI USING DLI-GU IO-PCB-MASK SPA-IO-AREA CALL CBLTDLI USING DLI-GN IO-PCB-MASK SWITCH-MESSAGE-SEGMENT. : : CALL CBLTDLI USING DLI-ISRT IO-PCB-MASK SPA-IO-AREA. CALL CBLTDLI USING DLI-ISRT IO-PCB-MASK OUTPUT-MESSAGE-SEGMENT 2) Deferred program switching. Its similar to the user simply invoking two separate applications one after another. The difference is that data stored in the SPA is passed from the first program to the second. This is called a "DEFERRED" message switch because the second program isn't invoked until the user sends the next input message. To achieve a deferred program-to-program message switch, the first program has to change the transaction code stored in the SPA to that of the second program before it saves the SPA. As a result when the next input message is received from the terminal, IMS knows that it should schedule the second program because its transaction code is already stored in SPA. The SPA is considered to be the first segment of an input message in a conversational pgm, and the transaction code stored in it -not the transaction code coming from the terminal determines what application program should be scheduled.