ENVIRONMENT - IBM Mainframe

DB2 requires either MVS/XA (extended architecture) or MVS/ESA (enterprise systems architecture) as the operating system. Both MVS/XA and MVS/ESA have a much larger amount of virtual storage than the other MVS operating system MVS/SP), which is no longer adequate for the newer releases of DB2. This is important because there is a strict correlation between the size of virtual storage and the number of users and transactions DB2 can support.

DB2 Environment Overview

DB2 Environment Overview

There are three MVS host environments through which applications can access DB2 resources. They are TSO, CICS/VS, and IMS/VS, which are illustrated in Figure 44.2. A DB2 application running under IMS/VS or CICS/VS can access both DB2 data (via SQL statements) and IMS data (via DL/I calls). In addition, C1CS/DB2 applications can also access VSAM, ISAM, and DAM datasets. TSO is the work environment for DB2's interactive facilities, e.g., program preparation and execution panels, interactive database access tools, etc. DB2 data can be accessed from application program written in COBOL, PL/I, Fortran, Assembler, or C.

Online programs can run under the control of TSO, CICS, or IMS. Batch programs can run under TSO or IMS. This book assumes the CICS environment and COBOL for online applications and the TSO environment and COBOL for batch applications.

Operating Environments

The various environments in which DB2 operates are:

  • IMS Batch (DL/1 Batch) - An IMS batch application accesses DB2 data using SQL statements and IMS data using DL/1 database calls. DB2 itself serves as the transaction manager in this environment.
  • IMS On-line (IMS/DC) - An IMS on-line DB2 application is an application that is invoked form an IMS terminal and uses the data communication facilities of IMS to exchange messages with that terminal. Like the IMS batch DB2 application, the IMS on-line DB2 application can access both the DB2 and IMS data. The combination of DB2 with IMS/DC acts as a complete Database/Data communication (DB/DC) system. But here the transaction manager is the IMS.
  • CICS - A CICS DB2 application is an on-line application that is invoked form a CICS terminal and uses the facilities of CICS to exchange messages with that terminal. A CICS DB2 application can access DB2, IMS and VSAM data. The combination of CICS and DB2 is also a full-fledged DB/DC system, with CICS acting as the transaction manager.
  • TSO Batch - A TSO batch DB2 application can operate on DB2 data but not on IMS data. Here DB2 acts as the transaction manager.
  • TSO On-line - TSO on-line DB2 application can operate on the DB2 data but not IMS data. Here also DB2 acts as the transaction manager. The application can use ISPF, GDDM and TSO screen management facilities to communicate with the terminal.
  • CAF - It is possible for a 'pure' MVS application running directly under MVS instead of IMS, CICS or TSO to operate on DB2 data. This is made possible by a feature called DB2 Call Attach Facility (CAF). CAF is intended for users who for some reason need more direct control of the environment than the cases discussed above can provide. Generalized applications provided by third party software vendors uses this facility. IBM supplied 'Query Management Facility (QMF)' is also implemented using CAF.

All the above-mentioned DB2 application types can execute concurrently. They can even share the same DB2 databases. Another important aspect is that the various categories are not interchangeable. That is am application that is designed to run under IMS/DC cannot be moved to CICS without some coding changes to the portions of the application programs that interact with the transaction manager. The portions that perform the database operations are the same in all cases.

DB2 Governor

The Resource Limit Facility (RLF), or Governor, is provided to simplify the task of controlling DB2 resource usage. The DB2 Governor allows a site to limit, by user ID, plan, or both the amount of CPU time permitted for the execution of dynamic SQL statements. QMF's Governor, which already existed, is super ceded by it, thereby making the QMF Governor somewhat redundant for the MVS/DBB environment. When you access DB2 through QMF or SPUF1, you are actually initiating a dynamic SQL program. It is called dynamic SQL because the SQL statement in the program is not known until you type it in at the terminal and press Enter. Interactive queries carry the risk that an end user may submit a complex SQL query and slow the whole MVS system down to a halt. The Statements which you embed in your programs, do not have this exposure because the program can be tested for performance and CPU utilization first. By limiting CPU time for dynamic SQL statements, the DB2 Governor can have a major effect on maintaining your system's processing capabilities.

Incidentally, although you will often use dynamic SQL programs like SPUFI and QMF, you probably will not write dynamic SQL programs yourself very often. Its counterpart, static SQL, is far more common for application programming.

DB2 Subsystem

A DB2 subsystem is a copy of DB2 that runs on a CPU, complete with libraries. Catalog, and Directory. One CPU can have one or more DB2 subsystems running on it.

Distributed Data Facility

Distributed Data Facility (DDF) is available with version 2.2 of DB2 onwards. With DDF, a user connected to one DB2 subsystem can read and update data stored at another. The subsystem to which a user is connected is considered the local system; the other subsystems' from which data may be accessed are considered remote subsystems. A local remote subsystem may run on one computer or may run on two computers at different physical sites.

DB2 Attachments, DSN, and Threads

DB2 requires its own address space. Therefore, for each of the three possible MVS host environments, DB2 must provide services to manage the interface between the host address space and the DB2 address space. These services are called attachment facilities. The connection between DB2 and the host environment is implemented by link-editing a copy of the appropriate attach code (i.e., TSO, CICS, or IMS) to the host language program. In the case of TSO, a program goes through a further layer, DSN. DSN is the TSO command processor provided by DB2 to act as an interface between TSO and DB2. To submit a DB2 batch program, you submit JCL, which executes program IKJEFTOI, which is the TSO Terminal Monitor Program (TMP). TMP is, in effect, TSO itself. Control cards in the JCL then tell TSO to invoke DSN to run your DB2 program. Unlike the non-DB2 batch programs you are used to, you cannot submit your DB2 batch programs as MVS jobs; they must run under TSO TMP.

DB2 does, however, provide the Call Attach Facility (CAF) software, which makes it possible to access DB2 directly from MVS. CAF is used mostly by software vendors as the link to DB2 for their DB2-based products. You will not need to use CAF in your work. DB2 also provides an extensive collection of utility programs for database and system administrators and, to a lesser degree, applications programmers. These utilities execute as standard MVS batch jobs and use their own internal attach mechanisms to provide fast sequential access to data.

DB2's attachment facilities make the connection, or thread, from DB2 to other subsystems possible. A thread is started with the execution of the first SQL statement of an application. At any given moment, the number of active threads equals the number of users (programs, utilities, interactive users, etc.) accessing DB2. The maximum number of concurrent threads is set at installation time. If that number is exceeded, an application will wait until a thread becomes available.

Interactive Access to Data

Unlike non-relational DBMSs, DB2 provides access to the data interactively as well as from user-written programs. As we said earlier in the chapter, you will find this a big help when you are developing and testing a program. Interactive access to the data is possible from TSO through SPUFI or QMF. SPUFI (pronounced "Spoofy") stands for SQL Processor Using the Input. It is a subcomponent of DB2I (DB2 Inter­active) and is provided with DB2. QMF (Query Management Facility) is a separate IBM product but is used in most DB2 installations.

Both SPUFI and QMF can be used interactively to process any type of SQL statement, although QMF is most often used for data retrieval only. While SPUFI does format its output, QMF offers sophisticated report formatting options and can be used as a report writer as well as a query tool. It is, in fact, increasingly being looked upon as a productivity tool to replace traditional report writing programs. Another difference between SPUFI and QMF is that SPUFI has been designed for technically proficient users (i.e., application programmers, database administrators, and system administrators) while QMF is intended for a broad spectrum of users, including end users. In our own work, we have found both to be very useful.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics