z/OS HCD HMC-Wide Activation Enhancement

This item is a valid requirement but unlikely to be given high enough priority to be placed into the product plan.

This item is not in our plans but is being kept in our backlog.

many thanks for describing your requirement and clarifying our questions in more detail.

Your requirement is a useful enhancement to our function 'HMC-wide activation'
and we will move it to our requirement list.

Kind regards,

I appreciate your consideration of this request.

We have about 40 separate LPARs, on 5 separate CECs, in our environment. We have about 10 system programmers that maintain these systems (and also manage a few other systems in separate, remote environments under contract). So, we basically share responsibility for all of the system programming work across all of these systems.

And, HCD changes is one of those responsibilities that is shared.

Typically, when we have HCD changes to make, such as defining new DASD addresses to a SYSPLEX, we will split up the work and assign the changes for each CEC involved to different system programmers, so one person doesn't have to do it all. (FYI: After coding changes are done, then the system programmers involved would then, typically, verify the coding for each other's changes before the changes are activated.)

So, with this in mind, all of our system programmers require full HCD access to all of the LPARs, on all of the physical CECs, in our environment. Using RACF to limit the access through BCPii to various HCD/IODF/LPAR/CEC resources wouldn't help.

And, going into HCD, and then choosing options 2, 11, and then V for the CEC that the system programmer are wanting to work with, is terribly slow when it has to go out and create a connection to all of these LPARs across all of the CECs.

Now, as to your questions...

First of all, we have a single HCD Profile dataset that contains the standard values that we want everyone to use, for consistency.

Next, when I opened this RFE, I wasn't sure what you might see as the correct way to implement something that would be the most useful for all users across the many diverse environments that HCD is used in. So, my request had several things in it that might be useful, although, depending on how things are implemented, may or may not be useful in the final version that is released.

>> 1. Since the user IDs and passwords are maintained in a single connection table, it would be useful if each user could have a separate connection table that could be set up in the HCD profile dataset using &SYSUID..HCD.CONNECT.TABLE, or something to that effect. And, possibly something along the lines of &SYSUID..&CECID..HCD.CONNECT.TABLE. The &CECID variable could then be assigned within the HCD REXX user exit that was a part of the request.

>> 2. With so many LPARs being maintained from this single HCD environment, and with there being only one connection table, not all LPARs across the environment have the system programmers defined with the same user ID. So, it would be useful to have a table, for each user, that would have the user ID associated with each LPAR, that each individual user would maintain. But, it would be nice to have only a single copy of a connection table that has the network connectivity information in it, rather than having a copy of that information for each individual user to maintain. So, the idea here is to have a single connection table with connectivity information, and then merge in the user IDs and passwords for each LPAR, for each individual user.

>> 3. For this user exit, the exit would probably need at least some basic information, such as the user ID, although &SYSUID could work, and the HCD IODF name from the first HCD panel, the CONNECTION_TABLE value from the profile (modifiable). For what I was thinking, depending on what is decided for item 1 or 2 above, the exit could take the HCD name and the CONNECTION_TABLE name, and ask the user which CEC is being modified, then pull in a user-maintained file of LPARs and the user ID to be used for each LPAR, and then ask the user for the passwords to be used for the LPARs. I'm thinking the exit, being under ISPF, could put up an ISPF panel that would list the LPARs, with a space for a password indicator, and then have a list of fields for the passwords to be entered, with a number or letter listed by each field. The user would enter the unique password values, and then enter the number or letter for the appropriate password by each LPAR. Or something along those lines, since most users would try to use the same password on more than one LPAR. Then it would copy the CONNECTION_TABLE to a temporary file, dropping the LPARs that are not on the CEC being modified, adding in the user ID and password for each LPAR. Then it would change the CONNECTION_TABLE value that was passed to the name of the temporary file and return control to HCD. HCD would then use the modified CONNECTION_TABLE for establishing the connections to the LPARs. After processing, if the CONNECTION_TABLE value used wasn't the original CONNECTION_TABLE name, it should delete the temporary CONNECTION_TABLE file to keep the passwords from being viewable by anyone else.

