One of the challenges facing IBM Z customers is that while their experienced sysprogs are able to expertly drive and operate z/OS, their IT folks coming from a Linux or Windows background may find it a steep learning curve to become fluent in the myriad of mainframey concepts like TSO, REXX, JCL, RACF. They're often more familiar with the world of unix shells, windows batch files, or languages like python or php.
This is the design point behind Zowe, an open source project owned and managed by the Linux Foundation. How to make the mainframe familiar to folks who didn't grow up with mainframe computing, how to make the mainframe open so different software vendors can collaborate on shared tooling and function, and how to make the mainframe as simple to operate as other platforms.
Where to begin ?
How do most IT folks operate their laptops ? Through commands like ls or dir to list contents of a directory, punched out on a terminal or command prompt. It's not just limited to operating your local machine however, commands like git push or docker compose build allow your shell to interact with source code repositories or provision distant build machines. What if we could do the same to a mainframe ? This is the purpose of the Zowe command line interface (CLI).
Picture this. You're at your laptop and you need to browse some mainframe partitioned data set members and their content. Many of us would open a 3270 emulator, log on with our TSO user ID and password, type ISPF and enter option 3.4, fill in the high level qualifier (HLQ) of the data sets, and use a combination of function key 8 and 7 to scroll, type B to browse, M for member, E for editor, and view the content in glorious green text on a black background. This scenario hasn't changed much since the last millenium.
Now picture this. You're at your laptop terminal and you type zowe files list data-set HLQ.*. This then lists all data sets for the high level qualifier right before your eyes. You then want to get the contents of a data set. zowe files download data-set HLQ.PDS(MEMBER) brings it to your laptop, whereupon you can edit it in your favourite PC editor (which could even be Microsoft Word), and then if you had been editing job control language you can follow up with zowe jobs submit local-file /hlq/pds/member.jcl. This is the beauty of the Zowe command line interface (CLI). You don't need to switch context from your PC to the mainframe.
Because the Zowe CLI is executing from your PC (running Windows, Linux, MacOS) you can blend mainframe commands and data with the best of breed tools that you have on your laptop. For example, if you have a Jenkins server that needs to submit a job, get the output, and analyze it for return codes or error messages you can do this in your favourite scripting language. You remain where you are already skilled and familiar, and the Zowe CLI presents the mainframe right into your lap.
Show me Zowe CLI in action
A picture speaks a thousand words. The bash script below was written by a DevOps colleague who understood javascript, was fluent in unix shell, but wasn't a mainframer. They are getting mainframe content and analysing it with jquery libraries to check whether data sets need deleting. They are streaming JCL directly from the script to be submitted on the mainframe. They are injecting shell variables to affect the job. They are doing all of this from script they can run on their PC without having to log onto the mainframe.
All of the old with all of the new
Many customers I talk to that have adopted the Zowe CLI are using it as a bridge between the world of folks experienced with JCL and REXX mainframe languages across to the world of newer IT folks familiar with off-platform or distributed technologies. Folks using script languages are used to named $VAR variables that form the basis for conditional logic. What about the hand off to JCL ? No worry folks, if the JCL has an & tag this can be substituted at runtime. Por example, if you have some JCL that needs a file name you want to set dyamically, write the line as //SYSUT1 DD DISP=SHR,DSN=WINCHJ.JCL(&FROMDS). Then when you submit this from the Zowe CLI if you want this value to be WINCHJ.JCL(FOOBAR) specify zowe jobs submit --jcl-symbols "FROMDS=FOOBAR". To show this running full throttle, the youtube clip below shows the some JCL with the IEBGENER that copies a data set member where the value of the target is being injected by the Zowe CLI.
This technique is used to good effect by a number of mainframe shops where I've seen teams rewrite and reshape on platform JCL with variables specifically so that the off platform folks can run them without even being aware of the JCL syntax. It's similar to how REST APIs can be used to open up traditional transaction processing programs with native z/OS interfaces to the world of the web.
There's more to life than JCL
Yup, there is more to life than JCL, and there is more to Zowe CLI than submitting jobs. The Zowe CLI can run TSO commands.
zowe tso issue command time will return the time.
zowe tso issue command exec 'HLQ.REXX(DOSTUFF)' 'ARG1' 'ARG1' will run the REXX member
HLQ.REXX(DOSTUFF) passing in the argument values. What the REXX member does is up to it and could/should be authored by a skilled z/OS REXX coder, however what the script that calls the REXX does it up to it and can be part of a CICD pipeline, an automation server, or a script that chains commands together to orchestrate some mainframe activity.
What about other mainframe tools ?
The core Zowe CLI talks to core z/OS. It can work with the MVS file system, the USS file system, JES, TSO, and issue console and MVS commands. Think of it as the interface you get on your mobile phone when you get it home from the store with a basic compass, map, calculator and other core apps. The first thing you probably do with your new shiny phone is visit the app store and download some games or cooking or astronomy or exercise apps, or whatever else floats your boat.
The same is true with Zowe. Because Zowe is open source and built to be an extensible platform it has published the APIs by which others can build CLI plugins. There are currently
28 extensions for the Zowe CLI, covering a wide range of tools from IBM that includes
System Automation,
Workload Scheduler,
NetView,
z/OS Connect, as well as the core z/OS runtimes for CICS, Db2, MQ and IMS. The Zowe CLI is not tied to just IBM tools and there are extensions from Phoenix Software, Broadcom, and MicroFocus. The
Zowe CLI reference documentation lets you view the scope and syntax of the CLI commands available through the vendor community.
What about security ?
The Zowe CLI uses TLS encryption of data between the client and the z/OS server, which is the same protocol used by web browsers to allow you to do secure banking and shopping. Each time a zowe CLI command is issued the client request has to identify the TSO user ID and z/OS will only perform that request if they're allowed to do. The password for the TSO user is entered by the user when they first configure their zowe CLI and stored securely on their laptop in the same location used to store other operating system passwords, away from the prying eyes of malware. For shops that don't allow persistent passwords the Zowe CLI also supports one time passwords (that get exchanged for a session token), multi-factor authentication, as well as x.509 client certificates.
How can I learn more ?
Visit
zowe.org to see all the great stuff going on in the community. There is way more to Zowe than just the CLI (such as the popular Zowe Explorer VS Code extension or the web browser Zowe Desktop interface to the mainframe), as well as some exciting incubator projects. To get started with the Zowe CLI there is great
on-line documentation.
Next time someone you see someone having to use mainframe interfaces that are unfamiliar to them, ask them what they are used to. If they've grown up in the world of Windows, Mac, Linux tooling then please introduce them to the Zowe CLI. It'll allow them to stay in their familiar world and yet become a skilled productive mainframer.
This is the design point behind the first of Zowe's goals, which is to build an open, simple and familiar interface to the mainframe.
With Zowe CLI, JCL substitution variables, 28 vendor extensions, and passing parms to REXX scripts, this allows old hand mainframers to give the new hands endpoints they can use to automate and operate z/OS. This is the design point behind the second of Zowe's goals. All of the Old with All of the New.