Open FALLAI-Denis opened 4 years ago
The way we are planning to do this is in combination with the work being done in Zowe CLI right now for making the connections a json/yaml file that can also be managed with the sources under SCM. This will allow to define connections with a name that is shared between users, which is then augmented with local user files for user-specific parts such as username and password. See here for examples how this will work: https://github.com/zowe/imperative/pull/450
These zowe.config.json files could then be companion files next to the zapp files and zapp could then refer to the connection by name.
The evolution brought by Zowe CLI "next" (v7) will not resolve the choice of the profile to use to perform the search for COPYBOOKs / INCLUDEs on a remote z/OS system.
The problem of selecting the Zowe CLI profile according to the resources to be accessed remains unresolved.
A remote resource is a name located on a host. It cannot be declared independent of the system that hosts it.
zapp-schema-0.0.2.json declares a "system" property for a "property-group-item" object.
This property could be used to define the way to access the remote system by adding a protocol prefix:
zosmf-profile://profile_name
zftp-profile://profile_name
rse-profile://profile_name
Description of the enhancement requested
Access to a PDS file on an mvs system for searching for COPYBOOKs or INCLUDEs, requires a connection profile.
Currently, the connection profile is either the one declared by default, or the one declared in the "zopeneditor.zowe" parameter in a settings.json file (User or Workspace).
However, this connection profile is in fact directly dependent on the context of the Application and has no overall purpose, and more precisely the connection profile depends on the mvs partition which hosts the Application in the development / test phase. In our context of use, the Applications are distributed over 4 development mvs partitions, and so far we only have one workstation, and therefore one VS Code / Z Open Editor installation.
So I think the connection profile should be managed in the "zapp.yaml" file, in the "property-groups" objects of type "mvs".
However, this assumes that each user has previously defined this connection profile on his workstation, and has given it the name declared in the "zapp.yaml" file. To avoid this constraint, it would be necessary to set up an "indirection":