IMS DC - A TOOL FOR DATA COMMUNICATION

This is the tool to use for:

Data Transfer
Data Communication
Real Time Update
IMS DC stands for Data Communication in IMS between the user and the database.
IMS DC Scenario must have the following five entities at all times:
Host System
Work Stations
Communication Controller
Communication Modem
Telephone Lines
As you can well imagine, in a DC Program, the user is reaching and touching the database, so
they can also be called Interactive Programs.
There are four types of interactive or Real-Time programs, currently in use in IMS DC
environments and they are:
Inquiry Programs
Data Entry Programs
Maintenance Programs
Menu Programs
However, some companies may decide to merge several functions into one program, such as an
Update Program. This can help the user to add, change or delete record in one program. It is a
wise idea to have a Browse-Only Program.
An Inquiry Program is always designed to satisfy the need of a users question, which means it
needs to retrieve data stored in the specific storage area connected to the computer. It may be a
database, or tape, or flat file, whatever storage medium has been appointed.
Details about Data Entry Program
Unlike Inquiry Program, these programs are used to let the user add data to the systems
database. This capability is not given in the Inquiry Program. The complexity of this program is
clearly driven by the specific application requirement.
Details about Maintenance Program
Unlike Inquiry Program and Data Entry Programs, these types of programs have the capability to
add data, modify or completely replace the existing data or delete any data from the necessary
storage device. All these operations are done, depending on a key value.
Details about Menu Program
A Menu Program allows a user to select the function, he or she wants to perform. But it is done,
following a typical pattern, which means the menu program will transfer the control to another
program, depending on the selection, the user has entered.
Any application, which is built around a set of menu programs, is called a Menu Driven System.
Since the original menu program is written in such a way, which shows all the options available in
the total application. Then it transfers the control to other programs, based upon user response.
Types of operation that a menu program can handle
Execution details for the menu

As you have seen in the previous slide, it can be either touch-sensitive or can be activated by a
mouse. It can also be operated by a choice of number, as shown in the next slide.
SAMPLE OF A NUMBER DRIVEN MENU
Browse a Record
Add/Update a Record
Update History
As shown in the previous slide, by typing 1 or 2 or 3 on the keyboard invokes separate functions,
within the menu driven system.
In an IMS DC Network, It is expected that different user from different parts of a country will
access the computer which is located at a remote site, which is a basic tenet of an on-line or real
time application.
Elements of a Data Communication Network
A Host System
A Communication Controller
High Speed Modems
Telephone Lines
Display Terminal
Differences and similarities between an IMS DC Program and a normal Batch Program
For a typical Batch program, input is a record or a transaction from a file, which contains a
collection or a set of transaction records. The program performs the processing right from the
first record and it continues until all the records are processed and then it stops, when there are
no more records to process. The condition is stated in the program itself.
For an IMS DC Program?
The same entity, which is called a transaction or input in a batch program, is called an Input
Message, entered by a Terminal user, and it can be processed one at a time, if necessary.The
program performs the processing right from the first message to the last and then stops, just like
a normal Batch Program.
Basic Difference between the two class
In Batch Program
In IMS DC Program
Trans is Trans
Trans is Message
No Phone Lines
Phone Lines a must
No use of Modem
Use of modem a must
No Screen Design
Screen Design YES
Less Control Block
More Control Block
Similarities between IMS DB and DC
Just like the DB Programs, the DC Programs also communicate with the database, as well as the
user or programmer. Except several coding differences, both of them are the same. Of course,
there is a big difference in the connection mechanism, that is the PCB. As you know from DB,
that the application program communicates with the DL/I thru an entity, called LINKAGE
SECTION.
Another entity, which resides inside LINKAGE SECTION, is called PCB-MASK in the DB
Programs, and IO-PCB for DC Programs. The basic difference between these two entities are,
that IO-PCB takes into account of several things, which were not necessary in DB Program.

Please take a look at a IO-PCB and find the difference, by yourself.

How an IO - PCB looks like
01
IO-PCB-MASK.
05 IP-LTERM
05 FILLER
05 IP-STAT-CODE
05 IP-DATE
05 IP-TIME
05 IP-MSG-SEQ-NO
05 IP-MOD-NAME
05 IP-USER-ID

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

You can clearly see the difference. Except the Status Code, there is not one more match and this
is because of the data communication scenario, which is not there in a DB Program. All items are
comm-related.
Something to watch
An IMS DC Program is also known as a Message Processing Program or MPP.
A Message is a unit of data, which is transmitted between a program and the data source, that is
a user terminal. It can also be called a Transaction, because that is what it is.
Types of transaction in IMS DC
Basically, IMS DC supports three types of IMS Input messages and they really cover three
different areas of operation, as stated in the next slide.
Types of messages in IMS DC Applications
Normal Transactions
Terminal to Terminal Message switches
IMS Commands
Little bit more about Input
It is a standard process for IMS to identify the message type, by checking the contents of the first
eight bytes. If it reflects the name of an application program(which must be identified at the
system definition time), IMS can immediately identify it as a message. The first eight bytes of a
transaction is called a TRANSACTION CODE.
Exactly, the same way, when the first eight bytes contain an LTERM name, IMS will know
immediately that the message is a message switch. Care must be taken by the IMS Systems
Programmer or IMS DBA, whoever is responsible to make sure that the Application Program and
the LTERM, must not have the same name.
Last, but not the least, when a command starts with a slash, that is /, IMS knows immediately that
it is an IMS Command. Then the operand followed by / is analyzed by IMS to plan the next
action.
Similarities
In normal condition, a / followed by the word, FORMAT sends the message to the IMS that a
transaction screen need to be invoked.
/FORMAT DI20
is where the IMS Command is followed by DI20, which is a MOD name.
It will immediately invoke the screen associated with DI20 modname.

