Written by Joe Winchester, Member of the Zowe Leadership Committee, Open Mainframe Project Ambassador and Senior Technical Lead at IBM
The Open Mainframe Project’s Zowe community is excited to announce that its 1.22 software release is now available. This blog covers some of the main highlights of the new release as well as the demos the Zowe squads shared in a community meeting on June 21.
High Availability
In 1.22 the Zowe z/OS component can be configured for high avaiability (HA). This is delivered as a technical preview to allow customers to try the functionality and give feedback before it will become fully included in the v1 long term support release in future.
Prior to HA the Zowe z/OS components were started with the ZWESVSTC proclib which brought up a single LPAR started task containing number of micro-service address spaces. Clients connected to the API Gateway server through port 7554 to access endpoints like the Zowe Desktop, the API Catalog, CLI token based authentication, or other services. The design goal for HA is to support Zowe being started on multiple LPARs across a parallel sysplex, so if a single LPAR goes down, or individual endpoints on LPARs are unavailable, the Zowe cluster remains functional and can route work between LPARs and services.
The Zowe HA software is not a separate download and include in the 1.22 release convenience build or SMPE rollup PTF. The configuration steps are different and described in Zowe High avaiability installation roadmap.
Because the different Zowe instances need to behave to the clients as though they are one data needs to be shared intra-zowe, and this is achieved with a new service The Zowe API Caching Service. This uses a shared VSAM dataset to store data and the new member ZWESVSM that contains the JCL needed for its creation.
To start Zowe for HA there is a new proclib ZWESLSTC that brings up the Zowe address spaces across the sysplex. The configuration data that controls the instances is specified in a new file zowe.yaml. For folks who have used the instance.env configuration file this is still available and will remain functional throughout Zowe version 1, however to support HA its successor zowe.yaml must be used instead. There is a convenience script convert-to-zowe-yaml.sh that takes instance.env as input to product a zowe.yaml file. Even for customers who aren’t using HA it’s recommended to start switching to use zowe.yaml as this provides more functionality and flexibility for configuring Zowe startup for ZWESVSTC as well as being a pre-req for ZWESLSTC. Examples of the greater flexibility provided by zowe.yaml is the ability to specify a separate zowe.externalCertificate and zowe.internalCertificate as well as other more fine grained ways to configure Zowe’s certificate usage.
Zowe documentation site
The documentation squad showed the work they’re doing to enhance the layout and navigability of the documentation site https://docs.zowe.org, a preview of which is available at https://zowe-docs-testing.netlify.app/. Key features are:
- Dark move available with a toggle indicator to switch between dark background / light text and vice-versa.
- Search box more prominent with keyboard short cut mapping
- Changed from 2 column to 3 column layout, with headings 1 and 2 on left hand side and headings 3 and 4 on right, meaning there isn’t such a deep tree on the left before finding content
- Left column is collapsable/expandable to make better use of real estate
- Graphics can be zoomed in and out in place with a magnifying glass icon
- PDFs can be created with an easy link on each page
- Feedback to create an issue with the documentation on each page that opens up a new GitHub issue in the Zowe documentation site repository with the page link carried across
One of the biggest areas of feedback in the recent Zowe user survey was to make the documentation more intuitive, more complete, and easier to use in order to understand Zowe and all of its functionality. Migrating the documentation site from VuePress to Docusaurus to improve its navigability and usability in 1.22 is the first in many steps to improve Zowe documentation. If you’d like to give the squad any feedback please use the git issue 1721.
API Mediation Layer
For z/OS deployment the Caching service used for sharing state between connected Zowe instances can be in-memory for a single LPAR or shared VSAM for LPARS in a parallel sysplex. The Zowe USS components are able to run off z/OS and in this scenario Redis can be configured as the caching service which uses a master and sentinel node model. Because the Caching service is storing data on behalf of Zowe instances that it can serve through REST API requests across LPARs, this data needs to be secured so only trusted clients can access it, for which client side certificates are used. Although Redis is only supported for off z/OS deployments of Zowe USS components, there is an epic to look at using Redis on platform for a full z/OS software stack.
The API Mediation Layer in 1.22 introduces an API for changing a user’s password which extends the scope of what can be done by clients. This is done with the <gateway_host>:<gateway_port>/gateway/api/v1/auth/login URL with a JSON body of
{
"username" : "userID",
"password". : "existing" ,
"newPassword" : "newpswrd"
}
One enhancement that vendors extending the API Gateway have requested is for more control over API routing, where that if a gateway is used as a proxy between their clients and servers, routing can be influenced between which from a family of servers a client request is dispatched to by the gateway. This is important in scenarios where the servers may themselves have state kept for a particular client session, and also where for scalability it might be more performant to have single servers be dedicated to particular sets of users. To do this a new header X-instanceId can be specified on API requests to the gateway with the value <host>:discoverableclient:<port> in which case the request is routed to that instance of the service. To determine the value of instanceId associated with a particular service this can be retrieved from the API Gateway’s discovery APIs (available through the catalog), A future release of the API Gateway will allow the instanceId to be returned in the response body which will allow clients to let the gateway shard the initial logon request to the most available server and then through the instanceId target the same service with subsequent requests. More functionality is planned in this area and the git epic 1378 can be used to give the squad feedback and track progress of this important piece of function.
Zowe CICS Explorer
The Zowe CICS Explorer is a new addition to Visual Studio Code that builds on the Zowe Explorer (which provides access to data sets, USS and JES) where the Zowe CICS Explorer extension provides access to CICS regions and their programs. The .vsix file is available at https://github.com/zowe/vscode-extension-for-cics that has instructions for how to install it into VS Code. It uses Zowe CICS CLI profiles and shows a list of regions together with their programs. More than one profile can be shown side by side which is a nice feature allowing you to work with multiple CICS regions even if they aren’t in a CICS plex (although if your Zowe CICS profile is pointing at a plex the Zowe CICS Explorer shows all the regions in the plex). The list of programs excludes all internal CEE, DFH, … programs and lets you filter by program name mask to narrow down on your applications’ programs. The menu actions against a program are Disable/Enable and New Copy and Phase In. You can also retrieve the attributes for a program as well as for a region.
If you’re an existing CICS user and enjoy using the Zowe Explorer, please check out this new extension and give us feedback for what is missing and what the squad should work on next. The existing MVP is just to allow programs to be listed and new copied, and future iterations may include support for more resource types (local files, transactions, URI maps,…), maybe support for CICS buindles, web services, … Zowe is an open source project driven by community and end user requests so please let us know what’s missing and you’d like to see included.
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 below.
