Reminiscence...

A refreshing session on
IMS database concepts
Anusha Battu

IMS
INFORMATION MANAGEMENT SYSTEM

Developed in 1968 by IBM

Data Language-I (DL/I) was developed as a interface between application code and data in IMS database

It supports Hierarchical DB structure

What is a hierarchical database???

There is always a basic or "root" segment.

A segment may relate downwards to one or more subordinate
segments; these subordinates are referred to as "child" segments.
A subordinate (child) segment may relate upward to only one superior
or "parent" segment.
Follows INVERTED TREE STRUCTURE

Structure of IMS Database

ROOT SEGMENT (PARENT)
A2

-- Level 1

A1
SEGMENT OCCURRNCES

B3
B1

B2

C1

TWIN SEGMENTS

D1

-- Level 2

DEPENDENT SEGMENTS

IMS terminology
Each box in the database hierarchy chart represents a SEGMENT

SEGMENT -smallest
-smallest block
block of
of information
information
SEGMENT
that DL/I
DL/I can
can access
access in
in
the
that
the
database.
Segment
name -max of 8 chars
database.
FIELD -- Field
Fieldisisthe
thesmallest
smallestunit
unitofofinfo
infoininthe
thedatabase.
database.
FIELD

Field name -max of 8 chars

Each segment contains one or more fields of information.
Two types of fields
Key

Field
Search Field
Key field is used to sequence the database and is unique. It cannot be changed
where as search field value can be change according to our prog requirement

Segments

PARENT SEGMENT - segment that has one or more segments dependent on it.

These dependent segments must be on the level directly below the parent.

CHILD SEGMENT - segment that is directly dependent on some other segment.

A segment without parent is called as ROOT SEGMENT.

DEPENDENT SEGMENTS - all the segments under a particular segment of a database.

SEGMENT OCCURRENCE - particular instance of a segment type

TWIN - occurrences (2 or more) of a segment type under a parent

SIBLINGS - occurrences of different segment types under a parent

RECORD - one occurrence of a root segment along with all its dependent segments

Segment Format

Prefix
Segment
Code
1 byte

Delete byte
1 byte

Data
Counters
and
Pointers

Size field

Seq. (key)

Data

field
2 bytes

4bytes per
element

Segment Code

To identify each segment type stored in a database (1 to 255).

Delete byte

To track the status of a deleted segment

Counters and
Pointers

Pointers consist of one or more addresses of segments pointed to by this

segment. Counter information is used when logical relationships are defined.

Size field

This field states the size of the segment, including the size field (2 bytes).

Seq. (key)

The sequence field is often referred to as the key field.

Data

To contain the actual data being stored in the database.

IMS DATABASE LIMITATIONS

15 levels
255 segments
1000 fields
No limitation on number of segment occurrences.

Physical & Logical Database

A

PHYSICAL DATABASE
Represents how the data is actually recorded or stored on the storage medium (usually disk). Database
records, composed of the root segment and all of its dependent segments are stored in hierarchical
sequence:
Top to bottom
Left to right
Physical Database is defined in the Data Base Description (DBD).
LOGICAL DATABASE
Represents the sequence of segments from one or more physical databases required by an
application program. These segments are combined to create a new hierarchical structure.
The logical data structure is defined in the Program Specification Block (PSB).

DBD

The DBA initiates a process called DBDGEN (database description

generator) to describe the physical structure of the database and to create
a DBD (database description).

Defines the layout and characteristics of the database

Name of the DBD

Type and access method for the DBD (HIDAM, HDAM, etc.)
DD Name for the database
Device Type
Block Size
Name, parent, length of each segment type in the database.
Name, length, starting position, and type of data for each sequence and
search field in each segment

Example for DBDGEN Control statements:

PRINT
DBD
DATASET
SEGM
FIELD
SEGM
FIELD
SEGM
FIELD
FIELD
DBDGEN
FINISH
END

NOGEN
NAME=VENDOR,ACCESS=HDAM
DD1=VEND,DEVICE=3380
NAME=VENSEG,PARENT=0,BYTES=10
NAME=(VENCODE,SEQ,U),BYTES=10,START=1,TYPE=C
NAME=ITEMSEG,PARENT=VENSEG,BYTES=5
NAME=(ITEMCODE,SEQ,U),BYTES=5,START=1,TYPE=C
NAME=LOCNSEG, PARENT=ITEMSEG, BYTES=9
NAME=(LOCNCODE,SEQ),BYTES=3,START=1,TYPE=C
NAME=ORDDATE,BYTES=6,START=4,TYPE=C

Macros/Control statements
DBD:
The DBD statement...
Names the database
Identifies the access method
DATASET:
The DATASET statement specifies.
The DD name used in the JCL
Disk DEVICE type (e.g. 3380)
Block size (e.g. 4096)
Free space % (FRSPC)

Macros/Control statements
SEGM:
There is one SEGM statement for each segment in the database. SEGM ...
names the segment (max 8 characters)
identifies the PARENT segment
establishes the length of the segment
NOTE: PARENT=0 signifies the root segment.
FIELD:
FIELD statements are used to define KEY fields and SEARCH fields...
SEQ defines EMPID to be a KEY field
U defines EMPID to be a UNIQUE key
BYTES defines the field size
START defines starting position in the segment for this field
TYPE defines field type

