Suit yourself: z/OSMF Software Update fits you to a T

 

Since its introduction to z/OSMF in October 2020 on z/OS V2.3 and higher, we've been collecting many customer suggestions for enhancements to z/OSMF Software Update.  After we delivered many of the high priority new functions in z/OSMF Software Management to help to install products, we needed to turn our attention to the backlog of ideas for installing service.  

Enter two new function APARs:

• APAR PH56074 (PTF UI93918 on z/OS 3.1), and
• APAR PH58221 (PTF UI96759 on z/OS 3.1).

These two APARs deliver some long-awaited functions.  I'll put a selected brief list here, and explain a little more about the items after that.  Notice I'll tend to use the terminology of z/OSMF Software Update, rather than the classic SMP/E-specific terms. 

1. Ability to delete Software Update operations that have been completed or cancelled.
2. Ability to install individual updates (fixes) from what has been acquired.  Ability to install updates based on a source ID, rather that have hardcoded values.  
3. Ability to run the Software Update operation as a different user ID than the one that logged onto z/OSMF and is using the interface.  
4. New REST API that can query an SMP/E CSI.

Ability to delete Software Update operations that have been completed or cancelled

Previously, all Software Update operations were saved forever.  Saving output and operations is important, but saving those you don't need or want anymore isn't.  Some of these operations could produce output that was quite large.  Since output is stored in the z/OSMF repository which is shared with many other z/OSMF functions, this meant that Software Update had the possibility of filling up the repository with output that was no longer needed. Now, in addition to the existing capability you have of exporting all the SMP/E output (or just HOLDs) to your workstation, you can also delete multiple updates and its associated output.

Ability to install individual updates from what has been acquired.  Ability to install updates based on a source ID, rather that have it hardcoded. 

Previously, there were three use cases for Software Update:

1. Corrective:  where you provide the name of the update(s) you want to install, and they will be installed. 
2. Recommended:  where you install all the recommended service for all the participating ISVs.  For IBM, that meant that you'd install all the updates that were associated with the latest RSU source ID (RSU*), HIPER, PRP, and SECINT.  
3. Functional:  where you select the fix category for the kinds of updates you want to install, and they will be installed.

The challenges with these first two options were:

• For Corrective:  Since the update had to have already been acquired (i.e. SMP/E RECEIVEd*, see footnote), why didn't we just provide the user the list of updates that could be installed and let them select?
• For Recommended:  many customers have their own local policies on what recommended service should be installed.  Hardcoding the vendor recommendations, although helpful, wasn't always what was needed.  

To address these challenges, there have been some noticeable changes in the three use cases:

1. Install by Name:  is the new title for the Corrective use case. This enhanced option will allow you see all the acquired updates available for the Software Instance you selected.  Then, you can select from that list which update(s) to install, and any software update that resolves an error for the selected update will be automatically selected too.  Also, there is additional information provided for the updates, to help you guide your selection better.  You can see information such as the source IDs, the REWORK date (which for IBM PTFs represents approximately the fix availability date), when the update was acquired by you, and if there is a description on the update. And, if that wasn't already enough, you can get details on the PTF such as the HOLDs and what we commonly call the "cover letter".   By using z/OSMF's powerful sorting and searching, finding the exact updates you want to install should be easier.  

2. Install by Source ID:  is the new title for the Recommended use case.  In this revamped option, you can see all the Source IDs, with the ISV recommended ones automatically pre-selected for you. Any update assigned to a Source ID you select that has an unresolved error will be excluded automatically from being installed.  You are free to add, change or remove any Source IDs from the selection list.  For those that want granular control over which groups of updates they install - this is the right path for you.  Just like in the Install by Name path, you can drill down and look at information about individual updates.  (Delivery of this function now satisfies the requirements ZOS-I-3265 and ZOS-I-3772.)

  

3. Install by Fix Category:  is the new title for the Functional use case.  Here, you can also see which updates are included in that category before you select them with a handy twisty.  Any update that will resolve an error for a selected update will be automatically included to be installed.  

Ability to run the Software Update operation as a different user ID than the one that logged onto z/OSMF and is using the interface  

We know that some shops have a "functional user ID" from which they might do installation work. Previously, z/OSMF Software Update would do the installation work from the identity of the user that was logged onto z/OSMF.  Now, in the Software Update Settings page, you can identify a different user ID under which to run the installation work, should you wish, for each system.  This value will be saved, and your authority to run under that user ID will be immediately verified so that you don't find out at a later time that you mistyped the user ID or didn't have access to it.  In fact, that userid will also be checked that it has proper authority to other necessary resources which Software Update needs.  What surrogate userid your update was run under will also be logged by the z/OSMF server.   (Delivery of this function now satisfies the requirement ZOS-I-2491.)

New REST API that can query an SMP/E CSI

This topic could have a blog on its own, and I just might do that one day.  I could see this being one of the most popular z/OSMF REST APIs we have!  Remember a long time ago, when you wanted to query information in the SMP/E CSI and you had to use ISPF or batch jobs?  Then, things got better when an API was added called GIMAPI which let us write C, PL/I, and Assembler programs to get at that data?  Well, let's get modern now with a REST API.  This new REST API is so powerful, and it doesn't work just on Software Instances, it works on any SMP/E CSI even if it is not in a Software Instance!

Imagine writing in a modern programming language that supports REST APIs - imagine wanting to look across every CSI in your enterprise's five data centers to gather information about the PTF level of a certain module (or to see what updates have been installed on DFSMS over the past month, or to see the HOLD information associated with a specific installed fix, ...).  

Of course, there is Swagger access to these new REST APIs so you can give them a test drive:

Summary

As you can see, the z/OSMF Software Update team has been busy with your customer requirements.  We know there's more to do, so keep those votes and ideas coming!

------------------------------------

*Yes, z/OSMF Software Update still does need you to do the acquisition of updates.  But, as you've heard us say so often, you should be using SMP/E RECEIVE ORDER for automated acquisition of updates.  If you automate that acquisition, you will never need to invoke it from the z/OSMF user interface.  My view:  zero clicks is the best you can do.  Setting it up once with automation and never touching it again is the least amount of work. However, if you do really want to click to acquire, please vote on this requirement ZOS-I-1931.  We have it on our list, and it's a matter of priority at this point.