Add back zwe init shell code path

[1000TurquoisePogs]

This PR temporarily adds back zwe init shell code path as an option.
This option is toggled using the zowe.setup.jcl.enable option.
It does not enhance the behavior of zwe init when disabled, but just exhibits 3.2-like behavior.

[github-actions]

build 8257 FAILED.
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16530101444

[github-actions]

build 8258 FAILED.
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16530164049

[github-actions]

build 8264 SUCCEEDED.
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16564617922

[github-actions]

Test workflow 7029 is started.
Running install test: Convenience Pax
The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/3.3.0-PR-4429/zowe-3.3.0-pr-4429-8264-20250728090026.pax
Running on machine: zzow11
Result: SUCCESS
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16564786365

[github-actions]

build 8265 FAILED.
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16565692771

[Martin-Zeithaml]

If you code this (will fail on missing prefix on purpose):

zowe:
  setup:
    dataset:
      prefix: ~

If will fail in javaScript code, but it should fail in shell - by default old code.

Also:

• ZWE_CLI_PARAMETER_DATASET_PREFIX is unique for old zwe install
• The code should check if FILE() or PARMLIB() was used -> only new code can handle this.
• And I think, this is opposite of what we discussed: user must use zowe.setup.jcl.enable=true to request new code.

# Temporarily, the zwe init commands have old shell code and new jcl code paths available.
# To determine the code path:
#   Config is uss file - more checks
#     --generate - implies JCL code
#     --dataset-prefix - parameter unique for zwe install & shell only
#     zowe.setup.jcl.enable=false | undefined -> shell code
#     zowe.setup.jcl.enable=true -> JCL code
#   Not uss file
#     FILE | PARMLIB | wrong input (we don't care here)
check_jcl_init() {
  # If uss file
  if [ -f "${ZWE_CLI_PARAMETER_CONFIG}" ]; then
    enabled=$(read_yaml_configmgr "${ZWE_CLI_PARAMETER_CONFIG}" ".zowe.setup.jcl.enable")
    if [ "${ZWE_CLI_PARAMETER_GENERATE}" = "true" ]; then
      echo "true"
    elif [ ! -z "${ZWE_CLI_PARAMETER_DATASET_PREFIX}" ]; then
      echo "false"
    elif [ "${enabled}" = "true" ]; then
      echo "true"
    else
      echo "false"
    fi
  # Not uss file
  else
    echo "true"
  fi
}

[github-actions]

build 8266 SUCCEEDED.
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16569076191

[github-actions]

Test workflow 7030 is started.
Running install test: Convenience Pax
The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/3.3.0-PR-4429/zowe-3.3.0-pr-4429-8266-20250728123513.pax
Running on machine: zzow09
Result: FAILURE
Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/16569185080

[Martin-Zeithaml]

Undocumented SDSF requirement: https://docs.zowe.org/stable/user-guide/systemrequirements-zos/#zos

[MarkAckert]

This is also in ZWEIAPF2 ...

[Martin-Zeithaml]

Will not fit into the 80 chars:

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
//PARMLIB  DD   DSNAME=----+----1----+----2----+----3----+----4----,DISP=SHR

DISP=SHR must be on extra line.

[MarkAckert]

modified the sed's to try and accomplish this, worked in a test on the side

[Martin-Zeithaml]

The sample ZWESASTC was changed, resulting into:

//STEPLIB  DD   DSNAME=ZOWE.PR#4429.SZWEAUTH,DISP=SHR 
//         DD   DSNAME=ZOWE.PR#4429.PLUGINS,DISP=SHR  
//             DISP=SHR                                       
//         DD  DSNAME={zowe.setup.dataset.authPluginLib},     
//             DISP=SHR                                       
//SYSPRINT DD  SYSOUT=*                               

[MarkAckert]

same comment as zwesistc

[MarkAckert]

I've got the core workaround in place; the shell-only code is now branching to 3.2 versions of keyring and no keyring shell methods, and uses ZWEKRING/ZWENOKYR.

Updated 8/4: Tested all 3 keyring options against RACF,ACF2,TSS, with and without --allow-overwrite

I've adjusted the following:

• All the new KR*# JCL uses a symbol for the z/OSMF CA label. We were generating invalid JCL if a user didn't set zowe.setup.certificate.keyring.zOSMF.ca, and we didn't require the field to be set. There's an _auto_ function in both the old and new keyring paths, and the new one wasn't respecting it.
• I'm erroring out if the IP address is unset, because again we have invalid JCL. Better message to be written later telling the user to fill out san or add an IP to externalDomains. This will need a doc update as well.
• zowex updated and hack removed

Issues:

• Scenario 3 (import from DS) fails due to schema error - (zowe.setup.certificate.keyring.label) is not defined in Zowe YAML configuration file.
  • Underlying cause: read_yaml_configmgr and the configmgr extract function do not respect defaults set in the schema! If the field is not present in the zowe.yaml, it will not be returned by extract. This explains my first note in the below section on label and caLabel, which are set as defaults in the schema file.
  • This same problem afflicts init generate and ZWEGEN00; default schema values are not supplied when rendering the JCL templates.
  • opened an issue request. I don't know what other impact changing the behavior of extract might have on zwe commands.
  • Worked around this by uncommenting label/caLabel in the example-zowe.yaml. There's no reason we should comment this out or hide the defaults. In other cases like zOSMF.ca, using JCL symbols and sed replacements. Doc needs to be updated to match. No impact on schema or validation outside init certificate
• KRT1, KRT2 and KRT3 do not always end with RC=0, so the init certificate is displaying an error for all three. This appears consistent with prior behavior, ZWEKRING always ends with RC=4 on TSS.
  • Ditto for ACF2 JCL
• Top Secret JCL do not support parameterized keyring.name. This appears true in the prior implementation as well.
  • Ditto for ACF2 JCL

Other notes:

• label and caLabel weren't required fields for init certificate in 3.2, but they are in this revision. I think we should accept this change. Doc update necessary. example-zowe.yaml updates necessary
• It's possible to run into mysterious failures due to user error. The keyring.name should disallow safkerying:// prefixes. (Strangely, the new JCL path seemed fine with this in RACF, the old one is the one that broke. Better to disallow regardless).
• We might want to indicate somewhere that users should run init generate before init certificate when they make changes to their zowe.yaml. It's an easy to forget step when you're tweaking certificate information in the YAML and using --jcl.
• I used the --jcl parameter to indicate new JCL, but it's kind of confusing and ridiculous in context; the old certificate + keyring path also submits JCL. I'm open to a better parameter name...
• RC=0 on every submission isn't ideal, I'd like to move the existing warning to the very end of the certificate's stdout in all cases so it's the first thing a user sees.

zwe init certificate issues

Config

• 3.2.0 - config is a file
• This - config is a file merged with defaults.yaml