REGIONS IN IMS DC
An IMS System uses several user regions which really is the area, where IMS does its work. The
Application Programmer must know that it is there. Setting up and maintaining these regions are,
however, the responsibility of the IMS DBA or the IMS Systems Programmer. It is again, an
installation-dependent decision.
An IMS System uses several user regions and each in its own address space. All these regions
are managed from one, most important region, which is called CONTROL REGION. This is where
all the control programs reside. From this region, various IMS Components provide service to
support the rest of the system.
The functions of the IMS Control Program are varied and highly complicated, but they are totally
transparent to the Application Programmers. All terminals, database and logging operations,
connected to an IMS DC Program(s), are executed through the control region, which provides
IMS DC, all the control on all entities, it handles.
The user regions in other address spaces which are used by IMS, are called, DEPENDENT
REGIONS. It is in these regions, that DC application programs are executed. IMS can very well,
manage numerous regions. However, under IMS/VS 1.3 and MVS/XA, there can be only a limit
of 255 regions.
The dependent regions are basically two different types of dependent regions, and they are:
Message Processing Program Region
Batch Message Processing Program Region
The Message Processing Program or MPP Region, is where the IMS schedules and executes
message processing programs.An IMS System has a fixed number of MPP Regions(decided by
the IMS Systems Programmer), and they are managed by the Control Program running in the
Control region.
Normally, a program, which occupies an MPP Region, runs until it has processed all the input
messages, that the IMS has received. After the completion of processing of this program, the
region is freed and given to some other requesting program.
BMP Region concept
As mentioned earlier, the second category of dependent region in an IMS DC environment is
called BMP or Batch Messaging Processing region. A BMP Program is much like a MPP, except
Terminal Response is not required for each input message.
And also, the data base processing, the particular input message requires, does not have to be
done immediately, unless it is urgently required. This is represented in an IMS Batch Job, when
the mode is represented to be BMP, instead of DLI.
A BMP Program is, more like a normal or typical batch program than MPP program. A Terminal
user enters the transaction thru the IMS Terminal system for a BMP Program to come later and
process it. IMS then accumulates them into a batch.
Then during off hours, the IMS Operators, presses the BMP Program into service to
process these waiting messages.
The basic rule for MPP is that it is formally scheduled and executed automatically by IMS as
rapidly as possible.
INPUT MESSAGE EDITING

Input Message Editing

An incoming input message is not allowed to proceed to its necessary destination, as soon as it is
received in the queue. Instead, it is checked for accuracy, or in other words, it undergoes
stringent editing, to make sure, what is coming, is correct.
Two types of Editing
IMS Basic Edit
Message Format service
IMS Basic Editing
Basic Edit does not do a whole lot more than just removing the small communication control
characters from the input message and adding them to the output message.We all know, it is
there, but it is not really a great tool, so to speak. It definitely performs its duty as an editor, but an
IMS DC Programmer needs lot more.
Message Format Service(MFS)
Message Format Service is a very important tool in the life of an IMS DC Programmer. This helps
a lot in the extensive editing of the Input Data and also it helps in formatting the Sending and the
Receiving Screen for the message, which is being processed.
As you can well imagine that well-designed screen Message Format Service(MFS)
Dramatically enhance the operator efficiency as well as accuracy of the data. In addition to that,
MFS can reduce the system resource an application uses, both in the Host System, as well as,
the Telecommunication Network. Let us look ahead to find out, what MFS has to offer us, in
qualitative and quantitative way.
Details about MFS
MFS Modules reside in IMS Control Region and they are put in action between IMSs
communication control module and its queue manager. Because of this, editing is always
performed for both the Input and also the Output messages between queuing and also at the
communication time.
As you have seen and heard about the Control Blocks in the IMS DB Programs, IMS DC
Programs also have some separate control blocks, which control the flow of the Input and Output
Message and also assist significantly in designing the screens to send and receive processed
messages or transaction, so to speak.
In addition to PSB, PCB, DBD, ACB, MFS brings into existence, four more control blocks, and
they are:
DIF - Device Input Format
MID - Message Input Descriptor
DOF - Device Output Format
MOD - Message Output Descriptor.
Now let us see, what each of them does.
For an Input Message, MFS uses:
Device Input Format(DIF) to interpret data, as it is received from a users terminal
Message Input Descriptor(MID) to determine, how that input data should be formatted to
be presented to the Application program
For an Output Message, MFS uses:
Message Output Descriptor(MOD) is used to interpret data received from the proper
Application program
Device Output Format(DOF) is used to determine, how that data should be formatted for
transmission to the users terminal.

This is the flow of data for the Input Message:

From User terminal
DIF
DIF
MID
MID
Application Program
This is the flow of data for the Output essage:
Application Program
MOD
MOD
DOF
DOF
User Terminal
This set of related DIF, DOF, MID and MOD is called Format Set. The most commonly used sets
have four blocks, but it is possible that some set may have more. For instance, if an application
can process messages with different formatting requirement, its format set must have a DIF/DOF
for each of those device types.
The next slide is going to furnish information about all the details that a MFS requires to edit
all the messages for a specific application and as you will see, how it is categorized into three
categories. The first segment will cover details about the hardware. The second and the third will
provide information about input and output message.
Format Set for the Display Invoice Application
PRINT ON, NOGEN
******************************************************************************************************
FORMAT SET FOR APPLICATION PROGRAM CID
******************************************************************************************************
CIDDF FMT
DEV
TYPE=(3270,2),FEAT=IGNORE,DSCA=X00A0
DIV
TYPE=INOUT
DPAGE CURSOR=((1,2))
TRANINV DFLD
POS=(1,2),LTH=15
OUTTEXT DFLD
POS=(3,2),LTH=702
FMTEND
******************************************************************************************************
Format Set for the Display Invoice Application
As you have seen in the previous slide, the DFLD can be modified into two categories of fields,
which are variable and fixed. The fixed fields are those fields, which occupies meaningful
literals and the variable slots are the places, which takes your input or output from the data
source, which can be updated. But this particular slide just does not have those things, which are
included in class handout.
Format Set for the Display Invoice Application
******************************************************************************************************
CIDO MSG
TYPE=OUTPUT,SOR=(CIDDF,IGNORE),NXT=CIDI
SEG
MFLD
OUTTEXT,LTH=702
MSGEND
******************************************************************************************************
CIDI
MSG
TYPE=OUTPUT,SOR=(CIDDF,IGNORE),NXT=CIDO
SEG
MFLD
OUTTEXT,LTH=15
MSGEND
******************************************************************************************************
END

This is all, an MFS will need to process the input and the output message.
The previous four slides showed you, just the basic structures of a MFS Format. Then you
need to insert all the fields, both fixed or variable within it, along with its individual attributes, so
that proper control is assigned into the whole screen to handle all types of data.
The following attributes or properties are used with reference to the design of a screen for an
IMS DC Application.
Protection
Protected
Unprotected
Auto-skip

Intensity
Normal
High
No-Display

Shift
Alphanumeric
Numeric
N/A

MESSAGE FORMAT SERVCE

Building a screen
As it was mentioned earlier, every screen has three distinct segments and they are:
Device Fields Input Message Field
Output Message Field

Begin and End Point

Begin and End Point
Ditto

Defining a screen in a format set

