IBM z/OS Management Facility (z/OSMF)

These are questions and answers captured from the Webex chat during the z/OSMF Guild Session 5 on March 16, 2022.  Questions were answered by @John Czukkermann, Hiren Shah, Travis Biro & Rolando Perez.  If you have further questions, you can respond to this forum or contact any of us directly.   

1. Where can I find the materials & links that were shared during Guild Session 5?

• Session 5 Presentation and Recording
• z/OSMF Guild Home
  
• Poll

This is a difficult question to answer because it depends on how much experience you already have with z/OSMF Workflows.  You must have a workflow definition in order to create a new service.  You can use the Workflow Editor tool to help create workflow definitions.  Workflow definitions can be very complex and sophisticated.  Most of the difficulty of creating a new service is likely to lie in creating the workflow definition.

7. Given the workflow definition, you will want to think in terms of the staff you are trying to help with the service being created.  What is the best way to organize the inputs?

• You can group inputs into pages, much like workflow input categories.
• You can determine if any of those inputs should simply have hard-coded values.
• Should some inputs limited selections based on conventions in your shop.
• What inputs are dependent on the selections of others. You can setup logic to show inputs based on the selection for another input.

The following PTFs are the latest service level for z/OS Management Services Catalog:

• z/OS 2.4: UI78976
• z/OS 2.5: UI78988

These require the PTFs for

• Core APAR 39637
• Configuration APAR PH41334
• Workflows APAR PH40841

You should refer to the z/OSMF Configuration Guide to learn about the required security setup.  The SYS1.SAMPLIB(IZUMSSEC) sample job can be used to accomplish the security setup.  Then: 

11. Don't we have to be careful not to insulate new z/OS system programmers too much, thus hindering them in doing their jobs

Making a task extremely difficult doesn't necessarily facilitate educating new system programmers and making them proficient.  It can actually inhibit establishing confidence in their ability to do their jobs.  The goal is not to dumb down z/OS management.   z/OS Management Services Catalog is designed to facilitate more rapid learning and productive contribution by early-tenure system programmers.

As with everything we do when managing z/OS, things will fail; things will break.  Early-tenure system programmers will have to dig into the failures to understand the root causes and learn how to address them.  z/OS Management Services Catalog facilitates this by allowing you to open the workflow instance of a service submission and visually inspect what the workfow instance did, ESPECIALLY when the submission failed.

Yes.  The initial release of z/OS Management Services Catalog currently ships the following sample services as UNPUBLISHED.  They will be visible to administrators via the Administration tab.

• Create a zFS file system
• Expand a zFS file system
• Mount a zFS file system
• Unmount a zFS file system
• Delete a RACF user ID
• Delete an alias from a catalog
• Replace SMP/E RECEIVE ORDER certificate

These services and submissions are artifacts on z/OS Management Services Catalog.  Like Cloud Provisioning & Management for z/OS, we leverage Workflows to get the job done.  We are not a veneer over the Workflows plugin.

To illustrate, when you create a service, we create a z/OSMF resource that we managed, including creating a protected copy of all of the workflow related files associated with the service.  When you submit the service, we use those workflow files to create a new workflow instance.  We monitor that workflow instance to determine if it failed or was successful which in turn determines if the submission failed or was successful.

z/OSMF workflow definitions are XML documents.  You could choose to call the files whatever you like, but it could be confusing.  It is pretty standard to use a suffix that identifies the form/format of the file's content.

I'd like to point out that the workflow definitions are not required to reside in files.  They can reside in sequential and partitioned data sets.

After we've copied the original files and performed validation, there are some minor internal changes made to our internal copy of the workflow definition.  But ALL customization done in the service builder support is saved as part of a service resource maintained in our catalog.  The service builder support is not a workflow editor/customization tool.  This is consistent with the prior answers where we emphasize that we leverage z/OSMF workflow definitions and the z/OSMF Workflows plugin support to accomplish our mission.

In that particular example, helloworld is not actually a program, but the work that was done by the service is actually in the workflow definition itself.

