How to use FOOTPRINT=VERIFY when a member is not named the same as &C1ELEMENT.

Document ID : KB000049862
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

This knowledge document explains why Endevor can't validate the footprint of a member/loadmodule with the processor utility BSTCOPY, when the member name differs from the element(source) name. In such a case, Endevor returns error message C1G0014E (member not found).

A solution is suggested.

Solution:

  1. Explanation of the footprint validation processing :

    • The footprint of a member contains the element name, so when a member's footprint is validated, Endevor uses the element's data. So Endevor should be able to validate the footprint of any member, whether its name matches the element name or not.

    • FOOTPRNT=VERIFY occurs before the processor step starts, and uses the DSN/MEMBER information in the processor JCL.

    • When a data set in the processor does not contain a member name, Endevor tries to validate the member with the name of the current element (&C1ELEMENT),

      since the member name is not known at this point.

  2. Reason for experiencing the C1G0014E errors :

    • You are using a BSTCOPY step in which you use INDD without member specification but with FOOTPRNT=VERIFY.

      Indeed BSTCOPY does not support a member specification on the DD statement here.

    • As we have seen, Endevor attempts to validate the footprint of a member whose name matches the element. If the element does not exist, Endevor will issue message C1G0014E (member not found).

  3. Solution :

    The simplest way to overcome this would be to add a DD statement to your BSTCOPY step as follows:
    //VALIDATE DD DISP=SHR,DSN=&LOADLIB(mbrname),FOOTPRNT=VERIFY.  

    as well as

    //INDD DD etc..        /OUTDD DD etc.. 

    The problem with such a statement would of course be that you may not know how to build a variable for mbrname.

    This can be fixed, actually quite easily, by an extra step.
    //BSTCPYL0 EXEC PGM=BSTCOPY,MAXRC=0,EXECIF etc        //SYSPRINT DD DSN=&&COPYLIST,DISP=(OLD,PASS)  //SYSUT3 DD UNIT=&WRKUNIT,SPACE=(TRK,(1,1)  //SYSUT4 DD UNIT=&WRKUNIT,SPACE=(TRK,(1,1)  //INDD DD DSN=&LOADLIB,DISP=SHR  //OUTDD DD DISP=SHR,DSN=&&TESTLOAD  //SYSIN DD * COPY O=OUTDD,I=INDDSELECT MEMBER=((&LOADNAM,TESTVALD,R)

    then in the next step
    //BSTCPYL1 EXEC PGM=BSTCOPY,MAXRC=0,EXECIF etc        //SYSPRINT DD DSN=&&COPYLIST,DISP=(OLD,PASS)  //SYSUT3 DD UNIT=&WRKUNIT,SPACE=(TRK,(1,1)  //SYSUT4 DD UNIT=&WRKUNIT,SPACE=(TRK,(1,1)  //VALIDATE DD DISP=SHR,DSN=&TESTLOAD(TESTVALD),FOOTPRNT=VERIFY  //INDD DD DSN=&LOADLIB,DISP=SHR  //OUTDD DD DISP=SHR, // MONITOR=&MONITOR,// DSN=&LOADLIB2//SYSIN DD *COPY O=OUTDD,I=INDDSELECT MEMBER=((&LOADNAM,R)

    In above example, a fixed member name 'TESTVALD' (in a temporary loadlib - one can use any fixed name, even &c1element), is used to ensure that the validation is performed in the actual copy step.

    Bottom line, Endevor works as designed, but with a simple addition to the processor one can also validate the footprint if a member does not have the same name as &c1element.