IMS DB/DC Workshop

(1)

IMS DB/DC

Workshop

Design of hierarchical DBs

or

A basic presentation about IMS DB/DC…

Presented by

Dipl. Ing. Werner Hoffmann

EMAIL:

or

[email protected]

(2)

Date: 21.06.2007 IMS_DB_01.ppt Page: 1

IBM Mainframe

IMS DB/DC

Workshop

Design of hierarchical

DBs

or or

A basic presentation about IMS DB/DC

…

June 2007

June 2007 ––1st Version1st Version

presented by

Dipl.

Ing

. Werner Hoffmann

EMAIL:

pwhoffmann @ t

-

online.de

A member of IEEE and ACM Mainframe

Please see the notes pages for additional comments. Please see the notes pages for additional comments.

(3)

2

IMS_DB Page: 2

Date: 21.06.2007

Agenda

I - Overview Workshop Sessions

II - IMS Overview

III - IMS Hierarchical Database Model

1: Initial Session

2: Basics

3: Hierarchical Access Methods

4: Logical Relationships/ Logical Databases

5: Indexed Databases

6: Data Sharing Issues

7: Implementing IMS Databases

IV - IMS Transaction Manager – Basics V - IMS Database Design

VI - IMS DB Implementation (DB Admin.) …

Here is the agenda.

Part II is an initial session about IMS.

Part III is the main part of this workshop: IMS Hierarchical Database Model. Note: Part IV…VI is currently not available.

(4)

IMS_DB Page: 3 Date: 21.06.2007

Let’s now start the sessions...

Worksh

_op

The worl_{d depend} s on it

(5)

1

Date: 21.06.2007 IMS_02.ppt Page: 1

IBM Mainframe

IMS DB/DC

Presentation

(Workshop)

Part II: IMS Overview

June 2007

June 2007 ––1st Version1st Version

presented by

Dipl.

Ing

. Werner Hoffmann

EMAIL:

pwhoffmann @ t

-

online.de

A member of IEEE and ACM Mainframe

Please see the notes pages for additional comments. Please see the notes pages for additional comments.

Welcome to the presentation (initial presentation/workshop) called “IMS DB/DC".

(6)

IMS_DB/DC Page: 2 Date: 21.06.2007

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

DB –Design Workshop: Point of Interest Note:

Here is the Agenda for the session part II: IMS Overview.

In this session I like to speak about:

1. Term of IMS

2. Overview of the IMS product 3. An initial example

4. IMS DB and IMS TM 5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends 7. Summary

(7)

3

IMS_DB/DC Page: 3

Date: 21.06.2007

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(8)

Term of IMS…

IBM’s

Information Management System

(IMS)

is a joint

hierarchical database

and

information management

system with

extensive

transaction processing

capability.

Data Communication

Manager (DC) or IMS TM

Database Manager (DB)

Note: IMS DB/DC is not “IP Multimedia Subsystem (IMS)”!

IMS/ESA is an IBM program product that provides transaction management and database management functions for large commercial application systems. It was originally introduced in 1968. There are two major parts to IMS, a data communication manager (DC) and a Database Manager (DB).

IMS TM is a message-based transaction processor that is designed to use the OS/390 or MVS/ESA environment to your best advantage. IMS TM provides services to process messages received from the terminal network (input messages) and messages created by application programs (output messages). It also provides an underlying queuing mechanism for handling these messages.

IMS DB is a hierarchical database manager which provides an organization of business data with program and device independence. It has a built in data share capability.

It has been developed to provide an environment for applications that require very high levels of performance, throughput and availability. The development has been designed to make maximum use of the facilities of the operating system and hardware on which it runs, currently OS/390 or z/OS on S/390 or zSeries hardware.

Note: IBM Information Management System (IMS DC/DB) is one of the world’s premier software products. Period!

IMS is not in the news and is barely mentioned in today’s computer science classes, but it has been and, for the foreseeable future, will be continue to be, a major, crucial component of the world’s software

(9)

5

IMS_DB/DC Page: 5

Date: 21.06.2007

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(10)

DB2

Overview of the IMS product

ACF/ VTAM SNA Network MVS TCP/IP TCP/IP Network ITOC MQ Series APPC/ MVS

IMS System

Services

Transaction Management Database Manager IMS Message Queues DB2 Tables IMS Logs MVS Console

IMS

Databases

IMS consists of three components, the Transaction Manager (TM) component, the Database Manager (DB) component, and a set of system services that provide common services to the other two components. The functions provided by these components are described in more detail in the following chapters.

The Transaction Manager and Database Manager components can be ordered and paid for separately if the functions of the other component are not required. The appropriate system services are provided for the component ordered.

As IMS has developed, new interfaces have been added to meet new business requirements. It is now possible to access IMS resources using a number of interfaces to the IMS components. IMS applications can also access databases managed by IBM’s DB2 relational database manager.

IMS has been developed so that each new release of IMS is upwardly compatible, so investment in existing applications is preserved. To accommodate the changing requirements of IT systems, many new features have been added.

This has also resulted in a number of IMS features being wholly or partially superseded by newer features normally providing better functionality. This should be kept in mind when looking at IMS documentation. The interfaces to IMS are pictured in above foil.

Applications written to use IMS functions can be written in a number of programming languages. Programming languages currently supported are Assembler, C, COBOL, Pascal, PL/I and REXX. The IMS resources are accessed by the application by calling a number of standard IMS functions. Applications access these functions through a standard application programming interface (API) for both the Transaction Manager and Database Manager components.

This interface is normally referred to as Data Language I (DL/I).

IMS Transaction Manager

The IMS Transaction Manager provides users of a network with access to applications running under IMS. The users can be people at terminals or workstations, or other application programs, either on the same OS/390 system, on other OS/390 systems, or on other non-OS/390 platforms.

A transaction is a specific setup of input data that triggers the execution of a specific business application program. The message is destined for an application program, and the return of any results is considered one transaction.