Typ

Description

Cobol
Picture

Character
(Default)

Packed Decimal

COMP-3

Zoned Decimal

S9

Half word Binary

9(4) COMP

Full word Binary

9(8) COMP

PSB

The PSB is made up of one or more PCB's (Program Communication Block), and this
defines the logical structure a program will use.

The PSBGEN process produces a load module stored in the PSBLIB library.
These load modules are called PSB's.

The PSB is a control block that defines the logical data structure a program will use.

While many application programs can share the same PSB (but usually do not),
programs can only use one PSB in a given application.

The Program Communication Block defines which of the segments in the database the
program is "sensitive" to (can access).

The PCB also defines how the application program is allowed to process the segments.

The Program Specifications Block (PSB) supplies IMS with a description of what
database information (which database segments) may be accessed by the application
program. Each PSB consists of one or more Program Communication Blocks (PCB).

Example:
PCB
TYPE=DB,DBDNAME=EMPDBD,KEYLEN=16
SENSEG NAME=EMPDATA,PARENT=0,PROCOPT=K
SENSEG NAME=WORKDATA,PARENT=EMPDATA,PROCOPT=G
PSBGEN LANG=COBOL,PSBNAME=EMPPSB1
END
TYPE:
Data type: Character
Length: 4
Valid values: DB, TP and GSAM.
DBDNAME: Name of the Database the program needs access to.
Data type: Character
Length: 8
KEYLEN: The length in bytes of the longest concatenated key for the segments
requested in the PSB. Segment key length may be found in the DBD.
Data type: SMALLINT

SENSEG The name of the segments in the database your program needs
access to.
NAME: Name of the segment sensible to the program
Data type: Character
Length: 8
PARENT: Name of the Parent Segment
Data type: Character
Length: 8
PROCOPT: Defines how the segment may be accessed (G, I, R, D, A, K, L etc.)
Data type: Character
Length: 4

Valid PROCOPTs include:

GET (READ)

INSERT

REPLACE

Access to only the KEY of the segment

ONLY: used with G to indicate that Get Hold calls are

not allowed

Position function (Path calls)

DELETE

All options (G, I, R, D)

LOAD (initial load of data)

LANG: Programming language in which the application program is coded.

Data type: Character
Length: 5
PSBNAME: It gives the PSB a name (usually the same name as the application
program name that will use the PSB).

IMS-COBOL application program:

Working Storage Section
Function codes
Segment search argument (SSA)
Input/output area

Linkage Section
program communication block (PCB mask)

Procedure Division
Entry and exit statements
DL/I call statement; status code checks

Function Codes:

A Function code is a 4-byte word used to tell DL/I what kind of call to make

CODE

MEANING

DESCRIPTION

GU

Get-Unique

To obtain a unique occurrence of a

segment within a database.

GN

Get-Next

To obtain the next occurrence of a

segment within a database.

GNP

Get-Next-Within-Parent

GHU

Get-Hold-Unique

GHN

Get-Hold-Next

GHNP

Get-Hold-Next-Within-Parent

REPL

REPLACE

To replace an occurrence of a segment

DLET

DELETE

To delete an occurrence of a segment

ISRT

INSERT

To insert an occurrence of a segment

into database

To obtain the next occurrence of a

segment under a parent; retrieves
child
segments under a parent sequentially.
The

GET-HOLD function codes

identical
to the GET codes except that they
must
be used for retrieval if you intend to
ALTER the data being retrieved.

SSA:

It is an optional DL/I call parameter that qualifies a call by specifying a

particular segment type or occurrence

In SEGMENT SEARCH ARGUMENTS (SSAs) you can provide:

The name of the segment type you want.
A description of a specific segment.
One or more "command codes" to qualify your DL/I call even more.

I/O: Input/ Output area

It is a standard record description in the WORKING STORAGE SECTION
which hold database segments for manipulation.
Must be equal to or greater than the length of the longest segment to be used
By the program

PCB MASK:

It is used to transfer information about each call made to DL/I back to the program.

You must code one Database PCB MASK for each database your program will access.

The 01 level name should be unique for each database.

Example:
WORKING STORAGE SECTION
LINKAGE SECTION
01 DB-PCB-1.
03 DBD-NAME
PIC X (8).
03 SEG-LEVEL
PIC X (2).
03 STATUS-CODE
PIC X (2).
03 PROC-OPTIONS
PIC X (4).
03 IMS-ADDRESS
PIC X (4).
03 SEGMENT-NAME
PIC X (8).
03 KEY-LENGTH
PIC S9 (5) COMP.
03 NUM-SENS-SEGS PIC S9 (5) COMP.
03 KEY-FEEDBACKS.
05 SEG-KEYS

