Endevor

The current date is old but the generate date is recent for an assembler macro:

ELEMENT    TYPE     NS ENVIRON  S SYSTEM    SUBSYS    VVLL CURRENT GENERATE
---------- -------- -- -------- - --------  --------  ---- -Date-- -Date---
amacro      MACRO       theenv     P thesys      thesub       0100 21FEB06 09FEB17

The assembler macro is an input component for an assembler program:

---------------------------   INPUT COMPONENTS   ------------------------------  
           MEMBER     VVLL   DATE   TIME  SYSTEM   SUBSYS   ELEMENT    TYPE     STG STE ENVRMNT 
%+0101      amacro 0100  09FEB17 14:49 thesys      thesub  amacro MACRO     2   2  theenv

When a package moving the assembler program is cast this results in a footprint error:

C1G0000I   ELEMENT aprogram
PKMR801I    OF ENV: theenv SYS: thesys SUBSYS: thesub TYPE: ASM STG: U  
                                                                
FPVL003E  FOOTPRINT MISMATCH FOR                                
C1G0000I   INPUT COMPONENT amacro
C1G0000I   FROM DATA SET alibrary.MACRO                
PKMR802I     FP ENV: theenv SYS: thesys SUBSYS: thesub TYPE: MACRO STG: P
PKMR805I     FP DATE/TIME IN COMPONENT LIST  : 09FEB17  14:49   
PKMR809I     CURRENT SOURCE DATE/TIME        : 21FEB06  10:02   
                                                                
Isn't this comparison of the assembler macro generate datetime with the input component list current datetime for the assembler macro an "applies versus oranges" comparison?  Why should anyone care if the generate and current datetime do not match?  It is the current datetime of the program element and the corresponding input component that need to match. Shouldn't the input component list also retain the current datetime and the footprint comparison be between the current datetime from the input component list and the current datetime from the program element?

Generating the entry stage TYPE ASM program element repeatedly makes no difference.  The input component footprint generate date of the macro in production is compared with the current date of that same macro in production and the mismatch results in this inappropriate FPVL003E  FOOTPRINT MISMATCH FOR.  A VALIDATE action on the macro program element in production reports no problems.

Wow, I learn so much from questions like this!

This explains why we have component validation switched off in our automated package cast (it doesn't explain why someone hardcoded the panel to only allow component validation though - go figure?!).

Thanks for being so clear in your explanation and I've voted up the idea.

Casting with input component validation warnings, or without input component validation (there is little difference), allows main routines to be moved to production without all of their modified input components.  A reason to limit the cast panel options to component validation is to try to prevent program elements that are using modified input components from being moved to production without the matching modified input components also being moved to production.  The problem here is that this footprint mismatch error is not really an error but the only way around this faux error is to cast with the input component validation warning option.  Yet doing makes it impossible to properly enforce the IT software change management goal for current production to contain all of the source code that is needed to re-generate the production executables.

Why is moving main routines to production without all of their modified input components a problem?  Ask these questions:  Is there ever a need to update main routines?  If there is, then what happens when the main routine needs to be updated and some of the input components need to create the main routine are missing because they were never moved to production?  Or what if the developer has copies of what may be the input components except the developer does not know if those input components were the ones actually utilized to create the main routine or are different, either older or newer versions, from the input components utilized to create the main routine that now needs to be updated because they are not moved to production simultaneously with the main routine?

This is why 1) the GAO in the United States declares it is a mandate that government institutions ensure they always have the complete set of input components in production that match what was utilized to create the production executables 2) someone hardcoding the input component validation into the cast panel is fully justified and good and 3) the false footprint mismatch errors are a major problem that needs to be corrected and more people should vote yes to this idea https://communities.ca.com/ideas/235735487.

Hi Mathew,

Can you check the new  Optional Features table( From INC09), this ENCOPTBL, parameter can cause the footprint on the Element in the source output library at the target of a Move action to retain the last generate date and time stamp.

The enhancement is included in PTF#RO93928.

***********************************************************************
* WHEN AN ELEMENT IS MOVED, THE CURRENT LEVEL OF THE ELEMENT WILL BE   
* WRITTEN TO THE SOURCE OUTPUT LIBRARY (IF DEFINED FOR THE TYPE) IN THE
* TARGET LOCATION. THE FOOTPRINT IN THE SOURCE OUTPUT LIBRARY MEMBER   
* WILL REFLECT THE CURRENT (TARGET) LOCATION AND THE DATE/TIME OF THE  
* MOVE ACTION.                                                         
*                                                                      
* THIS OPTION WILL CHANGE THE BEHAVIOR SO THAT THE DATE AND TIME IN THE
* FOOTPRINT WILL REFLECT THE DATE AND TIME OF THE LAST GENERATE ACTION,
* IN CASE EXPAND INCLUDES IS N. EFFECTIVELY, THE DATE AND TIME STAMP IN
* THE SOURCE OUTPUT LIBRARY MEMBER FOOTPRINT WILL NOT CHANGE WHEN      
* MOVING AN ELEMENT UP THE MAP.                                        
*                                                                      
* NOTE 1: THE LOCATION IN THE FOOTPRINT WILL STILL REFLECT THE TARGET  
*         OF THE MOVE ACTION.                                          
* NOTE 2: IF EXPAND INCLUDES IS SET TO Y IN THE TYPE DEFINITION, THEN  
*         THIS OPTION WILL HAVE NO EFFECT. THE SOURCE OUTPUT LIBRARY   
*         MEMBER WILL BE FOOTPRINTED WITH THE DATE AND TIME OF THE MOVE
*         ACTION.                                                      
*                                                                      
* THIS OPTION WILL HELP TO ELIMINATE SOME RARE UNJUSTIFIED COMPONENT   
* VALIDATION ERRORS DURING PACKAGE CAST.                               
*---------------------------------------------------------------------*

*        ENHOPT PRESERVE_GEN_TIME_IN_SOL_MEMBER_FP=ON    DEFAULT IS OFF
*             

Let me know if this can help you?

Regards,

Ollivier

Excellent.  That scenario fits our context, we are using source output libraries for the input component program elements, and it makes sense that not changing the footprint date and time during the move action will avoid a footprint mismatch problem.  It is also good that the expand includes setting allows stage by stage and system by system control over this behavior.  I will arrange to schedule an update to increment 9 to try this.  Thank you.