Enhance Security Subsystem Detection

[MarkAckert]

The current methodology for discovering security subsystem installation is by checking active jobs on the LPAR, and match against a whitelist of job names (RACF, TSS, ACF). This can run into two possible errors, though their prevalence is more pronounced on development LPARs

• The jobname of the security subsystem may vary - i.e. TSS160 for Top Secret v16, as opposed to just TSS.
• In a PLEX, there may be a different security subsystem on an LPAR within the PLEX. In this case, the script may detect one of those subsystems rather than the one running on the current LPAR.

Proposed solution: Issue commands in USS via tsocmd and check output for active security subsystem. Security subsystems which are not installed will have RC 255, while the installed one should have rc <=8.

[Martin-Zeithaml]

There is a small utility getesm, however it is working on LPAR only, no SYSPLEX scan.

[1000TurquoisePogs]

How about we somehow default zowe.setup.security.product to a value found by getesm?
One way, maybe, would be to expose the logic of getesm in configmgr zos module, and then have defaults.yaml contain product: ${{ zos.getesm() }}

[Martin-Zeithaml]

I believe, we can close this issue:

• There is a utility for all zowe users
• There is a support for this utility in javascript