Additional workflows to cover zfs mount&creation for smpe pax and un-paxing process

[pavelzlatnik]

In the installation road map, there is process called “download zowe smp/e build”, described as one box.

But in reality, this process are 3 actions.

1. Create manually your own JCL to allocate proper ZFS and mount it to mount point
2. Download PAX from zowe.org to your pc and upload it (via ftp, or winscp) to your new mount point
3. Create manually your own JCL which will do proper un-paxing

Action 1

Action 3

So for action 1 and 3 user have to have some mainframe skills with JCL creation, JCL debugging and some basics with USS, and because you as a user are creating those JCLs based on some samples in docs, it take some time to debug it into running version when you start from scratch.

It would be nice if for action 1 (zfs and mountpoint) and action 3 (unpaxing to uss) we would create 2 zosmf workflows which would do this for user. In the workflows would be inline jcl in exact forms with variables on proper places. So user will just download those 2 workflows from zowe download page User would download those workfows from https://www.zowe.org/download,

put it via ftp or winscp to uss, load it in zosmf, and he would have to just set up variable values, he would not need to re-create those jcls from scratch. So those 2 steps could be much easier and faster for him. (user would just review those JCLs inside the workflow and execute them, he would not need to create them).

note: Now you have to recreate jcls which would do this job for you by hand. In the online doc is missing info what should be zfs allocation size to be enough space for the smpe pax. As well jcls examples in online doc are slightly different from .txt description which is in the pax. And even examples from .txt needs some customization from user when he recreates it by hand in target LPAR.

[OnnoVdT]

If we are reworking what is available for download on zowe.org, we can also look into the idea of placing the SMP/E install workflow here, as mentioned in a #zowe-isntall-rework slack thread. It is a logical extension of providing the workflow to upload the SMP/E files.

[pdubz3]

Seems like it would be easier if that workflow was distributed as part of the pax file but not as part of one of the relfiles. Then you can refresh the pax file anytime the workflow is updated without impacting the SMP/E base relfiles. Is that possible?

[John-A-Davies]

Sysprogs who elect to go down the SMP/E route will be well-versed in editing JCL as provided in AZWE001.htm (the mandadory Program Directory) and AZWE001.readme.txt (fragments of JCL to create the USS directory, run GIMUNZIP etc) and indeed they may have their own. They may not know about workflows or even have z/OSMF running.

What I think you're proposing is an over-arching mechanism to process the FMID using workflow. FMID AZWE001 is fixed so if you want to embed workflow, you'd need a new FMID AZWE002, or to ship a separate ZWEWRF01 (?) file as a separate download. If there's a strong demand for a workflow that assists in the first few steps in the way you describe, then I'd suggest a separate download. Then you could have the new workflow ready for FMID AZWE002 when Zowe v2.0.0 comes out.

[pdubz3]

I could be missing the point, but I think what Pavel has pointed out is that the workflow is used to create the SMP/E environment, and therefore it should not be SMP/E managed. I think a separate FMID is overkill. A separate download would work, but I thought maybe it would be easier just to bundle it with the one download.

[John-A-Davies]

@pdubz3 Yes, you could add that to the AZWE001 .zip file, which at present contains pax.Z, htm and readme.txt files. It would need to go into the build pipeline in zowe-install-packaging and have a test in zowe-install-test to make sure it worked.

[OnnoVdT]

This discussion is also going on in a mail thread. Recapping possible solutions and their impact mentioned there:

• Do nothing and have customers use the sample SMP/E JCL until Zowe v2.x becomes available. If we opt for this then it's advisable to temporarily remove documentation that references the install workflow.

• Mark Zowe v1.x as service-only now and create Zowe v2.x, which has a new FMID and thus the updated workflow. I doubt anyone is willing to go down this path

• Refresh the v1 FMID on zowe.org, Shopz, and wherever else it is hosted. This requires paperwork, doc updates and a modification of the build pipeline. Customers will get the updated workflow without additional actions on their part. For this release the build pipeline must create a normal and a refresh SMPE package. We still need the non-refresh package to be created as it is used in other parts of the pipeline.

• Add the workflow to the FMID zip A modification of the build pipeline is needed, and this might not work for Shopz (does not ship zip but FMID). If it is possible for IBM, then I expect at least paperwork, which might accumulate to be the size of a FMID refresh. Customers will get the updated workflow without additional actions on their part. The build pipeline must add the workflow as seperate part in the zip, and documentation on how to get z/OSMF to use it.

• Place the updated workflow on zowe.org This requires changes to zowe.org, an announcement of the update and a modification of the build pipeline. Customers will need to know to go to zowe.org to get the latest workflow after obtaining the FMID and before starting the install. The build pipeline must create a new package to be placed on zowe.org holding just the workflow and documentation on how to get z/OSMF to use it.

[jp669844]

Closing: #1605