IBM Database 2 in an Information Management System environment

IBM Database 2 in anInformation ManagementSystem environment

Over the years, the IBM Information Management Sys-tem (IMS/VS) has been developed to meet expandinguser needs. During that time, a parallel developmenthas taken place. The relational data model grew fromCodd's original theory to a practical data base proto-type. Now a new data base management system, IBMDatabase 2 (DB2), has been built on the relationalmodel. This paper discusses the implementation anddesign considerations for the integration of IMS andDB2 from the user's viewpoint. It also presents theattachment facilities from a design perspective.

T he IBM Information Management Systems, IMS/VS, had its origins in IMS/360, which was an-

nounced in 1969. Over the years since its first devel-opment, IMS has greatly improved in function tosupport the rapidly growing need for data-commu-nications-based applications. 1 The data base part ofIMS/VS, known as IMS/DB or DL/I (Data Language/I),is a hierarchical data base management system(DBMS). In a hierarchical or tree data structure, eachapplication threads its way from data record to datarecord accessing groups of fields called segments.The connection between data records is establishedvia pointers. IMS/VS is referred to in this paper simplyas IMS.

In the late 1960s and early 1970s, Codd2 introducedthe relational data model as an alternative way ofstructuring and managing data. Here, data are struc-

IBM SYSTEMS JOURNAL, VOL 23, NO 2, 1984

by J. R. DashR. N. Ojala

tured in two-dimensional tables and related by theirvalue only, not by pointers embedded between datarecords. In the lexicon of data base terminology, thisstructure has created the term nonnavigational datastructure because no programmer navigation is re-quired to move through the data structure. In con-junction with the data structure, the relational modelsuggests data manipulation via a series of set-theo-retic operators that help achieve significant econ-omies in programming and end user access to databases. The new MVS data base management systemIBM Database 2 (DB2) is built upon the relationaldata model. Overall design principles of DB2 arediscussed by Haderle' and Kahn4 elsewhere in thisissue.

This paper discusses the linking ofDB2 with IMS (IMS/VS, Version 1, Release 3). IMS application programscan retrieve and update data in DB2 tables using thefacilities discussed in this paper. Whereas some ap-plication programs may access DL/I data bases only,other programs may access both DL/I and DB2 data,or perhaps access DB2 data only. Because the DB2system can be used by the Customer Information

4) Copyright 1984 by International Business Machines Corporation.Copying in printed form for private use is permitted withoutpayment of royalty provided that (I) each reproduction is donewithout alteration and (2) the Journal reference and IBM copyrightnotice are included on the first page. The title and abstract, but noother portions, of this paper may be copied or distributed royaltyfree without further permission by computer-based and otherinformation-service systems. Permission to republish any otherportion of this paper must be obtained from the Editor.

DASH AND OJALA 165

Figure 1 MVS address spaces

MVSCOMMON AREA

