Ny Naspa 2019 05 14 Zosmf v2r3 Migration Workflow Lab
Ny Naspa 2019 05 14 Zosmf v2r3 Migration Workflow Lab
This lab is an introduction to using the z/OSMF Workflow function. You will acquire a
workflow (the z/OS V2.3 Migration Workflow), create a workflow, assign steps to different
users, read notification messages, accept the assignment of a step, perform or skip a step,
and provide feedback on a migration action (and the overall release migration).
Exercise instructions
Here is a high level overview of the instructions that we will do in this lab exercise:
__ 1. “Pretend” to download the z/OSMF z/OS V2.3 migration workflow from the web.
__ 2. Logon to z/OSMF. Enter into the Workflow function.
__ 3. Create a z/OS V2.3 migration workflow within z/OSMF.
__ 4. Look at some of the z/OSMF workflow functions.
__ 5. Assign steps (migration actions) to different users.
__ 6. Accept the assignment of a step (migration action).
__ 7. Perform a step (migration action).
__ 8. Skip several steps (migration actions) at once.
__ 9. Provide feedback on the entire release migration.
2
1. “Pretend” to download the z/OSMF z/OS V2.3 migration
workflow
In this step, we will download the “as is” web deliverable from the internet. This will teach
you how to acquire a Workflow. For this lab, the Workflow is already acquired on our lab
system for you. This step is only if you want to know how to acquire the z/OS release
migration workflow when you return to your shop.
The z/OS V2.3 Migration Workflow has been provided on github. Here’s how to find it:
a. Go to https://github.com/IBM/IBM-Z-zOS, and then click on the „zOS-Workflow”
folder, and then the „zOS V2.3 Migration Workflow” folder.
b. If you were back in your shop and needed to acquire this workflow, you would
download three highlighted files: HC_rexx.txt, discovery.txt, and either z/OS
Migration from V2.1 to V2.3-Level2.0.xml or z/OS Migration from V2.2 to V2.3-
Level2.0.xml corresponding on which z/OS release you are coming from.
Note about z/OS V2.3 Migration Workflow! At your shop, you will need at least z/OSMF
V2.1 to run the z/OS V2.3 Migration Workflow.
It’s easy to download a file from github. You simply click on a file to open it. Then click on
„Raw” :
This opens the file completely and allows you to right click, and „Save As”. You do this for
all three files, then upload them to your z/OS system into a file system as binary, putting
them all in the same directory of z/OS UNIX.
4
Step 2: Logon to z/OSMF.
In this step, we will now go into z/OSMF to use the Workflow function. For this lab, we are
using a z/OSMF V2.3 system. It looks slightly different than z/OSMF V2.1, but the same
functions are present on both systems.
a. Go to https://mvs1.centers.ihost.com/zosmf/ on Firefox or IE. Accept any risks.
b. Using the userid you were given (SHARAnn, SHARBnn, or SHARCnn) and the
password, logon to z/OSMF. This is a secure connection to a z/OS host. The
userid you were given is a regular z/OS userid on this system, and has been given
access to z/OSMF. There is no z/OSMF code on this workstation (outside of the
z/OS V2.3 migration workflow files you just downloaded to the workstation).
c. Click on Log in”. Do no click on “Desktop Interface”, so that your screens will match
this handout.
https://mvs1.centers.ihost.com/zosmf/ #2a
#2b
#2c
#2d
6
e. This brings you into the main Workflow screen. You can see there are already
some workflows created from this screen. You will be creating your own workflow
for this lab. Click on the little arrow head to close the panel on the left, so you have
more visible space.
#3a
8
b. Carefully enter in the location of the XML workflow file that you have uploaded on
the z/OSMF system, where it says “Workflow definition file:”. You only need to
specify the XML file, as that one will pull in the other two files. The Workflow
definition file for this lab is found here (carefully enter the spaces!!):
/shareuser/mwalle/lab/zOS Migration from V2.2 to V2.3-Level2.0.xml
c. For “System:”, on the dropdown, select “SHARPLEX.S1”, which is the only choice.
Leave “Workflow variable input file:” blank.
d. Then click “Next >”. (“Leaving Workflow variable input file” blank.)
#3b
#3c
#3d
#3e
#3f
#3g
#3h
10
4. Looking at the workflow overall.
There are some things to notice at this point:
a. There are 223 steps (migration actions) in this workflow.
b. You have completed 0% of them: 0 of 223 steps.
c. There are five steps, of which three contain migration actions. This may be
confusing, as there are sub-steps that count as steps in that 223 total. (Also, you’ll
see later that a non-migration action also counts as a step!). These three major
steps correspond exactly to the three chapters in the z/OS V2.3 Migration book,
along with the first step to help you tailor or Workflow for what is in use on the
system (discovery), and the fifth step being the overall instructions for sending your
feedback back to IBM.
d. These five steps are in a state of “Unassigned”, meaning that no one has been
tasked with doing them yet.
e. Notes and History: you can put any notes on this entire workflow here. Perhaps
information on the entire schedule of this migration, or something else that is
appropriate to make at the entire workflow level. Under History, you can see the
history of this workflow: when it was created, who created it, etc.
#4e
#4b
#4a
#4c
#4d
#4f
#4g
#4h
#4i
12
Let’s now look at how an actual migration action for z/OS V2.3 looks like in the Workflow:
j. Make sure “Chapter 3: Migration from z/OS V2R2” is still untwisted.
k. Scroll down to “Communications Server migration actions”, which is step 4.4.
l. Untwist “Communications Server actions to perform before installing z/OS V2R2”,
which is step 4.4.1.
m. Click on the blue part “IP services: Migrate from SMTP and sendmail”, which is
step 4.4.1.2, to open it up. (Notice how the untwists are numbered, as you go
deeper.)
#4l
#4m
Notice the eight tabs across the top of this migration action:
n. General: This is where the actual migration documentation can be found. Exactly
what is in the book for documentation can be found under this tab.
o. Details: this is unused for the z/OS V2.3 migration workflow. If one migration
action had a dependency on another migration action, it would be put here. For
this workflow, though, no dependencies have been added.
p. Dependencies: If there were dependencies in this step, they would be described
here. For our sample Workflow, there are Dependencies that you can see before
you try to Perform this step.
q. Notes: This is where you can put whatever notes you want to about this migration
action. Type away, this is your spot!
r. Perform: This is currently grayed out, meaning that we can’t Perform the migration
action at this time. That is because we haven’t assigned it to anyone yet.
s. Status: This is grayed out also, because we haven’t Performed this migration
action yet. For some migration actions (specifically, ones that do not invoke health
checks), this folder is not used. For those migration actions that do invoke health
checks, this is where the health check output will be found.
t. Input Variables: We don’t use this for the z/OS Migration Workflow, but variables
which are provided to the step would be shown here.
u. Feedback. We DO use this for the z/OS Migration Workflow! This is where you
can provide your feedback to IBM, if you wish, on how this step went.
Read what is under the General tab, scrolling to the bottom. This is the exact same
template and words that is are in the z/OS V2.3 Migration book.
v. Click on Close.
#4r #4s
#4v
14
5. Assigning a step (migration action).
We now know the basic layout of what the z/OS Migration Workflow looks like. Let’s get
to the real work – assigning those migration actions to get them performed. You can
assign a group of migration actions (say, all the Communications Server migration
actions), or individual migration actions to a z/OSMF user. You select which steps to
assign based on what steps are checked – a higher level step (which would include all the
sub-steps), or on the smallest sub-step itself. The idea is the same. We will assign all the
Communications Server migration actions to a lucky person (ourselves) in this lab.
You should be back on the panel where the steps are shown:
a. Scroll down until you find “Communications migration actions”, step 4.4. You will
notice that the state of these steps is “Unassigned”.
b. Click on the empty check box for step 4.4. This will select all the steps in the
Communications Server section of this workflow, which contains 19 steps for
Communications Server to migrate from z/OS V2.2 to V2.3. You can see how
many steps are selected by the “Total Selected” just about the “Return to
Workflows” button.
#5b
#5a
c. With only the “Communications Server migration actions” selected, under the
Actions pull-down, go to “Assignment and Ownership”, then select “Add
Assignees… “.
#5c
16
This is an interface you are probably familiar with.
d. Click on userid in the list (SHARAnn, for instance), and if you wish, you can click on
another userid. These people you add will be assigned to this migration action
(step). If you don’t see your userid on the list…then add it! (Actions -> Add… ->
then for SAF User ID, type your SHARAnn userid and “OK”. Now, it should appear
on the list.). We are assigning to two people, so you can learn how to accept a
migration action (step) assigned to you.
e. Click on the “Add >” button, and see that two people have been added to the yellow
box on the right.
f. Type a friendly note, if you want, and then click on “OK”. If you left the “Send
z/OSMF notifications to assignees…” box checked, these people will be notified
they have something to do. The Notification is sent.
#5e
#5d
#5f
g. Now you are back into the workflow. Keep untwisting the “Communications Server
migration action” items until you can see the final steps. Scroll to the right and look
for the “Assignee” column.
h. Under “Assignees” you can see the migration actions for all of Communications
Server have been assigned to you and the z/OS Administrator (or just you,
depending on who you assigned it to). (You might have to expand the left hand
side to see Notifications, since we collapsed it before.)
i. Notice also that the State is now “Assigned” on all this element’s migration actions
(steps), because we selected the entire element of Communications Server’s
parent step.
j. Notice also that on the left side under “Notifications”, there are notifications which
means that something is waiting for us to look at.
#5j
#5g
#5i
#5h
18
6. Accepting a step (migration action).
“Assigned” isn’t enough to perform the migration action (step). You must also have the
migration action Accepted by the assignee. We are going to temporarily leave the
Workflow section in order to accept our assignment of the Communications Server
migration actions.
You should at this point see that ‘Notifications(nn)’ has appeared on your screen. If you
don’t see it, try to click “Refresh”, or you can logoff and logon back to z/OSMF. The lab
system sometimes loses connectivity at a conference and you may have to re-establish
your identity in order to see the Notification.
a. Click on “Notifications(nn)”.
b. Click the blue highlighted Description. (If the click doesn’t work on your browser, do
a right mouse click, then “Go To Task”.) This will bring you back into the workflow
where you have steps assigned to you. Once you click on the notification, it will not
show up as “Notifications(nn)” anymore. It will have just “Notifications” (without the
(nn)) indicating that you have seen new messages. You can delete a notification if
you wish in Notifications, by just selecting the item(s), then Actions pull-down ->
Delete.
#6a
#6b
We are put back in the workflow (which we got to by way of the Notifications selection).
Let’s see how to find what was assigned to our userid. Scroll to the right to find the
“Assignees” column, and click on “Filter”.
(You can collapse the left hand side again for more space.)
20
Then, under the “Assignees” blank area on the right, type your userid (SHARAnn,
SHARBnn, SHARCnn), to filter on migration actions that are assigned to you, and then
click on “Filter”.
c. You should see only the migration actions (steps) that are assigned to you because
of the filter. We are going to accept all the Communications Server migration
actions that were assigned to our userid. Check the one box called
“Communications Server migration actions”, step 4.4 (which indirectly selects all
the sub-steps).
d. Then click on the “Actions” drop-down, then “Accept”. If “Accept” is grayed out, you
have not selected any steps, so verify that all the Communications Server steps
have a check on them.
#6d
#6c
22
e. You can make a comment when you accept these steps, then click on OK.
#6e
You might need to scroll back down the Communications Server steps, but your filter
should still be active, showing just your assigned steps. These steps (migration actions)
for Communications Server which were assigned and accepted, and are “Not Ready” to
be performed. Why?
look
Click on the step, and go into the “Dependencies” tab…that is because a dependency in
our Workflow has not been completed.
This discovery step is a new step added into the z/OS V2.3 Migration Workflow. It is there
to help you “skip” unnecessary migration actions that you don’t need to do on this system.
24
What should you do? By yourself (with no screen shots, as you should be able to do this
on your own by now):
1. Go back to all the steps in the Workflow. An easy way to do that is to click on the
Workflow name “breadcrumb” at the top, highlighted below:
2. Assign yourself Step 1 “Discovery z/OS features to use” (you’ll have to “Clear”
the Filter to see it, since it’s not assigned yet and you had the filter on before),
3. Accept it. You should see the state as Ready then.
4. Click on Step 1 “Discover z/OS features in use” so that we can Perform it.
5. Go to the Perform tab inside the step. Read the instructions for what will be done
for this discovery task. Then click Next>.
6. You will have to fill in where discovery needs to store its findings, to be used by the
later parts of the workflow. Use the /tmp directory on this system, but make sure
you insert your own userid for the file name, and do not add a “new” directory. If
everyone uses the same /tmp file, we will all overlay each other’s information.
Insert your userid, and then click Next>. Verify your name is something like this:
/tmp/mwalle_migration_inputfile.txt
.
26
7. You need to supply a job card so that the discovery program can run. You can just
take the default. Click Next>.
8. Moving along, review the JCL if you like, and then click Next>.
10. When the job completes, you can look on the Status tab at the output. If you look
at the bottom of the SYSTSPRT tab, you can see that this lab system doesn’t have
all the priced features of z/OS enabled. Therefore, if we aren’t running them, the
steps for those features can be skipped. This makes our Workflow smaller! Look
at a couple of fields here after you return to all the steps in the Workflow:
a. The Discovery step has been Completed, and
b. the skipped steps are automatically marked as done at the
top!
28
7. Performing a step (migration action).
Let’s recap: you’ve defined a migration workflow to a system, you’ve assigned migration
actions to lucky folks, you’ve got the migration action assignments accepted (for the
Communications Server migration actions), you’ve run discovery to skip some migration
actions automatically, and now you need to perform the migration actions. Although the
migration action may require a lot of work to perform, it is very easy within the z/OSMF
workflow to say it’s been done and keep track of it.
Another benefit of using z/OSMF Workflows to help with your z/OS Migration is that you
can run associated health checks directly from the z/OS V2.3 Migration Workflow.
Performing a migration action step in a Workflow is very much like repeating what you did
for performing the discovery step.
At this point in time, you are going to be a little on your own to perform a migration action
step. We’ll list the exact activities to do, but you should be able at this point to perform a
Workflow step pretty much by yourself. See the screen shots above, if you need to. But,
it really is quite intuitive after you’ve already done one…now you know how to do them all!
1. Select the Communications Server step 4.4.1.10 “IP services: Accommodate the
removal of SMS as a default VTAM VIT trace option”. Notice that is it is now
“Ready”, because you Performed the dependency discovery step above.
2. Read the “General” tab. This is exactly what is in the z/OS V2.3 Migration book.
Notice how it has a Related Health Check? We are going to be running that health
check in a bit.
3. Go to the “Dependencies” tab. This is where you can indeed see that the
dependency (for Step 1) has been successfully completed.
4. Go to the “Perform” tab. This is where you will be running the health check from
the Workflow.
a. Review the instructions in the mini-wizard. You can see here which check
will run, and how it will affect the state of the step after it runs. Click on
Next>.
b. Here’s the jobcard it will use. You can just use the defaults. Click on Next>.
c. Review the JCL. You don’t need to change it. Click on Next>.
d. To Submit the JCL, just click on Finish>. The job is then submitted.
e. Look through the Status tabs. Did the job fail?
i. If so, why? Was it something you could fix by editing the JCL quickly,
like a JECL or stray commenting error that accidently was inserted if
you happened to edit the JCL?
ii. To fix the JCL quickly, you go back into the Perform tab, and use the
<Back button to edit the JCL and re-submit it.
iii. Did the health check run? (Hint: Status tab, then SYSTSPRNT at the
bottom.)
1. If yes, then the step will be Complete.
2. If not, then the step will be in Error. Look at the health check
output from the Status tab (SYSTSPRT and SYSOUT
specifically) for the reason why.
a. If the check was not found (SYSOUT has “No matches
found” which sometimes happens), it means that you
might need to install PTFs on your system so that the
check is available. Remember, not all checks are
available on all levels of z/OS, so check the General tab
to see if you are running on a z/OS level that contains
this check. (This is something I know would be a very
nice future enhancement!) If the check is trying to run
on a level of z/OS that doesn’t contain it, the only thing
you can do today to get the step completed is to select
the step and do an override (described below).
b. If the check fails because what it was validating wasn’t
set correctly (SYSOUT has STATUS: EXCEPTION-
xxx)…then you’ve got to look at that and decide what to
do? Do you want to fix the problem so the health check
will succeed? What do you do today when a health
check fails on this system?
f. When you are done getting the JCL run or given up on it, click Close to
return to the steps of the Workflow.
i. Fyi: If your step is Failed, and you want to force the state to
Completed you can. When the step check, go to Actions->Override
Complete. This will then make the state “Complete-Override”.
g. Now, you should be on the list of steps in the Workflow. With step 4.4.1.10
“IP services: Accommodate the removal of SMS as a default VTAM VIT
trace option” (the step we just completed, or overridden, or failed) checked,
click on Actions-> Feedback. This is where you will provide to IBM any
feedback you wish. This is completely optional. You control when the
feedback is sent to IBM, and you can edit it before you send it. Answer the
questions however you thought, and then click on Submit. Then OK and
Close.
h. If you want to give an overall review of the z/OS V2.3 Migration Workflow,
then Perform step 5 “Provide feedback to IBM on your migration
experience”.
i. When you want to collect all the feedback for all the steps that have
feedback, go back out to the main Workflow pages (with all the Workflows
on the system shown). You can use the breadcrumb called “Workflows” at
30
the top of the Workflow:
j. Check the Workflow that you want to provide feedback on. Then click on
Actions->Generate Feedback Summary. You can see all the feedback for all
the steps that have submitted them. From here you, can export it for
sending to IBM. You can Notify the step owners to provide the feedback.
8. Skipping steps
Although this Workflow has a lot of steps, we expect that not every migration action (step)
applies to you. For that reason, you will probably be Skipping steps in the workflow after
you have reviewed them.
To skip steps, it’s very easy. It’s very much like Assigning steps, which you’ve already
done. For this lab, let’s skip all the zEC12/zBC12 migration actions (assuming that
everyone is running on a newer server!).
1. Before doing anything, make sure you Filter in the Assignee column is cleared. It
4. Now, click under Actions-> Skip. Give a reason for skipping these steps, and then
click OK.
5. In one action, you’ve just skipped 5 migration actions (steps). Notice how the
“Steps Complete” at the top of the Workflow reflect this change in state.
32
Exercise review and wrap-up
By completion of this lab, you now know how to:
__ 1. Download the z/OSMF z/OS V2.3 Migration Workflow files from github. You know
where to find it, and which files to download. You know to transfer it in BINARY to
a file system on your z/OSMF system. Make sure you transfer as RAW!
__ 2. Logon to z/OSMF. Enter into the Workflow function. You know what the
Notification function is, and how to use it.
__ 3. Create a z/OS V2.3 migration workflow within z/OSMF.
__ 4. Look at some of the z/OSMF workflow functions, and generally how to maneuver
around a workflow. Understanding the concept of states and steps (and sub-steps).
Understand what the tabs for a step (z/OS migration action) are, and how they are
used.
__ 5. Assign steps (migration actions) to different users.
__ 6. Accept the assignment of a step (migration action).
__ 7. Perform a step (migration action).
__ 8. Provide feedback for a specific migration, and how to provide feedback for the
entire release, if you like.
__ 9. Skip several steps (migration actions) at once.
End of exercise
You can delete your lab workflow if you want. On the Workflows main panel, select the
Workflow and then Actions-> Delete.