Endevor - How to verify footprints for member names not matching element name.

Products

• Endevor
• Endevor Natural Integration
• Endevor - ECLIPSE Plugin
• Endevor - Enterprise Workbench

Issue/Introduction

This knowledge document explains why Endevor cannot validate the footprint of a member/load module 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).

Cause

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).

Resolution

1. 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,xxxxxxxx,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(xxxxxxxx),FOOTPRNT=VERIFY  
   //INDD DD DSN=&LOADLIB,DISP=SHR  
   //OUTDD DD DISP=SHR, 
   // MONITOR=&MONITOR,
   // DSN=&LOADLIB2
   //SYSIN DD *
   COPY O=OUTDD,I=INDD
   SELECT MEMBER=((&LOADNAM,R)

   
   In above example, a fixed member name 'xxxxxxxx' (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.