Although MFS requires both a DIF and DOF to define a screen format, you only have to code one
group of control statements to create both for a 3270 Display Station. This is because for a 3270
Screen, the same screen format must be used for both input and output.
The specific screen, thats sent for an Defining a screen in a format set Output message,
becomes quickly the format for the next input operation. Collectively, the group of statements, that
define the screen layout for a terminal, are called DEVICE FORMATS.
The parameter TYPE=INOUT specifies that the particular device is used both for input and output
operations.
Building a screen
Please consult Figure 5-10 in the IMS DC Book to have an idea of building the screen for any
application.
That format clearly shows the three segments of the screen formation.
Page 98 - 100.
Basically an IMS DB or DC programs contain similar structure, with minor difference. This is
attributed to its basic difference in the mode of functionality.
BASIC STRUCTURAL DIFFERENCE
DB
Segment IO Area
PCB MASK
No use of LTERM
No use of screen
Use of only three control blocks
It has one set of RC
WHAT IS A LTERM IN DC

DC
Input Message IO Area
Output Message IO Area
IO-PCB
Positive use of LTERM
Definite use of Screen
Use of more than three control blocks
Different set of RC

LTERM is called Logical Terminal Name. This is really an identification for the existence of a
location, from where message will be sent and received.
WHY IT IS CALLED LTERM
For application functions, IMS always uses Logical Terminal Identification Process, rather than
Physical Terminal Identification Process.
Why is it planned that way?
This is because while defining System or planning the System Configuration, one LTERM name
is associated with only one Physical Terminal Name.
However, one Physical Terminal can be associated with more than one Logical Terminal. So, if
IMS knows the LTERM, it knows, which PTERM, it is connected.
But these are really Transparent to the Application Programmer, since it is planned and designed
by the Systems Support Staff at the time of designing the system. But you must know, what it is.
But there is a catch. The System Support Staff can re-direct the LTERM from one PTERM to
another, for various reasons. For simple DC Programs, the Applications Programmer must
not worry about it, since IMS keeps track of the LTERM of the originating message and
henceforth returns the message to the same LTERM, from where the message came from. Care
must be taken, when there are lots of user for an application.
MASTER TERMINAL
One Logical Terminal in the IMS Network is designated as Master Terminal. It is the operational
center of the system. The Master Terminal Operator(MTO) can manage other terminals in the
network, as well as messages and program executions in the dependent regions.
The MTO can also dynamically adjust resources established when the system was started. For a
small example, if one physical terminal is disabled, the MTO can reassign the LTERM name,
which is normally associated with it to another nearby terminal, so work can continue.
DETAILS ABOUT SCREEN DESIGN
The Applications Programmer must remember that all the fixed fields must have PROTECTED
Attribute and the variable should have UNPROTECTED and the proper data attributes.
FUNCTION OF A DC PROGRAMMER IN AN APPLICATION DESIGN
Duties of a DC Programmer-1
It is clearly understandable that in creating an Application, which deals with Data Transfer,
Data Communication, Real-Time Update, a DC Programmer has a very important role to
play. But it varies from one company to the other, because of operational needs and
company business protocols.
Just like any other application, the most important duty of a programmer is to:
WRITE AND TEST THE PROGRAM, WITH ALL ITS EMBEDDED POINTS
AND CONDITIONS, NORMALLY RECEIVED FROM THE MOST IMPORTANT SOURCE, THE
USER OF THE SYSTEM.
The following are also the responsibility of the programmer:
- Discuss with the user about what will be the type of input message
- Discuss with the user about what will be the type of output message
- Discuss with the user about what type of data will be used for the input
- Discuss with the user about what type of data will be used for the output, that the

user would like to see

- Discuss about what type of information needs to be included in the screen
- Quantity of information in one screen
These will help the programmer to plan the screen details and the message details.
The programmer will therefore, be responsible to code:
DIF
Device Input Format
MID
Message Input Descriptor
MOD Message Output Descriptor
DOF Device Output Format
Receiving information from the user or the customer, so to speak, the programmer also will be
responsible for:
Coding the DBD Source
Coding the PSB Source
Coding the necessary JCLs to conduct the coding of the GEN JCL, or it may be obtained
from the System Support Group.
LET US TALK ABOUT CONTROL BLOCK, DIF
The user sits in front of the terminal. Then he/she enters input. The DIF is the block, which
interprets data, as it is received from the terminal user and then sends it to the next block,
called MID.
LET US TALK ABOUT CONTROL BLOCK, MID
The MID then determines, how to format the data, does the formatting and presents it to the
appropriate Application Program for ultimate processing.
MID and as prepared by DIF and then passed to the Application Program.
LET US TALK ABOUT CONTROL BLOCK, MOD
For an output message, in the similar fashion, application program passes it to the MOD or
Message Output Descriptor. The MOD then interprets the data and sends it to DOF.
LET US TALK ABOUT CONTROL BLOCK, DOF
The DOF or Device Output Format then determines how to format the data, performs the
function and transfers the message back to users terminal.

SOME TRICKY INFO

Although, MFS requires theoretically both DIF and DOF to be coded, but in practice, the
programmer can do very well by coding one of them.
This is done, primarily, because in majority of the cases, it has been observed that, the output
message gets transferred to the same terminal, where it originated.
But this logic will definitely not apply in the event of MID and MOD. A programmer must code both
of them. Without either one, the application will be incomplete.
But why this disparity for MID/MOD and not DIF/DOF
This is because one small input can generate a large output and the provision must be made in
advance to accommodate all the data, which have been received.
M F S - HOW DO YOU CODE THEM
HOW TO CODE MFS

MFS is also coded the same way, a COBOL Program is coded. But it has certain parameters to
follow, just like MARGIN - A and MARGIN - B of the COBOL Program. To code an MFS Source
code, special care must be taken to make sure that,all syntax rules are followed. Generally
speaking, MFS source coding has lots of similarities with that of an Assembler Programming.
MFS CODING GUIDELINE
The statements are 80 bytes long, just like a JCL Statement or a COBOL Program. The following
are the formats:
Field Label
Operation Field
Operand/Comment
Continuation Mark

Columns 1 - 8
Columns 10 - 13
Columns 16 - 71
Column 72

MFS CODING GUIDELINE

For example,
1

10

16

72

CURDATE

DFLD POS=(1,72),
LTH=8,
ATTR=(HI,PROT)

X
X

As you can see, CURDATE is the label for Current Date. DFLD shows it is a DEVICE FIELD
MFS CODING GUIDELINE
For example,
1

10

16

72

CURDATE

DFLD POS=(1,72),
LTH=8,
ATTR=(HI,PROT)

X
X

