The Open Mainframe Project Zowe community 1.24 software release is now available. This blog post covers the new and updated features that were presented on the September 20th System Demo. Zowe release occur every six weeks and details of how to join them, and all Zowe calls can be found on the Open Mainframe Project calendar. These are Zoom meetings and everyone and anyone is encouraged to join, listen and learn what the squads are up to, as well as give input and feedback to help shape future Zowe release and continue to make the mainframe open, simple and familiar for its users and vendors.
You can read about some of the main highlights of new and updated contents for the 1.24 release below or watch it in action in the systems demo video.
Command Line Interface – APIML token auto-retrieval during secure configuration
As part of Zowe vNext the CLI squad showed improvements to how configuration data can be secured. The command zowe config secure will prompt for all of the secure properties defined in a team configuration file such as userID and password, however in the case where one of these is a tokenValue for a base profile, it’s unlikely the user will be able to recall what the tokenValue should be (it’s a long string for use as a bearer token on REST API calls to benefit from single sign-on and one time use passwords). With the enhancement when the tokenValue is needed rather than the user having to enter it (which would have required them to previously log into the API Mediation Layer and generate one or else run the zowe auth login apiml --show-token and copy the result to their clipboard beforehand, the config secure command now recognizes a tokenValue is needed and will log into the APIML to get a token that it stored, without this being echo’d to the user or requiring clipboard transfer. This is part of the continuing journey that Zowe is on to provide the best and most secure user interface experience that enterprise customers are asking for. For customers wanting to use Zowe vNext it’s available for download at https://www.zowe.org/download.html selecting vNext preview, or else can be installed with npm install -g @zowe/@cli/next
API Mediation Layer supports AT-TLS
The API Mediation Layer now fully supports AT-TLS. This means that all of the function available through https:// encryption and communication can now be reached using AT-TLS and is useful for sites who are using http:// connections and securing them with AT-TLS and wish to enjoy a full APIML experience. To achieve this update instance.env with the parameters
SPRING_PROFILES_ACTIVE=attls APIML_SSL_ENABLED=false
In addition the APIML needs to know the server certificate described in the AT-TLS rule. Full details on how to do this are covered in a new Zowe documentation section.
API Mediation Layer token exchange
One of the popular features of Zowe’s API Mediation Layer is its ability to provide token based authentication on its northbound edge for clients wanting to connect to southbound z/OS services, delivering an SSO facade that can be extended to multi-factor authentication scenarios. A new feature in 1.24 is the ability for a client who has a token to exchange it for another with a longer expiry date. This is useful in the situation where the existing token perhaps has a fixed expiry of 8 hour and the client needs wishes to recycle it for another 8 hours to provide a longer client window. This done with a new post request auth/refresh. To allow system programmers to control the endpoint visibility it needs to be explicitly enabled with the APIML_SECURITY_ALLOWTOKENREFRESH=true value in instance.env. Both APIML_SECURITY_AUTH_PROVIDER of saf and zosmf are supported. If you use zosmf then to allow APIML to log into z/OSMF to generate pass tickets APIML_SECURITY_ZOSMF_APPLID=IZUDFLT needs to be set also with the correct APPLID, see Enabling Passticket Creation for APIML.
Zowe Desktop logon failure message improvements
The Zowe Desktop allows users to log on to z/OS through their web browser, and then access a rich set of apps ranging from the in-built File Editor to vendor plugins. If there were any errors logging into the desktop prior to 1.24 a generic failure message was shown that required the user to look into logs to further diagnose, or in some cases just wait for Zowe initialization to complete. With 1.24 the details of why the login failed are displayed that can be expanded to see the component name where the error has occurred. This can then be used to determine any actions needed to correct the login by comparing the failure with the list of know problems in the Zowe troubleshooting guide chapter Cannot log into the Zowe Desktop, giving end users and teams providing support better problem determination information,
Zowe Explorer profile validation for FTP
The Zowe Explorer allows users to work with data sets, USS directories and files, as well as Jobs. The z/OS service that provides the back end for these can be either z/OSMF REST APIs or else z/OS FTP. If the user has an FTP profile (usually on port 21) then the Zowe Explorer profile shows the status of the profile as a round circle that switches to green when a connection is first successfully made, or red if the connection fails together with a message with the return code error.
More information on how to configure Zowe Explorer for FTP can be found at Zowe Explorer Extension for FTP, which is very useful for customers who either don’t have z/OSMF REST APIs configured, or may more comfortable using FTP in environments such as zD&T.
Zowe Explorer now provides access to the base imperative logger
As well as Zowe providing base functionality from its community and squads, vendors and others can build extensions to each of Zowe’s core components. The Zowe Explorer now provides the ability for extensions to log messages that will appear both in VS Code and also in the base log, which aggregates all Zowe messages across the different extensions in a single place to help problem determination. The Zowe Explorer is the fourth component to provide a conformance program for vendor VS Code Extensions to be able to integrate well into the base Zowe Explorer, and access to the imperative logger provides extensions with the ability to allow end users to differentiate the source of errors and identify which plugin, and which vendor, to contact for support and assistance. Sample code to leverage the logger is shown below.
const logMessage = "Test Error";
const logger = new IZoweLogger("Zowe Explorer Extension Template", loggerPath);
logger.logImperativeMessage(loggerMessage, 4);
ZoweVSCodeExtension,showVsCodeMessage(loggerMessage, 4, logger);
Zowe Explorer Profile Cache API
One of the latest additions to the Zowe Explorer stable of VS Code extensions is the Zowe Explorer for IBM CICS. Very similar to how the Zowe Explorer builds on top of the Zowe CLI SDK classes, the Zowe Explorer for IBM CICS builds on top of the Zowe CICS CLI and allows users to connect to regions to view resources and perform developer tasks such as Program:NewCopy or LocalFile:Enable. To enable the Zowe Explorer for IBM CICS to introduce a CICS view into the Zowe Explorer and keep its profiles isolated from the base z/OSMF profiles, the API method ProfilesCache.registerCustomProfilesType(String type) has been introduced. For more information on how to use this see the class doc at ProfilesCache.ts.
If you have the time please fill out the Zowe survey where we’d love to get your input and thoughts that will help shape the content of future Zowe release as the community continues its journey to make the mainframe open, simple and familiar. The deadline to submit responses is November 30.
