You are on page 1of 16


DB2 is an abbreviation for IBM Database 2 and was launched in June 1983 as a
subsystem on MVS that allowed MVS users to build, access, and maintain relational
databases using the well known Structured Query language (SQL).

Since then, DB2 has come a long way and provides facilities to exploit the latest
hardware and software technologies, accommodating a majority of user requirements.
The latest versions are available on almost all platforms, including Windows, HP-UX,
Sun Solaris, Unix, AIX, NUMAQ, Linux, AS/400 and OS/390.

As the name suggests, DB2 "Universal Database" provides universal data types, universal
integration, universal access from clients of all types, universal applicability (for all types
of applications), universal scalability (across all types of platforms), universal reliability
(for non-stop 24/7 processing) and universal manageability.

The ability to manage many concurrent users, very large databases, high transaction rates
and deliver consistent rapid response is fundamental and delivered by DB2 through the
wide range of platforms and the exploitation of platform-specific features. Beyond this,
DB2 meets the requirements for high availability, low planned maintenance, wide
connectivity, open standards and effective manageability.


VSAM is a high-performance access method used in the MVS, OS/390 and VSE/ESA
operating systems. It was initially released by IBM in 1973 and is part of the Base

VSAM provides a number of data set types or data organization schemes. They are:

• Key-sequenced data set (KSDS)

• Entry-sequenced data set (ESDS)
• Relative record data set (RRDS)
• Variable-length relative record data set (VRRDS)
• Linear data set (LDS)

Installations have been using VSAM data sets to hold more and more of their data to the
point where many have reached the 4-gigabyte architectural limit for the size of VSAM
data sets. Beginning with DFSMS V1.3, you can create and use VSAM KSDSs that can
be much larger than the 4-gigabyte limit imposed on any VSAM data set defined before
this release. DFSMS V1.5 allows non-KSDS file types (ESDS, RRDS, VRRDS and
LDS) to exceed 4 gigabytes.

VSAM record-level sharing (RLS) was introduced to provide the value of the Parallel
Sysplex to the existing applications. RLS itself does not provide transactional recovery.
CICS provides a file access interface on top of VSAM. It is a CICS file control function

that includes transactional recovery for VSAM files. This isolation and rollback
capability enables VSAM data to be shared among CICS applications.

Comparison of DB2 and VSAM

Feature DB2 VSAM

Hardware PC to mainframe Only Mainframe
OS NT, Unix & OS/390 Only OS/390
Vendor RBDMS with ANSI std. Only IBM
Scalability PC to mainframes Only Mainframe

Upto 4000 terabytes for Maximum size is 128

LOB terabytes
Ease of Standard SQL Not so simple
Stored procedure & No such option
Ease of Standard SQL Difficult
Security High degrees of security Only at Dataset level
Referential DB2 enforces it Developers
Integrity responsibility
Manages even externally
stored data Not applicable
Query Easy to view/modify Not available
Products/tool IBM & 3rd Parties Not available
Data Capacity 254 times largest VSAM Limited to 2
Data sharing Across CICS, IMS, Batch, Very limited support
Web & Java JDBC, SQLJ, Need custom
support interfaces
Distributed Consistent across Only Mainframe
environment platforms
Not applicable
Stored procs reduce
network traffic
XML support XML extenders Not supported
Performance For less data Better when data is

Feature DB2 VSAM
Better for large data
For less data
Optimizer handles
Partitioning improvesresponsible
No partitioning
Performance Can be tuned anytime Depends on initial
Tuning design
Writes SMF records
No SMF records
Can be at SQL level
Only application level
Tools available for aiding
No tuning aids
Subsystem level tuning
possible Not a subsystem

Abundant tuning skills Tuning skills are rare

CPU & IO Scanning is Faster No parallelism
Parallel Can participate Can participate
Optimizer handles No optimization
Reorganization Direct reorganization Delete & recreate

Online reorg possible Downtime needed

Parallel reorg No parallelism

Recovery Managed by DB2 Managed by CICS/IMS

Always recoverable No recovery in batch

From log / backup From backup only

Auto Recovery Manual Restore

Parallel recovery No parallelism

Backup Online backup possible Downtime needed

Incremental backup No incremental

Parallel backup

Feature DB2 VSAM

No parallelism
Availability Parallel reorg, backup No online
Online reorg, backup
No parallelism
Less downtime
More Downtime
Disaster Supported by DB2 Part of DASD
Recovery recovery
Data Archival Selective archival No Selective archival

Selective retrieval No Selective retrieval

Upto row level archival Dataset level archival

Specific Products Dataset Migration

Personnel IBM & 3rd party training Not much training

Easy to find Skills Scarce skill

Reuse any RDBMS skill VSAM Specific skill

Same across platforms Mainframe Specific

Data Real time updates Batch updates only
Direct Propagation Extract & transform

Product suites available Not suitable for

Data types Images, Video, Audio etc Text only

Contents can be in file No such option


MVS (Multiple Virtual Storage) is an operating system from IBM that continues to run
on many of IBM's mainframe and large server computers. MVS has been said to be the
operating system that keeps the world going and the same could be said of its successor
systems, OS/390 and z/OS. The payroll, accounts receivable, transaction processing,
database management, and other programs critical to the world's largest businesses are
usually run on an MVS or successor system. Although MVS has often been seen as a

monolithic, centrally-controlled information system, IBM has in recent years repositioned
it (and successor systems) as a "large server" in a network-oriented distributed
environment, using a 3-tier application model.

The follow-on version of MVS, OS/390, no longer included the "MVS" in its name.
Since MVS represents a certain epoch and culture in the history of computing and since
many older MVS systems still operate, the term "MVS" will probably continue to be used
for some time. Since OS/390 also comes with Unix user and programming interfaces
built in, it can be used as both an MVS system and a UNIX system at the same time. A
more recent evolution of MVS is z/OS, an operating system for IBM's zSeries
mainframes. MVS systems run older applications developed using COBOL and, for
transaction programs, CICS. Older application programs written in PL/I and FORTRAN
are still running. Older applications use the Virtual Storage Access Method access
method for file management and Virtual Telecommunications Access Method for
telecommunication with users. The most common program environment today uses the C
and C++ languages. DB2 is IBM's primary relational database management system
(RDBMS). Java applications can be developed and run under OS/390's UNIX

MVS is a generic name for specific products that included MVS/SP (MVS/System
Product), MVS/XA (MVS/Extended Architecture), and MVS/ESA (MVS/Enterprise
Systems Architecture). Historically, MVS evolved from OS/360, the operating system for
the System/360, which was released in 1964. It later became the OS/370 and the
System/370. OS/370 evolved into the OS/VS, OS/MFT, OS/MVT, OS/MVS, MVS/SP,
MVS/XA, MVS/ESA, and finally OS/390 and then z/OS. Throughout this evolution,
application programs written for any operating system have always been able to run in
any of the later operating systems. (This is called forward compatibility.)

An MVS system is a set of basic products and a set of optional products. This allows a
customer to choose the set of functions they need and exclude the rest. In practice, most
customers probably use almost all of the functions. The main user interface in MVS
systems is TSO (Time Sharing Option). The Interactive System Productivity Facility
(ISPF) is a set of menus for compiling and managing programs and for configuring the
system. The main work management system is either Job Entry Subsystem 2 or 3 (JES2
or JES3). Storage (DASD) management is performed by DFSMS (Distributed File
Storage Management Subsystem). MVS is considerably more complex and requires
much more education and experience to operate than smaller server and personal
computer operating systems.

The Virtual Storage in MVS refers to the use of virtual memory in the operating system.
Virtual storage or memory allows a program to have access to the maximum amount of
memory in a system even though this memory is actually being shared among more than
one application program. The operating system translates the program's virtual address
into the real physical memory address where the data is actually located. The Multiple in
MVS indicates that a separate virtual memory is maintained for each of multiple task

Other IBM operating systems for their larger computers include or have included: the
Transaction Processing Facility (TPF), used in some major airline reservation systems,
and VM, an operating system designed to serve many interactive users at the same time


IBM mainframe utility programs are supplied with IBM mainframe operating systems
such as MVS to carry out various tasks associated with datasets, etc.

Disk drive support


ICKDSF ("Device Support Facility") installs, initializes and maintains DASD, either
under an operating system, or standalone.

VSAM utilities

IDCAMS ("Access Method Services") generates and modifies VSAM and Non-VSAM
datasets. The "Access Method" reference derives from the initial "VSAM replaces all
other access methods" mindset of OS/VS. It probably has the most functionality of all the
utility programs, preforming many functions, for both VSAM and non-VSAM files. It
was intended to replace most of the other dataset utility programs.

Dataset utilities

IEBCOMPR compares records in sequential or partitioned datasets.

The IEBCOMPR utility is used to compare two sequential or partitioned data sets. This
data set comparison is performed at the logical record level. Therefore, IEBCOMPR is
commonly used to verify that a backup copying of a data set is current.

During processing, IEBCOMPR compares each record from each data set, one by one. If
the records are unequal, IEBCOMPR lists the following information in the SYSOUT:

- The record and block numbers in question.

- The names of the DD statements in which the inconsistency occurred.

- The unequal records.

When comparing sequential data sets, IEBCOMPR considers the data sets equal if the
following conditions are met:

- The data sets contain the same number of records.

- The corresponding records and keys are identical.

For partitioned data sets, IEBCOMPR considers the data sets equal if the following
conditions are met:

- The directory entries for the two partitioned data sets match - that is, the names are the
same, and the number of entries are equal.

- The corresponding members contain the same number of records.

- The corresponding records and keys are identical.

If ten unequal comparisons are encountered during processing, IECOMPR terminates

with the appropriate message.




IEBCOPY copies, compresses and merges partitioned datasets. It can also select or
exclude specified members during the copy operation, and rename or replace members.

Some of the tasks that IEBCOPY can perform include the following:

- Creating a backup of a PDS

- Copying a PDS in place to reclaim the unused space from deleted members; Also called
compressing a PDS.

- Copying selected members to another PDS.

- Renaming selected members of a PDS.

- Merging multiple partitioned data sets into a single PDS.

- Altering, copying and reblocking load moduled.

The IEBCOPY utility differs from the other IEB-type utilities in that the DDNAMEs of
the input and output DD statements are defined by the JCL code as opposed to using the
standard SYSUT1 and SYSUT2 DDNAMEs. For the IEBCOPY utility, the required job
control statements are as follows:


//anyname1 DD ...
//anyname2 DD ...
//SYSUT3 DD ...
//SYSUT4 DD ...
//SYSIN DD ...

The EXEC statement specifies the utility program name IEBCOPY. You can give this
EXEC statement any stepname you wish, as long as you adhere to the naming
conventions for JCL statements. Following the EXEC statement are the specific DD
statements used by IEBCOPY. These DD statements must appear in every step that uses
IEBCOPY. In addition, the DD statements can be listed in any order within the step.

The SYSPRINT DD statement specifies a message data set to which the output message
generated from the utility, such as error and allocation messages, are sent.

The anyname1 and anyname2 DD statements are specific to the IEBCOPY utility. These
DD statements indicate the partitioned input and output data sets, respectively. You can
use any DDNAME for these two DD statements, as long as you adhere to the naming
conventions for DDNAMEs. As you will see, these DDNAMEs are specified in the utility
control statements to tell IEBCOPY the name of the input and output data sets.

The SYSUT3 statement specifies a spill (work) data set on DASD that is used to hold the
input data set's directory entries during the copying. This work data set is used if there is
not enough virtual storage allocated to the program by the JOB or EXEC statement
REGION parameter. The SYSUT4 DD statement also specifies a spill(work) data set on
DASD. This is used to hold the output data set's directory entries during the copying, if
enough virtual storage is not available.

The SYSIN DD statement specifies the utility control data set.


IEBDG ('Data Generator') creates test datasets consisting of patterned data.


IEBEDIT selectively copies portions of JCL.

An example of an IEBEDIT program:


//SYSUT1 DD DSN=xxxxx.yyyyy.zzzzz,DISP=SHR

In data set xxxxx.yyyyy.zzzzz you have to write a JCL program which contains 15 steps.
After that you have to execute the above program.


IEBGENER copies records from a sequential dataset, or creates a partitioned dataset.

Some of the tasks that IEBGENER can perform include the following:

- Creating a backup of a sequential data set or a member of a PDS.

- Changing the physical block size or logical record length of a sequential data set.

- Creating an edited data set.

- Printing a sequential data set or a member of a PDS.

- Creating partitioned output data set from sequential input data set.

An example of an IEBGENER program to copy one dataset to another:


//SYSUT1 DD DSN=xxxxx.yyyyy.zzzzz,DISP=SHR
//SYSUT2 DD DSN=aaaaa.bbbbb.ccccc,DISP=(,CATLG),

The EXEC statement specifies the program IEBGENER. You can give this EXEC
statement any stepname that you wish, as long as you adhere to the naming conventions
for JCL statements. Following the EXEC statement, ate the specific DD statements used
by IEBGENER. These DD statements must appear in every step that uses IEBGENER. In
addition, the DD statements can be listed in any order within the IEBGENER step.

The SYSPRINT DD statement specifies a message data set to which the output message
generated from the utility, such as information and error message, are sent. Remember
that the SYSPRINT DD statement can specify a system output device, a tape data set, or
a DASD data set.

The SYSUT1 DD statement specifies the input data set, that is, the name of the data set
that you wish to copy. For the the IEBGENER utility, this DD statement specifies a
sequential data set or a member of a PDS.

