Tip: How to Store Zowe CLI Arguments in Team Config (medium.com)

[FALLAI-Denis]

Hi @dkelosky

I read your post on medium.com Tip: How to Store Zowe CLI Arguments in Team Config.

I prefer to make my comments here, on a technical site, than on medium.com which is a social network type site.

I find the solution based on a config file very interesting, on the other hand I think that there are several architectural problems.

Separation between shareable and non-shareable information in a team or a company.

The zowe.config.json file contains everything ... whether it's information related to a user (especially credentials) or information that is actually shareable by a team or even a company.

I think the idea of ​​the config file should be declined on at least 3 levels:

• the user, user config file (local)
• the team, team config file (replicated ? synchronized ?)
• the rest of the world (the company), global config file (replicated ? synchronized ?)

It would also be necessary for the configuration parameters to be either attached to a Profile (in the sense of Zowe CLI Profile), or global to all Profiles.

With of course an order of priority in case of conflicts in the parameters at different levels and Profiles:

• first user config, otherwise team config, otherwise global config,
• first the parameters linked to a Profile, otherwise the global parameters for all Profiles.

User config should be local to the workstation, possibly shared by multiple workstations if the underlying operating system allows it.

Team config should be managed contextually, as one can belong to multiple teams.
When working with a Git Repository, the Teams settings should be in the Git Repository, and in the workspace corresponding to this Git Repository (especially when working in a Terminal open in VS Code).

Global config should be managed either at the "Zowe installation" level, or searched on a shared, published space, so a priori through network access, or even on the Host z/OS system (see how manage global parameters, all Profiles, therefore not attached to a particular z/OS system).

Reuse of command arguments.

In your talk, you illustrate the value of creating kinds of shortcuts to execute Zowe CLI commands.
You associate them with Profiles.
In my opinion this is an error because it is not about Profiles information (in the Zowe Profile sense), but about parameters on groups and actions.
I think it would have been better to manage them as "actions" defined in "groups".

If I take your example:

zowe files create pds "ibmuser.fb81.demo" --record-format FB --record-length 81 --block-size 162 --primary-space 2 --secondary-space 2 --directory-blocks 5 --show -attributes

I think it should have been implemented like this:

zowe files create pds.fb81 "ibmuser.fb81.demo"

By defining parameters associated with the pds command, create action, files group, and without impacting the z/OSMF Profile which is not concerned and remains just an identifier for access to a service.

At the config file level, it could be implemented like this:

{
  "shortcuts": {
    "groups": [
      {"files": {
        "actions": [
          {"create": {
            "commands": [
              {"pds": [
                {"fb81": {
                  "properties": {
                    "recordFormat": "FB",
                    "recordLength": 81,
                    "blockSize": 162,
                    "primarySpace": 2,
                    "secondarySpace": 2,
                    "directoryBlocks": 5,
                    "showAttributes": true}
                  }
                },
                {"listing": {
                  "properties": {
                    "recordFormat": "FBA",
                    "recordLength": 133,
                    "primarySpace": 2,
                    "secondarySpace": 2,
                    "directoryBlocks": 5,
                    "showAttributes": true}
                  }
                }]
              },
              {"ds": [
                {"sysin": {
                  "properties": {
                    "recordFormat": "FB",
                    "recordLength": 80,
                    "primarySpace": 2,
                    "secondarySpace": 2,
                    "showAttributes": true}
                  }
                }]
              }]
             }
          }]
        }
      }]
    }
}

[dkelosky]

Thanks @FALLAI-Denis 😄

Separation between shareable and non-shareable information in a team or a company.

To some extent (although probably not entirely as you might expect), we do have the three levels of config that you mentioned today:

• zowe.user.config.json, ("user config") intended to be in .gitignore and contain user-specific info, e.g. user proc or account number
• zowe.config.json ("team config") in project scope, intended to be sourced. the user + password are associated here but are stored in secure credential store
• zowe.config.json` ("global config") in workstation user's "home" directory - or in the future, some shared network drive / hosted site-wide

If you have all three of these files in existences, they're merged together to form all known profiles whenever you use a single zowe command.

Reuse of command arguments.

I wasn't intending to make a case for why the config is organized the way that it is; rather, I wanted to share what is possible today. However, you have an interesting idea for shortcuts here. Perhaps it could be some enhancement.

As a side note, you can reverse the shareable content differently than the way it was described in the blog and reuse common command options for multiple profile types (assuming they have the keywords), e.g.:

        "load": {
            "properties": {
                "blockSize": 32760,
                "directoryBlocks": 20,
                "recordFormat": "U",
                "recordLength": 15476,
                "dataSetType": "LIBRARY",
                "size": "5CYL",
                "showAttributes": true
            },
            "profiles": {
                "zosmf": {
                    "type": "zosmf",
                    "properties": {
                        "port": 1443
                    }
                },
                "rse": {
                    "type": "rse",
                    "properties": {
                        "port": 1444
                    }
                }
            }
        },

For:

• zowe files create pds ibmuser.zosmf.created.loadlib --zosmf-p load.zosmf
• For zowe rse create pds ibmuser.rse.created.loadlib --rse-p load.rse

[FALLAI-Denis]

Hi @dkelosky

Thank you for answering my message.

My main point was to say that it is not up to the "profile" to carry information linked to the groups / actions / commands, but to the groups / actions / commands themselves.

The profile should only manage information related to the services accessed and the credentials used to access these services.

And I even think that the information related to the services, like location informations, (url, port, protocol...), should be managed outside the profile because they are shareable informations and the profiles, which is related to an user, should only contain the reference to a service (and not the properties of the service) and the credentials to access this service.

[dkelosky]

Thank you for engaging in the discussion. I prefer it to posting silence

I see your point. I think our usage of profiles is a bit broader than information related to the services accessed and the credentials. We have an Endevor Zowe CLI plugin with lots of command groups. The Endevor CLI plugin introduces 2 profiles: endevor and endevor-location. The former for connection info and the latter for information about the Endevor environment/system/subsystem being accessed. Similarly, we have a sysview-format profile to controlling display formatting for various sysview commands.

That is, I think we allow any data to exist within profiles and allow for any type of profiles. We could probably introduce a files-create-data-set profile, but we'd need an enhancement to allow for shortcuts as you have described.