Teaching an old dog to hunt in the new world of Zowe™
{Ecosystem} IBM Z NetView® was first announced in 1986 and has evolved to meet the changing needs of customers for decades. Now with Zowe that tradition continues! Are you familiar with the Open Mainframe Project’s Zowe Command Line Interface (CLI)?
Zowe is an integrated and extensible open-source framework for z/OS. Zowe offers modern interfaces to interact with z/OS and allows you to work with z/OS in a way that is like what you experience on cloud platforms today. Zowe CLI provides a command-line interface that lets you interact with the mainframe remotely and use common tools such as Integrated Development Environments (IDEs), shell commands, bash scripts, and build tools for mainframe administration or development. You can use these interfaces as delivered or through plug-ins and extensions that are created by clients or third-party vendors. In a recent blog I described how to use Zowe CLI to create scripts that can fully automate some of your typical, repetitive job scheduling activities, eliminating manual effort and even reducing the potential for errors, thanks to the IBM Z Workload Scheduler plugin for Zowe CLI.
In this blog I will describe the main capabilities of another set of Zowe CLI plug-ins, that were announced as a technical preview in this blog, that enable you to interact with IBM Z NetView®, with an interactive scenario that leverages these plug-ins to update the automation in place.
There are Zowe CLI users that use it interactively or via scripted automation to manage z/OS resources like dataset, jobs and so on. Other users leverage it in a more advanced way to perform multi-step actions within a script which is launched automatically if an event is caught. In general, a Command Line Interface offers a Subject Matter Expert (SME) the ability to concatenate commands in scripts to execute multi-step actions. These scripts can have variable substitution, use additional script functions (grep, awk, etc.) to build powerful productivity tools.
IBM Z NetView provides message and alert automation and network management to address your requirements for business agility on IBM Z systems. System and Network Automation addresses the continued drive for increased IT availability. IBM Z NetView is a comprehensive platform for maintaining and automating complex, multi-vendor, multi-platform networks and systems from a single point of control.
In the last couple of releases, the IBM Z NetView product was modernized to provide additional interfaces on top of the classical NetView 3270 console.
IBM Z NetView v 6.3 introduces an OpenAPI-conforming NetView server that handles front-end requests from applications and provides RESTful APIs that are suited for industry standardization to interact with automation and network resources. The server can be accessed using Zowe. The swagger page of these REST API is in the following picture.
IBM Z NetView v 6.4 continues to provide a modernized user experience through the integration of technologies that may aid in productivity. This is accomplished by introducing three new IBM Z NetView plug-ins for Zowe CLI, a command-line interface that administrators and operators can use to interact with IBM Z NetView from a personal computer or cloud platform: znetview-base, znetview-automation and znetview-network, that are shown in the following picture resulting from the zowe -h command.
In this blog, I will go through a scenario that leverages IBM Z NetView Zowe CLI plug-ins to manage the update of console automation that is in place … and more! In the scenario description, I will use the command line interface interactively, but obviously it is not limited to this kind of use, as mentioned above, possibly the real power is to concatenate the different commands across different z/OS products with CLI plug-ins in a script to have a real automation of the workflow.
There are many users that already leverage Zowe CLI, however I thought it could be useful to have this blog to show a Z NetView scenario step by step.
Zowe CLI with NetView plug-ins
The NetView team decided to have three different plug-ins to group the commands by functional area. Let’s take a closer look at the capabilities provided by the three Z NetView plug-ins.
Base plug-in enables clients to access core NetView information and issue most NetView commands. Note that the base plug-in is required if you want to use the network and automation plug-ins.
The specific categories of data are:
- Authentication to NetView through the NetView REST Server. As you will see in the scenario description, before you can issue any command made available as part of the IBM Z NetView plug-ins, you must authenticate to the NetView REST Server with a NetView operator that is defined to SAF.
- You can alternately authenticate using the Zowe API Mediation Layer.
- Canzlog messages.
Canzlog (Consolidated Audit, NetView and z/OS LOG) NetView component provides consolidated access to all NetView and z/OS system messages (including the netlog and syslog). Go here for more details. - Task utilization information
- List of NetView domains to which commands can be sent
Automation plug-in enables you to manage NetView console message automation table members or statements:
- Activate an automation table member.
- Download an automation table member.
- List active automation tables.
- Run a simulated test of an automation table statement.
- Upload an automation table statement.
- Validate an automation table member.
Network plug-in enables you to monitor your network:
- Display distributed DVIPA (DDVIPA) health information.
- Display distributed DVIPA (DDVIPA) statistics.
To see what commands are available as part of the different NetView plugins, I leveraged the online help:
zowe znetview-base -h
zowe znetview-automation -h
zowe znetview-network -h
I could iterate with the online help for each command to drill down on the different commands, their parameters and so on, owever there is even an option to see all the commands available without even installing the plugin is to leverage Zowe documentation here.
NetView automation: the scenario description
NetView message and alert automation means using the NetView program (and some associated products) to automate many of the information-system and network operations that usually require human intervention. The NetView program provides specialized services to assist in system and network automation. Through these services, the NetView program can perform many routine operator tasks either triggered by message or alert content or via timers . For more details about NetView automation, you can look at the official documentation.
In this blog, I will describe how to change an existing Message Automation Table Statement … if few words, the automation table enables you to respond automatically to messages. This table contains statements that define actions that the NetView program takes when it receives specific messages and MSUs. For example, you can issue a response in the form of an individual command, a NetView command list (CLIST), or command processor. For more details, look at the documentation.
The scenario being described will act on a specific automation table statement, named ZOWETBL, that is currently enabled. As shown below, the status of the automation table can be retrieved through the “autotbl status” NetView command … that can be issued (after passing NetView security) through the Zowe CLI znetview-base plug-in with the following command:
zowe znetview-base issue command “autotbl status”
This automation table statement triggers a command (ZOWEOLD) if a specific message is caught by NetView (message ID DSI200I). The content of the automation table statement can be visualized leveraging the following Zowe CLI command:
zowe zos-files view data-set NETVIEW.V6R3USER.CNM01.SMU.DSIPARM(ZOWETBL)
That returns the content of the dataset member that contains the automation table statement as follow:
The user scenario envisioned is that the automation table statement needs to be updated, specifically it is needed to change the command issued from ZOWEOLD to ZOWENEW … this action can now be performed even through the Zowe CLI leveraging NetView plug-ins, let’s see how to implement the scenario step by step.
Update an Automation Table Statement: the scenario step by step
To use NetView related commands in Zowe CLI, the first action to perform is to login to the NetView REST Server authentication service and obtain a token. When you log in to the NetView REST Server authentication service without any option, the token will be stored in your default NetView profile until it expires or you logout. We will use the command without any option:
zowe nvbase auth login
We will be asked to provide userid and password as in the following picture.
Once you are logged in, you can download the automation table statement to be updated with the following command:
zowe znetview-automation download automation-table “ NETVIEW.V6R3USER.CNM01.SMU.DSIPARM(ZOWETBL) “ — automation-table-file-path “C:\test\zowetbl.txt” — replace true
That will download in your local file system, in the path you specified, the automation table statement: It is a text file that you can open with the editor of your preference to edit it.
For the scenario purposes, I will change it to the statement below, intentionally causing an error by specifying a command to be run, ZOWENW, that doesn’t exist.
Before uploading the updated automation table statement, I can validate that it is correct and then we will run a simulated test as well against a recorded message. The NetView plug-in command to validate the syntax of it is the following:
zowe znetview-automation validate automation-table — automation-table-file-path “C:\test\zowetbl_error.txt”
As expected, I got an error from this validation … it says that “INVALID COMMAND NAME “ZOWENW” SPECIFIED FOR CMD KEYWORD OF EXEC ACTION”
At this point, I can correct the correct the bug injected and validate again:
zowe znetview-automation validate automation-table — automation-table-file-path “C:\test\zowetbl_updated.txt”
And the result is that validation was successful:
The message DSI200I we are using in this demo is issued when a task is stopped, so to trigger the message, I will issue the following command to stop AAUTSKLP task:
zowe znetview-base issue command “stop task=AAUTSKLP”
The next step is to record the message in Canzlog to test the updated automation table statement against the recorded message. In order to record the message, I need the Canzlog ID (CZID), so I can retrieve the last 100 messages from canzlog and look for message ID ‘ DSI200I ‘ to have the canzlog ID through the following command (that will return the result in JSON format):
zowe znetview-base list canzlog recent — number 100 — rfj >C:\test\last_100_messages.json
Opening the created file, I can search for DSI200I
and find the czid:
then record the canzlog message leveraging czid ID 10275359
zowe znetview-base record canzlog <<czid>> — record-member-name TESTREC — domain CNM01
then test it
zowe znetview-automation test automation-table — record-member-name “TESTREC” — automation-table-name “ZOWETBL”
The result shows me that there is 1 match out of 1 comparison, that tells me that the automation table statement works as expected.
I am now ready to upload the updated automation table statement through the following command:
zowe znetview-automation upload automation-table “NETVIEW.V6R3USER.CNM01.SMU.DSIPARM(ZOWETBL)” — automation-table-file-path “C:\test\zowetbl_updated.txt”
Note in the real-world, the automation table might be stored in a source code management system, checked and approved by someone else before placing in production. Those steps could also be automated via the Zowe CLI.
Then I can activate it through this command:
zowe znetview-automation activate automation-table ZOWETBL — position LAST
As you can see from the message the swap request was completed. To verify that the automation table statement was really swapped, we can stop and re-start the task used for the scenario, it will trigger the automation and the new command will be issued.
Other NetView commands available in Zowe CLI plug-ins
In the previous section, I already leveraged many commands available as part of the NetView plug-ins for Zowe CLI, let’s take a look at few other ones.
What about getting the list of NetView domains? It is possible through this NetView plug-in command:
zowe znetview-base list domains
You can even get the information about the active tasks, through this command:
zowe znetview-base list task-info
We already leveraged in the scenario the command to retrieve the messages in Canzlog, you can have the output on the screen as well, however, if you want to integrate it in an automated process, it is likely better to redirect the output in JSON format in a file, like in this command:
zowe znetview-base list canzlog recent — domain CNM01 — number 10 — rfj >C:\test\last_10_messages.json
And you will get an output like this:
Finally, a useful command is the one that allows the Zowe CLI user to issue a NetView command. We used it in the scenario above, few other examples with the output on the screen.
zowe znetview-base issue command “list status=tasks” — domain CNM01
zowe znetview-base issue command “lista” — domain CNM01
zowe znetview-base issue command “autotbl status” — domain CNM01
Wrap-up
What was shown in the scenario is obviously just a small part of the power of the IBM Z NetView plug-ins for Zowe CLI and there is no limit on how many scenarios can be implemented, how much automation you can achieve leveraging the znetview-base, znetview-automation and znetview-network plug-ins in Zowe CLI. As mentioned at the beginning, the power of the Zowe CLI is not just the individual commands but the ability to write scripts (in the scripting language of your choice) to build multi-step actions to automate the NetView program or any other product with Zowe CLI extensions. These scripts can have variable substitution, use additional script functions (grep, awk, etc.) to build powerful productivity tools.
On the other hand, I am aware of users that are leveraging the NetView plug-ins in an interactive way, to avoid using the NetView 3270 console just to issue a command, to download the automation table statements, then update them and test them locally. Ultimately, different users will use the plug-ins in different ways. The Zowe CLI can have scripts that cross z/OS products and systems to allow coordination of actions in many ways.
Few customers commented on the power of Zowe in general during last IBM zDay 2022, what I found especially interesting was the interview of Stephen Westwood (Lloyds) that talked about the power of IBM extensions of Zowe CLI, describing how he uses on a daily basis the Zowe CLI extensions for IBM Z NetView and IBM Z System Automation, take a look at it here.
An important point to make is that customers that leverage IBM Z NetView, get IBM Z Distribution for Zowe as supporting program, so the support (for the scenarios that are related to the integration) is granted from IBM at no charge. This is important because many enterprises do not allow unsupported software in their production environment.
If you want to learn more about IBM Z Distribution for Zowe, visit the content page, you can find there other details about IBM product extensions and more.
If you want to download the IBM Z NetView plug-ins for the Zowe CLI, these are available here or from your IBM Z NetView v6.4 DVD image.
If you want to learn more about IBM Z Distribution for Zowe, visit the content page, you can find there other details about IBM product extensions and more.
Zowe is owned and managed by the Open Mainframe Project, which is a Linux Foundation project. If you would like to learn more about Zowe, join the conversation on the Open Mainframe Project Slack Channel #Zowe-dev, #Zowe-user or #Zowe-onboarding. If this is your first time using the Open Mainframe Project slack channel register here.
#zowe #opensource #IBMz #netview
This blog was originally posted on AIOps on IBM Z Community, here. Join today for the latest: http://ibm.biz/AIOpsCommunity
To learn more about IBM Z solutions that can help improve system management, IT operations, application performance, and operational resiliency with AI, visit our product portfolio page.