The SYSUT2 DD statement specifies the output data set, that is, the name of the data set
you wish to create or to which you wish to copy members. This DD statement specifies a
sequential data set, a PDS, or a member of a PDS.

The SYSIN DD statement specifies the utiity control statements. The utility control
statements are optional for IEBGENER. If utility control statement are used, the SYSIN
DD statement defines instream data, a sequential data set, or member of a PDS. If you do
not need to include any utility control statement you should specify a DUMMY
parameter on the SYSIN DD statement.

On some systems it is possible to send email from a batch job by directing the output to
the "SMTP" external writer. On such systems, the technique is as follows:


Subject: Test Mail




IEBIMAGE manipulates character set definitions (aka "load modules" or "images") for
the IBM 3800 printing subsystem.


IEBISAM unloads, loads, copies and prints ISAM datasets. (OBSOLETE) ISAM is no
longer supported by most modern operating systems. VSAM is used instead. See


IEBPTPCH ("PrinT and PunCH") prints or punches records from a sequential or

partitioned dataset.

Some of the tasks that IEBPTPCH can perform include the following:

- Printing or punching an entire data set, sequential or partitioned (PDS).

- Printing or punching selected PDS members.

- Printing or punching selected records from a sequential or partitioned data set.

- Printing or punching a PDS directory.

- Printing or punching an edited version of a sequential data set or PDS.

TITLE ITEM=('Name',22),
TITLE ITEM=(' ',1)
RECORD FIELD=(25,1,,22),
Person 1 307 C Meshel Hall 3.89
Second person 123 Williamson Hall 2.48
3rd person 321 Maag Library 1.52


IEBUPDTE ("UPDaTE") incorporates changes to sequential or partitioned datasets. The

UNIX "patch" utility is a similar program, but uses different input format markers (e..g,
"./ INSERT ..." in MVS becomes "@@..." in Unix Patch).

Some programmers pronounce it "I.E.B. up-ditty".

The IEBUPDTE utililty is a utility used to maintain source libraries. Some of the
functions that IEBUPDTE can perform include the following:

- Creating and updating libraries

- Modifying sequential data sets or PDS members

- Changing the organization of a data set from sequential to partitioned or from

partitioned to sequential.

IEBUPDTE is commonly used to distribute source libraries from tape to DASD.

IEBUPDTE uses the same job control statements required by most IEB-type utilities. The
only exceptions are as follow:

- IEBUPDTE accepts a PARM parameter coded on the EXEC statement.

- IEBUPDTE reads the input data set from either the SYSUT1 DD statement or from the
SYSIN DD statement.

The job control used by IEUPDTE are as follows:

//stepname EXEC PGM=IEUPDTE,PARM=parm

//SYSUT1 DD ...
//SYSUT2 DD ...
//SYSIN DD ...

The EXEC statement specifies the program IEBUPDTE and an optional PARM value,
NEW or MOD. A PARM value of NEW indicates that the utility control statements and
the input data are contained in the SYSIN DD statement. In this case, no SYSIN1 DD
statement is required. A PARM value of MOD indicates that the SYSIN DD statement
contains only utility control statements, as opposed to utility control statements plus the
input data. Therefore, the SYSUT1 DD statement is required to define the input data set.

Scheduler utilities

IEFBR14 is a dummy program, normally inserted to JCL when the only desired action is
allocation or deletion of datasets.

An example of an IEFBR14 program:


//DELDD DD DSN=xxxxx.yyyyy.zzzzz,

It consisted initially as a single instruction a "Branch to Register" 14. The mnemonic used
in the IBM Assembler was BR and hence the name: IEF BR 14.

The calling sequence for OS/360 contained the return address in Register 14. A branch to
Register 14 would thus immediately exit the program. However, before and after
executing this program, the operating system would allocate & deallocate datasets as
specified in the DD statements, so it is commonly used as a quick way to set up or
remove datasets.

This single instruction program had an error in it. It didn't set the return code and hence a
second instruction had to be added to clear the return code so that it would exit with the
correct status.

System utilities

IEHINITT ("INITalize Tape") initializes tapes by writing tape labels. Multiple tapes may
be labeled in one run of the utility. IBM standard or ASCII labels may be written.

An example of an IEHINITT program:



This example will label 3 tapes on a 3490 magnetic tape unit. Each tape will receive an
IBM standard label. The VOLSER will be incremented by one for each tape labeled.
Each tape will be rewound and unloaded after being labeled.


IEHLIST is a utility used to list entries in a Partitioned Dataset (PDS) directory or to list
the contents of a Volume Table of Contents (VTOC).

The IEHLIST utility is used to list the entries contained in any one of the following:

- PDS directory


- Catalog (OS CVOL)

An example of an IEHLIST program:



//PDS1 DD DSN=xxxx.yyyy.zzzz,DISP=OLD

This job will produce a formatted listing of the PDS directory of the PDS named

An example of an IEHLIST program to list a VTOC is very similar:




IEHMOVE moves or copies collections of data. (However, IBM does not recommend
using the IEHMOVE utility in an SMS environment.) A move differs from a copy in that
during a move the original data set is deleted, or scratched. Some of the tasks that
IEHMOVE can perform include the following:

- Moving or copying sequential and partitional data sets

- Moving or copying multi- volume data sets

- Moving an entire volume of data sets

On the surface, IEHMOVE may seen redundant to the IEBGENER and IECOPY utilities.
However, IEHMOVE is more powerful. The main advantage of using IEHMOVE is that
you do not need to specify space or DCB information for the new data sets. This is
because IEHMOVE allocates this information based on the existing data sets.

Another advantage of IEHMOVE is that you can copy or move groups of data sets as
well as entire volumes of data. Because of the ease in moving groups of data sets or
volumes, the IEHMOVE utility is generally favored by system programmers.

The job control statements required by the IEHMOVE utility are as follows:


//anyname1 DD UNIT=cccc,VOL=SER=dddddd,DISP=OLD
//anyname2 DD UNIT=eeee,VOL=SER=ffffff,DISP=OLD

//SYSIN DD ...

Following the EXEC statement are the specific DD statements used by IEHMOVE.
These statements must appear in every step that uses IEHMOVE. In addition, DD
statements used by IEHMOVE can be listed in any order within the job step.

The DD statements for IEHMOVE, order than SYSPRINT and SYSIN, refer to DASD or
tape volumes instead of individual data sets. However, referencing volumes can pose a
problem. Remember that when you modify a data set, you allocate it with a disposition of
OLD (DISP=OLD) to prevent other users from accessing the data set at the same time.
However, specifying DISP= OLD grants exclusive access to a volume. Therefore, when
your IEHMOVE job runs, other users cannot use the volumes allocated by IEHMOVE.
This is acceptable for private volumes, such as tape volumes or mountable volumes, but
unacceptable public volumes, such as DASD volumes.

The SYSPRINT DD statement specifies a message data set to which the output message
generated from the utility, such as information and error messages, are sent.

The SYSUT1 DD statement specifies a DASD volume where three work data set
required by IEHMOVE are allocated. You must specify unit and volume information for
this DD statement.

IEHMOVE was one of the first systems to be developed in PL/S.


IEHPROGM builds and maintains system control data. It is also used for renaming and
scratching (deleting) a data set.

Some of the tasks that IEHPROGM can perform include the following:

- Deleting (scratching) a data set or PDS member

- Renaming a data set or PDS member

- Cataloging or uncataloging a data set

- Maintaining data set passwords

Supporting Programs

(The following programs are not technically utilities -- they are not supplied with the
Operating System, but are sold as separate packages. Still, as they are standard items
required for programming the computer, nearly all shops will have them installed.)


The Sort/Merge utility is program to sort records in a file into a specified order, or merge
pre-sorted files. It is very frequently used; often the most commonly used application
program in a mainframe shop. Modern sort/merge programs also can select or omit
certain records, summarize records, remove duplicates, reformat records, and produce
simple reports. Sort/merge is important enough that there are multiple companies each
selling their own sort/merge package for IBM mainframes.


IEWL (also known as HEWL) is the linkage editor used to create an executable load
module from an object module. The linkage editor must be used to make an executable
copy ('load module') of a compiled or assembled program produced by an assembler or
compiler for some programming language. External symbols in the object module(s),
optional linkage editor control statements, and linkage editor JCL parameters determine
how the finished load module is to be constructed.


IGYCRCTL is a COBOL compiler that prepares a COBOL source program for execution
by producing a machine-language object module. Note that the object module produced
by the compiler must be processed by the linkage editor, IEWL, before the compiled
program is ready for execution. (This is the compiler for the current IBM Enterprise
COBOL for z/OS product; there have been several previous IBM COBOL compilers over
the years, with different names, as well as compilers for various other programming


DFSMS (System Managed Storage) is a set of programs that allows the operating system
itself to take over many of the tasks of managing storage, tasks that were previously
performed manually by systems programmers. The storage administrator defines classes
of storage, and rules defining dataset assignment into these classes. From then on, the
system manages the datasets automatically, taking care of assigning datasets to storage
volumes, providing backup and recovery, migrating datasets up or down between
secondary and tertiary storage as needed, and balancing usage of system resources. See
also: hierarchical storage management.