POS specifies the exact position, that is line 1, column 72, LTH stands for length of 8 bytes, and
the attribute is highlighted and protected.
Some more details
1
From 1 - 8 Label
10
From 10 - 14 Operation
16
Operand/Comment
72
Continuation Character X
How to add comments
It is pretty simple, just put an asterisk on Column 1 and it will get converted into a COMMENT
Statement.

1
*
THE TOTAL NO. OF MFS OPERANDS
FMT
DEV
DIV
DPAGE
DFLD
FMTEND
LET US TALK ABOUT MFS PARAMETERS, JUST WHAT REALLY THEY ARE?
FORMAT identifies the beginning of a device format.
DEV denotes the starting of a set of control statements for a specific device type. It can also
accept multiple DEV statements within a device format.
DIV represents the starting of a set of control statements for a particular type, subordinate to a
DEV statement.
DPAGE identifies the beginning of a series of control statements, for a device page, subordinate
to a DIV Statement.
DFLD identifies a device field within a device page.
FMTEND represents the end of a device format.
LET US TALK ABOUT HOW ARE THEY ARRANGED?
FMT
| DEV
DEV
|
DIV
DIV
|
DPAGE
DPAGE
|
DFLD
DFLD
|
DFLD
DFLD
|
DFLD
DFLD
|
DPAGE
followed by:
|
DFLD
|
DFLD
=====>
|
DFLD
|FMTEND
A Sample MFS Statement
PRINT NOGEN
****************************************************************
FORMAT SET FOR APP PROGRAM DI2
DI2DF

FMT
DEV

TYPE=(3270,2),
FEAT=IGNORE,
SYSMSG=ERRMSG,
DSCA=X00A0
DIV
TYPE=INOUT
DPAGE CURSOR=(3,12),
FILL=PT
Since all the control statements have been defined earlier, let us discuss about other parameters:

TYPE=(3270,2)
FEAT=IGNORE
SYSMSG

3270 Model 2 Display station

24 Line screen
Specifies that the DIF and DOF generated for this DEV statement will
work with the indicated 3270 terminal, regardless of any special feature.
This is the default value for this parameter.
Specifies the name of a device field, which can be used to display
messages from IMS. The field should be at least 79 bytes long.

DSCA=X00A0
Default System Control Area, where 00A0 is a hex value for this two
byte area. The value of this field determines default terminal action, when output messages are
received. X00A0 causes unprotected fields on the screen to be erased, before new data is
written to it.
DSCA=X00C0 X00C0 causes the entire device buffer to be cleared, before output is written on
the screen.
TYPE=INOUT Specifies that the same device format specifications should be used to generate
both DIF and DOF. It is a default value for all 3270 Display stations.
CURSOR=((3,12))
The first operand 3 is the line number, and 12 is the column number of
the default cursor position.
FILL=PT
Specifies the program tab, which is the default value. Output fields that
do not fill the device field are followed by a program tab character to erase the remainder of the
device field.
DFLD DATE=,
POS=(1,65),
ATTR=(HI,PROT)

X
X

What it really means:

This is a CURRENT DATE, and it is also a Display Field. But it is represented in the screen as a
hard coded literal called Date and it starts at Position 65 of first line and it is highlighted and
protected field. We also have to reserve space to display the actual date and let us see, how it is
coded in the next slide.
CURDATE

DFLD POS=(1,72),
LTH=8,
ATTR=(HI,PROT)

X
X

What it really means:

This MFS Statement means it is a CURRENT DATE and it is a Display Field. It starts at position
72 in the first line of the screen, and it is eight bytes long. It is highlighted and protected, which
means, no terminal user can change it. This is the space, where provision is made to reserve
space to hold the current date. It is eight bytes, since a date is always 8 bytes long, regardless of
format.
In the previous two slides, you have seen that one DFLD Statement has a label, and the second
one does not have one. Does it have a reason, and the answer is surely YES. To create a caption
on the screen, you assign a literal value to a device field. All you do is to code the literal value
between apostrophes as the first parameter of the DFLD Statement.
But when the device field defined, is related to a message field, both input, as well as output, it is
a must that you label the DFLD Statement. As you can well imagine that the DFLD definition,
which does not have label, clearly defines the screen title, whereas the other one defines the
message field, since it does not have any literal attached with it.

After defining all the message fields, the FMTEND control statement is coded, where the
message field definition concludes. In a way, you also have concluded the DIF and DOF
statements too, and you need to complete the remaining two control statements that is MID and
MOD. Let us look at the subsequent slides to see, how are they coded.
How a MID Looks
In normal coding standard, the FMTEND is followed by MID, which is followed by MOD;
DI2I

MSG

TYPE=INPUT,
SOR=(DI2DF,IGNORE),
NXT=DI20

SEG
MFLD
DI2
,
X
LTH=8
MFLD
INVNO,
X
X
JUST=R,
FILL=C0
MSGEND
Explanation of MID Operands
TYPE=INPUT Tells that the Message Descriptor
control statements, that follow,
will be used to generate a MID
SOR=(DI2DF,IGNORE)
DI2DF
The device format, to which, this
message descriptor is related.
IGNORE
Indicates that the device format
coded with FEAT=IGNORE
be used with this
message
NXT=DI20
If TYPE=INPUT, name of the next
MOD to be used and vice-versa.

LTH=6,
X

should

Explanation of MID Operands

The first MFLD statement reflects the Input Message Screen Title, which is eight bytes long.
The second MFLD Statement reflects the invoice number, that the terminal user is trying to
retrieve and it is six bytes long, right justified and if it is less than six bytes, the leading spaces will
be filled up with zeroes.
MSGEND shows the end of the MID Statements.
How a MOD Looks
The MID is followed by MOD:
DI2I
MSG
TYPE=INPUT,
SOR=(DI2DF,IGNORE),
NXT=DI2I
SEG
MFLD
(CURDATE,DATE2)
MFLD
INVNO,
MFLD INVDATE,
LTH=8
MFLD
SUBTOTAL,
LTH=9
How a MOD Looks
MFLD
DISCOUNT,
LTH=9

X
X

LTH=6
X
X

MFLD

SALESTAX,

LTH=9
MFLD
MFLD

FREIGHT,
LTH=9
ERRMSG,
LTH=79

MSGEND
**************************************************************
How a MOD Looks
DI2I
MSG

X
X
END

TYPE=INPUT,
SOR=(DI2DF,IGNORE),
NXT=DI2I