Network access to IMS Transaction Manager was originally via IBM’s systems, which evolved into the Network Architecture (SNA), as implemented in the VTAM program product. Also, there are now a number of ways to access IMS resources via networks using the Transmission Control Protocol / Internet Protocol (TCP/IP) network product.

IMS Database Manager

The IMS Database Manager provides a central point of control and access for the data (excluding DB2 Tables) that is processed by IMS applications. The Database Manager component of IMS supports databases using IMS’s own hierarchic database model. It provides access to these databases from applications running under the IMS Transaction Manager, the CICS transaction monitor (now known as Transaction Server for OS/390 or z/OS), and OS/390 or z/OS batch jobs. It provides facilities for securing (backup/recovery) and maintaining the databases. It allows multiple tasks (batch and/or online) to access and update the data, while retaining the integrity of that data. It also provides facilities for tuning the databases by reorganizing and restructuring them.

The IMS databases are organized internally using a number of IMS’s own internal database organization access methods. The database data is stored on disk storage using the normal operating system access methods.

IMS system services

There are a number of functions that are common to both the Database Manager and Transaction Manager: • Restart and recovery of the IMS subsystems following failures.

• Security — controlling access to IMS resources.

• Managing the application programs — dispatching work, loading application programs, providing locking services. • Providing diagnostic and performance information.

• Providing facilities for the operation of the IMS subsystems.

• Providing an interface to the other OS/390 or z/OS subsystems that the IMS applications interface with.

Note: The magnifier shows the main point of interest.

IMS as shown is available as both a transaction manager (IMS TM) and a database manager (IMS DB), which can be used individually or together. IMS DB can be used with other transaction managers, such as IBM’s Customer Information Control System (CICS). IMS TM can be used with other database managers, such as DB2 Universal Database for OS/390 or z/OS.

(11)

7

IMS_DB/DC Page: 7 Date: 21.06.2007 JAVA Batch Processing MPP MPP

IMS control region

MPP Application Program JAVA MPP IFP Application Program Fath Path DBs Logs

Network

IRLM Region

IMS

System

DL/I Separate Address Space DBRC Region

Full Function DBs RECONs IMS Message Queues

IMS Libraries Application Region Address Spaces System Address Spaces Control Region Address Space Dependent Region Address Spaces Legend: MPP MPP BMP Application Program Message Processing

The control region (CTL) is an MVS address space that can be initiated through an MVS start command, or by submitting JCL. The IMS control region provides the central point for an IMS subsystem.

It provides the interface to the SNA network for the Transaction Manager functions, and the Transaction Manager OTMA interface for access to non-SNA networks. It provides the interface to OS/390 for the operation of the IMS subsystem. It controls and dispatches the application programs running in the various dependent regions. The control region provides all logging, restart and recovery functions for the IMS subsystems. The terminals, message queues, and logs are all attached to this region, and the Fast Path database data sets are also allocated by the CTL region address space.

A type 2 supervisor call routine (SVC) is used for switching control information, message and database data between the CTL region, and all other regions, and back.

There are three different types of IMS control region, depending on whether the Database Manager and/or Transaction Manager components are being used. These three control region types are:

• DB/DC — This is a control region with both Transaction Manager and Database Manager components installed. It provides the combined functionality of both the other two types of control region. Note that when a DB/DC region is providing access to IMS databases for a CICS region, it is referred to in some documentation as providing DBCTL services, though it may in fact be a full DB/DC region and not just a DBCTL region.

• DBCTL — This is a control region with only the Database Manager component installed. This can provide IMS database functions to batch application programs connected to the IMS control region (BMPs), to application transaction’s running in CICS Transaction Manager regions, and to other OS/390 address spaces (for example, DB2 stored procedures) via the Open DataBase Access (ODBA) interface.

• DCCTL — This type of control region has only the Transaction Manager component installed. It provides access to the IMS message queues for IMS applications running in the MPP, IFP and BMP application address spaces described in the foil.

IMS system dependent regions

The control region will have a number of dependent system address spaces (dependent regions) to provide some of the services of the IMS subsystem.

These dependent regions are automatically started by the IMS control region as part of its initialization, and the control region will not complete initialization until these dependent regions have started and connected to the IMS control region.

Every IMS control region has a DBRC region. The other two dependent system address spaces are optional, depending on the IMS features used. For the DL/I, separate address space options can be specified at IMS initialization.

DBRC region

This address space contains the code for the DBRC component of IMS. It processes all access to the DBRC recovery control data sets (RECON). It also performs all generation of batch jobs for DBRC, for example, for archiving the online IMS log. All IMS control regions have a DBRC address space, as it is needed, at a minimum, for managing the IMS logs.

DLI separate address space (DLISAS)

This address space performs most data set access functions for the IMS Database Manager component (except for the fast path DEDB databases). The FF database data sets are allocated by this address space.

It also contains some of the control blocks associated with database access and some database buffers. This address space is not present with a DCCTL system, since the Database Manager component is not present. For a DBCTL control region, this address space is required, and always present.

For a DB/DC control region, you have the option of having IMS database accesses performed by the control region, or having the DB/DC region start a DL/I separate address space. For performance and capacity reasons, you would normally use a DLI separate address space.

Common queue server (CQS) address space

This is used by IMS DCCTL and DB/DC control regions only if they are participating in an OS/390 sysplex sharing of the IMS message queues. It provides access to the shared IMS message queues in the sysplex coupling facility, which replace the IMS messages queue data sets on DASD. The CQS address space is only available with IMS Version 6 onwards.

Application dependent regions

IMS provides dependent region address spaces for the execution of system and application programs that use the services provided by the IMS. The previously discussed region types (DBRC and DLISAS) are automatically started by the IMS control region.

These application dependent regions are started as the result of JCL submission to the operating system by the IMS CTL region, following an IMS command being entered. Once they are started, the application programs are scheduled and dispatched by the control region. In all cases, the OS/390 address space executes an IMS region control program. The application program is then loaded and called by the IMS code.

