BASIC IMS CONCEPTSFor Application Staff

By Dan O'DeaApril 15, 2000

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.

2

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 / SMITH, JOHN /MILITARY SCIENCE /B102/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:

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

3

Student

Classes

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.

4

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.

5

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.

6

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 / SMITH, JOHN /MILITARY SCIENCE /B101/MS. d'ARC / SMITH, JOHN /MILITARY SCIENCE /B102/MS. d'ARC /

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.

7

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.

8

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.

9

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.

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.

10

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.

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.

11

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.

12

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.

13

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.

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.

14

FSEAP RAP RAP RAP UNFORMATED SPACE ===>

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.

15

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).

16

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.

17

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.

18

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.

19

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.

20

IMS Batch Performance: Buffers continued

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,408192,5IOBF=(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).

21

IMS Batch Performance: Buffers continued

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,40IOBF=(8192,80)IOBF=(16384,40)IOBF=(28672,60)

22

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.

23