Do you generate when you move an element from stage 1 to stage 2?

[aalvarezSBC]

Hi all. Our developers would like to know how many of the community is doing a generate or not doing a generate when they move an element from stage 1 to stage 2 using a package. If you can please respond to this thread with a "NO" or "YES" please. If you have

some time, maybe give a reason why you are doing it this way.

 

Thank you for your time.

 

Alex

[Phontilla Shuffitt]

For our Endevor setup we compile until it goes to QA for regression testing, then after that point we perform a MOVE of the output to the next stage.  I would prefer to compile once, let the developers test in their area, then move to QA was development tested.  But there was a valid business justification to perform one last compile into QA.  Reason was that the developer may have changes in an input to his COBOL program and it will be a very long time from now before that input goes to production.  So 2nd developer using that input to his COBOL changes does not require that input and needs to get his COBOL change in quickly.  For both of these the processor group is standardized to execute the Generate process on a MOVE action or the MOVE processor from QA stage and forward.

 

Sorry not just a yes or no answer, but justification

 

Phon

[Dana Crawford]

YES, for more than one reason. Stage 1 and Stage 2 are for two different Test Environments and could have different data structures. We also have special processing done at Generate time.

[aalvarezSBC]

Hi Dana. Thank you so much for your answer. If you don’t mind, can you tell us if you do have a different stage for your Prod Environments and when you do move an element from the Test Environment to Prod Environment, do you generate?

 

Thanks Dana

 

 

Alex Alvarez

ISD – San Bernardino County, California

[Dana Crawford]

Hi Alex,

 

To answer your question from today, yes, we do have a separate Prod Environment. When moving from the Test Environment to the Production Environment, there is an interim Endevor Environment called PreProd. There is a generate done at PreProd because users are coming out of concurrent development paths, also to ensure all required components are staged for production install, also because debugging mode is allowed in the test environments but not production and this is the last compile before production, and because otherwise there will be footprint trouble. Ideally, the last compile before prod is your QA test environment so that what was tested is, in fact, what is moved to production. Auditors prefer it that way.

 

I do recommend implementing the simplest Endevor design that will work for the shop (e.g. - Gen upon Add into Test Environment then move that load to Prod) and never compiling into production. Things get complicated when there is concurrent development and multiple test environments.

 

Hope this info is helpful....Dana 

[SBAshby]

Never generate after the initial add so that the developer is in control of when code needs re-unit testing.

[John Dueckman]

I've seen a variety of installs with the following "main" ones:

 

1) Traditional: Add in Stage 1 does generate, all subsequent moves do moves (not generate).

 

2) Hybrid traditional: Add in Stage 1 does "generate" but in actuality the "generate" is '*noproc". This allowed the site developers to add their elements in Endevor in foreground without invoking a foreground compile (site did not have Quickedit and wasn't interested in Quickedit). Move to Stage 2 does an automatic generate with an actual compile processor. Subsequent moves do moves (not generate).

 

Note that whether or not a subsequent "move" required a (re)generate or not depended on type. Regardless, all stages have a valid and appropriate "generate" processor for that stage with the exception of Production; under no circumstances do I recommend an actual generate be allowed in production except under particularly unusual circumstances (that I can't even think of at the moment! )

[Josef Thaler]

short answer: "YES" and "NO" - it depends

a little bit longer answer: elements which potentially include "subordinate elements" like programs, which might include copybooks, subroutines and so on are generated until the stage before production change-over, so that always the correct=current subordinate elements are bound together. This might raise the need to test in every stage. The element which is finally tested and approved by all users are brought unchanged into production (MOVE).

Other Element-types (without subordinate elements) are MOVEd through all the stages.    

[Legacy User]

Yes. We generate via a package move from stage 1 (TEST) to stage 2 (QA) in our test environment after unit testing of the program is completed in TEST. When ready to be promoted to production (Q&A testing completed, if necessary), we do a move via package to our production environment, stage 2 (PROD). No re-generation is done with that move.

Source, load modules, compiler listings, etc. are moved directly to production libraries.

 

Arnold

[Anon Anon]

     In our Environment we have two different processes. The standard process is to generate in development only. We have one system that uses Static Link decks and some of these decks are quite large. We allow generate for this system when the code goes from development to the staging area for our QA regions. From QA on, no generates are done.    

[Legacy User]

Yes and No.  For some of our application systems we do a generate going into user acceptence testing.  These systems have static linked programs and some with linkbooks.  This ensures we are only bringing in the updated versions ready for production promotion or the production version of the program.  We never generate going into production even though that's often requested.    

[Mathew Goldstein]

Ideally, there would be one generate in the first or second stage of the migration paths and move actions that copy after that as recommended by John Dueckman.  Various dubugging and fault analyzer tools sometimes work best with testing options for the assemble/compile step that are ill-suited for production.  Therefore we assemble/compile again at the Quality Assurance stage without the testing options.  Otherwise, we will generate in the intial stage only.  Whatever stage(s) execute generate actions that are dependent on correct type sequencing should require a package.  To reduce the negative impact against the integrity of user testing from generating in more than one stage I recommend always casting packages with full input component validation.

[Karen Turner]

No.  Generate is performed on add and then moved with move processor the rest of the way to prod.

[Charles.E.Gaskell]

Note that even at some sites which say "No", for some (non-compile) types the answer may actually be "Yes" - an example might be JCL or control cards, where the Generate processor is used to create "testing" versions of elements in output libraries suitable for the testing associated with that stage of Endevor.

 

And of course, Endevor processor elements are regenerated when you move from stage 1 to stage 2 - I don't believe you have any choice.