PIC X (#)

The most important field in PCB mask is STATUS-CODE. This field informs you if the
DL/I call is successful or not.

You must specify the longest possible concatenated key.

DPRD#G.CHGMAN.CPY.BASE0(DPCMASK)

ENTRY and EXIT statements:

It must be the first executable statement in the program. It must follow immediately
after the title PROCEDURE DIVISION.

NOTE: List the names of the DB-PCB mask in the same order as they are defined in the
PSB for your program.

For exit, you can use GOBACK (not STOP RUN).

DLI CALL

CALL 'CBLTDLI' USING FUNCTION-CODE,

PCB-MASK,
IO-AREA,
SSA-1,
SSA-2...

SSA
SSA When specified in a DL/I call is an optional DL/I CALL parameter that qualifies a call by
specifying a particular segment type OR segment occurrence.

The SSA always follows the I/O area parameter

There may be 1 to 15 SSAs specified in a call stmt.

The SSAs must appear in hierarchical order by segment type.

The SSA contains the information necessary to obtain the segment you require.
This information could be
The segment name.
The segment name and segment key.
The segment name and search field.

Types of SSA
1.

Unqualified SSA: Searches for a specific segment type

An unqualified SSA is a segment search argument which specifies a segment name ONLY.
The 9th position in the literal must be blank. This indicates an unqualified SSA.

01 UNQUAL-SSA.
02 SEG-NAME PICTURE X(08) VALUE '........'.
02 FILLER
PICTURE X
VALUE ' '.
2. Qualified: Searches for a specific segment occurrence of a specific segment type.

Supplies the DL/I call with either a KEY or SEARCH FIELD value in addition to the SEGMENT NAME.

A left parenthesis '(' in position 9 or after a variable number of command codes signifies the beginning
of a qualification statement.

The right ')' closing parenthesis signifies the end of the qualified SSA.

01 SSA-EMPLOYEE.
03 SEGMENT-NAME
03 COMMAND-CODE
03 BEGIN-QUALIFY
03 KEYNAME
03 OPERATOR
03 KEY-VALUE
03 END-QUALIFY

PIC X(8) VALUE 'EMPLOYEE'.

PIC X(2) VALUE '*-'.
PIC X(1) VALUE '('.
PIC X(8) VALUE 'EMPKEY '.
PIC X(2) VALUE '='.
PIC X(11).
PIC X(1) VALUE ')'.

OPERATOR: Relational Operator

>(GT), < (LT), >=(GE), <=(LE), =EQ, =(NE)
COMMAND CODE:

Command codes are designated by a * immediately fallowed by one or more

command codes.

The initial value of COMMAND CODE is '*-'. The '-' is a NULL COMMAND

Code

Function

Use a concatenated key

Retrieve a path

Do NOT replace this segment

Establish parentage at this level

Access first segment occurrence

Access last segment occurrence

Maintain current position at this level

Maintain current position at this and higher levels

Null/ignore

FUNCTION CODES:
GU:

To obtain a unique occurrence of a segment within a database.

Qualified SSA is used
No SSA Root Segment

Blank Successful
GE Not Found
GB End of the DB
Example:
The SSA is used to build the GU call.
01 SSA-1.
03 SEGMENT-NAME
PIC X(8) VALUE 'SEGMENTA'.
03 COMMAND-CODE PIC X(2) VALUE '*-'.
03 BEGIN-QUALIFY
PIC X(1) VALUE '('.
03 KEYNAME
PIC X(8) VALUE 'AKEY '.
03 OPERATOR
PIC X(2) VALUE ' ='.
03 KEY-VALUE
PIC X(11) VALUE '12'.
03 END-QUALIFY
PIC X(1) VALUE ')'.
GU SEGMENTA *-(AKEY

= 12)

GN:

To retrieve segments sequentially

Used with 1.No SSA

2.Unqualified SSA
3.Qualified SSA
Blank Successful
GE Not Found
GB End of DB
Example:

GNP:
Get Next within Parent is used to sequentially access dependent
segments of an established parent segment.

The first thing you must do before using GNP is to establish

parentage. There are two ways:
1. By issuing a successful GU or GN call.
2. By using the P Command Code (Establish Parentage) with a GU,
GN, or GNP call.

Effected by GU, GN, ISRT or DLET

GP: Lowest Segment in the call is not under parent.

PATH CALL:

To retrieve a segment and all of its higher level segments without having to issue a call for each
one.
For this you need to use the Command code D which is called as Path Command Code used for
Path Calls.
The Program Specification Block (PSB) for your program must specify an additional PROCOPT
value (P) in order to make path calls.

GN SEGMENTA *D(AKEY =1)

SEGMENTB *D(BKEY =2)
SEGMENTD *-(DKEY =5)

REPL:

Should be preceded by GHU or GHN

Update the I/O area
No SSA
N No Replace

AJ: If SSA
AM: Replacing segments which doesn't have Replace sensitivity
DA: Key is changed
RX: Violation of Replace rules
Steps:
1.GHU call
2.Update I/O
3.REPL call

INSERT:

To 'load' records to an IMS database, you use the insert function code - ISRT - in a DL/I
call.
To add new records or segments to an existing IMS database you use the same insert
function code - ISRT - in a DL/I call.
So, the ISRT call is used in two modes,
LOAD
INSERT

LOAD Mode: In LOAD mode, only two processing options are allowed:
L (LOAD) and LS (LOAD SEQUENTIAL).
LS is usually preferred as it specifies that segments must be loaded in ascending
sequence. L processing option means load the database, but not necessarily in
sequential order.

INSERT Mode: In INSERT mode, processing options can be:

I - insert new segments in sequential or random order. IS - add new segments only in
ascending sequence.

 The segment to be inserted must first be built in the program IO-AREA.

Use SSAs to define the path to DL/I.
Using the 'D' COMMAND CODE to insert a path of segments.
Use an unqualified SSA at segment level(s) where the insertion will
occur.
New segments added to an existing database are inserted based on the
segment KEY field:
Segments with a KEY field can be inserted in KEY sequence.
Segments with no KEY or non-unique KEY will be inserted according to
Insert Rules specified in the DBD.
STATUS CODES for ISRT:
II: Tries to insert a segment that already exists
GE: Could not find the path of the segments specified in our SSAs.

DLET:

Just like REPL call, DLET call must be preceded by one of the three GET HOLD calls.
Deletes a segment along with all its dependent segments
No SSA is used
Only one situation to use SSA in DLET call

DA: Key is changed

DJ: No GH call
DX: Delete rule violation

Secondary Indexes
What is a Secondary Index?
Secondary Index is a alternate accessing path to access a segment
in IMS DB which in turn improves the response and faster access.
Why Secondary Indexes?
For accessing a segment type based on the search field in a
dependent segment type of search field within the segment type so
that we can avoid sequential scan of entire database

Allow you to process a segment type in a sequence other than the

one defined by the segment's key.

 Characteristics

of Secondary Indexes

A secondary index is in its own separate database so it can be processed as a separate

database and must use VSAM as its access method.

Are invisible to the application program. And program to use must code PROCSEQ= parameter
in the PCB

If an application program needs to do processing using the regular processing sequence,

PROCSEQ= is simply not coded.

If the application program needs to do processing using both the regular processing sequence
and the secondary index, the application program's PSB must contain two PCBs, one with
PROCSEQ= coded and one without.

There can be 32 secondary indexes for a segment type and a total of 1000 secondary indexes for
a single database.

3 Types of Segment used for S. Ix.

Target Segment.

It is the segment the application program needs to retrieve.

Can be at any of 15 level.

Source Segment.

contains the field that the pointer segment has as its key field.
Data is copied from the source segment and put in the pointer segment's key field.

Pointer Segment.

The pointer segment is contained in the secondary index database and is the only
type of segment in the secondary index database.

Notes:-

Target and source can be same.

Source is dependent and target
DLI call with S.Ix Ptr Segment search Access target Segment

How a Secondary Index Is Stored

Secondary Index are stored in a single VSAM KSDS if the key in the pointer segment is unique.

If keys are not unique, an additional data set must be used (an ESDS) to store segments
containing duplicate keys.

The pointer field at the beginning of the logical record exists only when the key in the data portion of the
segment is not unique.
Pointer segments containing duplicate keys are stored in the ESDS in LIFO (last in, first out) sequence.
The KSDS logical record is updated to point to the second duplicate.

the original pointer segment (the one in the KSDS) is retrieved last.

Format and Use of Fields in a Pointer Segment

Like all segments, the pointer segment has a prefix and data portion.
The prefix portion has a delete byte, and when direct rather than symbolic pointing is used, it
has the address of the target segment (4 bytes).

All fields in the data portion of a pointer segment contain data taken from the source

segment (with the exception of user data).

Delete Byte: The delete byte is used by IMS to determine whether a segment has been deleted from
the database.
Pointer Field: This field contains the RBA of the target segment.
The pointer field exists when direct pointing is specified for an index pointing

Constant Field: This field, when present, contains a 1-byte constant. The constant is used when
more than one index is put in an index database.

Search Field: The data in the search field is the key of the pointer segment.

All data in the search field comes from data in the source segment.

As many as five fields from the source segment can be put in the search field.

Need not be contiguous in the source segment but will be concatenated in the search filed.
The data in the search field (the key) can be unique or non-unique.

Subsequence Field: The subsequence field, like the search field, contains from one to five fields
of data from the source segment.

Subsequence fields are optional, and can be used if you have non-unique keys.
When a subsequence field is used, the subsequence data is concatenated with the data in the
search field. These concatenated fields become the key of the pointer segment.
The subsequence field can make non-unique keys unique.
Max of 5 fields in the source segment can be used in this field.
This field cannot be seen by application program.

Duplicate Data Field: The duplicate data field, like the search field, contains from one to five
fields of data from the source segment.

Use duplicate data fields when you have applications that process the secondary index as a
separate database.

This field cannot be seen by application program.

Concatenated Key Field: This field, when present, contains the concatenated key of the target
segment.

field exists when symbolic pointing is used

Also, symbolic pointers generally require more space in the pointer segment.

User Data in Pointer Segments: You can include any user data in the data portion of a pointer
segment by specifying a segment length long enough to hold it.

Like data in the subsequence and duplicate data fields, user data is never seen by an application
program unless it is processing the secondary index as a separate database.

During reorganization of a database that uses secondary indexes, the secondary index database
is rebuilt by IMS. During this process, all user data in the pointer segment is lost.

Making Keys Unique Using System Related Fields

If you cant make unique key using source fields

Using the /SX Operand:

FIELD NAME = /SXaaaaa In Source segment

You can code a FIELD statement with a NAME field that starts with /SX.

The /SX operand is specified in the SUBSEQ= operand in the XDFLD statement.

Creates RBA of the source segment as subsequent field ensuring that key is unique.

Using the /CK Operand:

FIELD NAME = /CKaaaaa In Source segment

You can code a FIELD statement with a NAME field that starts with /CK.

The /CK operand is specified in the SUBSEQ= operand in the XDFLD statement.

The /CK operand works like the /SX operand except that the concatenated key, rather than the RBA, of the source segment is
used.

you can use a portion of the concatenated key of the source segment (if some portion will make the key unique) or all of the
concatenated key using the parameters BYTES= and START=.

Making key fields unique avoids the overhead of using an ESDS to hold duplicate keys.

How the Secondary Index is Maintained

IMS always begins index maintenance by building a pointer segment from information in the source
segment that is being inserted, deleted, or replaced.
Inserting and Deleting a Source Segment: When a Source segment is inserted/deleted the
corresponding pointer segment will be inserted/deleted by IMS.
Replacing a Source Segment: IMS determines what needs to be done by comparing the pointer
segment it built (the new one) with the matching pointer segment in the secondary index (the old
one).

If there is no change to the old pointer segment, IMS does not do anything.
If the non-key data portion in the new pointer segment is different from the old one, the old
pointer segment is replaced. User data in the index pointer segment is preserved when the
pointer segment is replaced.
If the key portion in the new pointer segment is different from the old one, the old pointer segment
is deleted and the new pointer segment is inserted. User data is not preserved when the index
pointer segment is deleted and a new one inserted.

Processing a Secondary Index as a Separate Database

Because they are actual databases, secondary indexes can be processed independently.
2 Reasons to process Secondary as a separate database.
1.

When you want small piece of data from database, you can put the data in the pointer segment
itself. So that accessing the regular database can be avoided.

2.

You can add to or change the user data portion of the pointer segment. The only way an
application program can see user data or the contents of the duplicate data field is by
processing the secondary index as a separate database.

The restrictions are as follows:

Segments cannot be inserted.

Segments can be deleted. Note, however, that deleted segments can make your secondary
index invalid for use as an index.

The key field in the pointer segment (which consists of the search field, and if they exist, the
constant and subsequence fields) cannot be replaced.

PROT, NOPROT:
You can code the PROT/NOPROT operand in the DBD statement.
PROT:

You can delete the pointer segment

You can replace only the user data field in the pointer segment.
NOPROT:

You can delete the pointer segment

You can replace all the fields in the pointer segment except the key fields.

PROT is the default

For using the secondary index as separate database

Code a PCB for the application program. This PCB must reference the DBD for the secondary
index.

The SSAs must use the complete key of the pointer segment as the qualifier.

The PCB key feedback area in the application program will contain the entire key field.

How to Specify Use of Secondary Indexing in the DBD

Ex:

Where
EDUC: Actual database
SINDX: Secondary index database

DBD stmt for Actual database

Parameters in DBD stmt for Actual database:

An LCHILD and XDFLD statement are used to define the secondary index. These statements are coded
after the SEGM statement for the target segment.
LCHILD:

NAME= specifies the name of the secondary index SEGM statement and the name of the secondary
index database

PTR= parameter is always PTR=INDX when a secondary index is used.

XDFLD: Defines the content of the pointer segment and options used in the secondary index.

NAME= The name that can be used in the SSA to qualify a DL/I call on the secondary processing
sequence.

SEGMENT= This parameter identifies the source segment

this operand is omitted, the target segment is assumed to be the same segment as the source segment.

SRCH= Specifies the one to five fields from the source segment that are to be copied into the pointer
segment's search field.

SUBSEQ= Specifies the one to five fields from the source segment that are to be copied into the pointer
segment's subsequence field.

DDATA= Specifies the one to five fields from the source segment that are to be copied into the pointer
segment's duplicate data field. This parameter is optional.

DBD stmt for S.Ix database

Parameters in DBD stmt for S.Ix database:

DBD statement:
NAME= Specifies the name of the secondary index database.
ACCESS= Parameter is always ACCESS=INDEX for the secondary index DBD.
SEGM statement:
NAME= You choose name of the pointer segment.
This is used in PCB when using the secondary index as a separate database.
FIELD statement:
NAME= Parameter specifies the sequence field of the secondary index.
the sequence field is composed of both the search and subsequence field data
LCHILD statement:
NAME= Specifies the name of the target segment and target database
INDEX= parameter has the name on the XDFLD statement in the target database.
PTR=
SNGL: Direct address pointer
SYMB : Symbolic pointer

How SSAs with Secondary Indexes works ???

Use the name of an indexed field in your SSAs.

IMS goes directly to the secondary index and finds the pointer segment with the value you
specify.
Then IMS locates the segment that the index segment points to in the database and returns the
segment to your program.

Guidelines to use:

Define the indexed field in the DBD for the primary database in the XDFLD statement during DBD
generation.
Use the name that was given on the XDFLD statement as the field name in the qualification
statement.
Specify the secondary index as the processing sequence during PSB generation. Do this by
specifying the name of the secondary index database on the PROCSEQ parameter on the PCB
during PSB generation.
Can use two AND operators to connect the qualification statements: 1) * or &, 2) #