>> 4. The mechanism for the HMC-Wide Activation is making use of what was already created for the HCM product to use. We don't use HCM, as our management thinks it is too expensive for each system programmer to have a copy installed on each of their PCs. According to what I read in the HCD manuals, HCM has a file on the PC where the user could keep information that is then passed to the CBDQDISP task, which then reads and modifies the JCL for the CBDQAJSK job with the information passed from HCM, and then submits that job. I was just looking for something similar for HCD to use. So, job name, accounting field information, job class, message class, trace dataset name, etc. It would be nice if the CBDQDISP task could have some user-defined defaults, if not passed from the HCD, and then allow overrides for anything that is passed. For example, job class, message class, accounting information, etc. could be defined once in CBDQDISP for an LPAR, and then other fields would be passed from HCD, according to the user's values, and, according to the LPAR that CBDQAJSK is to run on, as one LPAR may require different values than another.

I know that I'm looking at this from my own needs, but I'm trying to make this generic enough to be usable by other users, in other environments, that may have many more systems than we do, or may have smaller, simpler requirements.

If you have further questions, let me know.

Thank you,
Alan

Hello Alan,

thanks for helping us to improve HCD.
We understand the overall intention of your proposed feature list, but we would like to ask a few more questions for clarification:

>> 1. Allow symbols or variables to be used in the dataset name of the HCD profile parameter CONNECTION_TABLE.
>> 2. Allow individual users to maintain a list of user IDs (and optionally, passwords) separate from the CONNECTION_TABLE, so that there can be a shared CONNECTION_TABLE, and each user can maintain their own user IDs.

Currently, connections to remote systems are established based on a single connection table.
We understand how an additional list of user IDs (and optionally, passwords) could be helpful in 'filtering' unwanted connections for individual users. Additionally (or possibly as an alternative), are you aware of a filtering technique that can be implemented based on SAF/RACF security profiles for BCPii:

HCD uses BCPii to find out about available images on a remote host.
Using BCPii security profiles, you can control for which images a user sees details.
The HCD User's Guide recommends a generic profile "HWI.TARGET.network.cpcname.*".
All users having read access to this profile can see all images, hence HCD tries to retrieve details for all those systems that appear in the connection table and are running on that host.
To limit the number of images that are returned by BCPii when asking for available images, more granular SAF profiles might be specified.
Instead of "HWI.TARGET.network.cpcname.*" you might create profiles for specific images, e.g. "HWI.TARGET.network.cpcname.mypart",
or for specific groups, e.g. "HWI.TARGET.network.cpcname.ABC*" meaning all images starting with the characters ABC.

By deciding which users get read access to a profile, you decide for which images HCD tries to get more information.
Conversely, by specifying access=none for a user to those profiles corresponding to 'unwanted' remote systems, this user might save a considerable amount of time. If the association between individual HCD users and the remote systems they work on is fairly static, then this technique may already bring some relief.

>> 3. Add a user exit that could manipulate a copy of the CONNECTION_TABLE when invoking a function such as "CPC Image List", based on information available, such as the currently selected IODF dataset name.

What parameters would you want to see in such a (REXX) user exit?
I.e., which parts of the connection table and what other information (IODF name, ...) ?
Which information (that HCD does not have) would the REXX program use to modify the table?
Is the modification something that could be done in a table-driven fashion as well (e.g., an IODF-name entry in the user-specific list according to (1) and (2)) ?
Can you provide an example of what and how the REXX program would modify?

>> 4. Add the ability to supply variable values, including user-defined variables, to be used by CBDQDISP when it modifies the CBDQASJK skeleton JCL and submits it for execution.

Please note that CBDQDISP today does not substitute user-defined variables in the CBDQAJSK skeleton JCL.
CBDQDISP knows only a small fixed set of variables that it can provide substitutions for.

Would the ability to supply values for the variables
(job name)
(job class)
(message class)
(trace dataset name)
be sufficient for you?

What would you want to achieve by having user-defined variables?

Thanks and kind regards,
Your HCD Team

Creating a new RFE based on Community RFE #85923 in product z/OS.