When using OSAM

•Reasons you may want to use OSAM are:

–Sequential Buffering (SB) — With this feature, IMS
will detect when an application is processing data
sequentially and pre-fetch blocks it expects the
application to request from DASD, so they will
already be in the buffers in the IMS address space
when the application requests segments in the
block.
 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 and 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.
 IMS batch performance:
Buffers(Cont.)
•The first read request for any file works something like this:
1.A read requested via an OS call
[Link] 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.
[Link] 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…
[Link] DASD is read to retrieve the specified record. The dataset block
containing the record is placed into a buffer.
 IMS batch performance:
Buffers(Cont.)
•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. 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.
 IMS batch performance:
Buffers(Cont.)
•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, underline
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.
 IMS batch performance:
Buffers(Cont.)
•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) of
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
 IMS batch performance:
Buffers(Cont.)
•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).
Two final comments on IMS buffers
•IMS buffers can be one of the following sizes: 512,
1024, 2048, or any multiple of 4096 bytes up to
32768(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 uses one or more of the forty 16k
buffers.
 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.
Locking: sharing IMS data between
multiple tasks
•A deadlock. IMS detects this, and will
abnormally terminate (abend) the application it
assesses has done the least work, backing out
its updates to the last commit point.
•What IMS cannot detect is a deadlock between
two applications where the two different
resources the applications are trying to get are
being managed by two separate resource
managers
Locking: sharing IMS data between
multiple tasks(Cont.)
•For example, CICS task A reads, and enqueues a database
record. CICS task B then issues a CICS ENQ for a resource, for
example to serialize on the use of a TDQ. CICS task B then
attempts to read the database record held by task A, and is
suspended, waiting for it. CICS task A then attempts to serialize
on the resource held by task B and is suspended. We now have a
deadlock between task A and B. But neither IMS or CICS is aware
of the problem, as both can only see the half of the deadlock
they are managing
•The person designing an application that uses IMS databases
needs to be aware of the potential problems with database
deadlocks, and design the application to avoid them.
Locking: sharing IMS data between
multiple tasks(Cont.)
•IMS supports three methods of sharing data between a number of
application tasks:
•Program isolation (PI) — This can be used where all applications are
accessing the IMS databases via a single IMS control region. This
provides the lowest level of granularity for the locking, and the
minimum chance of a deadlock occurring
•Block level data sharing — This allows any IMS control region or
batch address space running on an OS/390 system to share access to
the same databases. It uses a separate feature, the Internal Resource
Lock Manager, IRLM
•Sysplex data sharing — Where a number of OS/390 systems are
connected together in a sysplex, with databases on DASD shared by
the sysplex, it is possible for IMS control regions and batch jobs to run
on any of these OS/390 images and share access to the databases
 Why is reorganization necessary
•To reclaim and consolidate free space that has become
fragmented due to repeated insertion and deletion of
segments.
•To optimize the physical storage of the database segments
for maximum performance (get dependent segments that
are in distant blocks, increasing physical I/O, back in the
same block as the parent and/or root). This situation is
normally the result of high update activity on the database.
•To alter the structure of the database, change the size of
the database data sets, alter the HDAM root addressable
area, add or delete segment types.
 When to reorganize
•There are two approaches to deciding when to
reorganize, reactive and proactive
•When you initially install the application and
set up the databases, a lot of the reorganization
will be done reactively, as performance and
space problems manifest themselves
•As you develop a history of the behavior of the
application and the databases, the scheduling of
reorganization should become more proactive
 When to reorganize(Cont.)
•The initial thing to look at is, what the average and
maximum online response times and batch run times are.
•also look at the amount of database calls it is processing
•The solution to performance problems is normally an
interactive process involving the database administrator,
application support function, and the operating system
support function, as all three control areas that affect
performance
•The main things you will be doing when you look at the
monitoring data will be to try to minimize the physical I/O
for each database access, and optimize the free space
available in the database
 Minimize physical I/O
•Making the best use of buffers in the IMS subsystem;
the more requests for database access you satisfy from
the buffers, the fewer physical I/Os are necessary
•Minimizing the number of physical I/Os when a
segment does have to be retrieved from disk. For
example, trying to place as many dependents as
possible in the same block/CI as its parent, ensuring
HDAM root segments are in the same block/CI as the
RAP. This is where database reorganization and
restructuring is used
 Monitoring the databases
•The IMS monitor, to gather details of buffer usage and database
calls over a specified time period in an IMS subsystem.
•The //DFSSTAT DD card, used in batch JCL to provide a summary
of buffer usage and database calls. As there is very little
overhead in including this (the details printed to the DD at
region termination are accumulated by the IMS region controller
whether they are output or not), it is normally worthwhile
putting this in all batch jobs.
•Running the DB monitor on a batch job, to collect similar details
to the IMS monitor in an online system. As there is an overhead
on running this, it would normally only be turned on when
specific problems are being investigated
 Database recovery processing
•Database recovery, in its simplest form, is the restoration of a
database after its (partial) destruction due to some failure
•Periodically, a copy of the data in the database is saved. This
copy is normally referred to as a backup or image copy
•In addition to taking an image copy of the database(s), all
changes made to the data in the database can be logged and
saved, at least until the next image copy. These changes are
contained in data sets called log data sets
•There is an IMS facility called database recovery control (DBRC)
which provides database integrity and can be used to help
ensure that there is always a recovery process available. The use
of DBRC to control database backup and recovery is not
mandatory, but is highly recommended
 When is recovery needed ?
1.A DLI batch update job fails after making at
least one database update.
2.A failure has occurred on a physical DASD
device.
3.A failure has occurred in a database recovery
utility.
4.A failure of dynamic backout or batch backout
utility has occurred.
[Link] IMS online system failure and emergency
restart has not been completed.
 Online programs recovery
•IMS online transactions use dynamic backout to “undo” updates done
in any incomplete unit of work
•Abending online programs are automatically backed out by the
online system using the log records
•In addition, if the system should fail while an application program is
active, any updates made by that program will be automatically backed
out when the system is restarted
•At IMS restart time, if the emergency restart cannot complete the
backout for any individual transactions, then the databases affect by
those updates are stopped, and DBRC is requested to set the recovery
needed flag to ensure that a correct recovery is completed before the
database is opened for more updates
•In the case of dynamic backout failure, a batch backout or database
recovery needs to be performed, depending on the reason for the
backout failure
Overview of recovery utilities
 Database image copy utility
(DFSUDMP0)
•The database image copy utility creates a copy
of the data sets within the databases. the
output data sets is called an IMAGE COPY
•It is a sequential data set and can only be used
as input to the database Recovery utility
•The IMAGE copy utility does not use DLI to
process the database. Track I/O is used
•There is no internal checking to determine if all
the IMS internal pointer are correct
 Database recovery utility
(DFSURDB0)
•The database recovery utility program will
restore a database data set
•Unlike the image copy utility, the recovery
utility recovers one database data set per job
step
•The database recovery utility program is
executed in a DL/I batch region
 Database batch backout utility
(DFSBBO00)
•Batch backout, in it simplest form, is the reading of log
data set(s) to back out all database updates
•This is done by using the “before image data” in the
log record to re-update the database segments
•No other update programs should have been executed
against the same database (s) between the time of the
failure and the backout
•The program operates as a normal DL/I batch job
•It uses the PSB used by the program whose effects are
to be backed out
 Controlling IMS
•Monitoring the system
•Processing IMS system log information for
analysis
•Executing recovery-related functions
•Modifying and controlling system resources
•Controlling data sharing
•Controlling log data set characteristics
 Monitoring the system
•Monitor the status of the system on a regular
schedule to gather problem determination and
performance information.
•For example, to determine if you should start
an extra message region, you might monitor the
status of the queues during peak load.
 Processing IMS system log
information for analysis
•Using IMS system log utilities
–File Select and Formatting Print utility: You can use the File
Select and Formatting Print utility (DFSERA10) if you want to
examine message segments or database change activity in detail
–Fast Path Log Analysis utility: DBFULTA0 to prepare statistical
reports for Fast Path, based on data recorded on the IMS system
log
–Log Transaction Analysis utility: In an IMS DB/DC or DCCTL
environment, you can use the Log Transaction Analysis utility
(DFSILTA0) to collect information about individual transactions
–Statistical Analysis utility: In an IMS DB/DC or DCCTL
environment, you can produce several summary reports using the
IMS Statistical Analysis utility (DFSISTS0)
–Knowledge-Based Log Analysis: Knowledge-Based Log Analysis
(KBLA) is a collection of IMS utilities that select, format, and
 Executing recovery-related
functions
•The /RMxxxxxx commands perform the following DBRC
functions:
–Record recovery information in the RECON data set
–Generate JCL for various IMS utilities and generate
user-defined output
–List general information in the RECON data set
–Gather specific information from the RECON data set
•Recommendation: Allow operators to use the /RMLIST and
/RMGENJCL commands. Restrict the use of /RMCHANGE,
/RMDELETE, and /RMNOTIFY commands because they
update the RECON data set.
 Program structure
•Application programs executing in an online transaction environment
are executed in a dependent region called the message processing
region (MPR)
•The programs are often called message processing programs (MPP)
•The IMS modules which execute online services will execute in the
control region (CTL)
•the database services will execute in the DLI separate address space
(DLISAS)
•Batch application programs can execute in two different types of
regions
–Application programs which need to make use of message
processing services or databases being used by online systems are
executed in a batch message processing region (BMP)
–Application programs which can execute without messages
services execute in a DLI batch region
Structure of an application
program
 Entry to application program
•when the operating system gives control to the
IMS control facility, the IMS control program in
turn passes control to the application program
•At entry, all the PCB-names used by the
application program are specified
•The sequence of PCBs in the linkage section or
declaration portion of the application program
need not be the same as in the entry statement
 Termination
•At the end of the processing of the application
program, control must be returned to the IMS
control program
•Language:COBOL Return Statement: GOBACK.
 Message format service overview
•Through the message format service (MFS), a
comprehensive facility is provided for IMS users of 3270
and other terminals/devices
•MFS has three major components
–MFS language utility
–MFS pool manger
–MFS editor
•The MFS language utility is executed offline to generate
control blocks and place them in a format control block
data set named [Link]
•The IMS message format service (MFS) is always used to
format data transmitted between IMS and the devices of
the 3270 information display system
 Database recovery control (DBRC)
•DBRC includes the IMS functions which provide IMS
system and database integrity and restart capability
•DBRC records information in a set of VSAM data sets
called RECONs
•Two of these RECONs are a pair of VSAM clusters
which work as a set to record information
•A third RECON can be made available as a spare
•If one becomes unavailable, the spare will be activated
if it is available
 RECON information
•IMS records the following information in the
RECON:
–Log data set information
–Database data set information
–Event information
•Allocation of a database
•Update of a database
•Image copy of a database
•Abend of a subsystem
•Recovery of a database
•Reorganization of a database
•Archive of a OLDS data set
 RECON data sets
•The RECON data set is the most important data set for the operation of DBRC and
data sharing
•The fundamental principle behind the RECON data set is to store all recovery related
information for a database in one place
•Using three data sets for the RECON causes DBRC to use them in the following way
–The first data set is known as copy1. It contains the current information. DBRC
always reads from this data set, and when some change has to be applied, the
change is written database first to this data set
–The second data set is known as copy2. It contains the same information as the
copy1 data set. All changes to the RECON data set are applied to this copy2 only
after the copy1 has been updated
–The third data set (the spare) is used in the following cases
•A physical I/O error occurs on either copy1 or copy2.
•DBRC finds, when logically opening the copy1 RECON data set, that a spare
RECON has became available, and that no copy2 RECON data set is currently
in use.
•The following command is executed: [Link] REPLACE(RECONn)
 RECON definition and creation
•The RECON data sets are VSAM KSDSs. They must be
created by using the VSAM AMS utilities
•The same record size and CI size must be used for all
the RECON data sets
•The RECON data sets should be given different
FREESPACE values so that CA and CI splits do not occur
at the same time for both active RECON data sets
•For availability, all three data sets should have
different space allocation specifications
•The spare data set should be at least as large as the
largest RECON data set
 Initializing RECON data sets
•After the RECON data sets are created, they
must be initialized by using the [Link]
command of the DBRC recovery control utility
•This causes the RECON header records to be
written in both current RECON data sets
 Allocation of RECON data sets to
subsystems
•To allocate the RECON data set to an IMS
subsystem, the user must choose one of the
following two ways:
–Point to the RECON data sets by inserting the DD
statements in the start-up JCL for the various
subsystems.
–Use dynamic allocation.
 Allocation of RECON data sets to
subsystems(Cont.)
•It also allows recovery of a failed RECON data set,
since DBRC dynamically de-allocates a RECON data set
if a problem is encountered with it
•To establish dynamic allocation, a special member
naming the RECON data sets must be added to IMS
RESLIB or to an authorized library that is concatenated
to IMS RESLIB. This is done using the IMS DFSMDA
macro
•The appropriate RESLIB or concatenated RESLIBs must
be included for each subsystem start-up JCL
 Placement of RECON data sets
•Different volumes
•Different control units
•Different channels
•Different channel directors
 RECON data set maintenance
•RECON backup
–Operational procedures should be set up to ensure that
regular backups of the RECON data set are taken
–These backups should be performed using the [Link]
DBRC utility command
•[Link] INACTIVE command
–The only recovery related records in the RECON data set that are
not automatically deleted are the log records (PRILOG and
LOGALL).
•[Link] STATUS command
–Regular use should be made of the [Link] STATUS command
to monitor the status of the individual RECON data sets
–This command should be executed two or three times a day
during the execution of an online system, to ensure that no
problems have been encountered with these data sets
 RECON reorganization
•A plan for reorganizing the RECON data sets to
reclaim this space on a regular basis must be
considered
•If the online system is active:
•A reorganization of the RECON data sets should be scheduled:
–During a period of low RECON activity.
–When no BMPs are running.
–A [Link] STATUS command must be issued from each online
system which uses the RECON data sets, after the [Link]
REPLACE command is issued, in order to de-allocate the RECON before
deleting and defining it again.
•If the online system is not active:
•A reorganization of the RECON data sets should be scheduled:
–After a [Link] has been taken.
–When no subsystems are allocating the RECON data sets.
 Recreating RECON data sets
•The RECON data sets may need to be recreated,
for instance:
–In a disaster recovery site
–After the loss of all the RECON data sets when no
current backup is available
•Recreating the RECON can be a long and slow
process. When designing procedures to handle
this process, there are two basic alternatives:
–Restore the RECON from the last backup (if
available) and update it to the current status
required.
 RECON reorganization steps
[Link] the DBRC command to determine the status of the RECON data sets
[Link] [Link] REPLACE(RECON1) to discard RECON1. RECON2 will be copied to RECON3
and RECON1 will be discarded
[Link] and define the VSAM cluster for the discarded RECON. Before you can delete the cluster,
you must ensure there are no other users, such as batch jobs, using the data set
[Link] the [Link] REPLACE(RECON2) command to discard RECON2. RECON3 will be
copied to RECON1 and RECON2 will be discarded
[Link] and define the VSAM cluster for the discarded RECON2. Before you can delete the
cluster, you must ensure there are no other users using the data set
[Link] the [Link] REPLACE(RECON3) command to discard RECON2. RECON3 will be
copied to RECON1 and RECON2 will be discarded
[Link] and define the VSAM cluster for the discarded RECON3. Before you can delete the
cluster, you must ensure there are no other users using the data set
•You can automate this process by putting all the previous steps in the same job, but you need to
schedule the job at a time when there are no other subsystems using the RECON (or they must
be able to unallocate the RECONs as they get DISCARDED).You must also ensure that the
discarded RECON is released by all the sharing online systems. With only one online subsystem
and no other users (batch jobs or utilities), you can perform the /DIS OLDS command, for

example, by executing an Automated Operator BMP step that issues the command
•You can reorganize a RECON data set online if you are using dynamic allocation for the RECON
Summary of recommendations for
RECON data sets
•Use three RECON data sets — two current and
one spare.
•Define the three RECON data sets with different
space allocations.
•Put the RECON data sets on different devices,
channels, and so on.
•Use dynamic allocation.
•Do not mix dynamic allocation and JCL
allocation.
•Define the RECON data sets for AVAILABILITY,
 RECON record types
•The relationship is never imbedded in the records like a
direct pointer, but can be built by DBRC using the
information registered in each record type. This allows
constant access of the related records through their
physical keys
•There are six general classes of RECON record types:
[Link] records
[Link] records
[Link] accumulation records
[Link] data set (DBDS) group records
[Link] records
[Link] records
 RECON header record
•The header is the first record registered in the
RECON data set by the [Link] command
•The header identifies the data set as a RECON
data set and keeps information related to the
whole DBRC system
•The RECON header extension record identifies
the individual RECON data sets. It is also used in
the synchronization process of the two primary
RECON data sets. It is created by the [Link]
command, together with the RECON header
 DB record
•The Database (DB) record describes a database
•There is one DB record in the RECON data set for each
database that has been registered to DBRC through the use
of the [Link] command
•A DB record includes:
–Name of the DBDS for the database
–Share level specified for the database
–Database status flags
–Current authorization usage
•A DB record is symbolically related to:
–The DBDS record for each database data set
–The SUBSYS record for each subsystem currently
authorized to use the database.
 DBDS record
•The Database Data Set (DBDS) record describes a database data set
•There is a DBDS record in the RECON data set for each database data set that
has been defined to the DBRC using the [Link] command
•The DBDS record includes:
–Data set name
–DD name for the data set
–DBD name of the database
–Data set, database organization
–Status flags for the data set
–Information related to image copy or change accumulation
–Name of the JCL member to be used for [Link] or [Link].
•A DBDS record has the following relationship to other records:
–DB record for the database to which the data set belongs
–CAGRP record for the change accumulation group to which the
database data set belongs (when a change accumulation group has been
defined)
–ALLOC, IC, REORG, RECOV, AAUTH records.
 SUBSYS record
•The Subsystem (SUBSYS) record informs DBRC that a subsystem is
currently active
•A SUBSYS record is created any time a subsystem signs on to DBRCA
•A SUBSYS record is deleted when:
–The subsystem terminates normally
–The subsystem terminates abnormally, but without any database
updates
–DBRC is notified of the successful completion of the subsystem
recovery process (IMS emergency restart or batch backout).
•The SUBSYS record includes:
–ID of the subsystem
–Start time of the log
–Subsystem status flags
–DBDS name for each database currently authorized to the
subsystem.
 PRILOG/SECLOG record
•The Primary Recovery Log (PRILOG) record or the Secondary Recovery
Log (SECLOG) record, describes a log RLDS created by an IMS DC or
CICS/OS/VS online system, a batch DL/I job, or the archive utility
•A PRILOG record is created, together with a LOGALL record, whenever
a log is opened
•If the subsystem is an IMS batch job and dual log is in use, a SECLOG
record is also created
•A PRILOG record is deleted in the following cases:
–The command [Link] INACTIVE deletes all the log records
no longer needed for recovery purposes.
–The command [Link] TOTIME deletes all the inactive log
records older than the specified time.
–The command [Link] STARTIME deletes a particular log
record.
 PRISLDS/SECSLDS record
•The Primary System Log (PRISLDS) record or the Secondary
System Log (SECSLDS) record describes a system log SLDS created
by an IMS DC online system
•PRISLDS record is created, along with a LOGALL record,
whenever a system log is opened. A SECSLDS record can be
created at archive time
•A PRISLDS record is deleted in the following cases:
–The command [Link] INACTIVE deletes all the log
records no longer needed for recovery purposes.
–The command [Link] TOTIME deletes all the inactive
log records older than the specified time.
–The command [Link] STARTIME deletes a particular
log record.
 PRIOLD/SECOLD record
•The Primary OLDS (PRIOLD) record and the
Secondary OLDS (SECOLD) record describe the
IMS DC Online Data Sets (OLDS) defined for use.
•Whenever an OLDS is defined to IMS DC, the
PRIOLD record is updated. If IMS dual logging is
in use, the SECOLD record is also updated
 IC record
•The Image Copy (IC) record describes an image copy output data set
•This record can be created:
–Automatically, when the image copy utility is executed to create a
standard image copy
–With the [Link] command, when a standard image copy has been
created with DBRC = NO
–With the [Link] command, when another nonstandard image copy
has been created
–In advance, and reserved for future use with the [Link] command,
when the related DBDS record has the REUSE option
–By the HISAM reload utility, which creates an IC record pointing to the
unload data set if the REUSE option is not being used for the DBDS under
reload
•This record is deleted when the maximum image copy generation count is
exceeded and its time-stamp is beyond the recovery period
 REORG record
•The Reorganization (REORG) record informs DBRC that a
reorganization of a particular DBDS has taken place
•With this information, DBRC will not allow recovery
operations beyond the time-stamp of this reorganization
•The REORG record is created when:
–A HISAM or HDAM reload utility is successfully
executed
–A prefix update utility is executed
•The REORG record is deleted when its creation time-stamp
is older than the last IC associated with the database data
set
 RECOV record
•The Recovery (RECOV) record informs DBRC
that the recovery of a particular DBDS has taken
place
•With this information, DBRC knows when a
time-stamp recovery has been performed
•The RECOV record is created when the IMS DB
recovery utility is successfully executed
•A RECOV record is erased when its creation
time-stamp is found to be older than the oldest
IC record associated with the DBDS
 AAUTH record
•The Authorization (AAUTH) record indicates the
sharing status of a Fast Path Database Area
IMS logging
 IMS logging
•The IMS logs are made up of a number of
components:
–Log Buffers
–Online Log Data sets (OLDS)
–Write Ahead Data sets (WADS)
–System Log Data sets (SLDS)
–Recovery Log Data sets (RLDS)
 IMS log buffers
•The log buffers are used for IMS to write any information required to
be logged, without having to do any real I/O
•Whenever a log buffer is full, the complete log buffer is scheduled to
be written out to the OLDS as a background, asynchronous task
•The OLDS buffers are used in such a manner as to keep available as
long as possible the log records that may be needed for dynamic
backout
•If a needed log record is no longer available in storage, one of the
OLDS buffers will be used for reading the appropriate blocks from the
OLDS
•The number of log buffers is an IMS start-up parameter, and the
maximum is 999. The size of each log buffer is dependent on the actual
blocksize of the physical OLDS
•The IMS log buffers now reside in extended private storage, however,
there is a log buffer prefix that still exists in ECSA
 Online log data sets (OLDS)
•The OLDS are the data sets which contain all the log records required for
restart and recovery
•These data sets must be pre-allocated (but need not be pre-formatted) on
DASD and will hold the log records until they are archived
•The OLDS is written by BSAM. OSAM is used to read the OLDS for dynamic
backout
•The OLDS are made up of multiple data sets which are used in a wrap
around manner
•At least 3 data sets must be allocated for the OLDS to allow IMS to start,
while an upper limit of 100 is supported
•Only complete log buffers are written to the OLDS, to enhance performance
•Should any incomplete buffers need to be written out, the are written to the
WADS. The only exceptions to this are at IMS shutdown, or in degraded
logging mode, when the WADS are unavailable, then the WADS writes will be
done to the OLDS
 OLDS dual logging
•Dual logging can also be optionally
implemented, with a primary and secondary
data set for each defined OLDS
•A primary and secondary data set will be
matched and, therefore, the pair should have
the same space allocation
•Secondary extent allocation cannot be used
•All OLDS must have the same blocksize, and be
a multiple of 2Kb (2048 bytes). the maximum
allowable blocksize is 30kb
 Backward recovery
•When IMS or an application program fails, you need to remove
incorrect or unwanted changes from the database
•Backward recovery or backout allows you to remove these incorrect
updates
•The three types of backout are:
–Dynamic backout
–Backout during emergency restart
–Batch backout
•IMS automatically (dynamically) backs out database changes in an
online environment when any of the following occurs:
–An application program terminates abnormally
–An application program issues a rollback call
–An application program tries to access an unavailable database
–A deadlock occurs
 Archiving
•The current OLDS (both primary and secondary) is closed and the next
OLDS is used whenever one of the following situations occurs
–OLDS becomes full
–I/O error occurs
–MTO command is entered to force a log switch (such as /SWI
OLDS)
–MTO command is issued to close a database (such as /DBR DB)
without specifying the NOFEOV parameter.
•DBRC is automatically notified that a new OLDS is being used. When
this occurs, IMS may automatically submit the archive job
•IMS can define whether the log archive process will occur with every
log switch, or every second log switch, and the DBRC skeletal JCL that
controls the archiving, can be defined to also create 1 or 2 System Log
data sets, and 0, 1 or 2 Recovery Log Data sets
 OLDS errors
•In the case of a write error, the subject OLDS (or pair of
OLDS) will be put into a stopped status and will not be used
again
•Information is kept in the RECON data set about the OLDS
for each IMS system
•IMS issues messages when it is running out of OLDS
•During the use of the last available OLDS, IMS will indicate
that no spare OLDS are available
•When all the OLDS are full, and the archives have not
successfully completed, then IMS will stop, and have to
wait until at least 1 OLDS has been archived. The only thing
IMS will do is repeatedly issue messages to indicate that it
is has run out of OLDS, and is waiting
 Write ahead data sets (WADS)
•The WADS is a small direct access data set which contains a copy of committed log
records which are in OLDS buffers, but have not yet been written to the OLDS
•If IMS or the system fails, the log data in the WADS is used to terminate the OLDS,
which can be done as part of an Emergency Restart, or as an option on the IMS Log
Recovery Utility
•The WADS space is continually reused after the appropriate log data has been
written to the OLDS
•This data set is required for all IMS systems, and must be pre-allocated and formatted
at IMS start-up when first used
•In addition, the WADS provide extremely high performance. This is achieved primarily
through the physical design of the WADS
•All WADS should be dynamically allocated by using the DFSMDA macro, and not
hardcoded in the control region JCL
•All the WADS must be on the same device type and have the same space allocation
•Regardless of whether there are single or dual WADS, there can be up to 10 WADS
defined to any IMS. (WADS0, WADS1,...., WADS9).
•WADS0 (and WADS1 if running dual WADS) are active, and the rest remain as spares
in case any active WADS has an I/O error. The next spare will then replace the one
with the error
 System log data sets (SLDS)
•The SLDS is created by the IMS log archive utility, possibly after
every OLDS switch
•The SLDS can contain the data from one or more OLDS data
sets
•Information about SLDS is maintained by DBRC in the RECON
data set
•Dual archiving to 2 SLDS data sets (primary and secondary) is
supported
•Generally, the SLDS should contain all the log records from the
OLDS, but if the user wants to omit types of log records from the
SLDS, these can be specified within the log archive utility
•The blocksize of the SLDS is independent of the OLDS blocksize
 Recovery log data sets (RLDS)
•When the IMS log archive utility is run, the user can
request creation of an output data set that contains all
of the log records needed for database recovery
•All database recoveries and change accumulation
jobs will always use the RLDS if one exists, and this can
considerably speed up any of these processes because
the only contents of these data sets are database
recovery log records
•The RLDS is optional, and you can also have dual
copies of this, in a similar way to the SLDS
Overview of the logging process
Thanks!