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
The JCL in SAMPLIB can be run without intervention of zwe.
Some find this great, but currently zwe is the tool that can verify if the input to the JCL is even valid.
Further, #3634 wishes to move all JCL logic out of zwe, which previously would do validation before job submission. Without further action, we'd move from users not being able to use all our JCL, to users having no validation. We must have both JCL and validation.
I suggest using "configmgr-rexx", which is a tool currently in Zowe that can be used to read zowe.yaml from within rexx, and invoke schema validation upon it.
With configmgr-rexx, we could:
Reduce the amount of input to the JCL needed. Parameters can come directly from zowe.yaml
Verify the input before executing any system alterations
We don't NEED to get the parameters from zowe.yaml, if someone finds that bad, but if we don't then we have the problem of users typing information in twice, so I think its preferred.
The main goal though is to ensure that the JCL do not continue before verifying user input is okay.
The text was updated successfully, but these errors were encountered:
The JCL in SAMPLIB can be run without intervention of zwe.
Some find this great, but currently zwe is the tool that can verify if the input to the JCL is even valid.
Further, #3634 wishes to move all JCL logic out of zwe, which previously would do validation before job submission. Without further action, we'd move from users not being able to use all our JCL, to users having no validation. We must have both JCL and validation.
I suggest using "configmgr-rexx", which is a tool currently in Zowe that can be used to read zowe.yaml from within rexx, and invoke schema validation upon it.
With configmgr-rexx, we could:
We don't NEED to get the parameters from zowe.yaml, if someone finds that bad, but if we don't then we have the problem of users typing information in twice, so I think its preferred.
The main goal though is to ensure that the JCL do not continue before verifying user input is okay.
The text was updated successfully, but these errors were encountered: