Basic IMS For Applications

BASIC IMS CONCEPTS
For Application Staff

By Dan O'Dea
April 15, 2000

∆ΦΟ

2

What is IMS?

IMS stands for Information Management System. IMS has been around since 1965.
Many think it's old technology, but it's very useful.

IMS is a second-generation database. First-generation, or "master file update"
databases, are very slow and not flexible. Many records have the same data as other
records, so space is wasted. To reduce this waste, we need a way of reducing redundant
data. One way to do that is to create a data hierarchy.

Creating data hierarchy implies the most important data is stored first, the least
important data last. For practical purposes, "most important" refers both to being critical
(key fields) and being common (there are many doctors who work in a single hospital).
IMS uses hierarchical data organization.

You may have heard of dataset access methods such as QSAM (Queued Sequential
Access Method) or VSAM (Virtual Storage Access Method). IMS can use VSAM or
OSAM as its file access method.

In addition to the dataset access method, IMS imposes its own organization on data it
stores. Unfortunately, IMS data organizations are also called access methods. IMS has
several of these. This text talks about the two most common, HIDAM and HDAM.

All IMS organization names begin with an "H" to reflect the data hierarchy. The
“AM” means access method. The "D" in both HDAM and HIDAM stands for direct
access. Direct access means a program gets the record “right away” instead of having to
search for it.

When an "I" follows the "H," IMS gets the data using an index. An IMS index works
roughly like an index in a book.

First, let’s look at how we determine data hierarchy. Hierarchy implies two things.
Data are first broken down into related groups, and then ranked in importance. Part of
the logic of ranking data relies on how often the information needs to be stored. Here's a
simple example.

3

Data Evaluation

Let's say we run a school. We want to keep track of what classes students are taking.
Students can take more than one class. A master file database might have records like
these (slashes (/) show field boundaries).

SMITH, JOHN /ENGLISH COMP /A101/MR. CHIPS /
SMITH, JOHN /BASIC BASKETS /C101/MR. WEAVER /
SMITH, JOHN /PHILOSOPHY /A121/MR. BRUCE /
SMITH, JOHN /MILITARY SCIENCE /B101/MS. d'ARC /
SIMPSON, HOMER /DRAMATIC ACTING /E202/MR. MCCLURE/
SIMPSON, HOMER /HISTORY OF PORK /E132/MR. SVIEN /
SIMPSON, HOMER /BASIC BASKETS /C101/MR. WEAVER /
SIMPSON, HOMER /MILITARY SCIENCE /B104/MR. HUN /

There are five records for John Smith and four for Homer Simpson. See how the
name of the student is repeated exactly in each record? Hierarchical databases can group
all the data for John Smith into one record with two parts.

PART 1: Student name.
PART 2: What classes is this student taking?

You can draw this structure as:

Student

Classes

The first segment is called a root segment (or just a root). The second segment is
called a dependent or child segment. The root segment is a parent of the CLASSES
segment. The root segment is called a root when referring to it alone. When discussing
relationships between segments, the "higher" segment is the parent and the lower segment
a child.

We can reduce the size of our records by removing the name field from most of them
and storing it in the root segment. In the picture below, a slash indicates a field boundary
and bold double slashes (//) indicate a segment boundary.

SMITH, JOHN //ENGLISH COMP /A101/MR. CHIPS //BASIC
BASKETS /C101/MR. WEAVER //PHILOSOPHY /A121/MR. BRUCE
//MILITARY SCIENCE /B101/MS. d'ARC //MILITARY SCIENCE /B102/MS. d'ARC

SIMPSON, HOMER //DRAMATIC ACTING /E202/MR. MCCLURE//HISTORY OF
PORK /E132/MR. SVIEN //BASIC BASKETS /C101/MR. WEAVER //MILITARY
SCIENCE /B104/MR. HUN

4

Data Evaluation continued
The advantages to organizing data in this way are obvious.

• Less space is needed to store the data. We need only one name field for each
student rather than one name field per class taken by the student.

• Retrieval is quicker. You only need one I/O to get all of John Smith’s class
information rather than four, because all of his data is on one record.

• Retrieval is more flexible. If all you need is a list of student names, you can read
only the root segments. In this simple database, two I/O guarantees you get all the
students with no duplication. In the master file database all records must be read,
plus an algorithm is needed to determine when the program is done reading John
Smiths.

• Security is better. If you want everyone to see a list of students, but not everyone to
see what classes students are taking, IMS can do that. The master file allows full
access or no access at all.

In a master file database, all prior records must be accessed to write or read the one
you want. IMS lets you read from or write to a specific record in the database without
having to process any other records. Suppose we add this record to the master file
database:

FUDD, ELMER //MILITARY SCIENCE /B104/MR. HUN /

To add the record, we must read the entire database and then write all the records back
into the database. To add the record to an IMS database requires no reads at all, and only
one write.

To read Elmer's record later you'll need ten total I/Os: the five Smith and four
Simpson records, and then the one Fudd record. An indexed IMS database needs two
I/O, one for the index and one for the data segments. A non-indexed database would
need only one I/O.

To some extent this seems like magic. It was an enormous step forward in 1965.
That's why IMS is everywhere in data processing. Before DB2 came along IMS was the
database of choice for most IT shops.

By now some of you must be asking the question, "How do I describe my database to
IMS?" The database description is better known by its abbreviation, DBD. Let's look at
a DBD.

5

Describing an IMS database: the DBD

Here is a DBD. This particular DBD is from an HDAM database. All comments have
been removed to fit it on one page.
DBD NAME=HDAMDBDP,ACCESS=(HDAM,OSAM), C
RMNAME=(DFSHDC40,48,186651,1000)
DATASET DD1=HDAMDBDD,SIZE=8906,SCAN=0
*
SEGM NAME=PARSEG,PARENT=0,BYTES=121
FIELD NAME=(PARKEY,SEQ,U),START=1,BYTES=11,TYPE=C
*
SEGM NAME=DEPSEG1,PARENT=PARSEG,BYTES=46,PTR=NT
*
SEGM NAME=DEPSEG2,PARENT=PARSEG,BYTES=28,PTR=TB
FIELD NAME=(DEPSEG2K,SEQ,U),START=1,BYTES=6,TYPE=C
*
DBDGEN
FINISH
END

Before we proceed with the description of the fields of the DBD, here are some notes
on what you're seeing.

• The DBD is a collection of assembler language macros.
• IMS does not care what your record layout is, unless you intend on accessing a
segment directly. To access a given segment directly you must provide IMS with a
segment key field. This requires the root segment to have a key.
• The fields in this DBD are the required fields. There are many more fields to a DBD,
but they have default values we use most of the time. The defaulted fields are often
left off for clarity.

We'll revisit and discuss the fields of the DBD when we need to. For now, let's use
our existing knowledge to code a partial DBD for our student database.

6

Describing an IMS database: the DBD continued

Here is a single record from our master file database. Remember, a single slash
divides a field boundary; a double slash divides a “segment” boundary.

SMITH, JOHN //ENGLISH COMP /A101/MR. CHIPS /

We are treating the student name as the root segment and the class information as a
dependent segment. Here's how we chose to divide the record:

Root segment: 20 bytes of text, full name.

Child segment: total length of 36 bytes, as:
17 bytes of text, course name;
4 bytes of text, building indicator and room number;
15 bytes of text, instructor name.

The piece of the DBD describing these segments would be:

SEGM NAME=STUDENT,BYTES=20,PARENT=0
FIELD NAME=(STUDKEY,SEQ,U),BYTES=20,START=1,TYPE=C
*
SEGM NAME=CLASINFO,BYTES=36,PARENT=STUDENT
FIELD NAME=(CLASNAME,SEQ,U),BYTES=17,START=1,TYPE=C

Note the following:

• Segment or field names can be up to eight alphanumeric characters. The first one
must be alphabetic.
• Segment or field names do not have to be the same as COBOL field names. The
names do have to be the same in the IMS workarea, however.
• A segment may be all key.
• The key does not have to be in the first few bytes.
• No fields are described except key fields.
• The "PARENT=STUDENT" field tells us the CLASINFO segment is a child of the
STUDENT segment. A root segment has "PARENT=0" because it has no parent.

7

IMS Data Storage: the IMS record

Here are John Smith's five records again:

SMITH, JOHN /ENGLISH COMP /A101/MR. CHIPS /
SMITH, JOHN /BASIC BASKETS /C101/MR. WEAVER /
SMITH, JOHN /PHILOSOPHY /A121/MR. BRUCE /

Here is John Smith's one IMS record again:

SMITH, JOHN //ENGLISH COMP /A101/MR. CHIPS //BASIC
BASKETS /C101/MR. WEAVER //PHILOSOPHY /A121/MR. BRUCE
//MILITARY SCIENCE /B101/MS. d'ARC //MILITARY SCIENCE /B102/MS. d'ARC

The second child segment of the parent "SMITH, JOHN" is underlined. The slashes
are not data.

The record described above is a single IMS record. The definition of an IMS record
is, "A single root segment and all its dependent segments." We can see the IMS data
record is of variable length depending on how many dependent segments it has.

You can request only one dependent segment of the many John Smith may have. To
do so, you must provide the key of the child segment with the read request.

8

IMS Data Storage Rules

IMS has to have rules if the database is to be accessed consistently. We've seen some
of these in action already.

• You can have multiple child segments for a given parent. Any segment with
children can have none, one, or many children attached to it. In our class database
John Smith takes several classes.

• If a parent does not exist, its children cannot exist either. The DBD describes to
IMS what could be, not what is. This means we could also have a student named
Roger Ramjet, but we don't have to. If Mr. Ramjet is not on our database, we cannot
have segments describing what classes he is taking.

• If a parent segment is deleted all of its children are deleted also. This follows the
same logic as the previous rule. If we delete Homer Simpson from the database all
his class segments must also be removed. We must assume if he is not at school he is
not in any classes.

The following rule is not obvious but is nevertheless true.

• Before updating any record the program must do a GET HOLD (GH or GHU)
for that record. The reasons for this are quite simple. If the record isn't on the
database you can't update it. One of the two things a GH does is to make sure the
record you want to update actually exists.

The other thing Get Hold does is to make sure you have exclusive access to the
record. As the name implies, a GH tells IMS to "read the record and hold it for me."
When IMS holds a record it will not allow other accesses to the record for as long as
the hold remains.

9

Accessing an IMS database: Existing Records

When accessing an IMS database for anything but an initial load you need to know a
concept called position. IMS establishes its position in the database based on what it was
last asked to do.

When you open the dataset IMS has no position in the database. IMS will establish
position for itself whenever a call is made to the database.

You may do either qualified calls or non-qualified calls once IMS has established
position.

• Qualified calls (e. g. GET) return only the segment with the same key as your
request.

• Non-qualified calls (e. g. GET NEXT) act on the next segment in the database's
hierarchy, regardless of key. The next segment is determined by position.

Let's do a run through a set of calls to see how this works. We’ll open the database
and then issue the call GET "SMITH, JOHN". The segments you have immediate
access to are John Smith's root segment and his first CLASS segment. From this point
several things can happen based on IMS' position within the database:

• For a qualified call (G), the next segment retrieved is determined by the call.

• For an unqualified call (GN), you'll get the next child segment of John Smith's if
there is one. If there are no more child segments for John Smith, you'll get a non-
blank status code telling you there are no more child segments of that type.

Calls Other than GET on Existing Records

You can update or delete existing records or segments. You must issue a GET HOLD
before you update or delete a segment to make sure it is there and to reserve access to the
segment.

The call to delete a segment is DLT. The call to update a segment is UPD. You must
provide the key for the segment you are altering for both calls. To act on an entire
record, specify the root segment and its key.

10

Accessing an IMS database: New Records

A brand-new IMS database is no different from any other empty file. Because IMS
imposes a structure on the database, though, it needs to keep track of where it has records
and where it has free space. The first time an empty IMS database is accessed must be as
an initial load.

The initial load creates the space map IMS needs. It then loads all the records you
provide.

IMS needs at least one record to initialize a database. Of course, if you have more
than one record IMS loads everything you give it, as long as the records match the
description given in the DBD.

This document does not go into IMS space management. It happens automatically;
you don't need to code for it or understand how it works.

If the database has records in it, an ADD or ISRT call adds the new record or segment
to the database. Whether it is a segment or record being added depends on how the
instruction is coded and what data is being passed to IMS. The ADD call requires all key
information for all segments affected by the call.

An Important Note

If you have an existing IMS database do not try to load it. When IMS loads a
database it assumes the file is unformatted. When IMS builds the space map, it treats the
entire database as if it has no records in it. If there were records, you lost them.

11

Data Storage

IMS databases have data overhead; non-IMS files do not. There are additional fields
embedded in the data to account for the overhead. The organization of an IMS dataset is
not complex; let's take a brief look at it.

When you browse an ordinary data file all you see are data records. When you browse
an IMS dataset, though, you see every extra field IMS has added. This can be confusing,
especially since all the fields IMS adds are in hex or binary and translate to only
accidentally printable characters.

For an IMS OSAM database, the record size is equal to the block size. Therefore, the
"record" you're looking at is an entire block of data. More than one IMS record can fit in
a block, but there are no visible record boundaries.

The first record in a flat file is always a data record. In an IMS OSAM file, the first
record is a space map of the IMS database. This record is nonsense to you unless you
know its format.

Each block in an HD database begins with a Free Space Element Anchor Point
(FSEAP). This is maintained by IMS and tells IMS where the first free space element is
in its particular block. FSEAPs are four bytes long.

Each block in an HD database has a variable-length Anchor Point Area immediately
following the FSEAP. This area contains one or more four-byte pointers. These pointers
are called Root Anchor Points (RAPs) and are used differently in HIDAM and HDAM.
We'll look at them shortly.

Except for the space map block, all blocks in an HD database store their data
immediately following the Anchor Point Area.

IMS does all the work of maintaining free space and root anchor points, as well as the
work of maintaining data record storage. This document does not discuss pointer areas in
detail because you cannot directly access them.

12

IMS Data Storage: the DBD

A non-IMS dataset must specify both a record size and a BLKSIZE (or CI size in
VSAM). Record size fields aren't needed in IMS because the DBD tells IMS how long
each segment is. Let's look at our DBD again:

SEGM NAME=STUDENT,BYTES=20,PARENT=0
FIELD NAME=(STUDKEY,SEQ,U),BYTES=20,START=1,TYPE=C

SEGM NAME=CLASINFO,BYTES=36,PARENT=STUDENT
FIELD NAME=(CLASNAME,SEQ,U),BYTES=17,START=1,TYPE=C

Each SEGM statement in the DBD names a segment. The BYTES operand of the
SEGM statement tells IMS how many bytes of data are in that segment.

IMS doesn't need the block length field either, because it's also coded in the DBD.
Let's look at the first section of the HDAMDBDP DBD again:
DBD NAME=HDAMDBDP,ACCESS=(HDAM,OSAM), C
RMNAME=(DFSHDC40,48,186651,1000)
DATASET DD1=HDAMDBDD,SIZE=8906,SCAN=0

On the DATASET statement is an operand SIZE. This specifies the OS BLKSIZE of
the file. A mutually exclusive operand, BLOCK, also provides this information in a
slightly different way. Using SIZE is recommended because you get better control over
the BLKSIZE of your file.

You should never code an LRECL or BLKSIZE when creating an IMS dataset
because the DBD fully describes the dataset. JCL to load a new IMS database should
have the DDname look something like this:

//HDAMDBDD DD DSN=PROD.HDAMDBD.OSAM,DISP=(NEW,CATLG),
// UNIT=(3390,2),SPACE=(CYL,(1300,200))

There is no DCB information, because the DBD provides it. Please don't code a
RLSE parameter; it deletes the overflow area the DBD has built into it. If you code
RLSE your database almost certainly will take extents before you know it.

The DBD fully describes the database dataset down to its LRECL and BLKSIZE. An
HDAM DBD has one more set of information IMS needs to know to store the data
records. This set of information tells IMS where to put the records within the database's
dataset.

13

HDAM Data Access: the Randomizer

IMS needs a method to know where its data is stored so it can be retrieved later. For
HDAM databases a program called a randomizer provides the method.

The randomizer takes the root key and, based on the number of blocks in the file, tells
IMS where to put the record and where to find the record after it is written.

Look at the RMNAME parameter on the DBD statement:

RMNAME=(DFSHDC40,48,186651,1000)

In order, the RMNAME parameters specify the following items:

• The randomizer's name.
• RAPs per block. A RAP is a Root Anchor Point, a pointer to the location in the block
of a given root segment.
• The total number of blocks in the database.
• A byte limit, the largest record size to be stored in any given block. Segments of
records longer than this are immediately sent to overflow.

There are many things going on when IMS accesses records, most of which happen
automatically. To avoid confusion we'll just state the following:

• The randomizer returns the same location for a given key every time as long as the
RAP and number of blocks operands remain the same. This ensures your record will
not be lost.
• If you can't get a record you know is in the database, chances are you're using an
incorrect version of the DBD. Check with the DBA.
• Since the number of blocks specifies the file size, to change the file size a reorg is
needed to change the DBD and rearrange the data.

HIDAM Data Access

HIDAM databases have two datasets: an index dataset and a data dataset. The index
dataset is a VSAM KSDS whose records consist of the root segment's key and a four-byte
pointer field. This field is an address within the data dataset. The address is the location
of the start of the entire record.

To get a HIDAM record, IMS reads the index KSDS as if it were a native VSAM file.
It takes the address it finds in the index record and then goes to that location in the data
dataset (ESDS or OSAM file). From there, IMS follows record pointers to get the entire
record. Any access to a HIDAM database requires a minimum of three calls for I/O.

14

IMS Control Information: the Block Prefix

In an IMS direct access database, each block has a block prefix used to locate records
and free space within the block. The block prefix consists of one four-byte field called a
Free Space Element Anchor Point (FSEAP), plus (for HDAM) at least one RAP. RAPs
contain either low values or the address of a root segment.

Here is a picture of an empty IMS block for an HDAM database.

FSEAP RAP RAP RAP UNFORMATED SPACE ===>

Each RAP (root anchor point) is four bytes long. This database is said to have three
"RAPs per block." This block has 16 non-data bytes at the beginning and (BLKSIZE-16)
bytes for data records.

A Few Pointers on Pointers

We've seen how IMS uses RAP pointers to keep track of where its records are located.
IMS has three other pointers it uses to know where the next record or segment is. All
three of these pointers are considered part of the data record.

One type is called a hierarchic pointer. This pointer tells IMS what the next segment
is, regardless of type. They are not specific to segment type, so they are usually not used.

The other two types of pointers are called twin pointers and child pointers. Each
pointer is four bytes long. Twin pointers can point forward (next) or backward
(previous). Child pointers can be first or last. The database has twin forward and first
child pointers by default.

Twin pointers point to segments of the same type. For example, John Smith's twin
pointer contains the address of Homer Simpson's record. Smith's Philosophy segment
points to his first Military Science segment.

Child pointers point to the next segment in the hierarchy. For example, John Smith's
root segment points to his English Comp segment.

There are two things to keep in mind about pointers.

• You can mix pointer types in a database record.
• If a certain set of pointers is given for a certain segment type, all occurrences of that
segment type have the same pointers.

15

Inserting Root Segments: HIDAM

HDAM database records are inserted where the randomizer says they belong.
For HIDAM, however, the process is different.

1. The index is searched for the first, higher root key.
2. The new index record is inserted in ascending root sequence.
3. After the index record is created, the record is stored in the database at the
first available space. The index pointer is updated to reflect the storage
location after the data is stored.

Inserting Dependent Segments

After initial load, insertion of segments operates the same way in both HDAM and
HIDAM. This may mean the database record becomes fragmented. In other words,
some child segments may be stored quite far away from the root or related child
segments. This is the main reason for doing reorgs. If records are broken into pieces,
database performance suffers.

Deleting Segments

In HDAM, when any segment is deleted it is physically removed from the database.
This allows free space in the file to be re-used.

In HIDAM, when a segment is deleted it is marked as deleted but not removed from
the database. A reorg is necessary to remove deleted records.

Replacing Segments - Fixed Length

If a segment is updated it is written back to the database in the same place it was
before.

Replacing Segments - Variable Length

If the updated segment gets longer, IMS checks if there is enough adjacent free space.
If there is, the segment is written back to its original location.

If there is not enough space adjacent to the original location, the segment is stored
elsewhere. Pointers are updated to reflect this. The space the original segment used is
considered free space. This can cause performance problems if it happens may times.

16

Miscellaneous DBD Feature: Segment Compression

This function of the DBD can do more than compress data. The user exit specified in
the COMPRTN field can encrypt data, perform edits, or compress the segment.

There are many products to perform compression. IBM has both software and
hardware compression modules. BMC has a product called DataPacker/IMS.

IMS views a compressed segment as a variable-length segment. The application
program doesn’t know that, because compression and decompression happen before the
program sees any data. When the program requests an IMS record, a compressed record
is decompressed before the program is given control. Likewise, when the program writes
the record, it is compressed after the program gives control to IMS. There is no need to
write special code in a program to understand how the compression operates.

One thing with compression: without it, browsing an IMS dataset can show you all the
data in the record. Compressed data is not readable at all.

Database Partitioning

In partitioned databases, the entire structure is imposed upon multiple files, separated
by application program logic by data content.

When partitioning a database the following should be kept in mind.

• IMS requires a separate DBD for each partition because each is a separate database.
• IMS needs an algorithm to decide which partition a given record will go into.

The database structure must be maintained across all partitions. It is not necessary to
keep the same database size across partitions; that decision is based on how "even" a split
the application can get with its records.

Suppose we decide to partition based on the last digit of social security number. This
provides a fairly even spread. The chance of an SSN ending in a 5 is the same as the
chance of it ending with a 2. If ten partitions are used, the amount of records in each
database is roughly equal.

On the other hand, suppose we decide to partition based on the first three digits of
social security number, and we are servicing an area consisting of three states:
Connecticut, Massachusetts, and Rhode Island. While it is possible to get any first three
digits in the SSN, the chance the first three digits would be either 048 or 049 is pretty
high. If we divide into the same ten partitions, some partitions would be very small while
the first partition will be very large (all those Connecticut people).

17

Accessing your database

Until now, we've assumed you can access your database without restriction. You can
tell IMS which segment or segments you want the user to see. A PSB must be coded to
allow access to your database.

PSB is an abbreviation for Program Specification Block. A PSB contains one or more
PCBs, or Program Control Blocks. A PSB usually contains one PCB for each database
DBD accessed. Here is an example of a PSB:

PCB TYPE=DB,DBDNAME=HDAMDBDP,PROCOPT=GP,KEYLEN=18
SENSEG NAME=DEPSEG1,PARENT=0
*
PSBGEN PSBNAME=HDAMPSBR,LANG=ASSEM,CMPAT=YES,IOEROPN=451
END

This is a collection of assembler macros.

This particular PSB contains one PCB. It can be used to read only one database,
XTD103D0. PSBs can contain up to 255 PCBs or 1,000 segment names, whichever
comes first.

Note only one segment is named. This is an example of restricting a view of a
database by segment. To the user of this PSB, it is as if the database contains only this
segment. IMS knows better, but doesn’t tell the user.

How to Read a PSB

On the PCB statement is the name of the database's DBD, a PROCOPT field, and a
KEYLEN field.

The PROCOPT field is one way of allowing or preventing access to the database.
PROCOPT=GP means this PSB allows the database to be accessed as read only, and can
get all segments for a given parent at once. Common PROCOPTs you may see are L
(load), G (read), GO or GON (read only), and A, any access. No access is allowed with
"L" except to load an empty database. A PROCOPT of "A" is understood to be update
access.

The KEYLEN operand is also very important. The value of KEYLEN is the number
of bytes needed by IMS to store the largest key path of this database. What does that
mean exactly? Recall the DBD's segment description. While not all segments have keys,
most of them do. IMS doesn't just use the key of the segment we want; it also uses the
key of any segment above it in the hierarchy. Thus IMS has a work area to store all the
keys for any given qualified call. This work area must be able to handle the largest size
of the combined keys for any request. To learn how to calculate this, let's take another
look at our DBD.

18

The PSB: KEYLEN parameter

Here again is the HDAMDBDP DBD, minus the assembler instructions:
SEGM NAME=PARSEG,PARENT=0,BYTES=121
FIELD NAME=(PARKEY,SEQ,U),START=1,BYTES=11,TYPE=C
*
SEGM NAME=DEPSEG1,PARENT=PARSEG,BYTES=46,PTR=NT
*
SEGM NAME=DEPSEG2,PARENT=PARSEG,BYTES=28,PTR=TB
FIELD NAME=(DEPSEG2K,SEQ,U),START=1,BYTES=6,TYPE=C

This is a simple hierarchy; all segments have the same parent. They KEYLEN
parameter for this database would be 17 (11 for the root, 0 for DEPSEG1, and 6 for
DEPSEG2.

Accessing Your IMS Database - Batch

To access an IMS database in a batch job you need two things: a DBD (to describe
the database) and a PSB (to describe how to access the database). Both of these modules
exist in load libraries. The process to get a DBD into its proper load library is a
DBDGEN. For a PSB the process is a PSBGEN.

Once the DBD- and PSBGEN have been done, you are ready to access your database.
To access the libraries where these two components are stored we use the IMS DD
statement, like this:

//IMS DD DSN=IMSVS.DBDLIB,DISP=SHR
// DD DSN=IMSVS.PSBLIB,DISP=SHR

The order does not matter; the PSB library can be listed first.

IMS must be able to allocate the database datasets. There are two ways IMS can
allocate your database: dynamically or statically. To allocate your database statically,
specify a DDname and the name of the database dataset. The DDname must be the same
as that specified in the DBD. For our HDAMDBDP database, the JCL statement looks
like this:

//HDAMDBDD DD DSN=PROD.HDAMDBDP.OSAM,DISP=SHR

The IMS region obviously cannot have all database DD names coded in its JCL. The
IMS region allocates the file dynamically. To do that, another load module must be
created. This is called "dynamic allocation creation" and is done by the IMS online team.
The module tells IMS what dataset to allocate when your PSB is opened.

19

Accessing Your IMS Database From the IMS Region

The IMS on-line environment also requires a DBD and a PSB. However, IMS calls
are processed differently in the region.

A batch job step is processed as one transaction. Many people on-line may need to do
the same function simultaneously. In on-line we have the equivalent of running several
copies of the same batch job at the same time. Unless that is managed properly there is
contention.

Each transaction requires its own copy of the PSB and DBDs. As you can imagine, if
hundreds of people are running the same transaction you'll have hundreds of copies of the
same blocks in memory. IMS gets around the problem by creating an access control
block (ACB).

Unlike PSBs or DBDs, an ACB can be shared by different transactions. An ACB is a
load module consisting of a PSB and all needed DBDs for a given transaction. To build
an ACB requires an ACBGEN.

When the ACBGEN is complete, the IMS region is ready to access your database.
The ACB library in the IMS region is allocated to the IMS DD name.

//IMS DD DSN=IMSVS.ACBLIB,DISP=SHR

This DD name is the same as that for PSB and DBD libraries. You can run your batch
job using either the DBD and PSB libraries concatenated together or just the ACB
library.

IMS Batch Performance: Buffers

There are three types of datasets IMS can use as databases:

• HDAM - can use an OSAM or VSAM ESDS file;
• HIDAM - can use an OSAM or VSAM ESDS file for its data dataset, and must use a
VSAM KSDS as its index dataset.

Using buffers on datasets can greatly improve performance. Since VSAM and OSAM
use different buffering techniques, you need to know which type of file you're using.
Let’s look at how IMS and the OS access data.

20

IMS Batch Performance: Buffers continued

The first read request for any file works something like this.

1. A read is requested via an OS call.
2. The DASD is read to retrieve the specified record. The dataset block containing
the record is placed into an area of storage called a buffer.

The program is then free to process the record. Subsequent I/O requests add an
additional step just prior to reading the DASD.

1. A read is requested via an OS call.
2. Any buffers assigned to the dataset are checked for the record. If the record is in
the buffer it is returned from there. If the record is not in the buffers, only then...
3. The DASD is read to retrieve the specified record. The dataset block containing
the record is placed into a buffer.

Buffers are assigned to all files opened by a program. The default number of buffers
provided by the OS is five for a "flat" file (i.e. non-VSAM), and two buffers for a VSAM
ESDS. For a KSDS the OS provides one index buffer as well.

When a program runs under IMS' control, if no buffers are requested IMS provides
three buffers for each IMS dataset specified. If any buffers are given to IMS that is all
you get.

IMS does not use the OS-provided buffers for access to IMS databases. Batch jobs
should not provide any OS or VSAM buffers for IMS databases. Doing so may actually
hurt the job's performance because the unused buffers take up memory the program could
use otherwise.

One exception to that are certain IMS utilities: Image Copy, Recovery (but not Log
Forward or Backout), SMU, FRR, or HSSR. Those utilities use AMP or DCB buffers.

You can (and should) buffer non-IMS files with OS buffers.

An IMS real-time transaction uses the number and size of buffers supplied to IMS at
startup. Since you don't generally need to worry about real-time transaction buffers, we'll
discuss buffering for batch jobs only.

21


Batch job buffers are supplied to IMS via the DFSVSAMP DD statement.
DFSVSAMP buffer parms have this format.

VSRBUF=xxxxx,yy
IOBF=(xxxxx,yy,Y/N,Y/N,name)

Bold characters must be specified, underlined characters are defaults, and plain text are
optional arguments. The "xxxxx" is the size of the buffer and the "yy" is the number of
buffers to be used. The “name" can be anything up to eight characters, as long as the first
character is a letter. Here is a typical DFSVSAMP parm.

8192,6
20480,20
IOBF=(24576,15)
IOBF=(28672,15)

The first two arguments build VSAM buffer pools: one of six 8K buffers and one of
twenty 20K buffers. The last two arguments build OSAM buffer pools: fifteen each of
24K and 28K buffers. None of these pools is named.

Buffers designated for VSAM IMS datasets are numbers only, while OSAM buffers
begin with IOBF. Keep these three things in mind when coding buffers.

• Each buffer can contain 1 block (OSAM) or CI (VSAM) from any file.
• An unnamed buffer area is not attached to any particular file, but can be used by any
file with that BLKSIZE/CISIZE or a smaller one.
• Buffers specified here are applied to IMS databases only.

Here is a more complex buffer parameter:
4096,40
8192,5
IOBF=(8192,80,Y,Y,BP1)
DBD=HDAMDBDP(1,BP1)
IOBF=(20480,40)
IOBF=(28672,40)

You can see one of the buffer parameters is named. Named parameters should always
be followed by a DBD= parameter so the pairs are obvious. Naming a buffer pool lets
the user specify how many buffers are dedicated to the named database.

In this example, the first IOBF line builds a pool called BP1 with eighty 8K OSAM
buffers. The next line tells IMS to assign the pool to the HDAMDBDP database. The
idea here is to keep a large portion of this database in memory while being used, reducing
physical I/O to the file. No other database can use this pool because the pool is named
and no other database references this name (BP1).

22


The same restrictions and criteria apply to IMS buffers as with other buffers:

• Random access usually needs very few data buffers.
• Sequential access needs many data buffers.

Since HDAM and HIDAM databases use random access methods, you might think
only a few buffers would be needed. In most cases you'd be right. Of course, there are
exceptions.

For a very small, but high usage, database you may want the entire database in
memory. In that case, code enough buffers in a named pool to contain all the blocks in
the database. While that is not recommended often, sometimes it can make the difference
between finishing within the batch window or not.

Two Final Comments on IMS Buffers

IMS buffers can be one of the following sizes: 512, 1024, 2048, 4096, or any multiple
of 4096 bytes up to 32,768 (32K).

IMS uses a "best fit" method to decide what buffers a file uses. If a file has the same
BLKSIZE or CISIZE as a buffer pool IMS assigns the file there. If the file has a
BLKSIZE or CISIZE the parm doesn't list, IMS uses the smallest listed buffer size large
enough to hold an entire block.

For example, with this parameter a file with a BLKSIZE of 13682 would use one or
more of the forty 16K buffers.
4096,40
IOBF=(8192,80)
IOBF=(16384,40)
IOBF=(28672,60)

23

IMS Utilities

You can look at an IMS database in BROWSE (OSAM only). You can also copy an
IMS database file using REPRO (OSAM only). However, OS utilities do not use the
format IMS imposes on the file. Results are often less than acceptable… to be blunt,
outright bad.

Further, no OS utility can load data into an IMS database or reorg the file. This is a
real problem. Fortunately, IMS (or Tech Services) supplies utilities specifically for IMS
datasets. Most of them are vendor products, such as FileAid/IMS. However, IMS does
provide a program to do IMS calls for you, one at a time.

DFSDDLT0

This program is also called DLT/0. It is an IMS program you can use to make IMS
calls (e. g. ISRT, DLT). It is the program of choice for initializing an IMS database. The
basic strategy is to add a record using ISRT and then delete the just-added record using
DLT.

A Few Words on Testing in IMS

In ordinary circumstances there should be only one difference between databases in
production and test: the size of the database. The number of RAPS per block should be
the same, as should the BLKSIZE and the structure, including segment and field names.

The only exception to that is a deliverable calling for a change in the database
structure. This may include things like a new segment, a change in the length of an
existing segment, or any of a number of other things.

The number of blocks is what the randomizer uses to know where to store a given
record. Therefore, when working with a test database be sure to use the testing DBDLIB.

A Couple of Warnings for Test

• Please check to be sure you are using the correct DBD.

• Always image copy the database before any updates are done.

Basic IMS For Applications

More Related Content

What's hot

Viewers also liked

Similar to Basic IMS For Applications

Recently uploaded

Basic IMS For Applications