Aug 18 ’13

z/OSMF Version 2 Release 1 Enables Productivity Gains Through New System Management Tools

by Anuja Deedwaniya in Enterprise Tech Journal

The IBM z/OS Management Facility (z/OSMF) delivers many useful functions to help the systems programmer and IT teams at companies of all sizes manage their systems better. Though z/OS and z/OSMF now follow a two-year release cycle, many new functions and enhancements became available through a service update in fourth quarter 2012, making the product even more attractive and valuable for users.

Armed with endorsements from clients worldwide and validation of the stack and technology, the big focus for the upcoming release of z/OSMF V2R1 is to enhance the stack itself. The new release of z/OSMF is a separate product that will be released in September 2013, along with z/OS 2.1.

To that end, the z/OSMF product is based on the Liberty profile in WebSphere Application Server for z/OS V8.5. This new application server run-time reduces the size and resource requirements from the prior release. Users no longer need to separately configure a run-time (WebSphere Application Server for z/OS 7.0 OEM Edition [WebSphere OEM]) before deploying the z/OSMF application. The run-time is fully integrated with z/OSMF and thus, the steps required to configure z/OSMF are reduced to about half the number that were required in previous releases. The change in run-times continues the journey of simplifying the configuration of the product itself.

With the WebSphere Liberty profile run-time, the z/OSMF product package size is reduced to a few hundred megabytes from the previous size of more than 1GB, and the memory requirement is reduced from 2GB to 1GB. Whereas the current release required up to 100 MIPS for some scenarios, the new release is expected to require less than half that for certain functions.

An obvious benefit of the new and improved product package can be seen in the startup and shutdown time for z/OSMF; it’s reduced from minutes to just a few seconds!

z/OSMF Workflows

One of the highlights of z/OSMF 2.1 is the new Workflows function (see Figure 1). In this first stage, Workflows delivers a framework with a focus on simplifying the configuration of z/OS and performing a set of tasks on z/OS. Typically, when your installation needs to implement a set of tasks, different people in different roles are needed to perform those tasks. The z/OSMF Workflows function allows you to assign the various steps to different individuals or defined roles, such as “security administrator” or “systems programmer.” Once assigned, these individuals are notified through the new Notifications task. When these users log into z/OSMF, they see any tasks assigned to them and can then go ahead and accept the tasks and perform them.

In a typical use case, a product owner such as a vendor can create a workflow using the z/OSMF supplied schema and instructions provided with z/OSMF V2R1. The workflow could then be delivered, along with the product and installed on the client site as part of the product install. Then, using the z/OSMF Workflows function, the systems programmer could create an instance of this workflow in order to configure and customize the product on z/OS.

A workflow might contain steps that have dependencies among them; they can be manual steps or some steps might use wizards to submit jobs with JCL or drive a REXX exec or shell script that’s supplied with the workflow.

Expect to see more functions and enhancements in this area.

Expanded Software Management Capabilities

z/OSMF Version 1 Release 13 introduced the Software Deployment task for cloning installed software locally or remotely. Subsequently, later in this same version release, new, substantial software management functions were added. The Software Deployment task was renamed Software Management to reflect its expanded functions, which provide broader management and reporting capabilities for installed software, including the ability to: 

• View the products and FMIDs included in the software instance
• Determine whether a product is approaching or has already reached end of service
• Find missing HIPERs and PEs fixes for a software instance
• Query the service level, including specific PTFs based on fix categories for any software instance across all systems or sysplexes.

And now, with z/OSMF 2.1, you can even download some of these reports into a spreadsheet and print it.

As the Software Management function continues to be enhanced, this new and valuable function is quickly becoming an extremely attractive way for installations of all sizes to manage their software in a consistent manner.

Real-World Scenarios

Many large IT shops are exploring the idea of rolling out the z/OSMF Software Management function to centrally manage the deployed software across their enterprise. Doing so would allow the systems programmer to view all software across the enterprise from one browser session, including which software is installed on each image, the service level of each software and so on. 

Initially, this approach would require some planning and, in some cases, might seem like more steps to go through. However, long term, the Software Management function provides your installation with a centralized and standardized approach; there will be no need to maintain homegrown tools, which can be time-consuming and costly. In some shops, the people who originally wrote these tools and processes are retiring and it can be a challenge to keep enhancing those tools. Another case is where different teams such as z/OS, CICS, database, performance and so on, have different processes for managing software. It can be cost-effective to centralize and have a common process across all installed software. While it won’t necessarily be painless to change the way it has been for so long, it’s well worth it in the end. 

For smaller and newer IT shops, the Software Management function can be even more attractive if you want to minimize the time required to create and maintain homegrown tools, often unique for each product set.

z/OS Jobs REST Interface Services

The z/OS Jobs Representational State Transfer (REST) interface is an Application Programming Interface (API) implemented through industry standard REST services. This interface allows a client application to perform operations with batch jobs on a z/OS system.

Since the initial delivery of the z/OS Jobs REST interface services in z/OSMF V1R13, additional enhancements have been delivered through the PTF for APAR PM74502. With this service update, the z/OS jobs REST interface services have been enhanced:

• The service to retrieve the contents of a job spool file is enhanced to allow access to the JCL used to submit the job. This is equivalent to the JCL you see when using the SJ command under SDSF. Instream SYSIN data will also be returned if it exists. You can use the returned JCL to resubmit the job.
• You can submit for execution a job that resides in a z/OS data set or z/OS UNIX file (and request a non-waiting recall of a migrated data set). This enhancement greatly increases the flexibility of the z/OS Jobs REST interface, which previously only allowed you to submit a job that’s embedded in the HTTP request. This support can be used by customers with either JES2 or JES3. Figure 2 shows an example of a job that’s in a migrated data set.
• Increased support for secondary JES2 subsystems allows users to cancel a job, change job class and delete a job (cancel a job and purge its output).

For an example of these services in practical use, you can read about the recently announced IBM Explorer for z/OS V2.1, which uses the z/OS Jobs REST Interface services to manage jobs on z/OS by visiting

With z/OSMF V2R1, the z/OS Jobs REST interface is further enhanced to allow easier reuse of existing JCL and better detection of when a job completes (JES2 installations only). The services are extended with support for optional asynchronous notification upon job completion. This means that when you submit a job to run on z/OS, you can optionally specify a URL for receiving a notification (an HTTP message) when the job has completed. This function can be useful if you have a Web application that’s submitting jobs to a z/OS system; such an application wouldn’t need to keep polling z/OS for job status.

Also, support is added for passing JCL symbols to a job being submitted. You can provide the values for JCL symbols in HTTP headers when submitting a job, so the job doesn’t need to be updated for each different value.

Last, the z/OS Jobs REST interface services now also support the use of an optional job correlator that’s unique across the JES2 spool. You can use this correlator as an alternative way of identifying a job in place of the traditional jobname/jobid combination. To use this feature, you provide the user portion of the job correlator when submitting a job.

New Tools for Managing Incidents

Users are seeing real productivity gains and time savings by implementing the z/OSMF Incident Log task across their enterprise. In many shops, the Incident Log task is being used by all System z teams, spanning subsystems, networks and so on, as the primary interface for viewing and managing incidents and sending documentation for further diagnosis. As it’s being used more and more in production environments, the function continues to be enhanced. Some users, for example, requested the log snapshot names be customizable based on their internal naming conventions. Here again, the z/OSMF team responded to customer requirements.

Also, to help you better manage the inventory of incidents, a new batch program called ceatool was delivered, which you can use to clean up older incidents that aren’t being pursued. You can invoke ceatool periodically, as needed, either directly or through a CRON job. There’s even an option to delete an entire incident, including the dump, or delete only the log snapshots, thus leaving the dump so you can continue to manage it through traditional archiving and offload processes.

Changes in the Capacity Provisioning Task

In the recent service update for z/OSMF, considerable function was delivered, making it equivalent to the Capacity Provisioning Control Center (CPCC), the Windows client Graphical User Interface (GUI). As a result, starting with z/OS V2R1, the CPCC is no longer needed and isn’t scheduled for any further enhancements. From now on, the way to manage and interact with the Capacity Provisioning Manager (CPM) will be through the z/OSMF Capacity Provisioning task.

Changes in the Configuration Assistant Task

Network teams have been finding a lot of value in the z/OSMF Configuration Assistant task, which helps with configuring network policies. With z/OSMF V2R1, this task is enhanced to provide a more integrated look and feel with other z/OSMF tasks, as well as provide a better performing function. In addition, there are enhancements to take advantage of new functions in Communication Server for z/OS V2R1, including support for Policy-Based Networking for Application Transparent TLS (AT-TLS) and IPv6.

Configuration Made Easier

While the configuration process for z/OSMF has been streamlined in every release, it was still reasonably involved with the separate configuration procedures for WebSphere OEM and z/OSMF. Now, with the WebSphere Liberty profile run-time embedded in the z/OSMF application itself, there’s another big jump in the right direction. As mentioned previously, this change eliminates the need for a separate run-time configuration and reduces the number of steps for configuring z/OSMF. Additionally, this offers changes in the default ports and lets you generate a digital certificate, should you wish to do so, with support for hardware crypto built in. In z/OSMF V2R1, the service update process has been simplified to be more consistent with the z/OS service process. In prior releases, some PTFs required you to run a special script to redeploy z/OSMF after installing the PTF. In z/OSMF V2R1, this requirement is removed. Once you’ve applied a PTF, just restart the application. It’s that simple. Expect to see continued focus in this space.

For those coming from a prior release of z/OSMF, the use of SAF Authorization Mode to manage user authorizations to tasks is now a requirement. This is actually a good thing, as it means you can manage z/OSMF authorizations through the same security management product you use for z/OS. V1R13 installations currently using Repository Authorization Mode can convert to SAF mode in V1R13, and thus be prepared for migrating to z/OSMF V2R1. Or, you can convert to SAF Authorization Mode during the migration. During the configuration process, z/OSMF generates a REXX exec with RACF commands to help you make the transition. Early customer feedback is pointing to a smooth conversion to SAF mode.

All Aboard!

This latest release of z/OSMF delivers an even more compelling value proposition for you and your staff. As clients are poised to implement and roll out z/OSMF V2R1, this new and improved product package makes z/OSMF a more viable and consumable product. Modern tools such as the z/OS Jobs REST interface services and z/OSMF Workflows framework are giving z/OSMF a more central role in z/OS management. Further, substantial enhancements to the system management tasks continue to provide productivity gains for both new and experienced systems programmers.