Add an enhancement to support the use of same named RTEMS and HTEMS procs in Sysplex environment (shared PROCLIB)

Customer has a Sysplex environment. The same PROCLIB is shared between several z/OS systems.

Customer's environment is designed to use identical STC names on all z/OS systems in the Sysplex. 

They need a way to use the same approach with all Omegamon STCs in their environment too.

Example:

On MVS1 they are running OMEGDS; OMEGTOM and OMEGD5 STCs.
On MVS2 - OMEGDS; OMEGTOM and OMEGD5 STCs.
The above is true for MVS3 and MVS4.

Customer faces a difficulty when trying to use the same (named) proc to run HUB and REMOTE TEMS. 

In their environment, one of the OMEGDS (TEMS) is a HUB and all other OMEGDS STCs are REMOTE TEMS.

HUB and REMOTE TEMS procs are different. 

HUB TEMS specifies several additional DDs:

//******************************************************************
//* Hub-only TEMS VSAM DATASETS                   
//* TEMS type for this RTE=MVS1 = HUB TEMS             
//******************************************************************
//QA1DEVMP DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSEVMP         
//QA1DEVSR DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSEVSR         
//QA1DGRPB DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSGRPB         
//QA1DGRPC DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSGRPC         
//QA1DPYMR DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSPYMR         
//QA1CKAS DD DISP=SHR,DSN=&RVHILEV..&SYS..RKDSKAS        

  
RTEMS procs are generated without these DD statements. 

To get around the limitation and allow RTEMS STCs to run, customer does the following:

They use system symbols to set certain variables in their STCs for different LPARs in the Sysplex, including OMEGDS.

Customer's solution is to use the same HTEMS proc for ALL different RTEs - HTEMS and RTEMS.

At the moment, the customer has to implement a workaround while running GENERATE, when setting up REMOTE TEMS RTEs.

 This is because of these HTEMS and RTEMS proc DD differences. The workaround allocates HTEMS datasets for RTEMS RTEs.

The workaround looks like this:

1. Run GENERATE first with KDS_TEMS_TYPE HUB to allocate the missing HTEMS datasets for RTEMS RTE (all TEMS are using the same HTEMS proc)

2. Run second GENERATE with KDS_TEMS_TYPE REMOTE to get the correct configuration in their RTEMS RTE runtime libraries.

3. With the above done, the customer is able to use the same HTEMS proc with system variables for all different TEMS configurations in their Sysplex.