The Gift That Keeps Giving



(Repost from November 19, 2020)

Giving it all you can - a current global zone.

Way back in May 2018, I blogged about using electronic deliverables (Still using Shopz to pull z/OS PTFs?).  In there, I went on my soapbox to encourage use of SMP/E RECEIVE ORDER (vs Shopz).  I spelled out all the advantages of doing so, if you were able to have an internet connection from your driving system.  And, by the way, not only IBM supports RECEIVE ORDER, other vendors do as well.  Check with your ISVs to see if they support RECEIVE ORDER too, as there are even more reasons to use it!

Well, two years later I'm still here to recommend this, but I now have yet another reason to do so. Recently, we released a new z/OSMF Software Management task called z/OSMF Software Update.    This is the ability to install PTFs with a web brower in an interactive and easy way, aimed directly at those that aren't enthralled with the batch JCL job method.  We've been talking about this function at several conferences, and you can use this link to learn more. 

But, the one thing that consistently comes up while talking about z/OSMF Software Update, is that the PTFs that will be installed (SMP/E APPLYed) must already have been acquired (SMP/E RECEIVEd in the global zone). We understand well that folks do want z/OSMF Software Update to do the acquisition of both the fixes and the HOLDDATA, but that capability is not there today.   Indeed, this "missing" capability isn't even necessary if your regularly use SMP/E RECEIVE ORDER to acquire fixes and HOLDDATA automatically on a regular basis.

That's what this blog topic is about:  helping you help yourself by encouraging you to set up an automated batch job to do the SMP/E RECEIVE ORDER, so that you'll always have what you need at hand for any reason.  But even more so now, for z/OSMF Software Update is in our midst.   

Getting back to my soapbox, here's some persuasive reasons why setting up an automated job is to your own advantage.

Why do anything manual in a GUI, when you can easily automate it?

If given the choice to do something very repetitively manually, or with automation, well, you know the answer to that.  SMP/E RECEIVE ORDER is the way to go.  I like nightly, so I don't have to worry about missing more than one night's worth of information when something is unavailable.

Worried that your SMPPTS will fill up?  OK, fair enough.  But using SMPPTS spill data sets can help with managing the SMPPTS expansion, and some even occasional ACCEPTs (and any appropriate REJECTs) really can get your SMPPTS down to just what is applicable.  And, if it's applicable, why not have it already staged right now? You will use what is there someday, and you've just given yourself a leg up when that day comes.  

HOLDDATA is more important now than ever

There's a reason we have stellar availability on z/OS.  It's a partnership between you and IBM and other software vendors.  Our way of helping you know about defects found on z/OS, is to share them with you.  The HOLDDATA is how we do that, and this is something you really shouldn't go more than a day or two without having at your fingertips.  You could go into a GUI to pull the latest data, however, in this world of having too much to do...why?

More immediate use of z/OSMF Software Update

Today, we don't have the RECEIVE capability in z/OSMF Software Update, so those less experienced with installing z/OS fixes may not know they are not using the latest HOLDDATA, or have the latest recommended fixes acquired, or have access to the latest FIXCAT lists.  By allowing them to have this critical information assuredly, since it was already done for them, we can make them more productive and make gaps less possible to encounter.  

Please, do yourself a favor...check that your global zones are being updated regularly with the latest HOLDDATA and fixes automatically.  Contact your vendors and use all information they provide. Then you don't have the live on the edge.  

If we all do this, then the next James Bond film can be called:  The SMP/E Global *is* Enough.  


Comments