TSO TSO CICS IMS IM$ IMS IMS DB2 DB2 IRlMQUERY CONTROL MESSAGE sATC.H IMSIVS SYSTEM DATA IMSMANAGEMENT REGION PROCES$INl;l MESSAl;lE FAST SERVICES BASE RESOURCEFACILITY (CTl) PROGRAM PROCI;SSING PATH SERVICES lOCK(QMF) (MP!") (ElMP) (IFP) MANAGER

MVSSYSTEM AREA

Control System (CICS), Time Sharing Option (TSO),and Query Management Facility (QMF) users on thesame host, data gathered by one system can be sharedeasily by all systems within the same host. Figure 1shows various MVS address spaces that may be usedwith IMS.

We treat the subject of DB2 in the IMS environmentprincipally in two parts. We first describe variousaspects ofDB2 in IMS from a user's point of view. Wethen look at the DB2-IMS attachment facilities from asystems design perspective.

Use of DB2 in an IMS environment

Users of DB2 in an IMS environment comprise appli-cation analysts and programmers, data base design-ers and administrators, systems programmers, secu-rity administrators, operators, and end users. Whileend users of IMS transaction programs do not see anydifference with DB2, business professionals will findDB2 and QMF to be effective tools for access to dataextracted from IMS production data bases.

Data base design. From a theoretical viewpoint, thedesign of a data base on a logical level should not bedifferent for different data base management sys-tems. The logical data base design should resolvequestions as to which records are best suited to modelthe real business, which fields should go together ina record type, when it is better to split a record typeinto multiple record types, and what relationshipexists between record types. Data base design theo-ries covering these steps are somewhat formalized inthe process termed normalization. 5-7 Normalizationguidelines are designed to reduce update anomalies

166 DASH AND OJALA

and data inconsistencies. These guidelines are notexclusive to relational data base systems; they applyas well to the design of record structures for suchnonrelational DBMSS as IMS/DB.

After the normalization process, there follows thephysical design task to structure these record typesinto physical data bases according to the require-ments, facilities, and peculiarities of the actual DBMS.Although logical data base design should be inde-pendent of the physical aspects of data structure,usually the boundary is not as clean and distinct asit should ideally be. During the logical design phase,an experienced designer should take into accountthe effect of options on the physical design. At least,this had been the way the designer would proceed,until the appearance of relational data base systems.

An important characteristic of relational DBMSS isthe enhanced level of data independence (i.e., theseparation of the user's view of data from its storagerepresentation). Data are always modeled as valuesin actual tables. Therefore, many complex consid-erations are eliminated, such as which relationshipsshould be implemented in the data structures (hier-archies and networks) and which should still beimplemented as values (i.e., the decision between adirect and a symbolic pointer in DL/I). This leads toa simplification in going from a logical design to aphysical design.

In summary, the results of the logical design of a setof record structures map directly into a set of DB2tables. The advantage of this type of design activityis that DB2 table structures have a better chance tosurvive changing requirements and needs. This is in


contrast to a network or hierarchical system, wherethere is the further step of deciding which relation-ships should be implemented as part of the datastructure.

Data base implementation. When the resulting database design is implemented and defined to DB2, anumber of tasks are simplified. Logical objects areclearly separated from physical ones. The data baseadministrator can clearly define physical aspects(e.g., which indexes, partitioning or not, page size,or single or multiple tables per tablespace), andapplication designers can provide such logical defi-nitions as tables and views. Definitions of data basestructures can be accomplished directly from an on-line terminal and with no disruption to current database operations. An example of the SQL CREATEstatement for an EMPLOYEE table is shown in Figure2 and for a DEPARTMENT table in Figure 3. Data basedefinitions take immediate effect in DB2 because theData Definition Language (DDL) statements are proc-essed instantly, resulting in updates to the DB2 cata-log. Additional columns can be added without re-quiring unloading and reloading of the data base byusing the SQL ALTER statement. View definition mayinsulate one design from subsequent changes. DB2 ismore forgiving of an incomplete data base design.Thus, it is not so critical to make the design rightthe first time.

DB2 offers a uniform language (SQL) for both database access and definition. Having one consistentlanguage for these two tasks simplifies communica-tion among persons who define the data bases andthose who will later access them. The uniformity oflanguage for data definition and data access has alsocontributed to the fact that with SQL some aspects ofdata base programming have been moved over todata base definition. For example, the viewdefinition(DOl ADMIN) shown in Figure 4 eliminates the needfor program code that otherwise would have beennecessary in order to combine the EMPLOYEE andDEPARTMENT tables and to obtain the proper subsetof rows.

Finally, among the task simplifications, DB2 providesan authorization mechanism that allows data baseadministration to be centralized, partially decentral-ized, or completely decentralized. Portions of thedata base administration function can be parceledout to different areas without giving up completecontrol.

Application programming. An application programin the IMS environment can have accesses to DB2

IBM SYSTEMS JOURNAL, VOL 23,NO 2,1984

data intermixed with accesses to DL/I data. Com-munication with an IMS terminal uses the DL/I mech-anism. Transaction input is received using the DL/I,GU, or CHKP call, and messages are sent to terminalsusing ISRT or PURG calls. Applications running in the

The IMS end user should note nodifferences if atransaction accesses

DB2 data.

IMS batch region have no access to DB2 tables. Appli-cations can, however, run as Batch Message Process-ing (BMP) programs to communicate with DB2. TheIMS end user at the terminal should note no differ-ences if a transaction accesses DB2 data. No messagesrelating to DB2 are sent to the end user by IMS.

While details of application programming tech-niques can be found elsewhere," we describe heresome of the concepts and functions in DB2 that arenew to the IMS programmer. Because relationshipsin DB2 tables are represented only by values in thetables themselves, there are some significant advan-tages. At the user level all relational access is accom-plished through associative addressing by comparingvalues. Data base requests to retrieve or update dataare always made through the use of actual values inthe tables. This simplifiesoperations on tables by notrequiring data base requests in terms of an impliedposition, as in DL/I structures, and a movement alongthe segments within the structure.

A consequence of access through field values only isthat all access is symmetrical. The programmer doesnot code differently depending on what access pathis used. Access through different indexes, as an ex-ample, is not different in the way one codes, as inIMS/VS. The use of an index is determined completelyat the internal system level and is not specified bythe user in DB2. Therefore, indexes can be added ordeleted without affecting program logic.

The SQL language can be used as a stand-alonelanguage (via SPUFI in TSO/SPF), or it can also beembedded into conventional host languages such as

DASH AND OJALA 167

Figure 2 Employee table showing definition statement and table contents after LOAD

CREATE TABLE E~1PLOYEE

(EMPNO CHAR(6) NOT NULL,

LASTNAME VARCHAR (15 ) NOT NULL,

WORKDEPT CHAR(3) NOT NULL,

PHONENO CHAR(4),

JOBCODE DEClMAL(3),

EDUCLVL SMALLINT,

SEX CHAR (1) ,

SALARY DECIMAL(8,2));

EMPNO LASTNAME WORKDEPT PHONENO JOBCODE EDUCLVL SEX SALARY

000100 Spenser E21 0972 54 14 M 26150

000140 Nicholls COl 1793 56 18 F 28420

000260 Johnson D21 8953 52 16 F 17250

000310 Setright Ell 3332 46 12 F 15900

000030 Kwan COl 4738 60 20 F 38250

000060 Stern Dll 6423 55 16 M 32250

000010 Haas AOO 3978 66 18 F 52750

000220 Lutz Dll 0672 55 18 F 29840

000300 Smith Ell 2095 48 14 M 17750

000020 Thompson B01 3476 61 18 M 41250

000050 Geyer E01 6789 58 16 M 40175

000070 Pulaski D21 7831 56 16 F 36170

000270 Perez D21 9001 55 15 F 27380

000150 Adamson Dll 4510 55 16 M 25280

168 DASH AND OJALA IBM SYSTEMS JOURNAL. VOL 23. NO 2. 1984

Figure 3 Department table showing definition statement and table contents after LOAD (where < > indicates null value)

CREATE TABLE DEPARTMENT

(DEPTNO

DEPTNAME

MGRNO

ADMRDEPT

CHAR(3) NOT NULL,

VARCHAR(36) NOT NULL,

CHAR (6),

CHAR(3»j

DEPTNO DEPTNAME MGRNO ADMRDEPT

AOO Spiffy Computer Co 000010 < >

BOl Planning 000020 AOO

COl Info Center 000030 ADO

D11 Manufacturing 000060 DOl

DOl Dev Center < > AOO

D21 Admin Systems 000070 DOl

E01 Support Services 000050 ADD

Ell Operations 000090 E01

E21 Software Support 000100 E01

< > indicates NULL value.

COBOL, PL/I, or Assembler. This is an importantrequirement for a relational language like SQL, andthis property is characterized as the uniformly rela-tional property. 9

SQL operations apply to entire collections (sets) ofrows from tables, not just individual rows. The result

IBM SYSTEMS JOURNAL. VOL 23. NO 2. 1984

of each table operation is itself a table. Therefore,data base requests can be expressed so that results ofone operation become the inputs to another. Thisset-at-a-time capability is extremely powerful com-pared to record-at-a-time processing, where the cod-ing is required to be more detailed. This power isfully available to the interactive user of SQL.

DASH AND OJALA 169

Figure 4 D01ADMIN view showing employees and departments reporting to Department ID 001

CREATE VIEW D01ADMIN AS

SELECT EMPNO,LASTNAME,DEPTNO,DEPTNAME

FROM EMPLOYEE,DEPARTMENT

WHERE WORKDEPT = DEPTNO

AND ADMRDEPT = I DO 1•

EMPNO LASTNAME DEPTNO DEPTNAME

000150 Adamson Dll Manufacturing

000220 Lutz Dll Manufacturing

000060 Stern Dll Manufacturing

000260 Johnson D21 Admin

000270 Perez D21 Admin

000070 Pulaski D21 Admin

For the embedded version OfSQL (e.g., in COBOL andPL/I), the operations of insert, delete, and updatepresent no problems as set operations. Also, there isno problem when retrieval operations return onerow as a result. However, when retrieval requestsreturn a set of rows to the application program, thoserows are accessed one at a time by using a cursor.This is because the number of rows to be returned isnot known when the SQL statement is issued. Thecursor is a position holder in a set of rows, and thislimits the value of set operators in the host languageenvironments to some degree.

A single SELECT statement in OB2 (SPUFI) correspondsto a series of GU, GN, and GNP calls in OL/I. SELECTstatements using join conditions correspond to re-

170 DASH AND OJALA

trieval calls, depending on links carried in the hier-archical structure (i.e., GNP and GN).

Data consistency facilities are generally a character-istic of the implementation. With the current imple-mentation of OB2, consistency of data across tablesin general has to be maintained by the programs andprocedures that operate on the data bases. To acertain extent, this responsibility is simplified by thelanguage functions available in SQL. IMS/VS providessome data consistency capabilities through its hier-archical data structures and other capabilitiesthrough the logical insert/replace/delete rules.

Primary key consistency in DB2 is accomplished byspecifying that a primary key column is not allowed


to have null values and by specifying a unique indexfor the column. IMS/VS requires keys to be presentand to be unique if so specified, but there are optionsavailable to depart from this.

DB2 provides built-in functions for summation(SUM), ordering (ORDER BY), and basic statistics [Min-imum (MIN), Maximum (MAX), Average (AVG), and

DB2 provides alayered approach tosecurity.

COUNT]. There are no corresponding functions inIMS/VS, and all such functions have to be coded inapplication programs.

View definition can substitute for a considerable partof programming by eliminating irrelevant data thatotherwise would have to be handled by programcode. The example in Figure 4 illustrates this point.Also, if the same set of data is used in more thanone application, redundant coding can be eliminatedby establishing predefined view specification. TheSQL CREATE with CHECK OPTION for single-table viewscan be used to protect against inserts or updates thatmight destroy the very criteria on which the view isbased.

When program development is in a preliminary orearly stage, it is convenient to try out relational database request sequences directly from a terminal as astand-alone data base test without involvement ofan actual program. It is also convenient to set upand test data outside the actual program through theinteractive terminal interface. This is possible be-cause SQL is self-contained; i.e., it does not require ahost language in order to be used. For IMS users,Batch Terminal Simulator (BTS) can also be used fortesting application programs containing SQL state-ments.

Relational data bases offer the potential for addi-tional benefits in data base design and applicationdevelopment. One such area is frequently termedsemantic modeling. This refers to the incorporation


of meaning into the formal structure of the database, that is, meaning understood by the system. Anexample of a proposal based on the relational modelis Codd's RM/T work. 10

Data base security. Different approaches to securityare used by IMS and DB2. DB2 provides a layeredapproach to security that allows the installation todistribute control of various functions to differentorganizational units which may then distribute con-trol of certain functions to subunits. IMS installationscan take advantage of such a scheme for distributedauthorization. Data base security in DB2 is enforcedby two approaches: the view mechanism and theGRANT/REVOKE facility.

View definitions are a powerful facility for simplify-ing programming. A view need contain only the datathat a particular application has to deal with. Froma security viewpoint, this facility shields those datathat are irrelevant to a specific user. Security bycontent, in this way, is not specified in proceduralprogram code but is available through the data defi-nition facilities. Moreover, SQL built-in operatorsmay be used in views to restrict some users to suchaggregate data as averages and totals, without allow-ing them to access individual values.

GRANT/REVOKE commands are available to restrictusers to performing specific operations against tablesor views. The command GRANT INSERT ON TABLEEMPLOYEE TO PROGOI allows an application program-mer to insert rows into an existing table. An author-ization may be granted to a user WITH GRANT OP-TION, thus allowing the user to pass on this authorityto other users. Authorization can be restricted tospecific operations on specific tables, columns, androws.

The SQL REVOKE statement is used to take away acertain capability from a DB2 user. For example, thecommand REVOKE UPDATE ON DEPARTMENT FROMPUBLIC illustrates the revocation of the UPDATE au-thority from all users (PUBLIC) on the DEPARTMENTtable, where the system administrator had previouslygranted this authority to all users.

Data base maintenance. After data bases acquireproduction status, changing requirements sometimesdemand modifications to data base structures. Themore frequently a data base structure changes, themore expensive the maintenance activities become.

DASH AND OJALA 171

The reasons for these increased maintenance costsinclude requirements (I) to change definitions, (2)to run certain utilities, and (3) to make programmodifications. Changes to DL/I structures, such as

In 082, maintenance caused by database changes has been simplified.

adding a new segment type, establishing new logicalrelationships, changing pointer schemes, and addinga new secondary index, can require significant main-tenance activities.

In DB2, maintenance caused by data base changeshas been simplified. In one way, changes have alessened effect because all relationships are carriedthrough actual values in the tables and not throughlinks in an explicit data structure. Many changes totables do not require data bases to be unloaded andreloaded. For example, new columns can be addedusing the SQL ALTER TABLE statement in an interac-tive session in TSO.

Also, indexes can be added to an existing tabledynamically, using the SQL CREATE INDEX in the DB2Interactive environment (index-on-the-fly). There isno requirement for running special utilities in an off-line mode against the affected data bases.

View definitions can preserve a previous view of atable against new column additions.

The running of data base maintenance utilities fromDB2 Interactive (DB21) eliminates the need for sched-uled outage of production data bases. The partition-ing facility helps improve availability as does theAREA facility in fast path data bases in IMS.

User data base recovery. The basic principle of database recovery is to maintain duplicated data. Dupli-cation of the data base as well as the changes madeto it is required. This principle is true for both IMSand DB2. In IMS, users periodically duplicate the database (image copy) as well as changes via the DL/I logfacility. Forward recovery is used for both logical

172 DASH AND OJALA

and physical errors, whereas backward recovery (un-doing changes made to the data base) helps solvelogical errors in the data base.

The backup and recovery procedure is subject toerror, because the user must keep track of all imagecopies, logs, and change accumulations. A very use-ful tool in IMS is the Data Base Recovery Control(DBRC), which keeps track of various data sets usedand creates JCL for the various jobs needed in thebackout and recovery process.

The equivalent of the DBRC function in DB2 is pro-vided by the DB2 catalog and the Bootstrap Data Set(BSDS). The various backup and recovery utilities forDB2 are the following: Image Copy (full or partial),Incremental Image Copy, Merge Copy, and the Re-covery utility. The DB2 log becomes the nucleus forthe recovery process. Concepts of active DASD loggingand automatic archiving are incorporated. Figure 5illustrates the recovery scenario with the associateddata sets. The DB2 backup and recovery conceptallows the recovery of a table space, a partition, or agroup of pages. Two utilities are provided to main-tain image copies of tablespaces. The recovery utilitymay be used to recreate a tablespace from an imagecopy and also to log records. Some differences be-tween DB2 and IMS are the following:

• In IMS the base unit for recovery is a data basedata set, whereas in DB2 the base unit of recoveryis a tablespace or part of a tablespace.

• In IMS without DBRC it is possible to do a partialrecovery, i.e., restore a data base data set from animage copy without applying logged changes. Thisis sometimes used for regression tests. In DB2 (andin IMS/VS, Version I, Release 3) a recovery consistsof restoring a data base data set and tablespacefrom an image copy. Thereafter, all logged changesare applied.

• In IMS, index data sets have to be recovered sepa-rately, whereas in DB2, indexes are not recoveredbut rebuilt by using the DROP and CREATE INDEXstatements of SQL.

• In DB2, there is no equivalent for the IMS changeaccumulation utility where data base change rec-ords from various log tapes are merged. The MergeCopy utility of DB2 is used to merge Image Copiesand Incremental Image Copies (IIC) to construct anew full Image Copy or a composite IIC.

• There is no batch backout utility in DB2 as thereis in IMS. If dynamic backout fails, it is necessaryto perform a data base recovery or repair.


End user access to data. One of the major advantagesof the relational model is the ability of the end userto perform unanticipated queries. End users havetwo ways of accessing OB2 data: (1) using OB2 Inter-active (OB21), or (2) using Query Management Facil-ity (QMF). OB2 users in TSO/SPF can choose DB2I andthen select SPUFI for an interactive session with DB2data. SQL statements can be issued for an instanta-neous response of results on the screen. QMF providesa more powerful end user facility to do specializedreporting and aggregating. Users can also specifyreport formats and store them along with the queriesfor repetitive work."

Current IMS users can use the Data Extract (DXT)product to selectively extract from DL/I data basesexisting production data (as well as VSAM and SAMdata) and load them into DB2 format for access viaDB2I or QMF. DXT also takes advantage of the infor-mation in the IBM OB/DC Data Dictionary in prepar-ing for the extract process. The extract approach isuseful where enterprises need to avoid end useraccess directly to production data for performancereasons."

Existing IMS production programs can be modifiedto update OB2 data bases with summary information.The update may take place synchronously, by havingthe program update the data base, or asynchro-nously, by sending the information to a backgroundIMS transaction that can in turn update the DB2 database.

DB2 and IMS attachment facilities from a designperspective

So far we have been describing the use of DB2 in anIMS environment. In the remainder of this paper wediscuss how DB2 and IMS have been designed to worktogether and what IMS installation personnel mustunderstand in order to use DB2. The MVS addressspaces used with DB2 are shown in Figure I.

Attachment overview. OB2 and IMS are connected viaan attachment package. The designers of the OB2-IMS attachment package carefully considered manydesign tradeoffs. The design chosen stresses ease ofuse and flexibility in preference to requiring an in-stallation to predefine all naz-related items to IMS.The attachment between existing DB2 and IMS sys-tems can be installed without an IMS SYSGEN. Also,the attachment package makes use of numerousdefaults to simplify installation and maintenance.Once IMS and OB2 are operational, they connect


Figure 5 Data base recovery cycle

;';'~,;;:'h;:;;e,,"'?" ",-,,";;:;:

TABLE DB2 LOGSPACE

f--

IMAGECOPY

,-J L,L--IMAGE INCREMENTALCOpy IMAGE

COPIES

f-

I IMERGECOPY

IFULLIMAGECOpy

IRECOVERY

automatically and process OB2 requests from IMSwithout operator assistance. Operator commands areprovided to monitor the status of the connectionbetween on-line message regions and DB2. In addi-tion, records are produced that allow the installationto monitor and account for IMs-related activity withOB2. The capability exists for multiple DB2S to con-nect to a single or multiple IMS systems in one host.

Defining DB2 to an existing IMS system. We nowdescribe the steps and considerations that installationpersonnel must understand in order to install anduse DB2 in an IMS environment. When DB2 and IMS

DASH AND OJALA 173

have been installed, the installation personnel per-form the following three steps:

• Define a subsystem member in IMS.PROCLIB. Thatmember specifies the DB2 system(s) that can con-nect to a specific IMS.

• Place the name of the subsystem member on theexecute statement of the IMS control region JCLprocedure.

• Place a DFSESL DD card specifying the DB2 libraryinto the IMS control and each dependent regionJCL.

The default condition allows any IMS region to proc-ess DB2 transactions. The attachment code resides ineach IMS region and is loaded at message region

An IMS application program mayaccess and change IMS and DB2

resources.

initialization. For Batch Message Processing (BMP)regions, the attachment code is loaded when anapplication program issues the first SQL call. Theinstallation may control which message regions proc-ess DB2 transactions by using IMS class scheduling.

Operating IMS with DB2. IMS and DB2 are bothstarted by an MVS operator command. They can bestarted in any order, and they automatically connectwhen both systems are operational. No additionalMVS or IMS operator action is required to activate theconnection between the systems for normal opera-tions.

Once the connection is operational, the connectionmay be stopped by an IMS or DB2 command, eitherin quiesce or force manner. Quiesce allows applica-tion programs accessing DB2 to terminate before theconnection is broken. The STOP DB2 MODE(FORCE)command causes work in progress to be abnormallyterminated. The DB2 stop force command can beused after a quiesce request. A wait-for-input BMP orother programs may be connected to DB2, but theymay be waiting for another message or issuing IMS

174 DASH AND OJALA

requests. The STOP DB2 MODE(QUIESCE) commandrequest waits for these programs to terminate. It maybe necessary to terminate connected IMS regions viaan IMS stop region command. The DB2 stop forcecommand can also be used to break the connection.

IMS provides commands to control and monitor theconnection between IMS and DB2. There are also DB2-provided commands to control and monitor externalconnections. The IMS command jSSR allows IMS op-erators to issue DB2 commands. A DB2 commandentered by an IMS operator must pass both IMS andDB2 security checking. The automated operator fa-cility of IMS may also be used to submit DB2 com-mands from IMS.

Security considerations between IMS and DB2. Atransaction scheduled by IMS must pass IMS securitychecks first and then go through the DB2 authoriza-tion, if an SQL call is issued. The security identifica-tion used by DB2 depends on the security specifiedfor IMS.

For IMS message-driven programs, the authorizationID is the sign-on name if IMS is using sign-on author-ity. Otherwise, the authorization ID is the logicalterminal name. For IMS non-message-driven pro-grams, the authorization ID is the name of the userspecified on the JOB card, if the Resource AccessControl Facility (RACF) is present. Otherwise theProgram Specification Block (PSB) name is used.

Coordinated recovery. An IMS application programmay access and change IMS and DB2 resources. IMSand DB2 have coordinated recovery, which meansthat the status of changes to IMS and DB2 resourcesmade by an IMS application program is consistent.The changes are either committed or aborted in bothIMS and DB2. If a failure occurs in the IMS applicationprogram, in the IMS subsystem, in the DB2 subsystem,or in MVS, the resources involved are placed in aconsistent state. DB2 provides utilities to recover fromdisk media problems. The utilities are similar infunction, but operate independently of the IMS utili-ties, as has already been discussed in the section onuser data base recovery.

Application design considerations. An applicationprogram issuing SQL calls must be precompiled usingthe DB2 precompiler to create a Data Base RequestModule (DBRM). The DBRM is the input to the DB2BIND process which produces a DB2 application plan(or simply plan) that contains an optimized accesspath for each SQL statement. Besides the access path,


the plan also contains the tables to be accessed andthe appropriate locking information. The applicationprogram must be compiled and then link-edited withthe IMS Release 3 language interface module.

When IMS schedules an application program, theneeded IMS resources are available. The DB2 re-sources, however, mayor may not be present, be-cause the connection between an application pro-gram and DB2 occurs only when the program issuesthe first SQL call. The DB2 plan name, which isassociated with the application program, is passedby the IMS attached to DB2 at this time. It is possiblethat the DB2 subsystem is not operational or the planrequested is not valid. To handle such possibilities,the installation can allow three options to the appli-cation program. The options, described in the follow-ing paragraphs, can be specified for the entire IMSsystem, on the basis of IMs-dependent regions, or onthe basis of application program load modules.

The first option (the default) is for the applicationprogram to receive an SQL return code indicating theerror. This allows the application program to notifythe terminal operator that an error has occurred.

The second option is to back out any activity theprogram might have performed against DL/I, requeuethe message, and prevent the transaction from sched-uling until the problem is fixed. The transaction mustbe restarted by the operator when the problem isfixed. This option is similar to what IMS does whena PSB or IMS data base is not available. The messageis not lost.

The third option is to abnormally end the program,back out any DL/I activity, and discard the message.

Also, at the first SQL call, DB2 authorization checkingis performed. If the user is not authorized, the appli-cation program receives an SQL error code indicatingthe authorization error.

Currently in DB2, the size of a DB2 plan is directlyproportional to the number and complexity of SQLstatements in that application program. Also, DB2obtains locks on the resources specified in the plan.Thus, it is recommended to have small-size programsperforming specific functions.

DB2 uses the IMS Resource Lock Manager (IRLM) forlocking. IMS can use program isolation locking orIRLM locking. An application program referencingboth DL/I and SQL resources can end up with thefollowing situations regarding deadlock detection:


• A true deadlock may be detected between multipleprograms referencing DL/I resources.

• A true deadlock may be detected between multipleprograms referencing DB2 resources.

• A potential deadlock between multiple programsreferencing both DL/I and DB2 resources is detectedonly by an IRLM time-out. The time-out value is aDB2 installation parameter, and, if set too small,that value may give false deadlock conditions. Theinstallation should determine whether applicationprograms will access both DL/I and DH2 data basesand set the time-out value appropriately.

IMS and DB2 monitoring. IMS provides informationabout DB2 via the Data Communication (DC) moni-

DB2 is designed to exploit the 31·bitaddressing architecture of MVS/XA.

tor. The new monitor records contain informationabout each call to DB2, induding the time when thecall started and when it ended.

DB2 provides a number of tools that monitor storagespace, tables, and application usage. For each newmessage processed by IMS, or at the termination ofan application program, a DB2 accounting record iswritten to SMF. DB2 accounting keeps track of elapsedtime, CPU time, SQL calls, locking information, bufferpool information, application program terminationstatus-all on a user basis. The record also containsthe user m (authorization m), the DB2 plan name,the IMS Partition Specification Table (PST) number,the IMS PSB name. the IMS subsystem name, and atime stamp. The installation can use these tools todetermine the performance of IMS application pro-grams accessing DB2 tables.

MVSjXA considerations. DB2 is designed to exploitthe 3I-bit addressing architecture of MVS/XA, but itcan also run on MVS/370, which uses 24-bit address-ing. The MVS/370 24-bit addressing range is up to 16megabytes, whereas the 31-bit addressing range ofMVS/XA is extended to 2 gigabytes. Programs oper-ating in 24-bit addressing mode can access infor-mation up to the 16-Mb line only.

LJASH ANLJ OJALA 175

The majority of DB2 code and control blocks in MVS/XA have moved above the 16-Mb line, and themajority of DB2 Common System Area (CSA) usagehas moved to the extended CSA above the 16-Mbline. Thus, a DB2 MVS/XA system uses less CSA spacebelow the line than a comparable non-MVS/XA DB2system. Another benefit of running DB2 in the MVS/XA environment is that an installation can increasethe size of certain critical DB2 storage pools to handlemore users and tune the system to be more respon-sive.

In the MVS/XA environment, DB2 exploits 3 l-bit ad-dressing while communicating with IMS running ina 24-bit mode. An IMS application program contin-ues to operate in a 24-bit mode, because IMS doesnot support the 3 I-bit application call interface toDL/I or SQL.

Concluding remarks

In this paper, we have looked at DB2 from an IMSviewpoint. In the course of describing various facetsof this new environment, we have identified manypotential advantages that DB2 can offer to the IMSuser.

One question, however, remains: How do these usersdecide which applications to develop using DB2 andwhich to develop using DL/I? For the on-line part ofthe application, IMS/DC facilities are used; but for thedata base part some selection criteria (between DB2and DL/I) should exist. Unfortunately the dividingline between relational and nonrelational data baseapplications is not very sharp. Many applicationsmay in fact be developed using both types of database management systems.

A considerable number ofapplications will continueto be best served by a nonrelational DBMS like IMS/DB. The nature of such applications is that they areusing predefined and stable data base structures in arepetitive manner. For these applications, perform-ance considerations and detailed tuning facilitiesmay be more important than flexibility in changingand accessing data.

DB2 data bases tend to be more suited for applicationswhere there is a clear need to use different andvarying relationships in the data and where ease ofchange and high-level access to data is the moreimportant aspect.

As experience with DB2 application systems growsand the implementations of such systems mature, it

176 DASH AND OJALA

is likely that more and more applications will befound to be best served by relational data base sys-tems. In time, more and more environments willdiscover that flexibility in access and data basechange are key factors in successful data base growthand evolution.

Cited references

I. J. P.Strickland, P.P. Uhrowczik, andV. L. Watts, ~IMS/VS:An evolving system," IBM Systems Journal 21, No.4, 490-510 (1982).

2. E.F.Codd, "Arelational model for large shared databanks,"Communications ofthe ACM13, No.6,377-387 (June 1970).

3. D.J. Haderle andR. D.Jackson, "IBM Database 2overview,"IBM Systems Journal 23, No.2, 112-125 (1984, this issue).

4. S.Kahn, "An overview ofthree relational database products,"IBM Systems Journal 23, No.2, 100-111 (1984, this issue).

5. C. Beeri, P.A. Bernstein, andN.Goodman, ~A sophisticatedintroduction to database normalization theory," Proceedingsofthe 4th International Conference on Very Large Data Bases,West Berlin (September 1978), pp. 113-124; available fromtheAssociation for Computing Machinery, 1133 Avenue oftheAmericas, New York, NY 10036.

6. C. J.Date, An Introduction to Database Systems (3rd Edition),Addison-Wesley Publishing Company, Reading, MA (1981),pp. 237-272.

7. W. Kent, ~A simple guide to five normal forms in relationaldatabase theory," Communications of the ACM 26, No.2,120-125 (February 1983).

8. IBM DATABASE 2: Application Programming Guide forIMS/VS Users, SC26-4079, IBM Corporation; availablethrough IBM branch offices.

9. E. F. Codd, "Extending the database relational model tocapture more meaning," ACM Transactions on Database Sys-tems 4,No.4, 397-434 (December 1979).

10. E. F. Codd, "Relational database: A practical foundation forproductivity," Communications of the ACM 25, No.2, 109-117 (February 1982).

II. Query Management Facility: General Information Manual,GC26-407I , IBM Corporation; available through IBM branchoffices.

12. Data Extract: General Information Manual. GC26-4070, IBMCorporation; available through IBM branch offices.

General references

C. J. Date, An Introduction to Database Systems: Volume II,Addison-Wesley Publishing Company, Reading, MA (1983).C. J. Date, "Relational database: Some topics for investigation,"GUIDE 54, Anaheim, CA, May 1982, Session MP-29.IBM DATABASE 2: General Information Manual, GC26-4073,IBM Corporation; available through IBM branch offices.IBM DATABASE2:Data Base Administration Guide, SC26-4077,IBM Corporation; available through IBM branch offices.IBM DATABASE 2:Relational Concepts, 0024-1581, IBM Cor-poration; available through IBM branch offices.IBM DATABASE 2: Systems Planning and Administration Guide,SC26-4085, IBM Corporation; available through IBM branch of-fices.


Reprint Order No. G321-5216.

Jnan R. Dash IBM General Products Division, Santa TeresaLaboratory, P.O. Box 50020, San Jose, California 95150. Mr.Dash is an advisory planner in DB2 development. In 1974, hejoined IBM Canada at Toronto, where he held several positions inHeadquarters information systems and was responsible for design-ing and implementing several data base application systems. Later,he taught general data base and IMS courses to customers at theCanadian Advanced Education Center in Montreal. Outside IBM,he has worked as senior programmer analyst in Canada and database consultant in the U.S., where he was involved in teachingIMS and designing data base applications. Since 1981, he has beenpart of the data systems planning organization. His current re-sponsibility includes the DB2 product strategy. Mr. Dash receiveda B.Sc. in mechanical engineering from India and an M.A.Sc. insystems design from the University ofWaterJoo, Canada, in 1973.

Robert N. Ojala IBM General Products Division, Santa TeresaLaboratory, P.O. Box 50020, San Jose, California 95/50. Mr.Ojala is an advisory programmer in the advanced data base groupat the Santa Teresa Laboratory. He received a B.S. degree inbusiness from the University of Minnesota in 1964. After gradua-tion, Mr. Ojala participated in the design and implementation ofmany on-line systems, including message switching, order collec-tion, engineering document control, and engineering data collec-tion. From 1969 until he joined IBM in 1978, Mr. Ojala was anIMS systems programmer and IMS systems programming man-ager. He was also very active in IMS application design and in theIMS project at SHARE. At IBM, Mr. Ojala is one of the designersand implementers of the IMS attach package. He has also workedon the design of other components of DB2, including those forstatistics and accounting.

IBM SYSTEMS JOURNAL, VOL 23, NO 2, 1984 DASH AND OJALA 177

Documents

IBM Database 2 in an Information Management System environment