There can be up to 999 application dependent regions connected to one IMS control region, made up of any combination of the following dependent region types: • Message processing region (MPP)

• IMS Fast Path region (IFP) • Batch message processing region (BMP) • DBCTL thread (DBT)

• Other utility type regions, such as HSSP processing (BMH) and Fast Path utility program (FPU)

Internal Resource Lock Manager (IRLM)

There is one final address space that is, optionally, used with IMS. This is the IRLM address space, and is only needed if you are going to use block level or sysplex data sharing for the IMS databases. The IRLM address space is started before the IMS control region, via the MVS start command. The IMS control region, if the start up parameters specify use of IRLM, connects to the IRLM specified on startup, and will not complete initialization until connected.

There is one IRLM address space running on each OS/390 system to service all IMS subsystems sharing the same set of databases. IRLM is delivered as an integral part of the IMS program product, though as mentioned, you do not have to install or use it unless you wish to perform block level or sysplex data sharing. IRLM is also used as the (only) lock manager for the DB2 database program product, and for DB2 you must install IRLM. Because the tuning requirements of IMS and DB2 are different, and conflicting, you are recommended not to use the same IRLM address space for IMS and DB2.

(12)

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(13)

9

IMS_DB/DC Page: 9

Date: 21.06.2007

A Typical Manual System:

Loan Application

Customer eXtendBank Loan Officer 1. Fill in Loan Application at Loan Dept

2. Loan Officer enters loan information (3270 emulator) IMS 3. Requests FAX Credit Report 5. Makes a decision on Loan Application 4. Makes decision as

to whether this Loan application needs approval. 6. Loan Officer reserves Funds 7.Sends email to Assess Business Risk – (Government Watch List) 8. Notifies customer Business Analyst (Rules change frequently) Developer Loan Officer

Loan Officer Bank Manager Loan Officer Loan Officer Loan Officer

Application Server

Steps:

1. Customer has to come into the bank to fill out a loan application. 2. Loan officer enters the relevant data into the system.

3. Loan officer requests a a credit report and receives a fax with the information.

4. Loan officer decides that this loan needs to be reviewed by a manager before it can be approved or rejected.

Business Analyst may need to change the rules frequently and have the developers change the system.

5. Bank Manager makes the decision to approve the loan 6. Loan officer reserves the funds in the system.

7. Loan officer sends an email to check government watch lists to minimize risk. 8. Loan officer finally notifies customer that the loan was approved.

The process is very human-oriented and can have many wait periods while people make decisions and pass information.

(14)

Automated

*) *) *) *)

computer assisted

Loan Application Process

Start Create Loan App

Credit Check Pre-approved? Loan Officer Approval Approve Reserve Funds Assess Loan Risk

Too Risky?

Send Rejection Email Send Confirmation Email

End Service (Web) Service (IMS) Service (J2EE) Service (Web) Service (JavaMail) Service (JavaMail)

1

2

YES NO NO YES YES NO Legend Services Business Rules

The new version of the business process is very automated.

•User can start the loan application by entering data in the Create Loan Web Application, which stores the data in the same repository as before.

• The credit check can be done as soon as we know they are going to really submit an application. • Business rules can decide whether they are pre-approved or not.

• If not, then a Loan Officer can review the application. If they don’t approve, a rejection e-mail goes out.

• If the Loan Officer approves, funds are reserved automatically by a service.

• The Loan Risk is assessed by a service and an e-mail is finally sent letting the customer know the results.

Human interaction has been reduced, reducing the chances for errors in the process and greatly speeding up the process.

Services and business rules can be changed quickly to adapt to changing business conditions.

There could also be “undo” services created for things like reserving the funds, when the loan risk comes back positive.

(15)

11

IMS_DB/DC Page: 11

Date: 21.06.2007

Scenario 1:

Create an IMS Service

RetrieveCustInfo Import binding=<“EIS”>

Create Loan App Service (IMS)

1

CreateLoanApp Impl = “Java” IMS Connector for Java

IMS transaction is invoked and retrieves applicant information and returns it via the IMS resource adapter ACF/

VTAM IMS DB/DC

IMS DBs Classical IMS DB/DC environment:

To implement a complex business process such as the one showed previously IBM’s WebSphere Integration Developer (WID) is recommended as the development environment of choice.

In scenario 1, one of the steps in creating the loan application is retrieving the applicant information to be fed into the Pre-Approved business rule. You could use the assembly editor in WID to create an import

component from an IMS transaction using the IMS resource adapter.

Imports and exports define a module's external interfaces or access points. Imports identify services outside of a module, so they can be called from within the module. Exports allow components to provide their services to external clients.

There are two levels of imports and exports. An application on an Enterprise Information System (EIS) can be brought into a module as an import or an export component; this level is a system level import. A system level import lets your application access applications on EIS systems as if they were local components. An

application on an EIS system can be imported into a module and represented as an import service component. This is what would be created.

There is also a module level import and export, which lets modules access other modules.

Imports and exports require binding information, which specifies the means of transporting the data from the modules. An import binding describes the specific way an external service is bound to an import component. And it is created when WID generates the import component. The bindings created are of an EIS type. An export binding describes the specific way a module's services are made available to clients.

In this scenario the RetrieveCustInfo import component would be invoked by the CreateLoanApp component to see if the applicant exists and if so, to retrieve his/her information. It is a two-way or request-response interaction. The following slide will show what the RetrieveCustInfo import would look like in WID.

(16)

Scenario 2:

Create an IMS Web Service import

CreditCheck Import

binding = “WebService”

Credit Check Service (Web)

2 LoanApp

Impl = “BPEL”

…

Application IMS DB IMS Connect IMS Connector for Java IMS DB DB2 Application Server Application Application IMS TM

Do you remember the web service that was created in IRAD? Well this web service could be imported into WID as an import component as well, with a Web service binding. A Web service import binding allows you to bind an external Web service to an import component. In our scenario, this web service could invoke an IMS transaction that returns a person’s credit rating. This