Dependent AND:

GU PATIENT (XBILLING>=00500*XBILLING<=01000)

Independent AND:

GU PATIENT(XILLNAME=TONSILITIS#XILLNAME=STREPTHRT)

What DL/I Returns with a Secondary Index ???

Instead of giving you the key for the segment you requested, IMS gives you the
search portion of the key of the secondary index (the key for the segment in the
INDEX database).
I/O area looks just as it would if you had not used secondary indexing.

Status Codes for Secondary Indexes:-

NI: Try to insert or replace a segment that contains a secondary index source field

that is a duplicate of one that is already reflected in the secondary index,

NE: Finds no pointer segment for an existing source segment

GSAM Databases

GSAM enables IMS batch application programs and BMPs to access a sequential data set as
a simple database.

A GSAM database is a z/OS data set record that is defined as a database record.

The record is handled as one unit

it contains no segments or fields and the structure is not hierarchic.

To process a GSAM database, an application program issues calls similar to the ones it issues to
process a full-function database.

The program can read data sequentially from a GSAM database, and it can send output to a
GSAM database.

An IMS program can retrieve records and add records to the end of the GSAM database, but the
program cannot delete or replace records in the database.

You use separate calls to access GSAM databases.

GSAM DBD generation

During DBD generation for a GSAM database, you specify:

One data set group

The ddname of an input data set that is used when an application retrieves data from
the database
The ddname of an output data set that is used when loading the database

You cannot specify:

SEGM and FIELD statements

The use of logical or index relationships between segments

DBD NAME=DDBBT003,ACCESS=(GSAM,BSAM),
DATASET DD1=DDBBT003, RECFM=FB
DBDGEN
FINISH
END

GSAM PCB Statement

PCB TYPE=GSAM,DBDNAME=DDBBT003, PROCOPT=G
TYPE=GSAM
Is a required keyword parameter for all GSAM database PCBs

DBDNAME=
Is a required keyword parameter for the name that specifies the GSAM DBD to be used as the
primary source of data set description

PROCOPT=
the processing options on the data set declared in this PCB that can be used in an associated
application program.

Valid PROCOPTs:
G, GS, L and LS

Retrieving and Inserting GSAM Records

To retrieve GSAM records sequentially, use the GN call.

To process the whole database, issue the GN call until you get a GB status code in
the GSAM PCB.

GSAM automatically closes the database when you reach the end of it.

To create a new data set or to add new records to the end of the database, use the
ISRT call.

GSAM adds the records sequentially in the order in which you supply them.

You can retrieve records directly from a GSAM database, but you must supply the
record's address.

To do this, use a record search argument (RSA). An RSA is similar to an SSA, but it
contains the exact address of the record that you want to retrieve

Explicitly Opening and Closing a GSAM Database

IMS opens the GSAM data set when the first call is made and closes the data set when
the application program terminates.

However, explicit OPEN and CLSE calls are useful in the following two situations:

If the application program loads a GSAM data set, and then in the same step reads the
data set using GSAM (for example, to sort the data set). The application program should
issue the GSAM CLSE call after the load is complete.

If the GSAM data set is an output data set, and it is possible that when the program
executes it does not make GSAM ISRT calls. A data set is not created. Subsequent
attempts to read the nonexistent data set (using GSAM or not) will likely result in an
error. To avoid this situation, explicitly open the data set. DL/I closes the data set when
the step terminates. Closing the data set prevents the possibility of attempting to read
an empty data set.

The explicit OPEN or CLSE call need not include an I/O area parameter.

Depending on the processing option of the PCB, the data set is opened for input or
output.

GSAM Record Formats

GSAM records are non keyed.

For variable-length records you must include the record length as the first 2 bytes of
the record.

If you use undefined-length records, record length is passed between your program
and GSAM in the 4-byte field that follows the key feedback area of the GSAM DB
PCB.

When you issue an ISRT call, supply the length.

When you issue a GN or GU call, GSAM places the length of the returned record in
this field

The advantage of using undefined-length records is that you do not need to include
the record length at the beginning of the record, and records do not need to be of
fixed length.

The length of any record must be less than or equal to the block size (BLKSIZE) and
greater than 11 bytes (an MVS convention).

GSAM I/O Areas

The format of the I/O area depends on whether the record is fixed-length, undefinedlength (valid only for BSAM), or variable-length. For each kind of record, you have the
option of using control characters.

The formats of an I/O area for fixed-length or undefined-length records are:

With no control characters, the I/O area contains only data. The data begins in byte 0.

With control characters, the control characters are in byte 0 and the data begins in
byte 1.

The formats for variable-length records

Without control characters, bytes 0 and 1 contain the 2-byte length field, and the data
begins in byte 2.

With control characters, bytes 0 and 1 still contain the length field, but byte 2 contains
the control characters, and the data starts in byte 3.

PCB Masks for GSAM Databases

GSAM describes the results of those calls in a GSAM DB PCB.

Some of the fields are different from DB PCB masks, and the GSAM DB PCB has one field that the other PCBs
do not.

Because GSAM is not a hierarchic database, some fields in a PCB mask for other IMS databases do not have
meanings in a GSAM PCB mask.

01 DB-PCB-1.
03 DBD-NAME
PIC X (8).
03 SEG-LEVEL
PIC X (2).
03 STATUS-CODE
PIC X (2).
03 PROC-OPTIONS
PIC X (4).
03 IMS-ADDRESS
PIC X (4).
03 SEGMENT-NAME
PIC X (8).
03 KEY-LENGTH
PIC S9 (5) COMP.
03 NUM-SENS-SEGS PIC S9 (5) COMP.
03 KEY-FEEDBACKS PIC X (8).
03 UNDEFINED-LENGTH PIC X (4).

Database Name. The name of the GSAM DBD. This field is 8 bytes and contains character data.

Segment Level Number. Not used by GSAM, but you must code it. It is 2 bytes.

Status Code. IMS places a two-character status code in this field after each call to a GSAM database.

Processing Options. This is a 4-byte field containing a code that tells IMS the types of calls this program can
issue.

Reserved for IMS. This 4-byte field is used by IMS for internal linkage.

Segment Name. This field is not used by GSAM, but it must be coded as part of the GSAM DB PCB mask. It is 8
bytes.

Length of Key Feedback Area and Undefined-Length Records Area. This is a 4-byte field that contains the
decimal value of 12. This is the sum of the lengths of the key feedback and the undefined-length record areas
described below.

Number of Sensitive Segments. This field is not used by GSAM, but it should be coded as part of the GSAM DB
PCB mask. This field is 4 bytes.

Key Feedback Area. After a successful retrieval call, GSAM places the address of the record that is returned to
your program in this field. This is called a record search argument (RSA). This field is 8 bytes.

Undefined-Length Records Area. If you use undefined-length records (RECFM=U), the length in binary of the
record you are processing is passed between your program and GSAM in this field. This field is 4 bytes long.

When you issue a GU or GN call, GSAM places the binary length of the retrieved record in this field.
When you issue an ISRT call, put the binary length of the record you are inserting in this field before issuing the
ISRT call.

GSAM Status Codes

AF

AH

An I/O error occurred when the data set was accessed or closed.

GB

You have issued an invalid request against a GSAM database.

AO

One of the parameters on the RSA that you supplied is invalid.

AM

There has been a data management OPEN error.

AJ

You have not supplied an RSA for a GU call.

AI

GSAM detected a variable-length record with an invalid format. Terminate your program.

You reached the end of the database, and GSAM has closed the database. The next position is the
beginning of the database.

IX

You issued an ISRT call after receiving an AI or AO status code. Terminate your program.

Origin of GSAM Data Set Characteristics

For an input data set, the record format (RECFM), logical record length (LRECL), and block size
(BLKSIZE) are based on the input data set label.

If this information is not provided by a data set label, the DD statement or the DBD specifications
are used. The DD statement has priority.

Record Format:

Using the RECFM= parameter of the DATASET statement of DBDGEN, or

DCB=RECFM=xxx on the DD statement.
If the record format is specified on both, the DD statement has priority.
V, VB, F, FB, U

Logical Record Length:

using the RECORD= parameter of the DATASET statement of DBDGEN, or

DCB=LRECL=xxx on the DD statement.
If the logical record is specified on both, the DD statement has priority.

Block Size:

Using the BLOCK= or SIZE= parameter of the DATASET statement of DBDGEN, or

use DCB=BLKSIZE=xxx on the DD statement.
If block size is specified on both, the DD statement has priority.

DD Statement DISP Parameter for GSAM Data Sets

The DD statement DISP parameter varies, depending on whether you are
creating input or output data sets and how you plan to use the data sets:

For input data sets, use DISP=OLD.

For output data sets, you have a number of options:

If you are creating an output data set allocated by the DD statement, use
DISP=NEW.

To create an output data set that was previously cataloged, but is now empty, use
DISP=MOD.

When restarting the step, use DISP=OLD.

Finally, to add new records to the end of an existing data set, use DISP=MOD.

Suggested Method for Specifying GSAM Data Set Attributes

When specifying GSAM data set attributes:

On the DBD, specify RECFM. (It is required.)

On the DATASET statement, specify the logical record length using RECORD=.

On the DD statement, do not specify LRECL, RECFM, or BLKSIZE. The system determines block size,
with the exception of RECFM=U. The system determines logical record length from the DBD.

For the PSB, specify PROCOPT=LS for output and GS for input. If you include S, GSAM uses multiple
buffers instead of a single buffer for improved performance.

Use of Concatenated Data Sets by GSAM

GSAM can use concatenated data sets, which may be on unlike device types, such as DASD and
tape, or on different DASD devices.

Logical record lengths and block sizes can differ.

The maximum number of concatenated data sets for a single DD statement is 255.

The number of buffers determined for the first of the concatenated data sets is used for all succeeding
data sets. Generation data groups can result in concatenated data sets.

Database Recovery

Making sure that problems with the system have as little impact on the integrity of the DB and the
efficiency of the operations systems as possible.

Abnormal Termination Routine:

When an application program fails, DL/I intervenes to contain the damage thats done to the DB.
It does this by invoking Abnormal Termination Routine.

ATR makes sure that the DB datasets are properly closed and their catalog entries are properly
updated too.

In addition to that, DL/I log the program was using is also properly closed.

Although DL/I terminates your abending program in an orderly way, its function is to prevent
additional database damage, not to correct damage thats already been done.

Just because the ATR is executed does not insure that the DB in use is accurate.

Its necessary to back out changes made by the abending program, correct the error, then rerun
the program. To do this DL/I log is required.

Logging

DL/I records all the changes a program makes to its DB in a special file called a Log
that can reside on tape or DASD.
When a program changes a segment, DL/I logs both a Before Image and After Image
of it which are used to restore a DB to its proper condition in case of program or
system failure.
DL/I takes care of logging. In fact, logging often extends beyond your programs view
of the DB.

Recovery:

There are 2 types of Recovery

1. Forward Recovery
2. Backward Recovery

Forward Recovery

Change data for a period of time is accumulated, then applied to a copy of the database as is existed
before the changes began.

Forward recovery is normally used only when a DB is physically damaged in some way.

For ex, if a device error makes the current version of the DB inaccessible, forward recovery is used to
restore it.

There are 2 requirements for this

1.
2.

Old copy of the DB has to be available

All the changes posted to the DB since the copy was made must be available.

Dataset Image Copy Utility or Database Image Copy Utility is used to meet the first requirement.

Database Change accumulation Utility: Periodically combine all logs in case they have to be used to
recover the DB.

The O/P of this program is called an accumulated change log.

In situations like a head crash on the DSAD that contains the DB dataset, it has to be forward
recovered.

Forward Recovery can be a time consuming and awkward process.

Forward Recovery

Backward Recovery

Also called as Back out.

Its a simple and more appropriate for most situations.

It used the DB at the time of failure and reverses all the changes made to it since the
program began or since the program issued its last checkpoint.

During Back out, log records for the program are read backwards and their effects are
reversed in the DB.

When the back out is complete, the databases are in the same state they were in
before the failure.

Back out is appropriate when an application ends in a controlled fashion.

Recovery proceeds back to either the start of the program or to the last check point.

Check pointing

Also called as Synchronization point, Sync point, Commit point and point of integrity.

A point in the execution of the program where the DB changes are considered
complete and accurate.

Database changes made before the most recent check point are not reversed by
backward recovery.

DB changes logged after the most recent check point are not applied to an IC of DB
during Forward Recovery.

So, Whenever the BR or FR is used, the DB is restored to its condition at the most
recent check point when the recovery program completes.

Default for the batch programs is that the CP is the beginning of the program.

Basic Check pointing

To use check pointing, you code your program so that it periodically issues checkpoint calls.

Most programs issue check points at intervals like every 100 or 1000 transactions.

And some applications issue check points based on elapsed time, perhaps every 10 or 15 minutes.

CALL CBLTDLI USING DLI-CHKP

I-O-PCB-MASK
CHECKPOINT-ID.

For CHKP call under IMS, you supply the name of a special PCB called the I/O PCB.

Its normally used for Data communication programs. Here we use only the Status-Code field of the IO-PCB.

01

I-O-PCB-MASK.
05 FILELR
05 I-O-PCB-STATUS-CODE

PIC X(10).
PIC XX.

You must list the I-O PCB as the first PCB in the Procedure division.

In Checkpoint-ID field, your program places a value that identifies the Checkpoint record.

Then, During Recovery, the operations team can use the checkpoint-ID to restart the program.

Symbolic Checkpointing

It is similar to basic checkpointing in that you use a CHKP call to write checkpoint records
to a DL/I log.

But the symbolic checkpoint along with extended restart, provide an advantage: they let
you store program data along with the checkpoint records and retrieve that data when its
necessary to restart the program after a failure.

When you use symbolic checkpointing, the check point call begins with the same 3
parameters as the basic checkpoint call.

Then, you can code up to 7 pairs of field names to specify the working storage areas you
want to have saved along with the checkpoint record.

In each pair, the first item is the name of the full word binary field (PIC S9(5) COMP) that
contains the length of the data area to be saved, the second is the name of the data area
itself.

CALL CBLTDLI USING DLI-CHKP

I-O-PCB-MASK
CHECKPOINT-ID
AREA1-LENGTH
AREA1

A program that uses extended restart should always issue an XRST call before it issues any
other DL/I calls.

On XRST call, you list the same working storage fields you list on the CHKP call.

When the program is restarted, DL/I retrieves the values stored in the checkpoint record and
restores the specified fields.

CALL CBLTDLI USING DLI-XRST

I-O-PCB-MASK
RESTART-WORK-AREA
AREA1-LENGTH
AREA1

If the program fails, the problem that caused the failure is corrected and the affected data
bases are restored using forward or backward recovery.

Then, the program is restarted.

The operator supplies the last checkpoint-id on the PARM for the EXEC that invokes the
program.

Then, the XRST call, which is the first call in the program, know the program should restart
rather than begin a normal execution.

Symbolic CHKP and XRST with GSAM

To checkpoint GSAM databases, use symbolic CHKP and XRST calls.

By using GSAM to read or write the data set, symbolic CHKP and XRST calls can be
used to reposition the data set at the time of restart, enabling you to make your
program restartable.

When you use an XRST call, IMS repositions GSAM databases for processing.

When restarting GSAM databases:

You cannot use temporary data sets with a symbolic CHKP or XRST call.

A SYSOUT data set at restart time may give duplicate output data.

Do not use DISP=MOD to add records to an existing tape data set.

Do not use DISP=DELETE or DISP=UNCATLG.

Thank you