This matches exactly with MID Statements, except NXT where it is stated DI2I. You know the
meaning by now.
The MFLD Statements simply state the length of the various fields, which will be transferred to
the screen. You can map these field lengths easily with the DFLD Statements. Only the last
MFLD Statement will be the space, reserved for error message, should there be a need for it.
How a MOD Looks
Let us discuss one thing, which is the only remaining element in the MOD Statements,
and this is:
MFLD
(CURDATE,DATE2).
What this means that the contents of the special MFS field called DATE2 should be mapped to
the device field CURDATE. DATE2 contains the current IMS System Date and is one of the
several IMS System Literals, which can be specified in the MFLD Statements.
How an IMS System Date Looks Like
NAME
LENGTH
DESCRIPTION
DATE1
06
Date Format is YY.DDD
DATE2
08
Date Format is MM/DD/YY
DATE3
08
Date Format is DD/MM/YY
DATE4
08
Date Format is YY/MM/DD
TIME
08
Time Format is HH:MM:SS
LTNAME
08
Logical Terminal Name of the device that will receive the current
output message
JUST REMEMBER ONE THING
The format statements start with FMT and ends with FMTEND.
The message statements start with MSG and ends with MSGEND.
IMS DC
SOME SAMPLE CODING
Where is the difference in these two formats?
How a DB Call looks like:
CALL CBLTDLI USING CALL-FUNCTION,
PCB-MASK, SEG-IO-AREA,SSA-QUAL.
How a DC Call looks like:
CALL CBLTDLI USING CALL-FUNCTION,
IO-PCB-MASK, INP-MSG-SEG.

The IO-PCB will make all the difference.

Additional Details
Just like a DB Program, you see that there is a CALL-FUNCTION, IO-PCB-MASK and a mention
of INPUT-MSG-SEG, that is Input Message Segment. There is no use of SSA, because there is
no retrieval of records on the screen. Of course, there will be a SSA, when records will be
retrieved on the screen. Input Message Segment is nothing but an I/O area
Just as you have seen in a DB Program, records will be retrieved on the screen. Input Message
Segment is nothing but an I/O area, but an I/O Area does not look the same as it looks at a DB
Program. The reason for this being, is that the data has to be adjusted or manipulated to
accommodate it in the screen.This involves some extra configuration.
LET US SEE, HOW THEY LOOK
This is how an Input Message will look:
The input message segment, that IMS passes to your
IMS Prefix
LL
ZZ <---------User data (length n)------------------------>

program begins with 2 2-Bytes fields, LL followed by ZZ Field. After ZZ Field, comes the actual
data. This can be variable in length.
Additional Details
The basic IMS Input Message Format includes the transaction code immediately after the ZZ
Field. In multiple segment input messages, the transaction code is only present in the first
segment, and not in the subsequent ones. The LL Field contains, in binary format, the length of
the entire segment, including the LL and ZZ Fields. The ZZ Field is reserved for use by IMS, so
even if you define it in I/O Area, you dont do anything with it.
The ZZ Field should be defined with PIC S9(03) with COMP usage or it can also be done as PIC
XX. The structure of the data component varies, depending on the application complexity. But it
is considered as a duty of the Programmer, to code it correctly. It must be remembered that the
relationship between the data, thats passed to your program, and the data, terminal operator
entered, depends on how IMS and MFS edit the message. What it means that, the format of the
message, your program receives, can be just like what the operator entered in the terminal.
It is very important to make sure that the specification for a DC Program contains all the
information, a programmer needs to know about the input messages, to be processed.
This is how an Output Message will look:
IMS
LL

Prefix
Z1 Z2 <---------User data (length n)------------------------>

Now you can see that an output message has the same format like an input format, the first four
bytes contain information required by IMS. Everything is the same, just like the Input Message,
except one difference.
More about Output Message
Before an ISRT Call is issued, every programmer needs to be sure that the LL field in the I/O area
contains the actual length of the message to be sent, including the four bytes. There is
something different in an output message, as stated in previous slide.
You can see that, in an output message, the ZZ Field is divided into two binary fields, called Z1
and Z2 fields.The Z1 is reserved for IMS and it must be initialized to zero. The Z2 field can be

used to control some advanced terminal operations, but for most applications, It also needs to be
set to zero. As a result, the programmer can code the two fields together with PIC S9(03) and
COMP usage and initialize the field to zero. Or it can also be coded as PIC XX and VALUE LOWVALUE. After the four bytes, comes the actual data.
How to send an Output Message
In IMS DC Programs, you send output message segments by issuing ISRT Calls, which specify
the IO-PCB. Before you issue an ISRT call, you build the output message segment in the I/O
area, you named on the call. Although many output messages consist of just a single segment,
some require more than one segment. When that is the case, your program must issue a
separate call for each of the Segments.
IMS considers an unbroken series of ISRT calls to make up a single message. That series is
broken, when your program issues a GU Call against the IO-PCB; this sends a signal to IMS that
your program is ready to process another new input message. IMS holds all of the segments,
your program inserts in the destination terminals output queue, until the program processed all
input messages.
In most of the cases, the destination of the output message is the same, from where, the input
message came from. In this case, no special coding is necessary, but if the output message
needs to go somewhere else, other than the originating terminal, a separate PCB or an alternate
PCB must be used, which will drive the message to a different LTERM.
TESTING OF AN IMS DC PROGRAM - TIPS OF TESTING
As a DC Program is developed and also its MFS Blocks, it is expected that it will never be tested
in the Production Environment. This is because the Production Environment has been carefully
tuned to meet the business needs. It is absolutely positive that it will be tested in Test Side
And this is because, you can afford to make mistake in the Test side, just like any other program.
But if there is no real-time configuration on the Test Cluster, then what should a programmer do,
to make sure, the DC program is performing, the way it should.
In that scenario, you will use a special testing feature, built by IBM, for all IMS DC Programmers
convenience. This is called Batch Terminal Simulator or BTS in short. In this way, IBM made it
easy for you, to test an online or IMS DC Program in a batch process. It also gives you results
with impeccable accuracy.
BTS, what it is?
In BTS way of testing an IMS DC Program, you have to pay attention to the following three
elements:
How to interpret BTS Output and how to supply input to BTS
How to run BTS in a batch job
How to use BTS Full Screen Support under TSO.
MORE ABOUT BTS
BTS is an IMS DC Development Tool, which is used extensively and highly appreciated in all IMS
Users Circle. The wonderful part of this package is that, this allows to run your DC Application or
DC using real DL/I Databases, MFS Format Sets and IMS Modules. However, it does that
separately from production arena.
Regardless of whether, it is run in the batch, or in interactive TSO session, the output is supplied
in a dataset, which is called BTSOUT. For a program, BTS can provide a trace of all DL/I calls, it
issues, both for DB and DC operations. The programmer has the freedom to disable the trace

