Written by Joe Winchester, Member of the Zowe Leadership Committee
The Open Mainframe Project‘s Zowe community ended their first 2021 program increment with the availability of the 1.21 release. This includes some great content that was showcased by the squads at the System Demo on May 3rd. The video of the 1.21 demos can be found on Open Mainframe Project’s Youtube Channel – click here. Additionally, all previous releases that are held in github, and all future release demos (together with all Zowe meetings) are in the Open Mainframe calendar. All are welcome to join any call to not only see what the community is up to, but to give feedback and influence Zowe’s direction and content. A summary of the updated content in 1.21 is available in the New features and enhancements documentation chapter . This blog post summarizes some of the major enhancements and changes.
Zowe CLI – Submit jobs with replacing of symbolic variables
The Zowe command line interface allows folks to issue commands, either stand-alone or more commonly within scripts such as devops pipelines or other automation toolchains, to orchestrate z/OS tasks. One of these is the command
zowe jobs submit data-set "HLQ.PDS(MEMBER)"
This submits the contents of the PDS “HLQ.PDS(MEMBER)” to the JES queue to be executed as job control language, or JCL. What however if you wanted to pass some parameters into the JCL from the Zowe CLI command ? This is where symbolic substitution comes into play. In the original JCL you can use & characters to denote variables whose contents are supplied with the --jcl-symbols keyword on the CLI.
An example is shown above where the JCL members WINCHJ.JCL(COPYJOB) has been written to use the program IEBGENR top erform a copy. Instead of these being harded coded through the JCL has the lines
SYSUT1 DD DISP=SHR,DSN=WINCHJ.JCL(&FROMSYM) SYSUT2 DD DISP=SHE,DSN=WINCHJ.LCL(&TOSYM)
When this file is submitted as a job it fails with a return code of JCL ERROR because it’s not well formed. The values of &FROMSYM and &TOSYM are symbolics (which must be 8 chars or less and begin with an ampersand & symbole) waiting to have their values supplied. In our example these will be the name of the member to copy from (in our case it’s called FROM) and the data set member name we want IEBGENER to copy into (in our case called TO). This can be done with the CLI command replacing the FROMSYM and TOSYM variables.
zowe jobs submit data-set "HLQ.PDS(MEMBER)" --jcl-symbols "FROMSYM=FROM TOSYM=TO"
Zowe Explorer – Issue TSO Command
The VS Code marketplace extension Zowe Explorer has been extended to allow TSO commands to be issued using the pop-up menu action Issue TSO Command against a z/OSMF profile. If there is an existing TSO profile it will be used, if there is more than one you’ll be promoted to select, and if there isn’t one you’re asked to enter the TSO account ID. For more information on the TSO profile see Zowe TSO and CLI commands.
Zowe desktop – ZSS supports TLS
The Zowe desktop is composed of two components, the Z Lightweight User Experience (ZLUX) node server that serves the desktop web pages, and the Z Secure Services (ZSS) C server that does the native z/OS calls. An example of these working in concert is with the desktop File Editor that shows a tree of data sets or USS directories. ZLUX serves the angular java script classes, and ZSS fetches the data. ZLUX talks to ZSS using REST APIs.
Before 1.21 ZSS was only able to accept http:// traffic, which meant it wasn’t using a secure socket. This was an issue because the port used by ZSS either couldn’t be surfaced outside the z/OS network stack or else needed to be configured with AT-TLS to ensure that the socket communication was encrypted.
With 1.21 ZSS can now accept traffic over a secure socket, which means you can safely expose its port externally outside the z/OS network stack without the need to configure AT-TLS. If you don’t want https:// and want to revert to http:// you can set the instance.env variable ZOWE_ZSS_SERVER_TLS=false.
Zowe z/OS Component Configuration – NONSTRICT_VERIFY_CERTIFICATES
The Zowe API Mediation Layer is a reverse proxy gateway server that allows client requests to be routed to z/OS services. When the z/OS components register against the gateway their certificate is checked to ensure it’s valid, and if so the certificate is added to the APIML’s trust store. With some Zowe customers however even through their certificate was a good one, it didn’t have the correct host name or the certificate authority wasn’t a known one so the trust failed and the certificate was rejected. To override it was always possible to set the value ZOWE_APIM_VERIFY_CERTIFICATES=false in the zowe-certificates.env file in Zowe’s keystore directory. This told the API Mediation Layer to just not both checking anyone’s certificates, which always felt a shame as if the components registering had good certificates, but just ones that were either self signed, or signed for a different network address, why not use them ? For anyone who has used a browser against a site with https:// and received a self signed certificate they’ll be familiar with the “Untrusted certificate, do you want to proceed” warning.
Zowe now provides such a way to finesse what do to with invalid certificates with the addition of the ZOWE_APIM_NONSTRICT_VERIFY_CERTIFICATES value in the zowe-certificates.env file. The permutations are:
- Cert has trusted CA and a good SAN matching the server’s IP.
ZOWE_APIM_VERIFY_CERTIFICATES=true - Cert has trusted CA but a SAN that doesn’t match the server’s IP.
ZOWE_APIM_VERIFY_CERTIFICATES=falseandZOWE_APIM_NONSTRICT_VERIFY_CERTIFICATES=true - Cert has a self signed (untrusted) CA and a SAN that doesn’t match the server’s IP.
ZOWE_APIM_VERIFY_CERTIFICATES=falseandZOWE_APIM_NONSTRICT_VERIFY_CERTIFICATES=false
Zowe z/OS Component Configuration – ZWESSOTK and ZWENOSSO
One piece of feedback we’ve received from customer sysprogs is that we had too much configuration in shell scripts, and over time Zowe has addressed this by switching to use JCL members in the SZWESAMP PDS member created as part of the installation. With 1.21 the member ZWESSOTK was added, whose purpose is to create a PKCS#11 token and configure the required security setup. The JCL works with RACF and TopSecret (ACF/2 will be included in a future Zowe release) and performs tasks such as enabling the CRYPTOZ class, defining a USER.<token> and importing a JWT secret certificate from a data set into the security manager cert store.
For folks who want to get more involved with Zowe please create issues at https://github.com/zowe/community and let us know what we can do to help continue making the mainframe more open, more simple, and more familiar!
Watch the demo video:
