Surfing the 'Flows

 

On the IBM z/OSMF TechXchange Community Discussion I noticed an excellent question.  The poster was rightly confused about how the z/OS Upgrade Workflow and the z/OSMF Portable Software Instance (ServerPac) Workflows interact with each other. I responded to the Community, but thought that having it separately available as a blog would be helpful too.
 
Let’s look at these z/OSMF Workflows and how they are intended to be used.  Of course, you can modify these phases as you like, so below is only a recommendation to make sure you cover all appropriate tasks. 

(Btw – if you have any z/OSMF questions and want to get to the right z/OSMF Subject Matter Experts quickly, this Community a great spot to start a conversation or search for a similar question!)
 
z/OS Upgrade Workflow
This is the z/OSMF Workflow which replaced the “z/OS Migration” book.  This workflow is provided via PTF back to the supported coexistence releases for a new z/OS release.  For instance for z/OS 3.1, the z/OS 3.1 Upgrade Workflow was provided in PTFs to z/OS V2.4 and V2.5, and those PTFs are marked with the SMP/E FIXCAT IBM.Coexistence.z/OS.3.1. It is marked with this FIXCAT as you likely will be putting PTFs for coexistence on your V2.4 and V2.5 system, and so you “find” the z/OS Upgrade Workflow easily when you do that, in the /usr/lpp/bcp/upgrade  directory.
 
In z/OS 3.1, this Upgrade Workflow was restructured to be more chronological.  Prior to z/OS 3.1, it was sorted by the element name, and then within element name it had been chronological.  The major steps in the z/OS 3.1 Upgrade Workflow are found below.  Here, on your z/OS V2.4 or V2.5 system, you would preform all the steps up and through Step 4 “Upgrade actions before installing 3.1”:
 

At this point, once Step 4 is completed, you have performed all the “early” upgrade actions for z/OS 3.1 on your existing z/OS V.4 or V2.5 system.    Now, it’s time to install z/OS 3.1.
 
Do note:  of course, you can absolutely look at or even perform the “before first IPL” and the “after first IPL” steps, but do take care on the customization you do for those upgrade actions.  For instance, some of the changes you need to make might be appropriate only for the new target system you are preparing, and not the current V2.4 and V2.5 system you are running.  I do recommend looking these subsequent steps over, as knowing and planning your complete upgrade tasks as early as possible is a good thing.
 
z/OSMF Portable Software Instance installation
At this point, you will install z/OS 3.1.  You will use z/OSMF to do that if you ordered a Portable Software Instance (ServerPac), but you can still install the old fashioned CBPDO method if you wish.  I’ll assume you are using z/OSMF.
 
Using z/OSMF Software Management, you will Add your Portable Software Instance, and then Deploy your Portable Software Instance.  During the Deploy process, after you have submitted the deployment jobs, you will encounter more z/OSMF Workflows on the Deployment Checklist:
 

When you enter into this checklist item, you’ll see that there are three Workflows:
1.    OSxxx_YOURORDER
2.    OSxxx_POSTDEPLOY
3.    OSxxx_VERIFY
 

As you can see from the Description column:
1.    The YOURORDER workflow simply contains information about your ServerPac order.  The information found here is what products you ordered on Shopz, some descriptions of the sample installation-related data sets, some helpful links to understand basic z/OS maintenance concepts, and other general reference information.  You can launch this workflow and usually rather quickly browse the information it provides.  There are no jobs that run in this workflow, and no changes will be made to your system from this workflow.
2.    The POSTDEPLOY workflow is provided to you as the “workhorse” to get your system customized for the IPL.  After your deploy jobs ran, there are still several important customization steps to run to prepare the system.  Let’s take a somewhat deeper look at this workflow later.  However, do note at this point, that there are several very important steps in this POSTDEPLOY workflow you should not overlook.
3.    The VERIFY workflow is what you would run after your new target system is IPLed, so you should initially hold off in running this workflow until your IPL is complete. The steps in this workflow are what you could think of as the traditional installation verification procedures (IVPs) that can help you confirm the basic functions on your new system were correctly installed.  Personally, I’m not sure if many clients run this workflow as they likely have their own IVPs, but this workflow is provided to you should you wish to use the basic verification provided by the products you ordered. 
·       Do note, this workflow needs to be run on the IPLed target system, which is the whole point of providing it.  Since it is a z/OSMF Workflow, the z/OSMF on the driving system needs to be available to connect to that IPLed target system.  Keep that in mind in case you need to activate z/OSMF on the target system and also make the IPLed target system known to the z/OSMF on the driving system (in the z/OSMF Systems list).
 
More about the important POSTDEPLOY workflow …
As I mentioned above, the POSTDEPLOY workflow does some very important customization on your target system, based on your specific deployment.  Let’s take a closer look at some of the most important steps in this workflow.
 
Collect Configuration Options Step
Because the installation needs to cover users that need both a full new set of operational data sets (previously called “Full System Replace”) *and* users that only want to provide their own operational data sets (previously called “Software Update”), the workflow needs to be told what kind of user you are.  That is in the “Collect Configuration Options, ” step.
You'd select "Create new operational..." from the drop-down if you wanted to Ready the workflow steps that create new operational data sets (which have the word “Optional” in their title).  Using this option lets this workflow create those operational data set for you.
 

You'd select "Use existing operational..." if you wanted to Skip the steps that create new operational data sets (which are those Optional steps).  This means you would need to provide on your own, the operational data sets needed for this software.
 

Of course, you can always still perform any Skipped step you want.  By asking this question up front, we can then reduce the number of steps that are expected to be performed.
 
Update Default Dataset names Step
Once you’ve got that decision done, let’s look at another important POSTDEPLOY workflow step,  “Update Default Dataset names”.  This is an important step, as all the customized names you used for your deployment need to be updated in the supplied parmlib and proclib and other data sets.  If you don’t run this job, then likely the default data set names in these supplied data sets will not work for your IPL.  This step is not Optional.
 
Mount file systems and create BPXPRMFS member Step
This step will mount the file systems associated with your order, and customize the names you used for your ZFS data sets into a supplied BPXPRMFS parmlib member for you to use at IPL time. 
 

Back to the z/OS Upgrade Workflow, for “before first IPL” Steps
Remember those “before first IPL” and “after first IPL” steps in the z/OS Upgrade Workflow I mentioned near the top?  It’s time to revisit the “before first IPL” steps to make sure you’re set for your IPL.
 

These steps might have you update your 3.1 parmlib, for instance, on your target system. 
 
Now…the IPL
Usually one of the last steps of the POSTDEPLOY workflow is the “IPLing The System” step.  This is the time you can IPL your new system.
 

Back to the z/OS Upgrade Workflow, for “after first IPL” Steps
Like before, you can go back into the z/OS Upgrade Workflow  and this time concentrate on those “after first IPL” steps.  Ensure that those applicable steps have been performed, which will then complete your upgrade tasks! 
 

Lastly, if you like, the z/OSMF Deployment VERIFY workflow
After you have IPLed and done any necessary post-IPL upgrade actions, you can do your own verification procedures. 
 
If you wish, you can also run that VERIFY workflow you supplied as part of your z/OSMF deployment. 
 

Summary
As you can see, there are several switches between the z/OSMF Deployment workflows and the z/OS Upgrade workflow, so you can decide how you want to accommodate all the tasks involved.  In some cases (the VERIFY workflow), you might want to forgo them and use your own processes.  Also keep in mind, although I understand there are several switches, how you cover all the pertinent steps above does come with flexibility with your local procedures.
 
Looking at the above phases, here’s a recap at which points you would use the four z/OSMF workflows involved.  (Note that colors in the flow, do related to colored boxes above!)