Many IT professionals are used to having command line interfaces to interact with their systems and applications. What is we could the same level of productivity to the keyboard army so they can manipulate their z/OS environment directly from their PC terminal ? What if this could be scriptable and used in scenarios like devops pipelines, automation, and other orchestration products running off z/OS (like Jenkins, Travis, Bamboo) but needing to get at mainframe data and services. This is what the Zowe CLI was built to achieve.
The
Zowe.org open source project is owned and managed by the Open Mainframe Project (OMP) which is part of the Linux Foundation. At the initial design session three words were set as its goals to apply to the mainframe:
Open, Simple, Familiar. The mission was to make the mainframe usable to folks who are familiar with other computing environments. For many IT professionals despite the plethora of GUIs in existence, the way folks interact with applications is still through text commands. For a windows, linux or mac user typing
mkdir,
cd or
ls to create and navigate through directories is often the go-to interaction model, which when coupled with muscle memory are very productive ways to drive around a PC's file system without lots of reaching for the mouse or dragging and scrolling to get things done.
Progressive DiscoveryIf you don't know the syntax for a Zowe command, just ask ! The image below shows what happens if I think "Hmm, I'd like to use Zowe CLI to list some data sets".
zowe command shows me the files group exists.
zowe files then shows me what I can do with files (copy, create, delete, download, upload, list, and more...). Now I type in
zowe files list and I see that I can work with unix file mounts and file systems, as well as data sets and their members. I'm not sure what the right syntax is for data sets but no worry, zowe files list ds -h shows me some samples of syntax, leading me to enter
zowe files list ds "WINCHJ.*" (my HLQ is WINCHJ) and, ... I have a list of my data sets.
This kind of interaction model, type in part of a command, get help feedback for the remainder, is pervasive throughout the Zowe CLI. The full range of commands are too many to list in this blog, but you can work with jobs (submit, cancel, list files), issue tso and console commands, manipulate USS files and directories.
What system and which user ID is running these commands ?
I did skip a step above, which is to define the z/OS system that my commands run against. By default the Zowe CLI comes provided with the ability to connect to z/OSMF and call down to its REST API services. If you don't have z/OSMF configured you can also work with FTP and if you have the IBM Remote System Explorer (RSE) server installed then you can also configure the CLI to use it as an API back end. Which you choose is up to you and there are pros and cons of each service provider.
For the user ID the profile contains the TSO user ID. The password can be stored in the PC's native credential manager, so you'll be promoted for your desktop user ID the first time you use the CLI to prove you've got authority to retrieve it from there (much like the way a web browser stores passwords). Alternatively the CLI can be configured to work with multi-factor authentication products so a one time use password can be used on entry which then generates an authentication token.
Why don't I just ssh into z/OS or use TSO ?
Good question. ssh on z/OS is pretty powerful so you can just use it to get into z/OS and work there for USS. It doesn't support JES and MVS access, but more importantly than that when comparing against the Zowe CLI, once you ssh into z/OS that's where you are. You're in the mainframe environment. The CLI is the familiar part of Zowe where you are off platform, and being there you marry CLI commands with desktop unix commands like grep or awk, and create powerful scripts. This is the most common deployment scenario we see for CLI where the commands are embedded in devops pipelines or automation scripts that drive down onto the mainframe.
The snippet below looks like a piece of Unix bash shell, which it is. However if you look closely you'll see statements like
zowe zos-files create data-set-classic $DEMO_PDS which is a CLI call to create a dataset with the name of the unix variable
DEMO_PDS. Further down the
zowe zos-files upload stdin-to-data-set <<EOF //COPYJOB JOB ... is submitting a job using JCL that's in-lined into the shell script. No need to log into z/OS. No need to have the JCL statically held in a data set.
What more can I do with CLI ?
The list of available CLI command groups isn't fixed - it can be extended ? This was very key to the initial design principles of Zowe to create a community and ecosystem where capabilities can be provided by third parties such as vendors or even mainframe customers to suit their scenario and use case. The Zowe CLI currently has 25 extensions ranging from Phoenix Software EJES, CA Endeavor, IBM Remote System Explorer, IBM Z Workload Scheduler, IBM z/OS Connect, and the major subsystems CICS, Db2, MQ, and IMS.
How do I get the Zowe CLI ?
The CLI is a node application that can be installed directly from npmjs.com. Once you have node on your laptop, just run the command npm install -g @zowe/cli@zowe-v1-lts. The documentation at https://docs.zowe.org/stable/user-guide/cli-installcli.html has more information. I hope you enjoy your journey to make the mainframe more familiar, and become part of the growing Zowe user community. If you need to chat to the squad who built the CLI they'd love to hear from you and collect requirements for missing features or enhancements. They're on slack at https://openmainframeproeject.slack.org/ and the #zowe-cli channel.