You CAN take it with you!

 

It seems like I have this conversion many times, so I figured it was time to blog about it and hopefully save myself another meeting on my calendar.

You've likely seen we are doing a heavy amount of modernization of the z/OS stack, from the hardware all the way up.  Much (if not all?) of this modernization relies on APIs: those we have today, and those which we have yet to provide.  We've got a ways to go in many areas.  But one area we happen to have a lot of modern APIs today, is for managing software.  The APIs I'm talking about here are these z/OS REST APIs which are quite powerful, and have been built so that you can manage software centrally, and yet also drive remote operations just as easily.  Since many of these tasks you'll want to do again and again, they have also been provided as Ansible roles, if that is your automation choice. 

However, the point of this blog isn't to talk about those APIs.  The point of this blog is to explain that the basis of all this modernization with APIs for SMP/E-installed software, is the inventory of that software itself.  In other words, if we don't have an SMP/E consolidated software inventory (CSI), then we have no programmatic certainty that we know what exactly is running on every system, at every moment.  

Now, I do understand that there are deployment methods today which do not bring along the SMP/E CSI when the target libraries are copied. Yes, those deployment methods have worked great for decades!  And, I also understand that often there is an SMP/E CSI back on a sandbox system that once (or still?) represents those deployed target libraries when they were originally copied. 

But, I'll proffer - those times are a-changin'.  In a world with more frequent deployments of software updates (for security patches, for instance), we need to programmatically know with certainty what the software level is everywhere, all the time.  In other words, those powerful APIs could accurately tell us if a patch is running on each and every system in the enterprise, with complete confidence, if we are assured that that inventory travelled part and parcel with those target libraries.  If there was a single CSI back in the sandbox system that represented multiple systems deployed in an enterprise, I'd reckon that the opportunity for mismatch is going to be outside the comfort level of many.  

So what can be done?  It is actually not that hard to remedy this situation today if you find your deployment process gives you a ratio of  1 CSI : many running systems..  Update your deployment process to:

1. Export the target SMP/E zone.  You don't need the Distribution zone if you don't want it.  You can create a new global at your destination, if you like. You don't need to take your large SMPPTS data sets with  you.  
2. Copy that exported target SMP/E zone along with your target libraries to your destination.
3. Import it back into target SMP/E CSI, and add it to some existing or new global zone.  
4. Update the DDDEFs to reflect the right data set names, volumes, and paths which are on your destination system.  (This is important, you do want the inventory to actually represent what is really running on the system.)
5. If you like, you can "register" the record of that CSI on that system in your z/OSMF Software Management repository (Software Instances -> Actions -> Add, or do it programmatically with POST /zosmf/swmgmt/swi ).  This is nice, because once you have a record of that deployed software, you can drive lots of valuable functions without having to remember the name of that CSI.  

If you would like some sample JCL to do steps 1-4, customized just for you, you can do that!  All you need to do is start a z/OSMF Software Management Deployment process through the user interface. This is the exact same process you used to install your z/OSMF Portable Software Instance (ServerPac) into your sandbox system.  But this time, you'll deploy your software instance from your sandbox to somewhere else in your enterprise.  This deployment process will create some jobs for you.  These are the jobs you can save and model after, to incorporate into your own deployment process you've used for decades. Heck, you don't even need to run those JCL jobs if you don't want to.  Just the creation of them will provide you with nice customized samples you can update your deployment process with.  

Usually when I have conversation about the above, I've gotten some very good questions about the need to have a 1:1 relationship between a software instance and the CSI that represents it.  Here's an example of those questions:

• Q:  But, I never install fixes on a production/test system.  I always install them in the sandbox and deploy from there.  Why do I need a CSI around when I will never do an SMP/E APPLY on that system?  A:  Agree!  Doing an APPLY outside of a sandbox system isn't something that many people do, and isn't something that I hope you ever need to do.  But, I bet that you'll need to do a programmatic query on that system for a specific PTF ?  I bet you'd like to compare one system with another to prove that they are at the same service level?  Have you ever wanted to understand what product a certain FMID is part of?  There are many many queries I can imagine, because I do them all the time, and none of them ever require any updates to the target libraries themselves.
• Q:  If I want to query my production system, I know what the CSI name is on my sandbox that represents it.  I query my production system on my sandbox CSI.   A: OK, I guess?  Are you able to absolutely guarantee that the sandbox CSI was locked and never updated when the software was activated on that production system, until the next deployment was done?  Does everyone know where to find that CSI when you are on vacation, and know which systems downstream it covers?  Do you have a programmatic way or some record to know that a certain sandbox CSI represents a remote system's software, so accurate queries can be done and report back which system(s) are represented by that locked sandbox CSI?  This mapping of what is where when, can get difficult. With the inventory always with the target libraries, it is reliably accurate.  In addition, that's why keeping what was deployed in the z/OSMF repository makes for an easy programmatic solution because I don't even have to remember the CSI name - just the name of the software instance that was deployed.  And if I don't remember the software instance name, I can list them all and determine pretty fast from which ones are available. 
• Q:  I hear you, but I'm going to still keep with my method, and keep my sandbox CSI representing my deployed systems.  A:  That's ok!  You know the best way to manage what your enterprise needs.  Everything will still be as it is today.  My point would be to understand what you will be forgoing should the need in the future arrive:  the ability to dynamically discover, and query (and prove!) the content level of  software instances.  Especially in a consolidated manner and especially with automation samples which leverage the modern APIs which rely on one CSI for one software instance.    

That is the end of my soapbox for now.  If anyone does start to include the CSI in their existing deployment process, I'd love to hear your experience!