information could then be used to determine whether or not a person was pre-approved.

Application projects in the development environment (e.g. IRAD or WID) can easily be exported in the form of Enterprise Application Archive files which are then readily deployable to any of the WebSphere family of applications servers.

After deploying IC4J on the application server you can run your apps that can be invoked from various clients. These applications are accessible from a wide variety of devices, from telemarketers’ terminals to ATMs, from suppliers’ terminals to home PCs, from hand-held devices and point of sale terminals. All providing secure, seamless access to your enterprise applications and data. Your customers are able to use your Web-enabled applications anywhere in the world to invoke business transactions through WebSphere Application Server, IMS Connector for Java, IMS Connect and IMS TM to access your enterprise data stored in IMS and DB2 databases.

(17)

13

IMS_DB/DC Page: 13

Date: 21.06.2007

IMS TM &

the World Wide Web

3270 Terminal 1,2 VTAM IMS MPP 3 4,5 8,9 7 6 NCP Web Browser 1,2 Web Server CGI Program 3 4,5 8,9 7 6 TCP/IP TCP/IP Program to Program Communications

(18)

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(19)

15

IMS_DB/DC Page: 15

Date: 21.06.2007

IMS is a Database Management

System – IMS DB

ORDER DETAIL/PART SHIPMENT STOCK

Logical Database

Physical Databases

DETAIL STOCK PART STOCK ORDER DETAIL SHIPMENT PART Physical DB ORDER Physical DB IX-ADDR Logical Relationship Secondary Index Source Target concatenated segment

ORDER

STOCK

DEALER

STOCK

MODEL

ORDER

Hierarchical Database Model

Level 1 2 3 Parent Child Child Child Twins DB Segment Type Segments are Implicit joined with each other Siblings Root Segment Dependent Segment Key Key Key Key

Hierarchical Database Model.

IMS uses a hierarchical database model as the basic method of storing data. Unlike the relational model used by DB2 UDB, which was result of theoretical work, the hierarchical model was arrived at as a pragmatic way of storing and retrieving data quickly while using as few computer resources as possible.

In the hierarchical model individual data types are implemented as segments in the hierarchical structure. A segment is the smallest amount of data that can be transferred by one IMS operation, is uniquely defined, and something about which you can collect information (data fields).

The hierarchical structure is based on the relationship between the segments and the access paths that are required for applications.

IMS uses the term database slightly differently than other DBMSs. In IMS, a database is commonly used to describe the implementation on one hierarchy, so that an application would normally access a large number of IMS databases. Compared to the relational model, an IMS segment is approximately equivalent to a table and an IMS database implements the referential integrity rules.

The following list contains a little bit more detailed description of the various segment types and their interrelations within a hierarchical data structure:

•The segment on the top of the structure is the root segment. Each root segment normally has a key field that serves as the unique identifier of that root segment, and as such, of that particular database record. There is only one root segment per database record.

•A dependent segment relies on the segments above it in the hierarchy for its full meaning and identification. •A parent/child relationship exists between a segment and its immediate dependents.

•Different occurrences of different types under the same parent are called sibling segments. •A single segment can be a dependent and a child simultaneously.

IMS uses sequence fields to identify and to provide access to a particular database record and its segments. Each segment normally has one field that is denoted as the sequence field. The sequence fields should be unique in value for each occurrence of a segment type below its parent occurrence. However, not every dependent segment type must have a sequence field defined.

Physical Databases.

IMS DB is a DBMS that helps you organize business data with both program and device independence.

Hierarchical databases and data manipulation language (DL/I calls) are at the heart of IMS DB. Data within the database is arranged in a tree structure, with data at each level of the hierarchy related to, and in some way dependent upon, data at higher level of the hierarchy. In a hierarchical database, data is stored within the database only once. With IMS DB, you can:

•Maintain data integrity. The data in each database is guaranteed to be consistent and guaranteed to remain in the database even when IMS DB is not running. •Define the database structure and the relationships among the data elements.

•Provide a central point of control and access for the IMS data that is processed by IMS applications. •Perform queries against the data in the database.

•Perform database transactions (inserts, updates, and deletes) as a single unit of work so that the entire transaction either occurs or does not occur. •Perform multiple database transactions concurrently with the results of each transaction kept isolated from the others.

•Maintain the databases. IMS DB provides facilities for tuning the databases by reorganizing and restructuring them.

In addition to the basic hierarchical data structure described so far, IMS provides two additional methods for defining access paths to a data segment:

•Logical relationships. A logical relationship is a user-defined path between two independent segments. Logical relationships allow a logical view to be defined of one or more physical databases. To the application, the logical relationship looks like a single database.

•Secondary Indexes. Secondary Indexes provide an alternate access path for full function databases by using a root or dependent segment as the entry location to the database record in one physical database.

Logical Database.

Through logical relationships, IMS provides a facility to interrelate segments from different hierarchies. In doing so, new hierarchical structures are defined that provide additional access capabilities to the segments involved. These segments can belong to the same database or to different databases. This logical database allows presentation of a new hierarchical structure to the application program. Although the connected physical databases could constitute a network data structure, the application data structure still consists of one or more hierarchical data structures.

In the shown logical database the DETAIL/PART segment is a concatenated segment. It consists of the logical child segment (DETAIL) plus the logical parent segment (PART). You may want to use logical relationships for the following reasons:

•They provide an alternate access path for the application.

•They provide an alternate hierarchical database structure for an application so that different applications, or part of applications, can have a view of the physical databases that most closely matches that application’s view of the data.

(20)

IMS is a Database Management

System

A

B C

D E

IMS DB is organized hierarchically

To optimize storage and

retrieval

To ensure integrity and

recovery

A Database is a collection of interrelated data items,

stored once and organized in a form for easy retrieval.

A Database Management System is a collection of

