Endevor

My question for everyone is - - in your Endevor MOVE process using BSTCOPY Utility do you issue a FOOTPRNT=CREATE on the OUTDD?  Or do you feel the Footprint that was created in the Generate processor sufficient and that is what you want to have as the correct correlation for when the LOAD module was moved into a production state?

When I look at the Endevor Documentation and Sample Processors MLODNNL and MLODDNL, I do not see that the Footprnt=create is on the OUTDD, but other examples in the technical doc has it. 

What is your opinion?

The very short answer is “In the MOVE processor (doing the IEBCOPY and BSTCOPY), no I do not and never have done a FOOTPRINT=CREATE” in my MOVE processors. I only do a FOOTPRIINT=CREATE in the GENERATE processors (including processors that create the LOAD).

IMO, a FOOTPRINT’s job is to provide that indelible ink-mark identifying where and when that output was created, not necessarily when it was dropped into a library. It needs to match the last GENERATED date since it was during the GENERATE that the output member(s) was CREATED. It properly should match the last-generated date marked on the element regardless of where that element is now located.

No, we don't use "FOOTPRINT=CREATE" in our MOVE processors.  We want to maintain the integrity between the output component and the source code generate.  We use "FOOTPRINT=VERIFY" on the INDD statement and "MONITOR COMPONENTS" on the OUTDD.

We use footprnt=create on the object coming out of the compiler for creating individual CSECT footprints and on the SYSLMOD DD for creating load module footprints.   

Hi Phon,

I am not convinced that there is a correct answer. I believe it depends on how you implement Endevor. For example, do you Gen once upon ADD and then MOVE the rest of the way up the map (w/footprint=verify) or do you Gen at multiple locations with a last compile at PreProd (w/footprint=create all the way)? At one shop, the philosophy was the former. At another, the philosophy was the later....Best, Dana 

Debug and fault analysis capabilities sometimes require different generate options so it may be necessary to generate twice on the way to production, and a package move generate is usefull to enforce type sequencing, but it should rarely be necessary to generate more than twice.

All other things being equal, it is better to cast the final package that moves to production with input component validation and execute only move processors with footprint verification. Otherwise there is a risk that the production program will be different from the program that was tested at the prior stage. The integrity of the pre-production testing should be protected.

Hi Phon,

When you generate an program, Endevor build a component list with input component and output component. The footprint of each component is recorded in the component list.

When you move the element using move processor, the element, its output component(s) and the component list are moved. The component list with help to answer question When, Who, where, with what ? the element has been generated and its output components built.

Now if you move the output component with footprint=create, you will break the link between the element and it output component, except if you monitor the component list during move. But in this case, the current component list will lose a lot of information(Input component, generate processor, etc...) making the auditability of the element difficult.

The solution would be to use the generate processor for move action, but it may be risky since if some input components are left in the from location you could experience regression issues.

Of course Using package will reduce the risk. Also issue may occurs in case you have some difference between environment at technical level, ie CICS, DB2, etc... 

Looking at a standard life cycle where test and validation are generally performed at the development/test stage, I'm not convinced that generating at each environment/stage without testing would be secure. But depending on the organization, why not?

Here was some input, I know not exhaustive but I hope it can enrich the discussion.

Regards,

Ollivier