option or enable, either DB or DC call details, whatever is required to diagnose and complete the
debugging problem and BTS has the capability to print any calls function, its I/O area, and also
the PCB name.
For a format set, BTS can provide a printed image of a 3270 screen, that can be used to check
locations and size of fields, data entered into and displayed in them, with attributes.
You will know more only when you start testing a DC Program thru BTS.
BTS Input comes in three forms, and they are:
IMS Commands
BTS Simulator
BTS Commands
There are two types of IMS Commands which are used in BTS:
/EXIT - lets you end a conversational program
/FORMAT - lets you format the BTS
Screen Image by using a MFS MOD name, such as /FORMAT DI67.
BTS Simulator statements, which are supplied to BTS in card format, supply simulated terminal
input.
For example, L3C12 010000 means for third line Column Twelve, an input of 010000 is to be
keyed into Invoice No field of Display Invoice Application.
But that does not necessarily complete the simulator statements. Some other parameters need
to be added to make the command completely meaningful, as well as acceptable by BTS. The
complete command is stated in next slide.
Actual BTS Simulator Statements
Keyword
Action
ENTER
Simulates ENTER Key
CLEAR
Simulates CLEAR Key, which helps for next /FORMAT command
PFx
Simulates a PF Key
PAx
Simulates a PA Key
Correct BTS Simulator Statements
L3C12 010000 ENTER $
This means that in the third line, column 12, a quantity of 10000 should be entered. The dollar
sign is an EOM(end-of-message) character, this is also a default.
BTS under TSO, what a fun
When you use BTS under TSO, the terminal is used, as if, it was an IMS terminal. Formatted
input and output are accepted from and sent to it, just as if, the application is executing in the
production environment. As a result, you dont have to use simulator statements.
However, even though BTS under TSO runs in an interactive environment, it will still expect a
batch of card format simulator statements. As a result, the BTS modules, which provide fullscreen TSO support will have to translate actual terminal entries.
The simulator statements, which are generated, when you use BTS under TSO, are stored in a
dataset, called BTSPUNCH, that you can use later to recreate the exact sequence of entries,
you made in an interactive mode.
BTS Commands

BTS Commands are the third group of statements, that you can include in the BTSIN data. You
can use BTS commands to specify the transaction codes for the programs, which can be
scheduled, the terminal type to be simulated, and options to be in effect for the run.
The Normal BTS Commands
The following are the normal BTS Commands, which are used in BTS Scenario:
D,

T,

O,

P,

R,

and

SPA.

Let us take a look at the following slides to have individual explanation for each of these
commands.
BTS Command Code Explanation for D
D - This is used to specify the characteristics of the simulated terminal, which will be
associated with your programs I/O PCB. This means that this will be your applications primary
terminal.
Example:
/D TYPE=3270-A2 SIZE=(24,80)
BTS Command Code Explanation for T
T - This is used most often, and this is the most complicated too, of all BTS Commands. It is used
to supply information BTS needs about destinations, both alternate terminal and transaction
codes associated with the programs.
Look at the example:
/T TC=DI2 MBR=DI2 PSB=DI2 LANG=CBL TYPE=MSG
BTS Command Code Explanation for O
O - This is used to tell BTS, what information it should provide back to you at the time, your
application executes. BTS has the ability to generate a volume of information. As a result, it is
often useful to limit, what is printed.
Look at the example below:
/O MSG=NO SCREEN=NO TSO=NO etc.
But what about the other commands
Yes, there are five other commands, but you will rarely use them.
The ./SPA command lets you initialize a Scratch Pad Area to test a conversational program. The
four other commands are even less useful, even though they are there.
The ./P command lets you patch main storage to change a program dynamically.
The R Command lets you tell BTS that the simulator statements which follows, contains hex data.
The ./S command lets you specify a special action that should occur at particular points during
testing. It can be used to force a dump, or substitute a STATUS CODE, normally issued by IMS.
Yes, we definitely learned a whole lot about IMS DC.
But the most important question remains here, is that:
HOW DO WE MAKE ALL THESE THINGS WORK
Nothing different, just like any other program
Just like any other programs, we need to convert the program and the MFS to machine language.
The JCL to accomplish all these things, as you can well imagine, will be supplied by IBM. The
conversion of the program is the same, that is compile, link/edit. The process for converting the

MFS Code to machine language is called MFSGEN. There is another process, which is called
TPGEN and this is Nothing different, just like any other program
Nothing but configuring the LTERMS to a physical terminals.As said earlier, a physical terminal
can be defined to more than one LTERM. But one LTERM must be defined or related to only one
terminal. Most of the installations use this term, that is TPGEN, if this installation does use
something else, please make yourself familiar with the specific term for this installation.
Message Classes in an IMS DC Environment
In a typical IMS DC Environment, there can be hundreds of terminal users, who can invoke
hundreds of applications at the same time. Usually, when an MPP is scheduled, it quickly
processes the message(s) on its queue and then ends. Because of limitations in the system
resources, IMS has to pick and choose, which programs to schedule. To do just that, it uses a
scheduling schemes, involving classes, Message Classes in an IMS DC Environment, Priorities
and processing limits. To accomplish that, up to four message Classes, numeric values 1 and
255, are associated with each dependent region. Message Classes are used to force application
programs to execute in particular regions. When an application program is defined to IMS, it is
assigned one message class value. Then, for IMS to be able to schedule that program for
execution, when there is an input transaction is present for it, a dependent region with the same
message class must be available. But all these things are really transparent to the Applications
Programmers. But it is always advisable for the programmers to note that these things are
happening in backstage.
Glossary of Terms
Interactive System - Where a user working at a display station, interacts directly with the
computer.
On-Line System - Where data is entered and processed simultaneously.
Real Time System - It is the same thing as an On-Line System.
Menu Driven System - An application, which is built around a set of menu programs.
Response Time - How soon, the computer responds to a users request.
Host System - Where the IMS-based system resides, that is an IBM 370 or other machine.
Attribute Byte - It is a special character, which marks a beginning of a field. It takes up one
position on the screen, immediately to the left of the field it defines, but displayed on the
screen as a space.
Protection Attribute - indicates whether or not the operator can enter data in a field. If it is
protected, the entry will be denied.
Intensity Attribute - indicates how the data in the field, will be displayed, normal, bright or no
display, at all.
Shift Attribute - indicates whether the keyboard is in alphanumeric shift or numeric shift.
VTAM - This is an access method, by which the terminal user reaches the machine, and is
called Virtual Telecommunication Access Method, and which is the best method.
Input Message - indicates a record or request received from the terminal user to be
processed.
Output Message - indicates a record or request returned to the user after processing.