programs for storing organizing, selecting, modifying,

and extracting data from a database.

IMS is a database and transaction management system. A Database is a collection of interrelated data items, stored once and organized in a form for easy retrieval. A Database Management System is a collection of programs for storing organizing, selecting, modifying, and extracting data from a database. An IMS database is organized hierarchically with levels of data, each dependent on the higher level. an IMS Database

Management system organizes the data in different structures to optimize storage and retrieval, and ensure integrity and recovery.

(21)

17

IMS_DB/DC Page: 17

Date: 21.06.2007

Program Structure

–

Data Flow

(Traditional)

Application Program – (Batch)

PROGRAM ENTRY DEFINE PSB (PCB AREAS)

GET INPUT RECORDS FROM INPUT FILE CALLS TO DL/I DB FUNCTIONS

RETRIEVE INSERT REPLACE DELETE

CHECK STATUS CODES PUT OUTPUT RECORDS TERMINATION IOAREA Prefix Segment visible in Application program Segments Segments to/from to/from databases databases E N T R y E X I T DLI modules Call from from DLI PCB-Mask IO AREA PSB

Application programs can interact with IMS DB in two ways: •Traditional applications can use the DL/I database call interface.

•JAVA applications can use the IMS Java function’s implementation of JDBC or the IMS Java hierarchical interface, which is a set of Java classes that you can use in Java that are similar to DL/I calls.

In this foil the traditional DL/I call interface is shown. There are to basic types of DL/I application programs: •Direct access programs,

•Sequential access programs.

A DL/I application program normally processes only particular segments of the IMS databases. The portion that a given program processes is called an application data structure . This application data structure is defined in the program specification block (PSB). An application data structure always consists of one ore more hierarchical data structures (PCB), each of which is derived from a DL/I physical or logical database.

During initialization, both the application program and its associated PSB are loaded from their respective libraries by the IMS SYSTEM: The DL/I modules, which reside together with the application program in one region, interpret and execute database call requests issued by the program.

(22)

Data Characteristic s

Application Oriented

Limited Integration

Constantly Updated

Current Values Only

Supports Daily

Operations

Operational Data

Subject Oriented

Integrated

Non-volatile

Values Over Time

Supports Decision

Making

Informational Data

Operational and Informational Data Fundamentally Different

Operational and Informational data are fundamentally different. Operational data is more application oriented, is constantly updated and must support daily operations. Informational data is subject oriented, non-volatile, and supports decision making.

Hierarchical and relational data hence also have inherently different characteristics. Hierarchical characteristics make it more efficient in data access and storage but apply strict rules for access. Relational characteristics make it easier to access the data that has not been defined in advance. Thus they play different roles in the Enterprise. Each has a critical role to play in the enterprise

(23)

19

IMS_DB/DC Page: 19

Date: 21.06.2007

IMS in an Information Warehouse

Direct Access to IMS Data

IMS Data Propagation and Replication , eg. DB2

Decode, summarize and enhance data

Time-related values and cyclic update for reproducible results

Isolate from Operational system

Showing New Ways

of Exploiting

IMS Data

There has been growing interest in data mining and data warehousing. Data warehousing involves the collection of data from mainframe and workstation databases into massive centralized databases, often measured in terabytes. Because of the tremendous size of these databases, look for mainframes and 64-bit platforms to be the staple workhorses. An informational warehouse could be used to contain IMS data, derived from production data, for decision support. Users can be provided data in relational format, easily accessible with favorite decision support tools, with minimal impact on the production data. As the warehouse has become a sophisticated end-user tool, IMS remains an important source of data and tools for it. IMS data can be accessed directly or propagated/replicated in with that data being summarized, enhanced, and mined for use in new ways. This all makes it possible to use standard application interfaces for accessing IMS as well as other data.

(24)

Database Manager Positioning

Strategy:

Meet different application requirements

Continued investment

Complimentary rather than conflicting usage

Hierarchical

Mission Critical Performance

Relational

Decision Support Application Productivity Engineering Scientific

Object Oriented

Hierarchical and relational databases have grown up with their characteristics and roles to play. In recent years object database managers have also been providing a role in this as well. Hierarchical is best used for mission-critical work and for that which requires the utmost in performance. Relational is best used for decision support and where application productivity is required. Object is best used for engineering and scientific work where large, unstructured data is required. Although hierarchical and object-oriented databases can offer a significant performance edge over relational databases when queries are known beforehand, query optimization for relational databases are better known, and have the edge in this area. Each type is the best at what they do. The products supporting these are being enhanced to address the different application

requirements and are continuing to create more and more overlap in their capabilities. The type originally designed for that capability will however inherently be the best at that. IBM will continue to invest in providing complementary solutions for these.

(25)

21

IMS_DB/DC Page: 21

Date: 21.06.2007

Database Management Systems

-Differentiation

Hierarchical

Navigation done apriori by database design & application logic

Price: Longer development cycle Benefit: Performance

Relational

Navigation done at run time by 'SQL' engine

Price: Performance

Benefit: Shorter development cycle decision support

Propagation

SQL Engine Application SQL Engine Provides Independence How What Method 1 Data Method 2 Method 3

Navigation

Object Oriented

Navigation is not an issue

Object method is responsible for navigation -Application sends message to object's method to

manage navigation

Price: Development paradigm shift

Benefit: High reuse, high programmer productivity Data Structure

Drives Application Navigation

Application

What & How?

As we look closer, you can see differences of these. Hierarchical provides navigation by database design and application logic. The price for the more structured hierarchical is longer development cycles, but the benefit is better performance, thus useful for repetitive operational work. Relational provides navigation at run time by the SQL engine. The price is thus performance, but the benefit is a shorter development cycle, thus useful for ad-hoc decision support. With object oriented navigation is controlled by the method as requested by the application and requires a development paradigm shift. The result is a high reuse and future productivity. Tools for access and replication can assist in moving the data between the data base types.

(26)

Database Management Systems

-Differentiation

Product Positioning:

• Hierarchical DBMS (IMS)

• mission-critical work

• significant performance edge… when queries are known…

• IMS Transaction Manager and WebSphere

• Relational DBMS (DB2)

• decision support

• good performance where query is not known in advance…

• WebSphere

Strengths and Weaknesses.

• Object Oriented DBMS –

no weightiness in MF-area

Product Positioning. Hierarchical & Relational DBMS.

IMS Database Manager utilizes hierarchical organization technology, whereas DB2, and desktop systems utilize relational database technology. Hierarchical and relational databases have each continued to grow with their specific characteristics and different roles to play.

Hierarchical is best used for mission-critical work and for work that requires the utmost in performance. Relational is best used for decision support.

Hierarchical databases can offer a significant performance edge over relational databases when queries are known before hand. Query optimization for relational databases ensures good performance where the query is not known in advance. Each type is best at what it does. The products supporting these technologies are enhanced to address the different application requirements and are continuing to more and more overlap in their capabilities. However, the product originally designed for that capability will inherently be the best.

Relational and hierarchical technology can work together for optimum solutions. Users can efficiently store operational data in hierarchical form, which can be accessed easily by their favorite relational decision support tools, with minimal impact on the production hierarchical data. IMS data can be accessed directly or propagated and replicated with relational data for summarizing, enhancing, and mining. IBM provides standard application interfaces for accessing IMS as well as other data. Both relational and hierarchical IMS data can be most efficiently accessed, together or independently, using the IMS Transaction Manager and WebSphere servers.

IBM continues to invest in providing these complementary solutions. Note that most IMS customers also have DB2.

IMS Transaction Manager and WebSphere servers are both strategic application managers and are enhanced to take advantage of each other. They each have inherently different characteristics. IMS is more efficient in application management, data storage, and data access but applies strict rules for this access. WebSphere make it easier to serve the Web and integrate data that may have been less defined in advance. Thus, they play different roles in the enterprise. Customers are using both application managers — WebSphere for newer Web-based applications, and IMS for more mission-critical high performance/availability and low-cost/transaction applications and data.

IMS and WebSphere products together have been providing tools to make this combination an optimum environment. Using IMS Connect/Connector for Java, WebSphere development tooling can develop Web applications that can serve the Web and easily access existing/new mission-critical IMS applications. Using JDBC and IMS Open Database Access, WebSphere applications can also access IMS DB data directly.

IBM demonstrates its commitments to you by continuing to enhance IMS. Current investments have: Substantially improved database availability,

Established open access to IMS transactions, Extended Parallel Sysplex systems support.

Strengths and Weaknesses.

Hierarchical and relational systems have their strengths and weaknesses. The relational structure makes it relatively easy to code requests for data. For that reason, relational databases are frequently used for data searches that may be run only once or a few times and then changed. But the query-like nature of the data request often makes the relational database search through an entire table or series of tables and perform logical comparisons before retrieving the data. This makes searches slower and more processing-intensive. In addition, because the row and column structure must be maintained throughout the database, an entry must be made under each column for every row in every table, even if the entry is only a place holder-a null entry. This requirement places additional storage and processing burdens on the relational system.

With the hierarchical structure, data requests or segment search arguments (SSAs) may be more complex to construct. Once written, however, they can be very efficient, allowing direct retrieval of the data requested. The result is an extremely fast database system that can handle huge volumes of data transactions and large numbers of simultaneous users. Likewise, there is no need to enter place holders where data is not being stored. If a segment occurrence isn't needed, it isn't inserted.

The choice of which type of DBMS to use often revolves around how the data will be used and how quickly it should be processed. In large databases containing millions of rows or segments and high rates of access by users, the difference becomes important. A very active database, for example, may experience 50 million updates in a single day. For this reason, many organizations use relational and hierarchical DBMSs to support their data management goals.

Object Oriented DBMS.

(27)

23

IMS_DB/DC Page: 23

Date: 21.06.2007

Data Ac ces s

-Favorite Tool on -Favorite Platform

Traditional Applications Traditional API's •Data Integrity •Recovery •Security •Performance •Availability New Application New API

Data is growing in all the database types and coexistence becomes critical through propagation, common application interfaces and access gateways. An application written in one context must run with another. Both new and existing applications must be able to run with existing and new data. Data Access is being provided with transparency and consistency for this. Data provided in a particular database, accessible by a particular application type through a given interface can be propagated to another database, or accessed by a different application, using a different interface, and vice versa. This allows for new and traditional heterogeneous data and application types to work together side by side.

(28)

IMS is a Transaction Management

System

A B C D E Application Application Application

IMS TM continues providing leadership

To efficiently manage network, message, application, and data processing

To ensure high performance, availability, security, and recovery

A Transaction is the request and execution of a set of

programs, performing administrative functions and accessing a

shared database on behalf of a user

A Transaction Management System creates, executes, and

manages Transaction Processing Applications for scalability to

high transaction loads

Transaction processing is the software technology that makes distributed computing reliable. Large enterprises in transportation, finance, telecommunications, manufacturing, government and the military are utterly dependent on transaction processing applications for electronic reservations, funds transfer, telephone switching, inventory control, social services, and command and control.

Rapid expansion on the internet will expand the demands on high end transaction processing even further. Transaction Systems contribute to the performance, security, scalability, availability, manageability and ease of use.

The IMS Transaction Management system provides technological leadership to communicate with the network; manage input/output processing and security; provide message queuing, formatting, logging and recovery; to ensure scheduling, execution, and checkpoint/restart of online and batch message and data processing programs.

(29)

25

IMS_DB/DC Page: 25

Date: 21.06.2007

IMS Transaction Flow

Control Region Address Space

Message Buffers Data Communication Modules Queue Management Application Program - TP PROGRAM ENTRY DEFINE PCB AREAS

CALLS TO DL/I DB FUNCTIONS CHECK STATUS CODES

TERMINATION MFS Pool MFS Message Input Message Queue Data Sets IMS.FORMAT OLDS Buffers Logging WADS OLDS Program Isolation (PI) Scheduler ACBs ACBs Database Buffers GU IOPCB ISRT IOPCB ISRT ALTPCB

DL/I Separate Address Space

Message Processing Region (MPP)

IMS Data Bases

DL/I Modules

LL ZZ Data Message_Segment

1 2 3 4 Queue Buffers TRAN LTERM 5 7

IMS Transaction Flow.

The general flow of an input message is from a terminal or user to the MPP, and the general flow of the output message is from the MPP to the terminal or user. The shown foil describes a general flow of the message through the system, not a complete detailed description!

A further description follows:

1. The input data from the terminal is read by the data communication modules. After editing by MFS, if appropriated, and verified that the user is allowed to execute this transaction, this input data is put in the IMS message queue. The messages in the queue are sequenced by destination, which could be either transaction code (TRAN) or logical terminal (LTERM). For input messages, this destination is TRAN. 2. The scheduling modules determine which MPR is available to process this transaction, based on the

number of system and user-specified considerations, and then retrieves the message from the IMS message queues, and starts the processing of a transaction in the MPR.

3. Upon request from the MPR, the DL/I modules pass a database segment to or from the MPR. 4. After the MPP has finished processing, the message output from the MPP is also put into the IMS

message queues, in this case, queued against the logical terminal (LTERM).

5. The communication modules retrieve the message from the message queues, and send it to the output terminal. MFS is used to edit the screen and printer output (if appropriated).

6. All changes to the message queues and the data bases are recorded on the logs. In addition, checkpoints for system (emergency) restart and statistical information are logged.

7. Program isolation (PI) locking assures database integrity when two or more MPPs update the same database. The system also backs out database changes made by failing programs by maintaining in a short-term, dynamic log of the old database element images. IRLM is an optional replacement for PI locking. IRLM is required, however, if IMS is participating in data sharing.

(30)

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(31)

27

IMS_DB/DC Page: 27

Date: 21.06.2007

Why not just Data Systems ?

Database Management

2-tiered (client and database mgmt) architectures

are ideal for applications with

<100 clients

1 source of data

LAN-based network connectivity

Low security requirements

Enterprise-class systems require

Production quality factors - high availability, performance,

scalability, security, manageability

Supporting factors -- support/consulting,

tools/applications, training, service

Departmental systems are becoming increasingly business-critical, outgrowing their technology, and requiring more interaction and growth. Enterprise computing requires many application components, multiple

heterogeneous data sources, support for high-volume, update intensive workload, requiring significant inter-application communication, must work over wide area networks and the internet, have long expected lifetimes, involve multiple groups with a company. Beyond 100-150 clients, the cost per client can rise dramatically in a 2-tiered data environment. Upgrading hardware doesn't solve the problems. 3-tiered architectures can have higher initial cost but are far more scalable in the long run.

(32)

Why Transaction Management ?

Transaction Management

Database Management

2-tiered Stored-Procedural

Data Systems offer

Management of data resources

Efficient processing of large

queries

Integrity of one resource

Limited application scope

Proprietary language

Data-oriented decision support

Transaction Management

Systems offer

Access to multiple data resources

Efficient processing of small units

Integrity across heterogeneous

resources

General application scope

Standard languages

Process-oriented, Mission-critical

Both offer Online access to Data

The 2-tiered data system and the 3-tiered transaction management system each have their role to play in providing online access to data. But for Enterprise-level computing, Transaction Management Systems become a necessity. They focus on clients requesting application services, instead of data, and running in an

increasingly heterogeneous environment, and separating the client, application programmer, and operator from the uniqueness of the differences.

(33)

29

IMS_DB/DC Page: 29

Date: 21.06.2007

Why Transaction Management ?

Transaction Management

Both offer Online access to Data

Database Management

Enterprise Application Servers Application Platform Suites

J2EE or .Net Enterprise

Application Servers or

Application Platform Suites offer

•Integration/interoperability focus through support of newer devices, standard interfaces and protocols

•Portal capabilities

•Advanced Technology

•Tools to help assemble services through composition of existing and/or packaged applications

Transaction Management

Systems offer

Efficient processing of small units

Integrity across heterogeneous resources

General application scope

Standard languages

Process-oriented, Mission-critical

Enterprise level QOS (manageability, availability, performance, security)

Proven track record of support for large business-critical OLTP applications

Alternative enterprise application servers and platforms focus on integration and interoperation, supporting mobile devices, portals and standard interfaces. They also provide tools to help assemble services through composition of existing and/or packaged applications.

Transaction Management systems focus on ensuring efficient processing of small units, integrity across heterogeneous environments, general applications scope with standard languages, and support for Mission-critical applications with enterprise level qualities of service and a proven track record of support for large business-critical OLTP applications.

(34)

Why IMS Transaction Management ?

IMS Transaction Management

Database Management

IMS Transaction Management Systems

Integrate key servers such as database, message queuing,

communications, and Internet access

Provide Enterprise-class technology that is robust, secure,

high performance, scalable, and manageable

Offers choice and flexibility in networks, programming styles

and languages

Integrates well with existing investments in hardware,

software, applications, and skills

Interoperability and provides portability with other platforms

IMS offers the highest in transaction management availability, performance and integrity at the least cost per transaction. It supports the heterogeneous environments that our customers have. It provides transparency to application programmers. And it builds on your existing skills, applications, and data.

(35)

31

IMS_DB/DC Page: 31

Date: 21.06.2007

Agenda

1. Term of IMS

2. Overview of the IMS product

3. An initial example

4. IMS DB and IMS TM

5. FAQ about TM/DB Basics

6. IMS Usage and Technology Trends

7. Summary

(36)

Overall Message:

IMS is an evolving, thriving species –that is CORE to your business

Born to be

…

a Winner!

Overall Message: IMS is an evolving, thriving species –that is CORE to your business

