Build a COBOL/CICS Application with 30 Lines of Script Code

In the last post, I introduced a super build engine for Mainframe software projects: Endevor Team Build, which:

• Supports HLASM, COBOL, PL/1, Metal-C, LE-C/C++, CICS, and DB2;
• Handles declarative and automatic dependencies;
• Uses Javascript for very complex projects;
• Mirrors your Endevor project to your PC;
• Publishes/deploys the artifacts to binary repositories or PDSE data sets.

However, you were not convinced by the single-unit hello-world demo in the last post, were you?

This time, let’s look at a real-life COBOL/CICS project: the Slick Oil company’s account management system which allows users to create, remove, update, and display employee accounts and their work items.

Let’s look at the demo application’s frontend UI first:

The web UI

The 3270 terminal UI

The overall structure of the demo application is shown below:

Demo application

We will only focus on the parts that will be handled by Endevor Team Build, which are the modules inside the green box in the above diagram.

As a typical CICS project, it has each function implemented as a CICS transaction in a separate COBOL unit. Each has a BMS unit as its 3270-based UI. All modules share a few common COPYBOOKs.

The structure of the project’s directories is as below:

The structure of the project files

• The shared COPYBOOKs are in the COBCOPY directory.
• The CICS transaction units are the *.cbl files in the COBPGM directory.
• The MAP directory holds all the BMS units.
• The final outcome will be a group of load modules, named “SLICKP0”, “SLICKP1”, …, “SLICKPS”. They will be generated in the “build-out” directory (not shown here) and finally will be deployed in a PDSE the CICS region can access.

Now let’s look at the build script of this project section by section. Thanks to the JavaScript language and the Standard Library, you will find the build script very tidy and comprehensive.

First, we process all the BMS units:

Since we used a file glob pattern “./SLICK/SLICK/MAP/*”, we only called the “compile.bms()” API once to process all the BMS files. The “syslibs” argument tells the API which CICS macro library should be used.

Next, since the COBOL source files have embedded CICS statements, we need to translate them by the CICS precompiler using the “compile.cobol_cics()” API:

Again, we used a file glob to avoid specifying the source files one by one. We also specified some options and the load library for the precompiler by the “opts” and “steplibs” arguments respectively.

After the first 2 steps, we now have the translated COBOL source files and compiled BMS units, it is time to compile the COBOL source files into object files:

We called the “compile.cobol()” API with 5 arguments. The first two tell the API that we want to use the outcome of the BMS processing and the CICS pre-compilation as input. The “opts” and “steplibs” serve similar purposes as we have seen. The common COPYBOOKs are specified by the “copyPaths” argument. As you see, we can use USS paths and MVS data sets at the same time.

Lastly, we bind the load modules:

Similar to the compile API, the bind API also takes the outcome of the previous steps as input. The “separateModule: true” tells the API to generate a load module for each input object file.

As an optional step, we can use the file copy API to deploy the transaction programs to the PDSE associated with the CICS region:

Or publish them to an artifact repository:

You can skip the above optional steps and use your company’s existing deployment mechanism. If you need to run a USS program or shell script to trigger the deployment, just do this instead:

You can also run REXX or MVS programs (APF or non-APF) in the build script that are needed by your build logic but we will not dive deeper in this post.

That’s all it takes! Now you have seen how we build a real-life COBOL/CICS application with just 30 lines of code. Look at the whole build script again, tell me how you feel:

The complete build script for the demo COBL/CICS application

If you think it is easy to create and maintain, you are spot on.

But Endevor Team Build is not all about simplicity. Besides the Standard Library APIs, it also provides you with a lot more useful built-in modules, with which you can almost do anything on z/OS. For example:

• The “filesystem” module lets you manipulate USS files and directories;
• The “child_process” module lets you run USS programs even in parallel;
• The “mvs” module lets you run MVS programs and do dynamic allocation;
• The “crypto” module helps you leverage the hardware ability to calculate SHA1 code for files and strings really fast;
• The “adata” module lets you extract file/library records from the ADATA generated by many z/OS compilers.
• and so on…

However, in my opinion, the best thing in Endevor Team Build is not the API but is the JavaScript interpreter, because it is a general-purpose programming language that almost every programmer in the world can work with. According to the 2021 Developer Survey 2021 by Stack Overflow, JavaScript has been the most commonly used programming language for 9 years:

Source: Stack Overflow Developer Survey 2021

It means you and your team do not need to invest extra time in learning a new scripting language. You only need to become familiar with Team Build’s standard libraries, either for building your software projects or for automating your daily work on z/OS.

In my next blog, I will show you another powerful tool in Endevor Team Build: Exportz. It mirrors the existing Mainframe projects managed by Endevor to your PC so you can use your favorite editors to change the code and take full advantage of Endevor Team Build.