An ARCHIVE environment for redundant/obsolete/archived code and considerations for package shipment.

[John Scott]

Resurrecting an old topic, I  am interested in current observations from Endevor admins who have already implemented anything similar......

 

I am not talking about the Endevor action called ARCHIVE action but extending Endevor DISPLAY for decommissioned elements by setting up an new environment called ARCHIVE/OBSOLETE/DEAD or something.  

 

Source would be moved from PROD to an ARCHIVE environment.

 

This may be a MOVE to PROD next in map or TRANSFER to isolated environ (pros and cons to being visible up the map but a separate  subject).

 

My particular interest is in a process for users moving code to an archive environment and handling shipment to remote copy of prod when using the archive environment.

 

Normally our code moved to PROD will be SHIPPED to a mapped remote set of libraries that needs to be emptied when the source is removed from PROD stage.

 

That can be achieved by a package to delete from PROD and shipping that production package to the remote PROD destination.

 

However considering a new ARCHIVE environ, standard Endevor source management would be move and delete behind only if the source and output management at targe was already successful in arriving at the target ARCHIVE environ.

 

It makes sense the users want confidence of move to archive being okay before the delete happens.

 

They also want to take the outputs to output libraries for the archive environment in case they need to be  transferred back to prod in exceptional circumstances (bound to happen sometime).

 

To handle the removal from remote PROD destination requires delete from Endevor PROD stage and ship.

 

The requirement to see successful move to ARCHIVE requires the move to archive before the delete from PROD.

 

I want to keep using standard Endevor processing / panels as much as possible - allowing users to select the elements using the Endevor panels when building the packages etc 

 

Therefore I think,

 

Process required to use....

 

1) PACKAGE 1 MOVE actions from PROD (to ARCH) (NO DELETE BEHIND)

 

2) PACKAGE 2 DELETE actions from PROD 

 

3) SHIP PACKAGE 2 to PROD

 

 Assuming this process used I  would also need:

 

 Additional processing to be provided:

 

- build the delete from PROD package automatically include matching elements that was moved to ARCH  

 

(I can make a job for user where you enter the name of the ARCHIVE package and it builds the associated DELETE package). Later this can be included as step after shipment in skel when ARCHIVE detected so user did not need to create it.

 

- report elements in ARCH that still exist in PROD after  (the process was not completed)

 

Finally,

 

Backout considerations

 

Deleted from PROD and archived but still required in prod.

 

Backout in case a program is removed that was actually still needed

 

Standard package backout for the deleted element.

 

Plus some follow up process for Endevor admin to copyback from ARCH to re-instate source at prod. 

 

Thoughts?

[Felicity Vaughan]

I have an 'OBSOLETE' environment and when an element in PROD needs to be removed/deleted we create a Package that has a TRANSFER action. The delete processor for this will build the correct delete statements which we ship to our remote LPARs to delete the outputs there. The idea is that if for some reason the code is needed again, the Developer will need to retrieve it from the Obsolete environment and add it to the lower stages and recompile and move up the map again. Since the package builds backout members, we can perform a backout should the need be immediate. Don't know whether that helps, but I hope so.


Thanks,

Felicity Vaughan

[John Scott]

Thanks that sounds straightforward - was using MOVE and the package shipment only picked up target of move at OBSOLETE not deletes behing from PROD