Chapter 18. The Doors to DB2
| < Day Day Up > |
| IN THIS CHAPTER
You have learned how to embed SQL in application programs to access DB2 data, but you have yet to explore the possibilities when executing these programs. When accessing DB2 data, an application program is not limited to a specific technological platform. You can choose from the following environments when developing DB2 application systems (depending on their availability at your shop): TSO, CICS, IMS/VS, CAF, and RRSAF. You can think of each of these environments as a door that provides access to DB2 data. This chapter covers the advantages and disadvantages of each of these environments. First, I will discuss the basics of DB2 program execution that apply to all operating environments. Each DB2 program must be connected to DB2 by an attachment facility, which is the mechanism by which an environment is connected to a DB2 subsystem. Additionally, a thread is established for each embedded SQL program that is executing. A thread is a control structure used by DB2 to communicate with an application program. The thread is used to send requests to DB2, to send data from DB2 to the program, and to communicate (through the SQLCA) the status of each SQL statement after it is executed. Every program communicates with DB2 by means of a thread (see Figure 18.1). Figure 18.1. Programs access DB2 using threads. Now you can explore the process of invoking a DB2 application program. First, the program is initiated and the attachment facility appropriate for the environment in which the program is running is called. Next, security is checked (external z/OS security, internal environment security, and DB2 security). Finally, upon execution of the first SQL statement in the program, a thread is created. After the thread is established, DB2 loads the executable form of the appropriate plan from the DB2 Directory, where it is physically stored as a skeleton cursor table ( SKCT ). If the plan is composed of packages, DB2 loads the package table for the required packages into an area of memory reserved for DB2 program execution; this area is called the Environmental Descriptor Management Pool , or the EDM Pool. All DBDs required by the plan are also loaded into the EDM Pool from the DB2 Directory when the thread is established. Simply put, when a thread is created, DB2 performs the necessary housekeeping to ensure that the application program operates successfully. Now that you have an overall picture of the way that an application program communicates with DB2, you can explore the processing environments. DB2 programs can be run in the foreground (also called online ) or in the background (also called batch ). Online applications are characterized by interaction with an end user through a terminal. Most online applications display a screen that prompts the user for input, accept data from that screen, process the data, and display another screen until the user decides to end the session. Online programs are generally used to provide real-time update and query capabilities or to enter transactions for future batch processing. Batch applications are characterized by their lack of user interactions. A batch program is typically submitted using JCL. It can accept parameters as input, but it does not rely on an end user being present during its execution. Batch programs are generally used to perform mass updates, to create reports , and to perform complex non-interactive processes. Each environment provides different modes of operation, depending on whether the application is online or batch. For an overview of which environment supports which mode, consult Table 18.1. Table 18.1. DB2 Processing Environments
|
| < Day Day Up > |
EAN: 2147483647
Pages: 388