Note that this idea could also be useful for automatic source code standards enforcement processes that are set up within ChangeMan ZMF.

We are modifying our Pro/JCL syntax scan batch process to also reformat our JCL-related components as well as do JCL-related standards enforcement.  Currently, using the in-house created “JCLSCAN” procedure that creates a batch job submitted during staging, the batch job runs a Pro/JCL syntax scan, prepares JCL runbook(s), and then generates an INFO/X reports.  A requirement has come-up to run a JCL, PROC, etc. reformat and standards enforcement process using Pro/JCL before running the Pro/JCL syntax scan.  This means that somehow the changed JCL-related component needs to be automatically put back into the package's staging library during the batch staging job, and still satisfy component component integrity checks that have been introduced in recent versions of ChangeMan ZMF with use of a "CHT=" CMNBATCH control card in the SUCCESS job step.

True, the easy workaround would be to simply not feed CMNBATCH the "CHT=" control card in the SUCCESS job step when using the JCLSCAN procedure, but that would open-up the potential for the following defects creeping back into the ChangeMan ZMF product in the case of putting a reformatted JCL back into the package's staging library:

• ZMF 8.1.0 Change Request - DEF17229: Exposure for timing related errors when staging components
• ZMF 8.1.2 Change Request - DEF17270: Missing SYNCH9 being reported

To be specific, here is the component integrity check "in action," where the package's component's hash token which was calculated prior to batch job submission was different than the hash token which was calculated during the batch job's SUCCESS job step (because of the JCL reformat):

ChangeMan(R) ZMF CMNBATCH - 8.2 Patch 3 2021/01/06 15:25:02
Attempting to initiate dialog with ChangeMan ZMF subtask
Session established with ChangeMan ZMF subtask
SYSIN: UAS 000062 90 RTP=ISRC
SYSIN: UAS 000062 90 LIB=JCS
SYSIN: UAS 000062 90 LNG=JCL
SYSIN: UAS 000062 90 SID=STD50
SYSIN: UAS 000062 90 CHT=70122489000002E7
SYSIN: UAS 000062 90 SSI=72C5CDB2
SYSIN: UAS 000062 90 TLT=LSJ
...
SYSIN: UAS 000062 90 725=
SYSIN: *
SYSIN: UAS 000062 90 CNM=ACP100
ACP100.JCS modified after build submitted, cannot activate. UAS 000062
SYSIN: UAS 000062 90 CID=
SYSIN: UAS 000062 90 RTP=ILOD
...

To get around this issue and also continue to ensure component integrity that has been built into ChangeMan ZMF recently, I had developed a CMN$$CHT ISPF skeleton that can be potentially included in the product (attached).  More information can be found in this proposed ISPF skeleton.

Additionally, the CMN$$VAR would need to be modified as follows:

)CM O N E 762
)SET SYSLIBL = SYSLIB O N E 763
)CM O N E 764
)CM O N E 765
)CM SET DEFAULT DDNAME FOR LINK INCLIB CONCATENATION IN COMPILE O N E 766
)CM PROCEDURES (USED IN THE CMN$$ILL SKELETON). O N E 767
)CM O N E 768
)SET SYSLIBI = INCLIB O N E 769
)CM O N E 770
)CM O N E 771
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++
I )CM Initialize &CMPHASHD variable to blank. This variable will be set DIF T W O 783+
I )CM to "Y" when the CMN$$CHT ISPF skeleton is imbedded, which results DIF T W O 784+
I )CM in using the value of the dynamically determined component hash DIF T W O 785+
I )CM token in the CMNBATCH "CHT=" control card instead of the "CHT=" DIF T W O 786+
I )CM control card generated by the CMN90 skeleton. See CMN$$CHT for DIF T W O 787+
I )CM more information. DIF T W O 788+
I )CM DIF T W O 789+
I )SET CMPHASHD = &Z DIF T W O 790+
I )CM DIF T W O 791+
I )CM DIF T W O 792+
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++

)CM SET PREFERRED LIBTYPES
)CM
)CM Build processes (compile, recompile etc.) require a specific
)CM library type into which to copy the DBRM generated by the
)CM Db2 precompile. This can be set here by any method you like.

and the following modification would need to be done in CMN90:

&BPKGNME!&TRAN90!&ENCR90!LIB=&CMPTYPE O N E 31
&BPKGNME!&TRAN90!&ENCR90!LNG=&LNGNAME O N E 32
&BPKGNME!&TRAN90!&ENCR90!SID=&STGERID O N E 33
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++
I )SEL &CMPHASHD EQ Y DIF T W O 45 +
I /* DIF T W O 46 +
I // DD DISP=(OLD,DELETE),DSN=&&&&CMPHASHD DIF T W O 47 +
I // DD * DIF T W O 48 +
I )ENDSEL &CMPHASHD EQ Y DIF T W O 49 +
I )SEL &CMPHASHD NE Y DIF T W O 50 +
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++

&BPKGNME!&TRAN90!&ENCR90!CHT=&CMPHASH O N E 34
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++
I )ENDSEL &CMPHASHD NE Y DIF T W O 52 +
++++++++|+++.++++1++++.++++2++++.++++3++++.++++4++++.++++5++++.++++6++++.++++7++++.++++8+++++++++++++++++++++

&BPKGNME!&TRAN90!&ENCR90!SSI=&SETSSI O N E 35
&BPKGNME!&TRAN90!&ENCR90!TLT=&TLODLTP O N E 36
&BPKGNME!&TRAN90!&ENCR90!SUP=&BTCHMSG O N E 37

As to when to imbed the CMN$$CHT skeleton, a good time to do it is after the Stage from Development of the reformatted JCL:

//*
//* IF THE JCL-RELATED COMPONENT WAS REFORMATTED, THEN CALL
//* XML SERVICES TO STAGE FROM DEVELOPMENT THE REFORMATTED
//* JCL-RELATED MEMBER BACK INTO THE PACKAGE.
//*
//STAGEDEV EXEC PGM=SERXMLBC,
// COND=((4,LT),(0,EQ,SUPERC))
)IM CMN$$SPR
//SERRPLY DD SYSOUT=*,DCB=(RECFM=VB,LRECL=4080,BLKSIZE=0)
//SERPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//XMLOUT DD SYSOUT=*
//XMLIN DD *
)CM
)CM The following default has been set to allow for "<" and ">" in
)CM XML tags.
)CM
)DEFAULT )&?!{|}
)CM
<?xml version="1.0"?>
<service name="CMPONENT">
<scope name="SERVICE">
<message name="CHECKIN">
<header>
<subsys>&SUBSYS.</subsys>
<product>CMN</product>
<userid>&USER.</userid>
<format>SPLIT</format>
</header>
<request>
<package>&PKGNAME.</package>
<component></component>
<componentType>&CMPTYPE.</componentType>
<chkInSourceLocation>1</chkInSourceLocation>
<sourceStorageMeans>6</sourceStorageMeans>
<sourceLib>&MERPREFX..RFRM</sourceLib>
<lockAfterChkIn>N</lockAfterChkIn>
<savePriorStagingVersion>Y</savePriorStagingVersion>
<changeDesc>Reformatted &&amp; Standards Enforcement</changeDesc>
<listCount>0001</listCount>
<targetComponent>&CMPNAME.</targetComponent>
</request>
</message>
</scope>
</service>
/*
)CM
)CM Calculate the new hash token, since the contents of the component
)CM could have changed.
)CM
)SET CHTPDS = &MERPREFX..RFRM
)SET CHTCMPNM = &CMPNAME
)IM CMN$$CHT

Note that in order to use the CMN$$CHT skeleton, it must be fed a (temporarily) cataloged data set into the &CHTPDS variable, which is what the Stage from Development job step also requires.

Note that I did have an earlier version of CMN$$CHT that used the "CMPONENT PKG_COMP LIST" XML service to get the component's hash token (which was nice because no "parameters" needed to be passed into CMN$$CHT before imbedding it).  But there was still potential for the above defects to occur.  Thus, CMN$$CHT was changed to use the "DSS SERVICE LIST" XML service to determine the component's hash token.  This way, it is ensured that the hash token of the reformatted JCL component is determined vs. possibly from some other version of the JCL component in the package.  (Just want to thank Alice Chernavsky from Support to point me to "DSS SERVICE LIST" to make CMN$$CHT better than it was originally.)