You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature or enhancement request related to a problem or limitation? Please describe
An improvement that can make procedures executions much faster, enable cleaner JCL repositories and explore much more the utilization of important features of Zowe is the capability to send commands and submit JCLs changing them using variables based on the system it is targeting.
It would be much faster and easy if Zowe CLI could override some variables on JCL or in console command, based on variables related with a profile or a hostname.
Describe your enhancement idea
The suggestion is before sending JCL to execution, create a previous step which overrides variables on JCL which is being sent to execution. It can be done creating a json file, similar to .zowe.env.json, for each host the users have configured, or adding variables to existing yaml files of profiles, and Zowe CLI would be responsible to substitute all variables by its values on that current target host.
Describe alternatives you've considered
The reference to this idea was Ansible which works in a similar way, changing templates of JCL in real JCLs before executing them in the LPAR.
As Ansible the Zowe could have a directory to hold json files so the users could define all variables related to that system (for instance: .zowe.LPAR1.json), or using the yaml file of profiles placed on C:\Users\user1.zowe\profiles. The example below demonstrates how it could be defined.
Provide any additional context
The example above is a IEFBR14 JCL stored in a shared file server that can be executed in any mainframe system. The dsn allocated can follow the specificities of the target system based on the profile it is using during the execution.
The text was updated successfully, but these errors were encountered:
Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.
Here are a couple methods that could be used to substitute variables from the client:
A shell script that uses find and sed to find/replace values where needed, submitting the edited JCL file with the substitutions in place
Using Handlebars or Mustache templates to make a JCL template file, and then generate the JCL files to submit using this template
You can also substitute variables on the target host using JCL symbol substitution - see the --jcl-symbols option in this section of the web help for more info.
Would one of these satisfy your use case? The team would like to rule out any alternatives before implementing this feature, so any feedback is appreciated.
Is your feature or enhancement request related to a problem or limitation? Please describe
An improvement that can make procedures executions much faster, enable cleaner JCL repositories and explore much more the utilization of important features of Zowe is the capability to send commands and submit JCLs changing them using variables based on the system it is targeting.
It would be much faster and easy if Zowe CLI could override some variables on JCL or in console command, based on variables related with a profile or a hostname.
Describe your enhancement idea
The suggestion is before sending JCL to execution, create a previous step which overrides variables on JCL which is being sent to execution. It can be done creating a json file, similar to
.zowe.env.json
, for each host the users have configured, or adding variables to existing yaml files of profiles, and Zowe CLI would be responsible to substitute all variables by its values on that current target host.Describe alternatives you've considered
The reference to this idea was Ansible which works in a similar way, changing templates of JCL in real JCLs before executing them in the LPAR.
As Ansible the Zowe could have a directory to hold json files so the users could define all variables related to that system (for instance:
.zowe.LPAR1.json
), or using the yaml file of profiles placed on C:\Users\user1.zowe\profiles. The example below demonstrates how it could be defined.Provide any additional context
The example above is a IEFBR14 JCL stored in a shared file server that can be executed in any mainframe system. The dsn allocated can follow the specificities of the target system based on the profile it is using during the execution.
The text was updated successfully, but these errors were encountered: