System Programming (Application Development Procedures)
Part Three - Challenge #11


A System Programmer does not know it all. However, they get very good at knowing which professional manuals to reference and figuring things out. The more they are required to figure out, the more effective they are in their System Programmer role.

DevOps is a popular clipped compound that emphasizes the collaboration and communication between business application developers and other IT professionals where Dev represents development and Ops represents other IT professionals that setup up and maintain the environment used by development. The other IT professionals include z/OS System Programmers. This relationship has existed for many decades in the mainframe environment, long before the DevOps clipped compound was introduced. An objective of DevOps is a standard way for all organizations to approach the plan, build, and run, of the development process with standardized procedures, practices, and tool sets. The primary objective of DevOps is to speed up delivery of applications and new application features through continuous integration (CI) and continous delivery (CD).

DevOps tool sets are software products based upon "Eclipse IDE, Integrated Development Environment" which is a workstation GUI, Graphical User Interface. IBM Z DevOps tool set is IDZ, IBM Developer for Z (formerly call RDz, Rational Developer for z). Prior to the GUI tool sets used by developers to interface with z/OS, the TN3270 TSO/ISPF environment was the primary development interface. The GUI interface makes the underlying mechanics of navigating z/OS transparent to the developers while meeting the objective of DevOps. However, someone must understand and maintain the underlying mechanics critical to the DevOps GUI tool sets.

Developers (Dev) are dependent upon procedures created and maintained by System Programmers (Ops) when the target system of development is z/OS. An example would be an IDE graphical user interface with a click selection to compile a COBOL program using a DB2 table as a data source. All the developer knows is how to make a GUI click selection where the result is the z/OS executable program to test.

The z/OS technical plumbing to build the z/OS executable program needs to be developed. A z/OS System Programmer would create and support the technical plumbing enabling a simple GUI selection. What occurs as a result of the GUI selection is totally tranparent to the developer.

The challenge explores the technical plumbing to make a developers job easier, enabling the developer to deliver applications quicker.


Things you currently know as the System Programmer to accomplish the challenge:

  • IDE GUI selection to compile COBOL source with DB2 table data source executes a JCL procedure to build the program executable
  • Sample JCL PROCs are provided by IBM. Local customization of the JCL PROCs were completed and successfully being used by the developers
  • The JCL PROC is in a Production JCL procedure library, VENDOR.PROCLIB, and the member name is CBLDB2

A developer reports a problem with the following details:

  • No program executable is available to test following selection to build executable
  • IDE GUI reports no COBOL syntax errors prior to selection to build executable

A System Programmer learns to get as many details as possible from the person reporting the problem, then applies knowledge of the z/OS environment that might be related to the problem to begin to define the real problem based upon the known symptoms.

The developer reports, "my computer did everything correctly. Your computer must have a problem with what my computer requested to be done". That is the extent of the developers technical knowledge to help you.

You ask the developer to select the compile from the IDE GUI for you to observe z/OS activity and problem symptoms.
You looked at the z/OS system log for activity as a result of the developer workstation request to compile.
For this challenge, you only need to review the steps the System Programmer took to isolate the problem. No action is needed by you until instructed.
The following actions were taken by the System Programmer:

Review of the z/OS System Log from SDSF in Figure 1. shows CBLDB2 JCL job submitted as a result of the developer, Z99999, requesting a COBOL compile from the IDE
Figure 1.
The system programmer, you, has the authority to view all JCL job output. Observe SDSF settings in Figure 2.
Figure 2.
CBLDB2 JCL job is selected to view output in Figure 3.
Figure 3.
CBLDB2 JCL job shows the LKED PROCSTEP with RC of 08 in Figure 4.
Figure 4.
? shows CBLDB2 DDNAMEs and ProcSteps
Figure 5.
Select of DDNAME SYSPRINT ProcStep LKED to see more details about RC 08
Figure 6.
Figure 7 shows the error. CLRSCN is unresolved - whatever that really means
Figure 7.
Figure 8. selects COBOL compile output view the source code
Figure 8.
Figure 9. show a find for CLRSCN anywhere in the COBOL compile listing
Figure 9.
Figure 10. finds a COBOL CALL of module "CLRSCN". This is a very significant problem symptom that resulted in the RC 12. You, the System Programmer, have information about this module "CLRSCN" that will be explained later.
Figure 10.
Figure 11. is a select of the CBLDB2 JESJCL to see exactly what was executed
Figure 11.
Figure 12. shows JCL job CBLDB2 is executing a JCL PROC, EXEC CBLDB2, that has the same name as the JCL job
Figure 12.
Figure 13. JESYSMSG shows JCL PROC library where CBLDB2 JCL procedure was found
Figure 13.
Figure 14. shows the JCL procedure, CBLDB2 was found in VENDOR.PROCLIB
Figure 14.

