Modern Tooling: VS Code and Zowe

Source: IBM Z Open Editor on the Visual Studio Marketplace; IBM Z Open Editor documentation; Broadcom COBOL Language Support on the Visual Studio Marketplace; Zowe overview; IBM Developer for z/OS documentation; Rocket Software documentation portal

Install one COBOL language extension, not both: IBM Z Open Editor if the shop uses IBM tooling and licenses, Broadcom COBOL Language Support (free) if it uses Code4z. Both give the features that make a copybook-heavy program navigable: a document outline of the divisions, sections and paragraphs, go to definition for a data name or a paragraph, find all references, diagnostics from a parser as you type, and expansion of COPY members from a local folder or a data set. The Open Editor also supports the embedded EXEC SQL, EXEC CICS and IMS statements of recent releases and, with a licence, features such as a preprocessor and a data flow view; which of its features are free and which need the licence is stated on its Marketplace page, and should be checked before it is rolled out. The Broadcom extension documents that it supports IBM Enterprise COBOL only, so it does not understand GnuCOBOL-only syntax (for example some intrinsic functions that GnuCOBOL adds).

A workspace setting tells the extension where to look for copybooks, so a program that says COPY LOANREC resolves to the copybook folder of the repository. The setting names differ between the extensions and are documented by each; the folder layout of DevOps and CI/CD for COBOL (programs in src, copybooks in copybooks) works with both.

Zowe is an open source framework (Open Mainframe Project) that exposes z/OS to modern tools through REST services and a command line. Two parts matter to a COBOL developer.

Zowe Explorer is a VS Code extension: a data set tree (with patterns such as the Circulation USERID.CIRC.*), a USS file tree and a jobs tree. A member opens in an editor, saves back to the data set, and the job tree shows the spool output of a submitted job. It is how a developer edits USERID.CIRC.COBOL(LOANCHK) without a terminal emulator.

Zowe CLI is the same capability as commands, which makes it scriptable. The command groups used by a COBOL developer are zos-files (data sets and USS files) and zos-jobs (jobs and spool), with zos-tso, zos-console and others for further tasks. The connection is not typed on every command. It comes from a team configuration file, a JSON file that names the host and port of the z/OSMF service and which fields are stored securely; the CLI documentation describes the user-level and project-level variants of the file, and the zowe config commands that create and edit them. A minimal file for the Circulation team has this shape (the host is a placeholder from the reserved example.com domain, and no real values appear):

The user name and password are marked as secure fields, so they are stored in the operating system’s credential store and never in the file; the file can then be committed to the project repository for the team, while each developer’s own credentials stay on their machine.

Typical commands for the working day, with the same data set names used on the other pages (z/OS; not run here):

The first lists the team’s data sets, the second and third move one program between the host and a working copy, the fourth submits the nightly job and waits for its output, and the last lists its instances. Options and defaults of each command are in the generated command reference, which is the authority; the command forms above are the same ones used on the JCL and data set pages.

Source: Zowe CLI: using team profiles; Zowe CLI: list data-set; Zowe CLI: download data-set; Zowe CLI: upload file-to-data-set; Zowe CLI: zos-jobs submit data-set; Zowe CLI: zos-jobs list jobs

IBM Developer for z/OS (IDz) bundles an editor, the compile and link steps, a debugger, code coverage, unit-test generation (zUnit) and related tools in one workstation product. It targets teams that want a single supported product from the vendor of the compiler and that already use the integrated pieces (the debugger and zUnit are described on the debugging and testing pages). The documentation is at the link below; the current release is not named here because the page could not be read for verification.

Rocket Visual COBOL and Enterprise Developer (the products that Micro Focus built and Rocket Software now sells) compile COBOL on Windows and Linux with their own compiler, which is dialect-compatible with IBM’s to a large degree, and can run CICS and file-based programs against emulated services. They are used when a team wants to develop and test COBOL without any mainframe connection or to run COBOL on distributed systems; the vendor documentation is the authority on dialects and licences.

Source: IBM Developer for z/OS documentation; Rocket Software documentation portal (Visual COBOL, Enterprise Developer)

For the programs that are portable, VS Code can compile and run with GnuCOBOL from a task. The file .vscode/tasks.json below defines two tasks: one compiles the current file into a build folder with -Wall -std=ibm and the copybook folder as the include path, the other runs the result. The problemMatcher turns the compiler’s file:line: warning: message lines into entries in the Problems panel.

The JSON parses, and the compile command it runs (with the variables replaced by VALLOAN.cob, copybooks and build/VALLOAN) built the validation program of the coding standards page with no warnings and ran it in a GnuCOBOL 3.2 container. The regular expression of the matcher was checked against real cobc output: for a program that moves to an undefined item, the compiler prints

and the expression captures bad.cob, 7, error and the message from the first line; the source lines that follow are ignored. The task assumes cobc is on the path of the VS Code terminal; on Windows that is the GnuCOBOL installation folder, on Linux a package or a build from the release tarball, and on macOS a package manager or a container. VS Code’s own task variables (${file}, ${workspaceFolder}, ${fileBasenameNoExtension}) are documented by the editor.

Source: GnuCOBOL 3.2 manual: compiling; Visual Studio Code: Tasks

Source code on z/OS has traditionally lived in partitioned data sets with a library manager for versions. Git is now supported on z/OS and workstations alike, and shops move to it so that the mainframe code gets branches, pull requests and history like every other code base. Three practical points:

The workflow itself is the same as in any language: a short branch, a commit per logical change, a pull request with the checklist of the coding standards page, and a CI run (DevOps and CI/CD for COBOL) as a required check.