• 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 http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS213-141.
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.
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.