IMS FOR Z/OS:

AUTOMATION TO REDUCE CI SPLITS IN IMS DB

 Table of Contents
IMS FOR Z/OS:..................................................................................................................................................... 1

A UTOMATION TO REDUCE CI SPLITS IN IMS DB............................................................................................................. 1

TABLE OF CONTENTS........................................................................................................................................... 2

1. SUMMARY.................................................................................................................................................. 3

2. WHAT IS CI ?............................................................................................................................................... 5

3. WHEN DO WE REORGANIZE?...................................................................................................................... 6

4. MANUAL REORGS?...................................................................................................................................... 7

5. AUTOMATION OF REORG PROCESS.............................................................................................................. 8

6. APPENDIX................................................................................................................................................. 10

7. REFERENCE............................................................................................................................................... 10

Summary
The following document is based on IBM IMS 12 for z/OS and is intended for Database
administrators and application architects. It outlines how CI split occurs in a VSAM database and
what is the solution for controlling them with less effort for monitoring the database.
History
Problem Statement

May want to explain CI/CA

CI and CA splits occur as a result of data record insertions (or increasing the length of an
already existing record) . If a record is to be inserted (in key sequence) and there is
insufficient free space in the CI, the CI is split. Approximately half of the records in the CI are
transferred to a free CI provided in the CA, and the record to be inserted is placed in the original
CI. If there are no free CIs in the CA and a record is to be inserted, a CA split occurs. Half of the
CIs are sent to the first available CA at end of the data component. This movement creates free
CIs in the original CA, and then the record to be inserted causes a CI split. These CI splits requires
a number of I/O operations and this will deteriorate the performance of the VSAM dataset.

You may want to have a pictorial diagram showing the two splits above

Previous Options

Reorganization (reorg) was the option to minimize the CI Splits and decrease the I/O operations.
Previously, reorg jobs were available and whenever required the jobs will be submitted manually.
Also, a regular monthly check for CI splits is done and if CI splits are more than 100, (May want
to show how you determine Split) the reorg job will be run manually to allocate free spaces for
the VSAM datasets.

Proposed Solution

Instead of running the reorg jobs manually, a solution was proposed (are we talking about an
account specific process ??) to automate the reorg process for around 40 databases. The whole
idea is to schedule a set of jobs in OPC (Production Control). This automation includes following
steps:

1. Issue stop scripts to bring the DB down. These stop scripts will be issued automatically
using a REXX exec and scheduled in OPC. Most accounts use AOI jobs for this process – but
most AOI's have little logic to verify command
2. Run the pre image copy job which takes a backup of DB before reorg.
3. Run the reorg job. This includes a LISTCAT step which lists the properties of the DB. The
DB free spaces will be re allocated and the CI splits will be reduced. 4. Run the post image copy
job.
5. Issue start scripts to bring the DB back online. These scripts will be issued automatically
using REXX exec to verify the status of DB and bring them back online. Most accounts use AOI
jobs for this process - – but most AOI's have little logic to verify command = There are also
utilities that will DBR and STA Dbs within the utility. - like IBM IMS reorganization Expert -
There is also online reorgs which is a much better solution

Benefit
There are 2 main benefits of this proposed solution:
1. The manual intervention of running the reorg jobs is no more required.
2. The jobs are scheduled in OPC and thereby they can be run once in a week/month
depending on the record additions/deletions for a DB, which is causing the CI split. Doing this, no
manual health is needed for CI splits as the reorganization allocates the free space accordingly.

Implementation

The proposed solution is implemented by IMS DBA team for 2 applications for a client. After the
implementation, a drastic change in the CI splits was observed. This solution can be
implemented after the jobs for - Stop/Start scripts, Image Copy and Reorganization are tested
and the results are validated. Coordination with Production Control team is required to schedule
the jobs to run automatically without manual intervention.

Authors
Document owner is Dasnavis Juliet R from IBM India.
Email address is : dajuliet@in.ibm.com .

Any comments or corrections should be forwarded to her attention.

Company: IBM
What is CI ?

IMS database use VSAM datasets. VSAM datasets use Control Interval (CI) for basic unit of
storage. A CI is formed by physical records and it is the contiguous area of storage that VSAM
uses to store data records and control information that describes the records. CIs are contained
in a Control Area (CA). A CA is formed by two or more CI's put together. A VSAM dataset is
composed of one or more CAs. . A Control Area (CA) is a logical grouping of CIs, usually set at a
cylinder. VSAM picks a CA size based on the data set’s allocation units..

A CI consists of logical records stored from beginning to end. Free space, for data records to be
inserted into or lengthened. Control information, which is made up of two types of fields; one
control interval definition field (CIDF) per CI, and several record definition fields (RDF) describing
the logical records. Here CIDF is a 4-byte field. It contains information about the amount and
location of free space. RDF is a 3-byte field. It describes the length of records. For fixed length
records there are two RDFs, one with the length and other with how many with the same length.
When do we reorganize?
There are 2 scenarios when we opt for reorganization.

Scenario 1

When the amount of free bytes in free CIs embedded in CAs included in used RBA percentage is greater
than the CA freespace percentage, it's time for reorganization. It is described in the example,

Show report where we can derive this information

Example:

Ci Size = 4K

HARBA = 16*4k = 64k

HURBA = 12*4k = 48k

HARBA- HURBA = 16k

FreeSpace = 11*4k = 44k

44k – 16k = 28k (7 Cis)

The subtraction, HARBA - HURBA = X, gives the amount of free bytes in the free CIs allocated in the CAs
beyond HURBA.

If you subtract FREESPC - X = Y, it gives the amount of free bytes in free CIs embedded in CAs included in
HURBA.

Y includes the CA Freespace%, 25%, for example.

If (Y / HURBA) * 100 is consistently greater than CA Freespace% (25%), and the number of deleted
records (in catalog) is a large figure, it means that it is time to reorganize due to non- reclaimed CAs.

Scenario 2

Another reason to reorganize is when the Index CI size is defined too small and is not big enough to
contain information about all the data CIs in the data CA. An example is shown in Figure 2. In this case
the CA is truncated and the rest is unused. In such a case, you have to redefine the data set with a larger
index CI size.
Manual Reorgs?

Reorg JCL's was set up to reorganize the database. There are 3 basis steps which are followed in
the JCL when reorganizing a database offline. They are:

1. Unloading the existing database.

2. Deleting the old database space and defining the new database space. Database space
3. refers to clusters defined to VSAM for database datasets.
4. Reloading the database.

Apart from these steps, when logical relationships or Secondary indexes exist, in addition to the above
steps more utilities are run to collect, sort and restore pointer information from a segment's prefix. If
logical or secondary indexes are used, update prefixes to reflect new segment locations. The various
utilities involved in updating segment prefixes and indexes are:

 Database Pre reorganization utility

 Database Scan utility
 Database Index building utility
 Database Prefix Resolution utility
 Database Prefix Update utility

These steps in the Reorg JCL are coded with these utilities. Whenever the CI splits go beyond 100, the
reorg jobs are submitted so that the databases are reorganized.

To monitor the CI splits, every month a health check report is taken which has the detailed list of each
database and the number of CI splits they have. This is done every month so that the growth of the
splits is also monitored. The freespace calculations are carried out like in figure-1 and if the freespace
percentage is found to be lesser then reorganization is recommended for the particular database. This is
fine, but in general in IBM supported account we do not or cannot do this manual due to time
restrictions give for support. We schedule reorg to remove manual health checks.

There is a significant process to be followed to perform this

reorganization in database offline mode. The steps followed are:
Automation of Reorg Process

The steps in the above flowchart are performed one by one manually after the CI splits are found to
rapidly increase. So, instead of doing this manually the new proactive measure that is now implemented
is to run the reorg jobs once in a month through OPC scheduling. To accomplish this, not only the reorg
job but all the steps before and after should also be included in the OPC scheduling. OPC is an
automated scheduler that submits jobs to the operating system on the appropriate date, at the
appropriate time, and after the successful completion of all prerequisite processing. The sample OPCE
scheduling application that is considered here is
'REORGS'. Each step that is performed in the application is listed below:

Step1: Take the DB Offline

IMS Commands are issued in the online region to bring the database down. To automate the process,
REXX execs running under BMC Mainview product is required. In this case, APMODE is the REXX exec
that is running under BMC Mainview. This exec will read config datasets. The config dataset is a PDS
dataset holding members. These members will use commands to start, stop and verify the status of IMS
databases and programs. To schedule one of these APMODE members to stop the databases, it should
be done through any one of the scheduling package and in this case it is OPCE scheduling.

When OPCE makes a request to run APMODE member, the syslog will look like:

EQQW775I APPLICATION: WHATEVERYOULIKE OP#: 0002 WITH INPUT

ARRIVAL: 0409211046 AND JOBNAME: $$$$$$$$ ON WORK

STATION: IMSY HAS BEEN STARTED.

OPERATION TEXT: J=#

This means that the exec is started its execution and the IMS commands specified in the config dataset
member will start to get issued.

Step2: Run Pre Image Copy Job High Performance utilites can do Pointer validation as part of the IC
The pre Image Copy is to take a backup of the database before performing the reorganization. This is
done so that if anything goes wrong while doing a reorg; the database can be recovered using the
backup file. This job uses the standard IBM utility to perform Image copy. In the application 'REORGS',
this is tagged as successor for the APMODE stop script.

Step3: Run Reorg Job

Reorg job is tagged as successor to the previous pre Image copy job.

Step4: Run Post Image Copy Job (High Performance utilites can do Pointer validation as part of the IC

The post Image copy job is run to take a backup of the database after reorganization. This job will be
tagged as successor to the previous job.

Step5: Run Pointer Checker Job

The pointer checker job is run to validate if there are any pointer errors in the database after
reorganization. (show pointer report to show improvement on CI/CA's.)

Step6: Bring the DB back online

Using the APMODE REXX Exec the DB is brought back online. This EXEC will be scheduled as successor for
pointer checker job.

The entire REORGS application sample schedule in OPC is shown below:

Oper Duration Job name Internal predecessors Morepreds

No.of
ws no. HH.MM.SS -IntExt Conds
DMY 001 00.00.01 DUMSTART 0 1 0CPUG 010 00.00.02
PREIMAGE 001 0 0 0CPUG 011 00.01.00 REORG 010
0 0 0CPUG 014 00.00.02 POSTIMAG 001 0 0 0CPUG
015 00.01.00 POINTERC 014 0 0 0

The APMODE script to bring the DB down is listed below:

Application : REORGS MONTHLY 2ND SATURDAY

Operation : DMY 001 DUMSTART

Row Type Oper Transport Application id Jobname Cond

cmd ws no. time (for ext pred only) no.
' P EXEG 010 APMODE#REORGDN REORG 000
Appendix

 CI - Control Interval
 CA - Control Area
 OPC - Operations Planning & Control
 JCL - Job Control Language
 REXX - Programming language in Mainframe
 PDS - A dataset is mainframe(file)

Reference

 'IMS Database Administration Guide' - IBM Manual

 'Reorganization for IMS DB' - IBM manual
 'VSAM Demystified' - IBM Redbook