VENDOR.PROCLIB member CBLDB2 is one of the most complex JCL procedures.
Figure 15. is a diagram of the JCL CBLDB2 PROC which you are not expected to understand to complete the challenge.
However, references will be made to Figure 15.

Figure 15.

More things you know as the System Programmer

  • Developers were given executable module names to be called to provide local functions
  • CLRSCN was one those modules. CLRSCN will clear a screen during interactive processing
  • CLRSCN executable module is in data set name LVL0.LINKLIB
  • The Linkedit step in JCL PROC CBLDB2 is responsible for finding a "called" module
  • Linkedit step result was RC 12 due to failure to find CLRSCN
  • CBLDB2 JCL PROC linkedit step has JCL stepname of LKED
  • SYSLIB DDNAME concatenation in CBLDB2 LKED step must include LVL0.LINKLIB to resolve the problem

Take the following actions to recreate the problem using a private copy of the source, JCL, and JCL PROC:

  1. tso submit 'zos.public.jcl(dbrmlib)'
      Above JCL allocates a personal DBRM Module library as seen in Figure 15.
  2. Edit hlq.SOURCE data set
  3. Select s new member name db2fso
  4. Copy 'zos.mtm2017.public.source(db2fso)'
  5. Learning System IDs Only (AU0####), click on link below for special instructions.
    Learning System ID special instructions for this challenge.
  6. Change c all occurrences of ##### to last 5 digits of your ID
  7. F3 to save and exit
  8. Edit hlq.JCL data set
  9. Select s new member name CBLDB2
  10. Copy 'vendor.proclib(cbldb2)'
  11. F3 to save and exit
  12. Select s new member name CBLDB2J
  13. Copy 'zos.public.jcl(cbldb2)'
  14. Modify the JCL to reference the private JCL PROC previously copied into hlq.JCL member CBLDB2
    Insert line and enter the JCLLIB statement as seen below
    The reason is for EXEC CBLDB2 to reference private JCL PROC library to load CBLDB2 JCL PROC from your personal JCL library
  15. Submit, jump to SDSF status panel
  16. Select the CBLDB2 JCL job you just submitted
  17. The output shows your just recreated the RC 08 problem in LKED step
  18. Edit hlq.JCL
  19. Select the JCL PROC, CBLDB2
  20. Find the LKED step in the JCL PROC
  21. If done correctly, the action here will fix the problem
      Observe line 53 is the SYSLIB DDNAME
      All DD statements following SYSLIB DDNAME without any DDNAME belongs to the SYSLIB DDNAME concatentation
      The SYSLIB DDNAME concatention is searched for "called" modules
      LVL0.LINKLIB must be added to the SYSLIB DDNAME concatention
      Insert a line immediately after line 55
      Add data set name LVL0.LINKLIB in the SYSLIB DDNAME concatenation
      Remember to include DISP=SHR on the DD statement - mandatory for successful completion
      F3 to save and exit
  22. Submit the CBLDB2J JCL job located in hlq.JCL to test the change to the CBLDB2 JCL PROC
  23. Use SDSF to select the output of JCL job just submitted
  24. If CBLDB2 JCL PROC fix was successful, then LKED show RC 00
      BIND PROCSTEP of RC 04 is ok and expected
      If the JCL job fails, then correct hlq.JCL(CBLDB2) JCL PROC and try again
  25. A double check to verify success is to execute the compile program
      Jump to the the ISPF Command Shell =6
    dsn system(dbbg) starts a DB2 interface environment
  26. Once in the DB2 (DSN) environment
      Enter run prog(db2fso) lib(load) plan(z#####a) where ##### is your 5 digit ID number
      If you review Figure 15. Run box, that is what is being done below
  27. The successfully compiled program DB2FSO, begins execution
  28. Enter a valid 6 digit client number such as 000222
  29. The client number 000222 company name and credit payment information is displayed
  30. Enter 000000 to stop the program, then enter end to terminate the DB2 environment

The DB2FSO program could easily be a service for authorized employees to retrieve this information on their smartphone and to invoice the client immediately upon the delivery of the flours, sugars, and oils that were previously ordered by the client.

To get credit for the competion of challenge 11, submit the following:
tso submit 'zos.public.jcl(p3ch11)'
The JCL job writes information to P3.OUTPUT(#11) proving the challenge was completed.

Next: Challenge #12