Hi David,
This particular site uses Serena ChangeMan ZMF to manage the mainframe software development life-cycle. However the same considerations exist for sites that use CA Endevor. While both products can seamlessly handle pure COBOL and COBOL/DB2 SQL, neither of them has comprehensive interfaces to handle CA Ideal, CA MetaCOBOL+ and CA Datacom. Therefore significant customisation is required to interface with the Software Change Manager package (whether ChangeMan or Endevor). Serena ChangeMan does have a component called Merge and Reconcile that can attempt to auto-merge changes from two versions of the same COBOL source (and Endevor has something similar), but this site chose NOT to implement it.
To explain that decision, and to elaborate on the RippleBack alternative that we developed, it's probably simplest if we take a sample scenario and work it through...
Let's say we have three parallel development streams, with 5 concurrent projects working on the following components...
Stream 1
Project 1 (expected to be promoted to production before Project 2)
Ideal program IDL001
COBOL program COB001
Datacom Table TBL001
Project 2 (expected to be promoted to production after Project 1)
Ideal program IDL002
COBOL program COB002
Stream 2
Project 3 (might go to Production before or after Projects 1&2)
Ideal program IDL003
COBOL program COB003
Datacom Table TBL002
Stream 3
Project 4 (might go to Production before or after Projects 1,2&3)
Ideal program IDL003
COBOL program COB004
Datacom Table TBL004
Now let's say Projects 1 and 4 are included in the release to Production. RippleBack determines which streams/projects are modifying components that have been changed and therefore MUST be reconciled before that other project is promoted (so that the changes from Project 1 are not regressed). An email is generated to the Project Managers (obtained from the ChangeMan package definition) detailing the components that have changed, and the potential impact on their project, as follows...
Projects 1 and 4 are closed by the promotion to production, and so no notification is necessary.
Project 2 is notified that components IDL004 COB003 and TBL004 have changed from Project 4. There are no DIRECT conflicts and so the rippleback release can be processed. The project team need to know about these changes because there may be INDIRECT implications from the change (for example if IDL002 is impacted by changes to the output from IDL004). Project 2 was already sharing the changes in Project 1 so is not impacted by the Production implementation of Project 1.
Project 3 is notified that components IDL004 COB003 and TBL004 have changed from Project 4, and IDL001 COB001 and TBL001 have changed from Project 1. Component IDL003 is a DIRECT conflict, and so the Project team must decide what they want to do to reconcile that component. They have two choices for that IDL003 component - (1) To save their changes, accept the RippleBack, and then re-apply their changes to the "production" source, or (2) to keep their changes and manually merge the changes that went to Production.
Why do we give them this choice? And why do we not use the Merge and Reconcile component to do this? After extensive discussions with the Development teams about what happens in the "Real World", it was discovered that it is extremely rare for there to be two concurrent projects to perform MAJOR changes to the same program. Normally the situations are one of the following..
1. Several "Small change" projects implementing minor bug fixes/enhancements that impact small distinct areas of the code. It is easy to obtain the "Delta" of the changed lines from ChangeMan (or Endevor) to identify the required simple changes to be re-applied.
2. One project performing a large change, and one project performing a minor (or emergency) change. If the project that was released to the Production environment is the large change, then the outstanding concurrent project would be better to obtain the delta of their changes from ChangeMan, and then re-checkout the component to re-apply their project's small changes. But if the production implementation was for the small change, then it is easier to obtain the delta for the production->history version and apply those changes to the component that is in the outstanding project.
In ALL cases, a manual review of the changes is essential, to check for both direct and indirect conflicts (for example the emergency change might have been a "temporary fix" that is superceded by the large change. Or the changed business processing caused by the smaller change may have other consequences for the second change that CANNOT be detected by any "automatic" merge process).
It was decided that the critical need for this site was to be able to IDENTIFY conflicts so that changes were not inadvertently regressed. There was no justification to implement the Merge and Reconcile component (which cannot handle CA Ideal and CA MetaCOBOL+ source properly anyway). The Change Management tool's Delta reporting (which DOES work for all components) provides the necessary data for the developers to make the correct decisions and merge the changes appropriately.
So that's the "notification" side of RippleBack. What does it actually do? Here's a simplistic view of the process that generates the RippleBack schedule..
For each environment in each application stream...
For each pure COBOL program
No action required (the ChangeMan baseline already has the new load module, and any conflicting COBOL component has been reconciled by the decision mentioned above)
Endfor
For each COBOL/SQL program
Import the Datacom SQL plan
Endfor
For each Datacom table
Import the changed BTG definition and logically implement to Production status/CXX
Perform data reformatting for updated tables (if physical structure has changed) and dataset allocation for new tables
Endfor
For each Runtime environment (Quality Assurance, User Acceptance Testing etc.)
For each Ideal program/panel
Issue IDENTIFY MODULE commands to pick up the new Ideal Load Module components
Endfor
Endfor
For the Development environment (only one per stream)
For each Ideal program/panel
IMPORT the changed source components
COMPILE programs and MARK to PROD status
Endfor
Endfor
Endfor
For each Datacom table
Import the changed BTG definition to the MASTER DataDictionary and logically implement to Production status
Endfor
I hope this helps.
Cheers,
Owen