MFS - This is an edit process, by which the the input message is edited, before it is actually sent
for processing and it is called Message Format Service.
LTERM - For application functions, IMS uses Logical Terminal names or LTERM, rather than
physical terminal names. One LTERM is connected with one physical terminal, but one PTERM
may have more than one LTERM.
MPP Region - or Message Processing Program region, where IMS schedules and executes
message processing programs. Most of the dependent regions in IMS DC are MPP region.
BMP Region - or Batch Message Processing Region is a region, where a request can be
processed without receiving a request from a terminal user, batch runs, when online us up.
Control Region - IMS uses several user or dependent regions, with their own address space. All
these dependent regions are managed from the IMS Control Region, where IMS Control Program
resides.
Input Message - There are three types of input messages, which are Transactions, IMS
Commands and Terminal to Terminal Message switches.
I/O PCB - Like DB Calls, a DC Call must specify a PCB Mask, but this should pertain to more on
the data communication than database, which is why it is called I/O PCB.
Leading Bytes in Message - There are two 2 Bytes fields at the beginning of a message, which
are called LL and ZZ Bytes. LL Bytes contain length of the entire segment and ZZ Bytes are
reserved for use by IMS.
DIF - Device Input Format, which interpret data, as it is received from the Terminal user.
MID - Message Input Descriptor determines, how the input data should be formatted for
presentation to the Application Program.
MOD - Message Output Descriptor interprets data received from the Application Program.
DOF - Device Output Format determines, how to format the data to pass back to terminal.
BTS - called Batch Terminal Simulator, which helps the programmer to test an online program
through a Batch Processing. It needs to follow a certain format of identifying the Input and Output
Data.
Conversational Program - It is a special type of program, where it is able to carry on, a continuous
conversation with the terminal user, even if, it process transaction from other users, between
terminal interactions. A special entity or a tool, called SPA or Scratch Pad Area is used in this
unique process of program execution.
A unique SPA is associated with each terminal, which is running a conversational
transaction. As one of the terminal users works thru the program, the SPA is retrieved along
with the input messages.
Then the program can use the data in the SPA to process the input. When an output
message is saved, the SPA is saved too, so it can be retrieved in the next terminal interaction.
The programmer must have a clear understanding of the relationship between SPAs and the
application program. Regardless of the number of users, only one copy of program is scheduled,
used.
SOME IMPORTANT STATUS CODES IN DC ENVIRONMENT
AB
The call did not specify a segment I/O Area. This is a programming error.
AC
The call included an SSA with a hierarchical error. This is also a programming error.

AD
AH
A1
A2
LB
LC
NO
QC
QD
QE
QH
RX

The function code field specified for the call contains an incorrect value. Programming
Error.
This call requires at least one SSA. Program Error.
Destination name invalid - Programming Error.
The program tried to change the destination, which is associated with a fixed alternate
PCB. Program Error.
The segment already exists in the database. This is also a programming error.
The input data is not in hierarchical sequence.
This call caused an operation that resulted in a physical I/O Error on a Secondary Index.
This requires immediate intervention by System Programmer
No more input message is available for processing. This is a condition to be anticipated
by your program.
No more segments are available for the current input message. This is quiet possible.
The program issued a message GN Call before issuing a message GU Call.
The destination of the output message is undefined.
The call violated a replace call.

THE SECURITY FEATURES IN IMS DC

One of the major strong points of IMS is that, it provides substantial security features. These are
in effect for both database and terminal use. It is provided by three components:
IMS/VS itself
Features implemented through SMU(Security Maintenance Utility)
RACF(Resource Access Control Facility)
If nothing is specified, IMS Default Terminal Security is in effect.
Let us try to write couple of IMS DC programs.
What are the steps to follow
TO MAKE AN IMS DC PROGRAM WORK FROM INCEPTION TO BE MOVED TO THE
PRODUCTION FOR USE IN BUSINESS ENVIRONMENT.
JUST REMEMBER THAT IMS DC IS STILL A WINNER, AND GOING STRONG IN SO MANY
COMPANIES, EVEN TODAY, WITH FULL ENERGY.
Conversational Programming
A new and highly novel way to save a piece of data between Terminal Interaction. But does it
really differ from other message processing?
The answer to this question is YES.
As we have seen in the other programs, all programs get a particular message and then they
process them one at a time. But there may be a time, when two terminal users need to share
data at different times. Or it may even be necessary that one terminal user enters data,
manipulates it and stores it for next user to do some more things in it.
This type of data interaction between the users can be done in three ways.
Since this type of data entry is highly complicated, IMS made it easy by storing it in an area called
SPA.
What is a SPA
SPA, as the acronym says, it is a Scratch Pad Area and this is the main mantra of Conversational
Programming.
Just think about it, You work in the morning shift, and you generated some information for your
friend who works in the evening.

You need to save the information for your friend, very likely in a Scratch Pad either in
your office or his office, which will be used later.
Normally in IMS this saving of data between terminal interaction can be done in three
different ways. And they are stated in the next slide.
Saving the data
Store the data in the terminal screen
Since we are dealing with a data- base, rather store it in a database
Store it in an area supplied by IMS, that we call Scratch Pad Area
Storing the data in a Terminal Screen
This may sound to be the easiest form of saving the data, but it has its own drawbacks. Let us
see, what are those in the next slide.
The data should be defined by setting the MDT to ON This is not suitable for a large volume of
data.
This is suitable for not-so-important data. This is why, it is not used extensively in IT
environment. Then also comes the size of a Terminal screen which is only 24 X 80 = 1920 Bytes.
Let us talk a bit about MDT
In the normal attribute scenario, we always talk about Protection, Intensity and Shift. But there is
another important attribute which is MODIFY. This plays a very important role.
What is a MDT
MDT stands for Modified Data Tag. This keeps track of whether or not, the data has been
changed or not, since the screen was last reflected on that specific work station.
How MDT works
The moment, the screen is ready on the CRT or work station, all MDTS are set to OFF. This
means that no data has been modified.
As soon as the variable field has been changed, it is set to ON.
Storing a data in a database
If there is a need to store more data, than the terminal savings, database is surely an extremely
reliable medium. But this method may create more problem than solution for you.
This means that you need to create a new database with all its pertinent exercise, and it
will not be a cost-effective or efficient process for you to use such an expensive storage device
just for some intermediate usage. This will also require much more extensive system
configuration to figure out, from where the data came from, thus making the whole process,
unnecessarily complicated.
So what do we do now
Find the easiest and most efficient process to save data. And there comes the SPA.
Considering all the aspects of data saving between terminal interactions, that we have
discussed so far, it seems that storing data between terminal interaction, using a Scratch Pad
area is by far, the most convenient method of handling a Terminal Interaction between Terminal
Users.
As you can well imagine that all programs which are labeled as a Conversational
Program will invariably use Scratch Pad or SPA. The specialty that it contains, is that it is always
able to establish a contact with terminal users, even if it is handling transaction between other
users.
Where are they used
A Typical area of Conversational Programming can be found in the following areas of
business:
Stock Brokers

