DB2 11 for z/OS: Basic Training for Application Developers

Legal

Disclaimer

The contents of this book are based upon the author’s understanding of and experience with the IBM DB2 product.  Every attempt has been made to provide correct information.  However, the author and publisher do not guarantee the accuracy of every detail, nor do they assume responsibility for information included in or omitted from it. All of the information in this book should be used at your own risk.

Copyright

The contents of this book may not be copied in whole, or in part, without the explicit written permission of the author. The contents are intended for personal use only. Secondary distribution for gain is not allowed.  Any alteration of the contents is absolutely forbidden. 

Copyright, 2017 by Robert Wingate

DB2, DB2 UDB, UDB, and MVS are all registered trademarks of the IBM Corporation. 

Introduction

Welcome

Congratulations on your purchase of DB2 11 for z/OS: Basic Training for Application Developers!  This text book will give you the essential information you need to know about DB2 11 so you can be productive as soon as possible.  You’ll receive instruction, examples and questions/answers to help you learn and to gauge your proficiency and readiness to join a DB2 development team.    

Assumptions:

While I do not assume that you know a great deal about DB2, I do assume that you’ve worked on an IBM mainframe and know your way around.  Also I assume that you have a working knowledge of either the COBOL or the PLI programming language which we will use for all the embedded SQL examples. Finally, I assume you have some familiarity with Structured Query Language (SQL).  All in all, I assume you have:

1.   A working knowledge of ISPF and JCL

2.   A working knowledge of COBOL or PLI

3.   A basic understanding of SQL

4.   Access to a mainframe computer running z/OS and DB2

To maximize your chances of success as a DB2 11 developer on z/OS, I recommend that you have or acquire two things:

1.   Knowledge of DB2 11.

2.   Experience with DB2 11.

Knowledge of DB2 11

We’ll cover the fundamentals, beginning with the z/OS methods for accessing DB2 data stores.  Then we’ll deal with the three languages associated with relational database management systems:  Data Definition Language (DDL), Data Manipulation Language (DML) and Data Control Language (DCL).  Next, we’ll look at embedded SQL in application programming using COBOL and PLI.  Later we’ll look at data concurrency, something many programmers don’t get much exposure to, but which is really important for system performance.  Finally, we’ll look at testing and validation of DB2 programs.

Experience with DB2 11

Unless your shop has already upgraded to DB2 11, you may not have any experience with it.  My suggestion is to practice with whatever version of DB2 you have, and then put some extra study effort on the new features of DB2 11 so you’ll be prepared when your shop adopts DB2 11. Once you are in an environment that uses DB2 11, this effort will pay off.

If you do not have access to a mainframe system through your job, I can recommend Mathru Technologies.  You can rent a mainframe account from them at a very affordable rate, and this includes access to DB2 (at this writing they offer DB2 version 10).  Their environment supports COBOL and PLI as well.  The URL to the Mathru web site is: 

http://mathrutech.com/index.html

Knowledge and experience.  Will that guarantee that you’ll succeed as a DB2 application developer?  Of course, nothing is guaranteed in life.  But if you put sufficient effort into a well-rounded study and exercise plan that includes both of the above, I believe you have a very good chance of excelling on your team as a DB2 application developer.     

Best of luck!

Robert Wingate

IBM Certified Application Developer – DB2 11 for z/OS

CHAPTER ONE:  BASIC Z/OS TOOLS FOR DB2

Welcome to basic training for DB2 11 for z/OS!  Before we get into development activities, I want to introduce you to the environment we’ll be working in.  If you’ve used DB2 on the mainframe, you’re almost certainly familiar with these tools and this will be a quick review.  But if you have little or no exposure to DB2 on z/OS, we need to make sure you are familiar with how to access it and use the basic tools available.

DB2 Interactive

You’ll do much of your DB2 work in DB2 Interactive which is now typically called the DB2 Primary Option Menu.  Regardless of which shop you work in, there should be a menu option on the ISPF main menu to get to DB2.  It may be called DB2 or some other name with DB2 in it.  On my system, the option is called DB2 and the description is DB2 Primary Menu.  Select whichever option is on your main menu for DB2.

