This is the public portal for all IBM Z Hardware and Operating System related offerings. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Now, the reason why this SymLlink processing was not omitted in the installation of Server Pac for z/OS V2.3 is that there was a key point in the JCL that generated the installation JCL for V2.3.
In V2.3, there is a JCL member called ALTCAT, and as you know, the process is to change prefix.official name → official name.
Example) ZOSYS.SYS1.LINKLIB → SYS1.LINKLIB
This is the process of renaming all datasets to official names.
At the beginning of this process was the process of changing /etc and /var to SYMLINK, which was omitted this time.
This was not leaked in V2.3 because it was handled before customization and IPL.
On the other hand, in this z/OSMF version of Server Pac for z/OS V2.5, I found that the processing of this SYML change to /etc /var by BPSISETS was moved after customization and just before IPL.
A customer requested an improvement to change OMVS.ROOT to the specified name when executing the installation JCL in the z/OSMF version of the z/OS Server Pac, just like the z/OS V2.3 Server Pac. It was done.
Therefore, I would like to see an earlier BPSISETS work step that changes the attributes from DIR to SYML for OMVS.ROOT, /etc, and /var in the z/OSMF version of the z/OS installation ServerPac.
Example) Temporary installation prefix.OMVS.ROOT brought in from DVD → change to user-specified Prefix.OMVS.ROOT
My customers do their own customization with the z/OSMF version of ServerPac once they have deployed the necessary datasets, just like with the traditional ServerPac.
It is likely that many customers do this.
If you adopt the ideas above, you will be able to avoid the problems experienced by this customer, reduce inquiries to IBM, and become more efficient.
Therefore, please consider this idea and adopt it.
Thanks ans best regards. ...Masafumi.Kageyama.
Idea priority | Medium |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
In the z/OSMF ServerPac process, we can think of there being two ?phases?: the actual deployment wizard and jobs (in z/OSMF Software Management), and then the post-deployment customization and verification (in z/OSMF Workflows).. Within that first phase is where all product-independent install work occurs ? which we could relate in ALTCAT to the renaming and cataloging of all data sets portion of that job. However, the z/OS UNIX conversion to symlinks is a *product-dependent* task, and belongs in the z/OSMF POSTDEPLOY Workflow which is dependent upon the product content of the order, after the appropriate customization is done, prior to IPL. Just like in the ALTCAT job where the z/OS UNIX conversion to symlink occurs just prior to IPL, that is the corresponding point in the Workflow where the symlink conversion happens, so there is no difference in the z/OSMF process where that z/OS UNIX task is performed. The z/OSMF Software Management portion of the installation remaining as *product-independent* as possible is critical - which means putting any z/OS UNIX specific step in those Software Management deployment jobs is not feasible. However, it does belong in the *product-dependent* customization Workflow, and so it is approximately at Step 39 of a 45 step Workflow ? analogous to the same point in the old process, right before the IPL.
Of course, the steps in the POSTDEPLOY workflow might be able to be skipped or executed in a more customer-preferred order, if an individual user desires. z/OSMF Workflow will keep track of what has been completed so progress can be ascertained. The Workflow does need some of the basic configuration settings decided early on, but once those are known, the customization steps (including ?Step 39 Create /etc and /var Symlinks?) might be able to be done earlier. However, notice, that the customization may need the /etc and /var file systems mounted, and for that reason, the symlink conversion is best to stay in the last position before IPL, for those that prefer to execute the steps in order.