• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Delete PY/QA Projects that never went to PD

pupamonkey

Member
So I wanted to get a feel of what people think the best practice would be in this scenario:

Old projects from consulting company over 2 years old sitting in PY & QA environments. Consultants are no longer working for company. Projects have interactive programs and UBEs that are modified in lower environments but never made it to PD. I want to remove the projects and revert code back. I'm not a CNC person and I think they are wanting to just remove the objects from the project and then delete the project. This loses the audit for what was in the project and the code is still modified in the lower environments. Is there any Best Practice information from knowledge Garden regarding this? I tried a few searches and couldn't get anything that spoke about it.
Thanks :)
 

peterbruce

Legendary Poster
pupamonkey,

I have a couple of OMW projects in the same situation and have done nothing with them. I am not aware of any Best Practice in handling such projects, but I have not done any search.

But here is my AUD 0.02 worth:

I was thinking along the lines of saving the OMW project in a .par file or a boomerang package and reverting to unchanged code (providing it hasn't been changed since in an active OMW project or one that has been put into production).

As far as an audit trail goes there is also the OMW logs, if you have them turned on and have not deleted them.
 

altquark

Legendary Poster
The right thing to do is to use OMW to perform either an "advanced get" or create a OMW Configuration code that will overwrite objects from PD down to the non-production environments.

DO NOT just refresh your non-production pathcodes with Production pathcode - that is the best practice to AVOID doing ! If you did that, you'd invalidate much of your audit trail with OMW Logs.

I recommend always to have OMW Logs turned on, and to never deleting them - that way, you always have an audit trail of how an object got to be modified and how it was tested, etc. Therefore, you need to always keep that in mind when refreshing an object from production.

However, to get the list of modified vs non-modified objects, you might want to create some SQL against the F987* tables to identify those objects that are different from PD to non-PD. Then from that starting point, use OMW to "downgrade" those that aren't needed anymore.

PeterBruce is also right - back up the objects ! Either a .PAR file or a BOOMERANG file before you start making major changes. Don't trust the SAVE pathcode (if you have one !)
 

BOster

Legendary Poster
This is more or less a summary of what others have said, but this is what we would do.

1. Demote Projects to DV
2. Save objects to save location AND PAR file if you are paranoid about losing changes you might want back.
3. Check objects out
4. Do advanced get from PD
5. Check objects in
6. Promote projects back to where they were before starting. In your case either PY or QA

At this point you want to drop the token on the objects in the projects and this could vary depending on how you have things set up in OMW. For us I would do something like:

1. Drop projects back to DV
2. Release token on all objects in projects
3. Drop projects to 11 (for us projects are created at 21 and that is our default filter) OR set project status to "Entered in Error" - for us something like 91, 92
 

altquark

Legendary Poster
Hi Brian

Yes - that sounds about right. The important thing is to ensure that the OMW Logs are "correct" and can be audited to show exactly how code made its way into production.
 

Mike Mackinnon

Well Known Member
We basically do the same as Brian as well. We use steps 1 thru 5, then promoting the OMW project to a "91 - Cancelled" status so that we still get to keep all documentation/auditing on the OMW projects.
We have done a DV code refresh a couple of times because after a long time the test objects (process options, etc.) get messed up and cause issues/inconsistencies when testing :)
 
Top