This is the DB2 main menu.  Select the first option, which is SPUFI.  SPUFI is an acronym for SQL Processing Using File Input. 

You’ll see the following screen.

This is the place you can specify an input file which will contain the SQL, DDL, DML or DCL statements you wish to execute.  We’ll explain DDL, DML and DCL in future chapters.  For now just think of it as the place you can run SQL.

You must also specify an output file to capture the results from your statements.  If these files do not already exist you must allocate them.

I recommend that you specify the processing options shown below, i.e., NO for CHANGE DEFAULTS, and yes for EDIT INPUT, EXECUTE, AUTOMCOMMIT and BROWSE OUTPUT.

When you press ENTER your input dataset will open and you can type the statements that you want to execute.  In the example below, I’ve coded a SELECT statement to retrieve all records from a sample table named EMPLOYEE.

When you press PF3, and then press ENTER again, the output dataset is shown with the results from the query.

You will use SPUFI very frequently unless your shop has adopted another tool such as Data Studio. 

DCLGEN

DCLGEN is an IBM utility that generates SQL data structures (table definition and host variables) for a table or view.  DCLGEN stores the structure in a PDS member and then the PDS member can be included in a PLI or COBOL program by issuing an EXEC SQL INCLUDE statement.  Put another way, DCLGEN generates table declarations (hence the name DCLGEN). Don’t worry if this doesn’t make sense yet.  We’ll generate and use these DCLGEN structures when we start writing programs.

Here’s an example of running a DCLGEN for a table.  From the DB2 Primary Option menu, select option 2 for DCLGEN.

Now enter the DB2 table name, owner and the partitioned data set and member name to place the DCLGEN output into.  In the example below we have a table named EMP_PAY_CHECK owned by HRSCHEMA.  We want the output of the DCLGEN to be placed in member EMPPAYCK of partitioned dataset HRUSER.DCLGEN.COBOL.

Once you’ve entered the required information, press ENTER.

Next, you will receive a message indicating the DCLGEN has succeeded.

DSNE905I EXECUTION COMPLETE, MEMBER EMPPAYCK ADDED     

***     

Now you can browse the PDS member EMPPAYCK to see the resulting structures.  The first structure will declare the DB2 table definition, and the other structure will declare COBOL host variables that correspond to the table definition.

Again, the above structure can be included in your application program by simply issuing:

EXEC SQL

   INCLUDE EMPPAYCK

END-EXEC

Once you’ve included the structure in your application program, you have host variables declared for every column in the table, so you don’t need to code these variables yourself.

DB2I Defaults

Your shop should have standard settings for DB2I defaults.  If you are studying on your own, I recommend setting some defaults.  First select option D from the DB2 Primary Option menu:

Select the following options, specifying your correct DB2 subsystem identifier as the DB2 Name (ask your system admin if you are not sure – I have used DB2X as mine and that represents the subsystem identifier on my system). 

If you are developing in COBOL, specify IBMCOB as the application language.  Otherwise specify PLI or whichever language you are using.  Our programming examples will be in COBOL and PLI.

BATCH UTILITIES

DB2 provides some batch utility programs you can use.  The two most useful of these are DSNTIAUL and DSNTEP2 (and DSNTEP4 if you have large numbers of rows to unload because it uses multi-row fetch).  You can use these instead of SPUFI to operate on data (or issue other statements) in a batch mode. 

DSNTIAUL

DSNTIAUL is a utility most often used to unload a DB2 table into a flat file.  Here is a sample JCL to run it, and of course you must adjust file names to your own environment.  In the SYSIN file you specify the name of a table to unload. In this example we will unload the EMP_PAY table (the HRSCHEMA is a schema qualifier – we will talk about that later).

The above unloads the entire EMP_PAY table.  Our second example allows you to use SQL to select the data you want to unload.  Notice that it includes PARMS('SQL') as a RUN parameter.  The SQL is coded in the SYSIN file:

The above example shows that you can specify which columns to include in your output, as well as selecting which rows to unload.

DSNTEP2

The DSNTEP2 sample program allows you to execute dynamic SQL to select or update data.  The JCL looks like this, and the example is reading data from the EMP_PAY_CHECK table:

You could also run an update or delete action with DSNTEP2.  Just change the SYSIN control file content.  Here’s an example: 

UPDATE HRSCHEMA.EMPLOYEE

SET EMP_SERVICE_YEARS

= EMP_SERVICE_YEARS + 1

If you are not already using these sample programs, I suggest you learn more about them and use them.  They are great utilities and will save you some custom coding effort!

CHAPTER TWO:  DATA DEFINITION LANGUAGE

Before rushing into programming it is a good idea to understand how to create and maintain the basic DB2 objects.   We’ll look at the properties of the various objects (tables, indexes, views).  We’ll look over the various data types that DB2 provides as well.  Finally we’ll look at the DB2 catalog and the information it provides.

A DB2 database is a collection of objects including tablespaces, tables, indexes, views, triggers, stored procedures and sequences.  Generally a database is concerned with a single domain such as marketing, accounting, shipping and receiving, etc.  Within the database there are objects such as tables, indexes, views, etc. 

In many shops a DBA creates and maintains the database objects.  I don’t expect you to know every nuance of each database object, but you need to know the basic Data Definition Language.  So let’s step through how to create and maintain the basic database objects.

For purposes of this text book, we will be creating and maintaining a simple human relations system for a fictitious company.  So we’ll create objects with that in mind.

DATABASES

CREATE

You can create a database with the CREATE DATABASE statement and you can assign options such as bufferpool, index bufferpool, storage group and CCSID.  The required syntax to create the database is:

CREATE DATABASE

However you would normally specify names for a storage group, bufferpool and index bufferpool.  Here’s an example:

CREATE DATABASE DB1

STOGROUP DS1

BUFFERPOOL BP1

INDEXBP BP2;

You may not have security access to create a DB2 database, even a test database.  This depends on your shop and whether or not it allows application developers to create database objects.  If not, then you can ask a DBA to create the objects for you.

For our purposes, let’s assume that you do have security and we’ll go ahead and create our HR database.   Let’s name the database DBHR and we’ll specify a bufferpool named BPHR, an index bufferpool named IBPHR, and a storage group called SGHR.   Finally we need to choose a CCSID (conceptually this is similar to a codepage) from ASCII, EBCDIC or UNICODE.  We’ll talk more about CCSIDs in the subsection on tables.  For now, let’s go ahead and specify UNICODE as the CCSID for our database. 

The DDL to create our HR database is as follows:

CREATE DATABASE DBHR

STOGROUP SGHR

BUFFERPOOL BPHR

INDEXBP IBPHR

CCSID UNICODE;

ALTER

If you need to change anything about the database in the future, you can use the ALTER statement.  Suppose for example we want to change the default bufferpool.  You could issue this DDL to change the default bufferpool in the DBHR database to BPHR2.

ALTER DATABASE DBHR

BUFFERPOOL BPHR2;

DROP

Most database objects can be removed/deleted by issuing the DROP command.  The syntax to delete a database is very simple:

DROP DATABASE

You could DROP the DBHR database by simply issuing this command:

DROP DATABASE DBHR;

We won’t drop the DBHR database now because we are going to add some more objects to it in this chapter. 

TABLESPACES

A tablespace is a layer between the physical containers that hold data and the logical database.  In essence, a tablespace defines storage areas into which DB2 objects may be placed and maintained. 

DB2 11 supports the following types of tables spaces:

1.   Universal

2.   Segmented

3.   Partitioned

4.   EA enabled

5.   Large Object (LOB)

6.   XML

7.   Simple (cannot be created in DB2 11 but still supported if already exists)

Universal table spaces                   

A universal table space is