zOS COBOL/DB2 vs GnuCOBOL/DB2 LUW

zOS COBOL/DB2

  1. RACF - the security system
  2. DCLGEN - Create an INCLUDE copybook member that defines the table and adds host variables.

GnuCOBOL/DB2 LUW

  1. No RACF. Since there is no RACF, the DB name, the userid, and the password must be supplied to the program for it to connect to the DB.
  2. There is a db2dclgn command included with IBM DB2 LUW but it does not generate the table definition within a "EXEC SQL DECLARE" statement. It only defines the COBOL host variables.

So, you have to create the EXEC SQL DECLARE "xxxxx" TABLE statement, the host variables, and the DB Connect variables within the program itself.

TL/DR: 3 different methods in the repository to supply the program with the DB parameters?

A look at the examples to see the differences:

Original Code from Murach book

In the repository on GitHub, this is cbl/CUSTINQ.cbl

It will not compile with GnuCOBOL.

Also, as I'm not sure about the copyright and my ability to "re-distribute" the code included in the book, this will the only time I will include the exact original code from the book. I will be using it 3 more times (Version 1, 2 and 3) but those have changes made to them to compile and run using GnuCOBOL.

As you will see in Versions 4 and 5, I have my own program structure and style and while the results will be the same as the original, the code will be quite different.

Version 1

In the repository on GitHub, this is cbl/CUSTIN1.sqb

I started with cbl/CUSTINQ.cbl and:

  • removed the INCLUDE CUSTOMER statement

  • added the EXEC SQL DECLARE TABLE statement

  • added the host variables and the DB Connect variables

  • added Procedure code to use ACCEPT to get the userid and password from the user when the program is run.

Version 2

In the repository on GitHub, this is cbl/CUSTIN2.sqb

I started with cbl/CUSTIN1.sqb and:

  • created GETDBID program to "hardcode" the userid and password.

  • updated to call GETDBID and removed the ACCEPT from User code.

  • updated the Compile script to add GETDBID LLM to the compile step.

Now the program will run without needing to ask the user for that information.

Version 3

In the repository on GitHub, this is cbl/CUSTIN3.sqb

I started with cbl/CUSTIN2.sqb

  • created a .env file with the parameters for the DB.

  • removed GETDBID program.

  • updated to ACCEPT FROM ENVIRONMENT code.

  • updated the Compile script to remove GETDBID LLM from the compile step.

  • updated the Run script to export the parameters from the .env file to the Environment Variables.

This program will also run without needing to ask the user for the DB parameters.

Version 4

In the repository on GitHub, this is cbl/CUSTIN4.sqb

As I alluded to in Version 1, this is that completely re-written program.

Here's the thing, when I went to school, I completed all the programming assignments, got very good grades and all the professors said I was prepared to get a job as a programmer.

At the first job, I was told what I would be doing and was given the name of the program I would work on.

I logon to TSO/ISPF, go to the PDS, open the member, start reading it and thought, "What is this? It looks similar to what I created in school but it is really, really different."

Every company has a standard and/or style that all(most?) code adheres to.

At some shops, it is kind of loose, at others, it is VERY rigid.

This is an example of getting the same result; just doing it a different way by applying a different structure to the program.

As I continue to add programs to the repositories, they will "follow along" with the book or tutorial or website but will be using this structure.

Version 5

In the repository on GitHub, this is cbl/CUSTINQ.sqb

Just as CUSTIN2 was converted into CUSTIN3 by replacing the "CALL to GETDBID" with "ACCEPT FROM ENVIRONMENT", this is CUSTIN4 converted into CUSTINQ the same way.