Monthly Archives: August 2012

JCL or the stern face of a main frame

I realise that working on a main frame can be very intimidating. Look at the JCL: the job language that you use to get things done. This is the way how you might copy files, how to execute a programme, to compile a programme. This implies that you will use the JCL every day when working on a main frame.

Let us see how such JCL looks like:

This is a programme that writes two lines “0 tom” and “1 papa” to a file (or data set as it is called on a mainframe). Oops: to get it done, one needs 9 lines of jcl.
On the other hand, most of the lines can be reused. Take as an example, the first two lines that give a name to the job. These lines are probably only created once and later copied from job to job.
I can also imagine that this programme that copies two lines into a file, is used as a skeleton to copy lines into files. Only a change in the lines or the filename is sufficient to perform a new task.

On book helped me hugely to understand jcl: Murach’s OS/390 and z/OS JCL. This helped me to pass that impressive hurdle.

But let us go back to the JCL.
[1] The first two lines indicate the jobname. These two lines can be copied from job to job. They indicate what job is run and who is accounted for the costs of the job.
[2] The third line indicates what is done. In this case the programme IEBGENER. This programme copies one dataset to another. The programme IEBGENER requires four datasets. These four datasets are described in subsequent lines.
[3] SYSIN: it must be included but the reason is not really clear in a copy statement
[4] SYSPRINT: indicates where the job warnings are written
[5] SYSUT2: the output dataset. As a new dataset is created, the properties must be indicated
[6] SYSUT1: the input dataset. In this case the input dataset is directly included as an instream dataset.

One could make minor modifications. Such a modification is given below. In this case the output dataset is an existing dataset and the data are appended to the bottom of the dataset.

This implies that only the SYSUT2 statement must be changed. The programme below copies the data to the bottom of the output dataset.

000001 //MAAN093 JOB (12345678),MAAN093,MSGCLASS=H,
000002 // MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID
000003 //STEP1 EXEC PGM=IEBGENER
000004 //SYSIN DD DUMMY
000005 //SYSPRINT DD SYSOUT=* KOMMENTAAR VAN NIKS
000006 //SYSUT2 DD DISP=(MOD,KEEP),DSN=MAAN093.DATA.TXT16
000007 //SYSUT1 DD *
000008 01 TOM
000009 03 INE1
000010 /*

Let us go to another programme. Just to show what is possible in JCL. The programme looks like:

000001 //MAAN093 JOB 'MAAN093',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
000002 //*------------------------------------------*
000003 //GOOI PROC
000004 //MAKEFI EXEC PGM=IEFBR14
000005 //DD2 DD DSN=MAAN093.FLIP.TXT,DISP=(SHR,DELETE) GOOIT OUD WEG
000006 // PEND
000007 //*------------------------------------------*
000008 //STEP EXEC GOOI

This programme creates a procedure that is called “gooi”. This procedure starts with a declaration: “gooi proc” and it ends with “pend” to state where the procedure ends. This procedure “gooi” contains two lines. One line indicates what is to be done. In this case IEFBR14 is executed: the deletion of a file. The file that is deleted is indicated by the dd2 line.
The procedure “gooi” is executed in the last line: exec gooi will initiate the gooi procedure.

 
To finalise, some more examples of JCL code
Sortprocedure with JCL
 
Combine two input datasets into one sortprocedure with JCL

 

 

Querying a Db2 database on a mainframe

Recently, I was in a situation where I had to query a Db2 database on a mainframe. I was also in a situation where the knowledge and documentation on that mainframe was not very widespread. So there I found myself, sitting in the dark with only a so-called 3270 screen looking at me, waiting for a first step that I would take.

The first question: how are the tables called. Second question: what tools to use to query the database.

I remembered from a distant past that IBM has a so-called “File-Aid” for Db2. This tool has a browse option that allows you to browse¬†interactively tables in a Db2 database. The nice thing about it that the browse mode accepts wild-cards like *. When multiple answers are possible a pop-up appears that gives a clear choice on the possiblities. I used this tools to get a hunch of the table-names and to get a first impression on the content of the tables.

Once I had a list of filenames, I started with a second tool that gave me more insight. This tool is called “Spufi”. This tool basically uses two files (or datasets as they are called on a mainframe). One file is used to store the SQL statements, whereas a second dataset is used to capture the output. I realised that the two files must be allocated beforehand and that both files could best reside under your own name. I created two files: “tom.input.sql”¬† and “tom.output.txt”. I then used these two names in the first screen of Spufi where the exact names of input- and output files is being asked for.

This allowed me to start investigating the database.