All great things seem to start in a box. Many successful motorcycle companies started out in small garages or shacks – an idea, a place to tinker. IMS started in a box: the System 360/65 computer (pictured is the operator’s console).

Then the hard work and innovation takes off – winning races (first racing bike and first rocket to the moon (Apollo program)), and defining ‘cool’ - (the cruisers (a style of motorcycle) and access 24/7 to your cold hard cash (the ATM))...

And a good thing keeps on going – with modern superbike designs that push the limit speed, and hardware (the z9) that blows away anything in its path.

But, at the heart of both are powerful engines. IMS is a powerful engine that continues to adapt and grow – helping you and your company win…

(37)

33

IMS_DB/DC Page: 33

Date: 21.06.2007

The World Depends on IMS

IMS is a part of everyday life. When you:

Turn on a light

Get a business loan

Make a telephone call

Process accounting records

Use your ATM card

Control inventories

Put money in a bank

Process payroll

Rent a car

Update personnel records

Purchase life insurance

Control an assembly line

Travel

Control a railroad

Send a package

Use corporate data bases

Track in-transit packages

Run a government agency

Trade stocks

Conduct international

business/banking

And more... ... you are likely using IMS!

IMS, IBM's premier transaction and hierarchical database management system, is the product of choice for critical on-line operational applications and data where support for high availability, performance, capacity and integrity, and low cost are key factors. Chances are you are using IMS when you turn on a light, make a telephone call, get a business loan, process accounting records, use your ATM card, put money in a bank, rent a car, purchase insurance, travel, send a package, track in-transit packages, trade stocks, control inventories, process payroll, update personnel records, control an assembly line, control a railroad, use corporate databases, run a government agency, conduct international business/banking, and many more.

(38)

The World Depends on IMS

• Manufacturing

• Finance

• Banking

• Retailing

• Aerospace

• Communications

• Government

• Insurance

• High Technology

• Health Care

• …

Who Uses IMS ?

Over 90% of the top world companies in the above shown industries use IMS to run their daily operations, eg. • Manufacturing • Finance • Banking • Retailing • Aerospace • Communications • Government • Insurance • High Technology • Health Care

IMS is still a viable, even unmatched, platform to implement very large online transaction processing (OLTP) systems and, in combination with Web Application Server technology, it is the foundation for a new generation of Web-based, high-workload applications.

(39)

35

IMS_DB/DC Page: 35

Date: 21.06.2007

An IMS Customer Then and Now…

Number of Terminals

Number of Data Bases

DASD used to hold Data Bases Number of Transactions per Day

Number of Transaction Codes Number of Applications System Availability Response Time

An Original

Environment in 1969

139 on 110 Lines 30 4 - 2314 DASD 17,000 - 20,000 260 8

Less Than 24 Hours

2-5 Seconds

A Large Customer

in 2007

Tens of Thousands Thousands Terabytes of DASD Over 100 Million Thousands Thousands 2-3 Hours of Planned and Unplanned Outages per Year Sub-Second

Today, IMS manages the world's mission-critical data and has been at the forefront of the swing back to mainframe usage. Companies worldwide depend on IMS. Only with IMS can help customers obtain their growth objectives. For example, banks are assured the integrity of their high volume financial processing. With IMS, they have managed to continually grow their workload, and as they merge with other banks, they are able to continue to handle the capacity that results.

(40)

IMS Runs the World...

Most Corporate Data is Managed by IMS

Over 95% of top Fortune 1000 Companies use IMS

IMS Manages over 15 Billion GBs of Production Data

$2.5 Trillion/day transferred through IMS by one customer

Over 50 Billion Transactions a Day run through IMS

IMS Serves Close to 200 Million Users a Day

Over 100 Million IMS Trans/Day Handled by One Customer on a single system

120M IMS Trans/day, 7M per hour handled by another customer

6000 Trans/sec across TCP/IP to single IMS with a single Connect instance

Over 21,000 Trans/sec (near 2 Billion/day) with IMS Data/Queued sharing on a single processor

Gartner Group:

"A large and loyal IMS installed base. Rock-solid reputation of a transactional workhorse for very large workloads. Successfully proven in large, Web-based applications. IMS is still a viable, even unmatched, platform to implement very large OLTP systems, and, in combination with Web Application Server technology, it can be a foundation for a new generation of Web-based, high-workload applications."

Industries worldwide rely on IMS to run their businesses. IMS is part of everyday life. More than ninety-percent of the Fortune 1000 companies use IMS. IMS serves 200 million end users, managing over 15 billion Gigabytes of production data and processing over 50 billion transactions every day. IMS still owns the high-volume on-line transaction and database management environment. IMS customers have been driving their own growth and the world's business with IMS. One customer had transferred over $2.5 Trillion through IMS in a single day. Over 100 million transactions were handled by one customer in a single day on a single sysplex system.

7 million Transactions/ hour and 120 million transactions/day were handled by another customer. IMS in-house testing reached nearly 6000 transactions/sec across TCP/IP to a single IMS on a single machine. That equates to over 500 Million per day. And we reached over 21,000 trans/sec (near 2 Billion trans/day) with IMS Data/Queued Sharing on a single zSeries machine (limited only by the size of the processor used in testing). One large customer has also indicated they have reached over 3000 days without an outage and still going strong.

IMS, IBM's premier hierarchical transaction and database management system, is the product of choice for critical on-line operational applications and data where support for high availability, performance, capacity and integrity, and low cost are key factors. Today, IMS manages the world's mission-critical data and has been at the forefront of the swing back to mainframe usage.

A recent Gartner Group Vendor Catalog entry stated "A large and loyal IMS installed base. Rock-solid reputation of a transactional workhorse for very large workloads. Successfully proven in large, Web-based applications. IMS is still a viable, even unmatched, platform to implement very large OLTP systems, and, in combination with Web Application Server technology, it can be a foundation for a new generation of Web-based, high-workload applications."