Archiving from DEV and Deleting from Prod

[r.santosh]

Hello,

 

How can we archive say cobol source program from Endevor and delete all the related components(load,dbrm package) etc from Production environment?

Currently we first delete the load/dbrm from production PDS and then archive the source from Endevor. Sicne both are independent and separate manual process many time we end up with inconsistency. In some case there is no source in Dev but load is present in prod PDS and vice versa.

How can it be automated and achieved in single process? Does Endevor have any such feature/function?

 

Regards,
Santosh

[Steve Blackett]

I don't believe there is a feature/function in ENDEVOR, but I have asked for one before.

We have multiple techniques for dealing with the scenario of code becoming redundant but also facing the challenge of audit that it needs to be actually archived as well as deleted in production.

 

This year we came up with a fully automated solution to delete first and then archive afterwards.

 

This process was important (to us) as with the agile world people tend to perform less impact analysis and just request deletes (for things like JCL and programs) and then get called that their stuff has failed and need it back again (hurray for backout).

 

The other requirement was it should be fully automated and under end user control. Our team do not have the time to support this process in any kind of manual way as we have millions of elements.

 

So, it can be done. It certainly wasn't easy and we spent a lot of time coding and complaining and found out a number of issues with ENDEVOR about what we could and couldn't do (especially as you would imagine around the area of packages). Full automation meant creating archive environments and datasets on the fly and ensuring housekeeping cleared it all up.  it's been live now for 5 months and stable.

 

Having said all of that, I'm not in a rush to roll out this solution to other instances of ENDEVOR. Although we try to design and build once for multiple instance deployment, we feel there could be a far better solution in the wings from the vendor. It starts with requirements though and I feel this is a bigger area than just knocking up an ideation.

[Edward Marks]

At our site we have a separate 'Archive' environment for archiving the, we then run two packages, one to transfer a copy of the source to Archive for safe keeping and one to delete the elements from the PROD environment (as it's an Endevor delete it removes the source and the outputs). 

 

This is all run under some automation that is also used for doing our production deployments.

[r.santosh]

Hello,

 

The 2nd package "To delete the elements from the PROD environment" uses CONDELE which "June Abercrombie" has mentioned below? I am assuming "Prod Environment" is Prod LPAR which is different than DEV LPAR where the Endevor keeps the source etc.

 

Regards,
Santosh

[Mathew Goldstein]

And if you have remote shipping destinations, under this scenario I assume you would ship the delete package to also delete from the remote shipping destinations.  I think this answers the original question being asked, where DEV is ESCM machine and PRD is the shipment target machine.

[June Abercrombie]

Hi Santosh,

Yes, this can be automated in a special Archive Delete processor and an ARCHIVE Environment. 

 

This Archive Delete processor, first checks to see if you are deleting an element from the Production Environment.

If so, it then kicks a Transfer of the Element to the ARCHIVE Environment with the following OPTIONS -

IGNORE GENERATE FAILED
WITH HISTORY
BYPASS GENERATE PROCESSOR
BYPASS ELEMENT DELETE
OVERRIDE SIGNOUT

 

After the Transfer is done, then use the Endevor CONDELE to clean up the other libraries 

 

Here is a link to CONDELE on the Endevor DocOps site 

Processor Utilities - CA Endevor® SCM - 18.0 - CA Technologies Documentation 

 

 

June

[r.santosh]

Hi June,

 

Thank you. So this CONDELE will clean up the libraries which are in prod LPAR, different than DEV LPAR?

So basically after the transfer we need to run this CONDELE in Prod LPAR and this whole thing can be setup in Endevor?

All I knew is when package is shipped then only the Endevor processes are run on Prod LPAR. 

Sorry I am asking very basic questions.

 

Regards,
Santosh

[June Abercrombie]

Hi Santosh,

I did not realize that you were shipping packages to a remote LPAR.

 

 

No, CONDELE does not delete things from the remote LPAR. It only cleans up the processor outputs on the local LPAR. 

 

To delete things from the remote LPAR, you must ship the Delete Package to the remote LPAR. 

 

When the Delete Package is shipped, it does not execute the Delete processor on the remote LPAR and since the Delete processor contains the step to perform the TRANSFER actions before deleting the processor outputs, no TRANSFERS are performs on the remote LPAR.

 

June

[r.santosh]

Hi June,

 

So for sake of my clarity, if we ship the delete package , it will delete components from remote LPAR library?

i.e say if my Delete package has 2 statements, one for delete JCL say TEST1 and one for delete cobol say CBTEST then if I ship the package 

1. TEST1 will get deleted from the remote LPAR PDS say PRODPDS.JCL 

2. CBTEST load will get deleted from the remote LPAR PDS say PRODPDS.LOAD

 

Regards,

Santosh

[Mathew Goldstein]

Someone correct me if I am wrong. I think it is possible to ship a package that executed either delete actions or archive with delete actions to delete at the ship target destination(s). Does anyone know what happens when a package that has transfer with delete actions is shipped?

[Phontilla Shuffitt]

yes you are correct Mathew, the package will ship the outputs regardless of the action.  If the package executes the Delete processor 'FROM ENVIRONMENT' then IDCAMS delete members will be shipped to the libraries.