IBM Z Hardware and Operating Systems Ideas Portal
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).
Shape the future of IBM!
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:
Search existing ideas
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 your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
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.
This is Ken Nufer from JPMC. I opened case TS011865490, which is referenced in the RFE. I can provide a little more clarity on how this happened. When we do our LPAR builds (a GDPS control LPAR in this case), we restore an initial set of system volumes from DSS dumps and then run CONVERTV against them in the new environment. It is possible that a given TSO alias may not be defined in the master catalog when the dumps are taken on the source system. We have had that issue on multiple plexes and are working to clean that up and prevent future issues.
I opened the RFE at the request of the IBM engineers who struggled with us through this issue for nearly two months. I have to say I'm surprised that this is being given no consideration. It was a painful issue for us. We were able to work around it by doing data set moves, which corrected the catalog issues.
The RFE is to help prevent these issues. I'm unclear on why it would be rated as 'not under consideration'. Should this be addressed against CONVERTV instead?
Thanks,
Ken
Yes, I can explain. The SMS 'bit' was not being turned off. Someone issued a DEFINE NONVSA< command using the name, The name is never verified on a DEFINE NONVSAM. If the data set is SMS managed, the correct operation is DEFINE NONVSAM RECATALOG. When DEFINE NONVSAM RECATALOG the NVR or VVR is read from the VVDS for the volume to verify the data set exists on the volume and to copy the SMS construct information to the Catalog record.
"And how can a define create a wrong back pointer in the VVDS NVR record if it is SMS managed? NONSMS datasets do not even have NVR (or VVR) records. If no usercatalog alias existed at the time of the define, then it's actually correct to put the mastercatalog name there as that is where datasets are cataloged if no alias exists. However if you have multiple mastercatalogs and each LPAR of a Sysplex might use a different one then you could have some with aliases defined and others not which could create this situation where on SysA it has an alias point to USERCATa but on SysB it has no alias so datasets are cataloged in that local mastercatalog and is invisible to SysA"
You cannot use DEFINE to create a wrong back pointer in the VVDS NVR/VVR. The back pointer (NVR/VVR catalog field) is used only to ensure that the user does not DELETE the wrong data set. Allocation and other IDCAMS command are not affected by When a REPRO NOMERGECAT is performed, all SMS managed data set NVRs or VVRs have their catalog entry (back pointer) . This is normal and has been this way since ICF Catalog was introduced in the 1980s.
What is said about multiple LPARs and multiple catalogs is correct. If SYSA has ALIAS CDF with related usercatalog AB and SYSB has no ALIAS CDE, entries on SYSA will be placed in usercatalog AB and entries on SYSB will be placed in SYSB's mastercatalog. Keeping ALIASES with non-shared master catalogs in synch can be difficult. That is the whole reason that installations use shared master catalogs.
If you have further questions or observations, you may reach me at branchs@us.ibm.com.
Can you explain HOW the SMS 'bit' was being turned off, and where? Was it the catalog record or the DSCB/VVDS or what? I cannot see how it is possible without trying to do something very wrong or unusual. (CONVERTV, Zap of DSCB, null the STORCLAS, activating a null SMS config or different SCDS/ACDS/COMMDS on different LPAR's in a plex...the mind boggles!)
And how can a define create a wrong back pointer in the VVDS NVR record if it is SMS managed? NONSMS datasets do not even have NVR (or VVR) records. If no usercatalog alias existed at the time of the define then it's actually correct to put the mastercatalog name there as that is where datasets are cataloged if no alias exists. However if you have multiple mastercatalogs and each LPAR of a Sysplex might use a different one then you could have some with aliases defined and others not which could create this situation where on SysA it has an alias point to USERCATa but on SysB it has no alias so datasets are cataloged in that local mastercatalog and is invisible to SysA