Included in ZMF 8.3
We have two separate Sysplexes, one for production (PLEX1) and one for development/testing (PLEX2). There is another Sysplex for systems testing (PLEX3). None of the Sysplexes have shared DASD between them.
We use FTP for package distribution and remote promotion, though NDM has been used before for remote promotion with some of the similar concerns. I have configured the FTP-related skeletons for package distribution and remote promotion to use an IP address by hardcoding the IP address within the ISPF skeletons. This seems silly, being that the IP address is already specified within Global Site Information. Knowing that the SER#PARM information is generated on-the-fly for the job that initiates a backout or revert from a DP-site that is done against a P-site, I had looked at the CMN$$BRQ skeleton. Within this skeleton, there is reference to the IP address (&STEIPAD) and port number (&STEPORT).
I tried to find reference of these variables elsewhere, such as the remote promotion and freeze skeletons, but nothing obvious was found. I could be mistaken, but it appears that such information is not available in these other areas to eliminate the need to hardcode IP addresses, etc. within the ISPF skeletons.
Granted, I do see that the “Logical unit name”from Global Site Information is available via the &RSTNDE variable, which is 256 bytes in length. Note that as of v8.1.4.01, I see that in “Global Parameters - Part 1 of 8” the “Logical unit/system name” is 8 characters, whereas under “Global Site List” information the "Logical unit name" is 256 characters. Why is this different? Shouldn't these be the same length? In any case, I was thinking about using &RSTNDE for the IP address for the FTP process (even though it uppercases whatever is entered in that field), since the delivered FTP skeletons already reference do a “)SET NODE = &RSTNDE”, but there is the 8 character limitation I had mentioned in the “Global Parameters - Part 1 of 8” that has me hesitating using this as a workaround.
It would seem appropriate that when a package freeze is done or a remote promotion is done, the local (originating) DP-site information for:
- ChangeMan ZMF Subsystem ID (currently “P”)
- Logical Unit Name (currently “TEST”, but not really used for anything)
- JES Node Name (currently “PLEX2”)
- IP Address (&LCLIPADR) (something like “plex2.domain.com”)
- IP Address Port Number (something like “1234”)
- ChangeMan ZMF Environment (currently “DP”)
should be consistently available in ISPF variables whether during promotion or during freeze, and even other functions such as stage.
Just as well, having the remote (destination) information in separate ISPF variables being available would also to be helpful:
- ChangeMan ZMF Subsystem ID (currently “G”)
- Logical Unit Name (currently “PROD”, but not really used for anything)
- JES Node Name (currently “PLEX1”)
- IP Address (&RMTIPADR) (something like “plex1.domain.com”)
- IP Address Port Number (something like “4321”)
- ChangeMan ZMF Environment (currently “P”)
For the FTP configuration, a fair bit of rework needed to be done to the delivered skeletons to allow them to work to handle package distribution, package distribution acknowledgement, remote promotion, remote promotion acknowledgement, and even the production JCL scanning process that is done during staging (where the stage process kicks-off the scan process from PLEX2, runs on PLEX1, and then runs again on PLEX2 to communicate a SUCCESS or FAILURE of the JCL scan). For example, in CMN$$F16, we have:
//SND&STEPID!EXEC PGM=FTP,
// PARM='(EXIT',
)SEL &STEPID NE FAIL
// COND=(4,LT),
)ENDSEL &STEPID NE FAIL
// REGION=6M
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//INPUT DD *
&SSRIPADR
&FTPXMTID
// DD DISP=SHR,DSN=SECURE.PASSWORD.INFO
// DD *
BINARY
)SEL &FTPIN NE &Z
SITE RETPD=0
SITE &STGSTYP
SITE PRIMARY=&STGPRIM
SITE SECONDARY=&STGSECN
PUT '&FTPINF' +
'&FTPOTF'
QUIT
Keep in mind that the same CMN$$F16 FTP skeleton is used to have PLEX2 connect to PLEX1 (e.g. package distribution), and then PLEX1 needs to connect back to PLEX2 (e.g. package distribution acknowledgement). Therefore, depending on the direction (i.e. relative from the ChangeMan ZMF subsystem’s point-of-view), the FTP-related local and remote IP address variables are set in file tailoring depending on the direction the FTP connections are done so that file tailoring results in generating correct JCL that works:
)CM
)CM Determine the environment type of the ChangeMan ZMF subsystem ID
)CM (&SUBSYS) FOR WHICH the ISPF file tailoring process is being done.
)CM Note that this is different than the value of &ENVTYP8, which is
)CM the environment type of the ChangeMan ZMF subsystem IN WHICH the
)CM ISPF file tailoring process is being done.
)CM
)IF &SUBSYS EQ P OR &SUBSYS EQ I THEN )DO
)SET SUBSYSEV = DEVPROD
)SET SSLIPADR = plex2.domain.com
)SET SSRIPADR = plex1.domain.com
)ENDDO
)ELSE )DO
)SET SUBSYSEV = PROD
)SET SSLIPADR = plex1.domain.com
)SET SSRIPADR = plex2.domain.com
)ENDDO
)CM
)CM
)CM Determine the environment type of the ChangeMan ZMF subsystem
)CM remote site (&RMTSITE) FOR WHICH the ISPF file tailoring process
)CM is being done. Note that this is different than the value of
)CM &ENVTYP8, which is the environment type of the ChangeMan ZMF
)CM subsystem IN WHICH the ISPF file tailoring process is being done.
)CM
)IF &RMTSITE EQ PLX2 THEN )DO
)SET RMTSITEV = DEVPROD
)ENDDO
)ELSE )DO
)SET RMTSITEV = PROD
)ENDDO
As you can see, there is a limitation to the customizations above with hardcoded IP address, where we can only support 2 Sysplexes. I’m about to set up remote promotion to PLEX3, and I will need to jerry-rig the customizations to make it work. This is not an impossible task to do, but I can’t imagine what other shops are doing that have many more Sysplexes to manage; they may very well be testing the value of &RSTNDE within an ISPF file tailoring to set the IP address, which is what I’m planning on doing to handle communicating to both PLEX1 and PLEX3 from PLEX2.
However, if appropriate remote site transmission information would be available within ISPF variables, then extending to 3 (or more) Sysplexes would not be an issue, as coding would be simpler and not hardcoded with logic that would only get more complicated with more Sysplexes:
)CM
)CM Determine the environment type of the ChangeMan ZMF subsystem ID
)CM (&SUBSYS) FOR WHICH the ISPF file tailoring process is being done.
)CM Note that this is different than the value of &ENVTYP8, which is
)CM the environment type of the ChangeMan ZMF subsystem IN WHICH the
)CM ISPF file tailoring process is being done.
)CM
)IF &SUBSYS EQ P OR &SUBSYS EQ I THEN )DO
)SET SUBSYSEV = DEVPROD
)SET SSLIPADR = &LCLIPADR
)SET SSRIPADR = &RMTIPADR
)ENDDO
)ELSE )DO
)SET SUBSYSEV = PROD
)SET SSLIPADR = &RMTIPADR
)SET SSRIPADR = &LCLIPADR
)ENDDO
This area of ChangeMan ZMF, where it would better handle multiple Sysplexes using transmission vehicles, seems that it could use some improvement so that it needs more of a product configuration to make it work vs. setting-up customizations to make it work. However, please let me know if there is already an elegant way to handle all this which is already available that I’m not aware of.
#TransmissionVehicle
#RemotePromotion
#LocalandRemoteSystemInformation
#PackageDistribution
#ftp
