I’ve been getting an interesting question lately.  It does show me that folks are thinking more deeply about how z/OSMF is going to fit into their enterprise and how they will use z/OSMF for managing their software.  This is something I like to see, so I love this question!

This is the question:  Once I have installed my product(s) with z/OSMF, do I need to continue to use z/OSMF to service those products?  Which is also sometimes worded as:  Do I have to install PTFs with z/OSMF once I have used z/OSMF to install the products?

To answer this question, I’d like to think more about what a z/OSMF product installation results in.  What is delivered.  What you have when you are done.  What valuable capabilities you have when z/OSMF knows about your software.  Once you understand these things, it will be evident what the answer to that question is.  If you only want to see the answer, just jump to the bottom in bold italics. 

What is delivered in the z/OSMF package

The z/OSMF package for IBM is the ServerPac, modified to be used with the z/OSMF user interface.  The contents of the products you ordered will be pre-installed, just like they were with a ServerPac.  You will receive basically the same product-specific configuration and verification JCL jobs you had with the old CustomPac ISPF ServerPac package, except that those JCL jobs will be stitched together in two z/OSMF Workflows as steps. 

What you have when you complete a z/OSMF install (also known as a “deployment”)

You will have allocated and restored onto your own DASD volumes the products you requested on Shopz.   Meaning, you get target, DLIBs, CSIs, and some sample data sets.  Those products will be at the same service level (installed PTFs) in the z/OSMF ServerPac that you had with the CustomPac ISPF ServerPac.  Let’s just jump to result:  if you showed me a product that was installed with a z/OSMF ServerPac, or a CustomPac ISPF ServerPac (or probably CBPDO!), it would be hard for me to tell you how it was installed as the result is pretty identical.  The product is installed, serviced, and you have the resulting CSI ready to service the system again in the future.

If I may regress into more terminology to explain:

•  “z/OSMF ServerPac” really should be called a “z/OSMF portable software instance”.  The term “ServerPac” really should be obsoleted, as it does represent IBM’s package format.  Now that we have many software vendors shipping portable software instances (including IBM), it would be proper to not use the term “ServerPac” anymore, but alas, it does exist in many nooks and crevices of our interfaces and documentation today. 
• When you “install a ServerPac”, it really should be called “deploying a portable software instance”.   Remember the result of a “deployment of a portable software instance” is a normal “software instance”.    Both portable software instances  and normal software instances can be deployed to result in normal software instances. 
• You don’t specifically use a “Workflow to deploy a portable software instance”. This is a small pet peeve of mine.  Although a portable software instance may or may not contain z/OSMF Workflows for you to use, the deployment interface is z/OSMF Software Management.  After most of the deployment is complete, then you can launch into any supplied workflow for configuration or verification purposes, but by that time, you already have your data sets and CSI all loaded up on the DASD and you are nearly complete with the installation. 
• I think sometimes our z/OS Upgrade Workflow causes confusion here, as you know, that *is* a workflow that is needed for upgrading from one z/OS release to another.  However, that upgrade workflow doesn’t not actually do the deployment of your products. 

What valuable capabilities you have when z/OSMF knows about your software

This is the part that really stands out when you’ve deployed a portable software instance, or even just made your existing products known to z/OSMF!  When you do this activity, z/OSMF Software Management can remember your deployment information.  Now, for the SMP/E content of that deployment, only the CSI and zones names are remembered.  Meaning, there is no specific duplication of what sysmods are in the CSI stored into z/OSMF Software Management itself, so there will be no out of sync conditions to worry about.   Once you need to look at a software instance, Software Management can then find that information, as it knows the right CSI and the right zones to query.  For that reason, you can understand why there is no reason to remember individual sysmods in Software Management.

As you can deduce here, we will force the CSI to come along with the target libraries for a deployment (but not DLIBs), because we need to know and have the CSI that represents the software that is being deployed.  This is a difference that some people are still getting used to if they didn’t do that before.  Please just get used to that happening – z/OSMF Software Management will nicely do all the heavily lifting here to set up the CSI(s) and get the DDDEFs all matched up, so just give it enough space to hold the small CSI data sets, and let it do its work.  Believe me, this will be worth it in the end, even if you are not used to doing that today!

Getting back to some value points when z/OSMF Software Management knows about the software instance, and the right CSI and zone names:

• The handy and powerful UI can identify what CSI has been deployed to what system.  Previously this would have been very hard to do without some homegrown tool, log, or some person to ask who knows what CSI on what system holds the software where it was deployed.
• Compound and extensive queries across an enterprise and software instances.  OK, you might know where all your CSIs are across the world, but can you get at them simultaneously?  Not really, but z/OSMF Software Management can!  Looking for a nasty PE that might have been installed?  Looking to verify a SECINT is everywhere?  With z/OSMF Software Management, I can do that in only a couple of clicks. 

There are a lot more value points, and there will be more coming.  The above two are just the biggest and hardest ones I can think of right now without making this longer than it already is.

What you can do with it during the lifecycle of that software level

Finally, rounding the bases into home plate.  Think about what you have above – you have nicely installed software, CSIs that accurately represent them known in an inventory (without sysmod duplication!), and a powerful UI at your fingertips.  Now the original question at bat:  Must I put on PTFs with z/OSMF once I’ve installed a product that way?  I think you know the answer to that. 

You can put on SMP/E PTFs anyway you want,  because you will use the CSI that represents what you have, and z/OSMF will pick up that CSI information dynamically to report to you.  You can install with batch jobs, you can install with your own homegrown tools, you can install with another function in z/OSMF called “Software Update”.  [Think of Software Update as a very easy way to do certain APPLY commands into an existing CSI for those that don’t want to use JCL, although that over-simplification really is understating how powerful it can be.]  It doesn’t really matter, because the CSI is the source of all sysmod tracking, just as it should be.