There are two steps in the workflow definition that do the work.  One is used to write to a dataset and another step is used to write to a file.

The dataset step uses the following in-line template that is run as JCL by Workflows:

//STEP010     EXEC PGM=IEFBR14,TIME=5            

//NEWPDS02   DD DSN=${instance-dataset_name},                   

//            DISP=(MOD,CATLG,DELETE),UNIT=3390, 

//            SPACE=(TRK,(5,5,5),RLSE),          

//            DCB=(BLKSIZE=0,RECFM=FB,LRECL=80)  

/*                                                

//STEP1   EXEC PGM=IEBGENER

//SYSPRINT DD SYSOUT=*

//SYSIN DD DUMMY

//*SYSUT1  DD DSN=${instance-dataset_name}(${instance-member_name}),DISP=(OLD)

//SYSUT1   DD *

${instance-greetings}

//SYSUDUMP DD SYSOUT=*

//SYSUT2  DD DSN=${instance-dataset_name}(${instance-member_name}),DISP=(OLD)

/*

The file step uses the following in-line template that is run as shell-JCL by Workflows:

rm ${instance-file_name}

touch ${instance-file_name}

echo ${instance-greetings} >> ${instance-file_name}

This question implies that Workflows are inherently 'slower' than other methods of accomplishing work on z/OS.  Workflows provide the ability to compose steps in a series of tasks to orchestrate completing more complex z/OS tasks.  Therefore, running a workflow for a complex sequence of tasks should take no longer, processing wise, then it would to perform each of the tasks in the sequence manually.

If you are running workflows that have manual steps, of course they will be slower because people must be involved.  z/OS Management Services Catalog only supports automated workflows at this time.

Having said that, z/OS Management Services Catalog submissions actually run a workflow instance.  Therefore, they are neither faster or slower, processing wise, than simply running a workflow instance.

You could think of running a service as being more convenient because you don't have to manually create a workflow instance, which requires not only entering inputs, but providing the workflow definition XML file that is needed to create each workflow instance.  That workflow definition was provided when the service was created.  So to run the service you simply locate it in the catalog, click to start a submission, and enter your inputs.

No, not yet.  The current support uses ZMFAPLA resource profiles to determine user roles, which controls what a user sees and can do in z/OS Management Services Catalog.  We adopted a software defined role-based approach.  The roles are controlled by the security manager (RACF/ACF2/TopSecret).  The plugin defines what operations can be performed by each role.  The current roles are:

• User – Can access the catalog, submit services, monitor and manage submission through Activity/History.

• Administrator – In addition to capabilities of the User role, the Administrator role can create new services and manage the lifecycle of existing services. Additionally, the Administrator role provides the ability for administrators to take action on any submission, even if they did create the submission.

• Publish approver – This role is only in effect if the setting to require approvals to publish services in the catalog is enabled.
  Eligible to be assigned as an approver of services that an administrator requests to be published. When publish approval is enabled in settings, only users with this role can be add to the table of eligible publish approvers.  When an administrator requests approval to publish a service, they will be prompted to select one or more publish approvers from the list of them identified in settings.
  Users with this role will have access to the Administration page and can view only those services for which they are identified as a publish approver.  The only actions they can perform on the services available to them are related to approval/rejection of requests to publish services.

• RunAsUser approver – This role is in effect even if publish approvals are disabled. Only users with this role can approve the use of runAsUser steps used in the workflow definition for a service.
  
  The runAsUser approvers are identified in the workflow definition itself.  When the service is being created, we validate that any the approvers identified for each runAsUser step in the workflow definition have the runAsUser approver role in z/OS Management Services Catalog.
  
  As with publish approvers, users with this role will have access to the Administration page and can view only those services for which they are identified as a runAsUser approver.  The only actions they can perform on the services available to them are related to approval/rejection of requests to publish services.

• RunAsUser – Only users with this role can be specified as the surrogate user ID used to run the associated step in the workflow definition.