Foreign Exchange Dealers

Major International Airlines
News Reporters
and some others.
But how do I use SPA in my program
That is the question here to find out.
The major point to use a SPA in your program is To find out, how do you define and
access it. The normal process of defining a SPA is Just like coding a message in a Nonconversational Program. But there is a small difference in how a SPA is defined, compared to a
regular message, that you are perhaps used by now.
This is how a SPA looks like, can you find the difference
01
SPA-IO-AREA.
05 SPA-LL
PIC S9(4) COMP.
05 SPA-ZZ
PIC S9(4) COMP.
05 SPA-CI
PIC S9(4) COMP.
05 SPA-TRAN-CODE
PIC X(8).
05 SPA-EXCHANGE-DATA
PIC X(??????)
Yes, you got it right, there is a minor difference with major impact You can see that everything is
the same, except the third half-word binary field, which is called CI or Conversational Identifier.
But this is really a Control Block. Then there comes a question.
I never heard of any such control block. Only things we know are
DBD
MID
DIF
ACB

PSB
MOD
DOF

Then another question will come to your mind. Then I need to code this Control Block, just like
the others that I have done. But I dont know, what type of information should it include.
Absolutely, nothing to worry in this regard. IMS will take care of it, as you know, it also does for
another field in the message, and it is ZZ.
You must remember one thing that every programmer can be allocated one SPA, so they can
all be active at the same time. Regarding this thing, we all call Scratch Pad Area or SPA
The moment, you start your transaction, your SPA immediately becomes active.
You also must remember the following points
A SPA is retrieved along with the first message, that you are trying to process.
The moment, a message is saved, the SPA is saved too, to be used at the next
terminal interaction.
You also must remember the following points
If your specification is about developing a Conversational Application, it must be clearly stated to
the IMS DBA or IMS Systems Programmer, whoever has the responsibility to define and
configure the system.
It is for you to remember that If your system is not defined to IMS, as a Conversational
application, no SPA will be allocated to it and defined to IMS. Your SPA is unique to your program,
and this is applicable to one and only one program.

As you have seen that for any IMS Program, regardless of DB or DC, the very first thing you do is
to build or establish a contact by coding:
CALL DLITCBL USING either Batch PCB-MASK or IO-PCB.
You still have to do the same for a Conversational Program. It is not that you do not have to do it
for a Conversational Program, it will still be your first statement in the Procedure Division, where
you will establish contact with IMS.
Then you have to do something else.
Now you do something different than other DC Programs Chances are there is something,
seating in your SPA.Therefore, first activate the SPA, before you do anything else. There may be
something sitting there for your use.
This will be done in the same way, you make any other call in IMS. Something more in this than
meets the eye.
This logic will start executing, only when the program makes the first call to retrieve the the first
message. Now whether it should be a stand-alone logic or part of a paragraph, it only can be
decided, based upon the design of the program.
Let us see, how you do just that. Here is the format:
CALL CBLTDLI USING
CALL-GU,
IO-PCB,
SPA-IO-AREA.
Just like any other call, If the STATUS-CODE is not equal to spaces, something wrong has
definitely occurred. Try to investigate what is the value of the STATUS CODE see, what is the
problem, for which SPA could not, just like any other call, be retrieved.
You can very well consider the SPA as your first message. Then start working with other
messages, just as you will do.
The SPA is initialized to binary zeroes and it is done by IMS.
Just remember this, When a CALL is made to SPA, as shown in one of the previous slides, the
first call is made with a GU Call Function and then the subsequent calls will be made by GN Call
Function.
This iteration will continue, just like any other DC Program, that is the processing will continue
until IMS issued a STATUS CODE of QC.
It is somewhat different from the other programs, where the user can manipulate the QC
STATUS CODE, since the user stops using the program, until he/she has lots of messages to be
processed but in a Conversational Program it is bound to happen, but why?
This is because all messages, which are left in the SPA must be processed until the last
message.
This is very important that a message must not be sent anywhere before it is saved in SPA.
When you retrieve data from the database and store it in the Segment I/O Area, you make sure
that the record layout for the I/O Area matches exactly with the same for the Segment you are
retrieving.

The same logic also applies here. The I/O Area for the SPA must match the same for the input.As
you can well imagine, if this is not true, this will surely be a cause for Data Truncation.
Transaction Code must occupy 7-14 Bytes in the message. Just remember that If an attempt is
made to transfer information using an alternate IO PCB, the whole process will terminate
immediately.
This is because, the whole process is configured that way to IMS.
To save data in SPA You issue the following calls:
CALL CBLTDLI USING
CALL-ISRT, IO-PCB,
SPA-IO-AREA.
It is no different than any other IMS Program.
To get data from SPA, you issue the following calls:
CALL CBLTDLI USING
CALL-GU, IO-PCB,
SPA-IO-AREA.
It is no different than any other IMS Program.
It is really a Two Way Traffic. With the information from the database, you can hold information
on the SPA. In the same manner, you can take information from the SPA, and either add, delete
or change information in database.
Have you found something funny, something wrong? Just try to find out, what you do
normally with SPA, that you dont do other times.
Have you found something funny, something wrong Something wrong somewhere or may be,
every thing is right and you and I are wrong.
As you know that to either retrieve a record from a dataset or to add a record to a database, we
use the following four parameters to conduct our operation:
CALL-FUNCTION
IO-PCB OR PCB-MASK
SEGMENT-IO-AREA
QUAL OR UNQUAL SSA.
But in the event of a SPA we are using the first three, but not the last one, that is SSA.
Why is it that way
This is because a Scratch Pad Area is not really a database.
In the event of a SPA So you dont need either a qualified or unqualified SSA. You are just
bringing some information, which is stored in a specific area, from where you retrieve it for further
activity.But something still remains the same Even though you are not retrieving anything from the
database, but since it is defined to IMS, you still use the STATUS CODE. Because you must
know what happened But something still remains the same When you tried to get the information
from the Scratch Pad Area, because you still need to use that information to do something in your
database. So it is important. Because you must know what happened.

Conversation Program Is really nothing but when two programs talk to each other by sharing
information, which has been left by one in a specific area to be used by the other, whenever there
is a need.