Marble Computer Refactoring COBOL Programs

Why Refactoring is Needed

COBOL programs evolve over time. As such, maintenance is an ongoing process. Each time a program is modified, the program typically becomes a little larger with added functions that were not planned for during initial development of the program.

A good programmer normally attempts to keep clarity established in the program. Unfortunately, even with good intent, over time ease of understanding deteriorates tremendously.

Whether it is the programmer’s responsibility or management’s responsibility to keep ease of understanding at a high level, both benefit greatly from refactoring, as the programmer must work on the code and management needs to protect their investment should the programmer retire or be unavailable.

An important step to be considered separately

Refactoring does not correct existing errors that currently reside or exist within a program.  More importantly, the output of refactoring needs to match the output of the program’s execution before refactoring was done.  Therefore, if errors exist, ideally, they should be discovered and removed in a separate process from doing refactoring.

How Using Control/DCD Software Simplifies Refactoring

Control/DCD is a powerful analysis and documentation tool which has been greatly enhanced since it was first developed in 1975.

In its latest versions, ongoing maintenance is made better with the use of the “Special Narrative” feature that tells a story in detail for each data name. 

There are several other features in Control/DCD’s current release that are designed for doing refactoring as follows:

  1. A developed “PERFORMed Routine Hierarchy” is available in a Forward Tracing Report that is available in Control/DCD’s program documentation.  This report may be used to restructure Performed Names in a better format for easier program understanding.  This report may also be used to help in deciding what areas of code might be moved to another sub-program to help alleviate larger programs.
  2. A Perform Analysis report shows all backward PERFORMs for use in reorganizing the correct Program Hierarchy.
  3. The “Special Narrative” is ideal for tracking the use of any data field when questions arise in refactoring. 
  4. A PERFORM Error report shows if there are any PERFORM errors in the program, and this should be looked at separately from refactoring.
  5. Unused PROCEDURE DIVISION code is made available in a report in the one program documentation mentioned above.
  6. Unused 01 Records is again made available in a separate report in the one program documentation mentioned above.
  7. “Unused Data Names” is made available in its own report for easy use.
  8. COPY report showing what COPY members are used within each program.

Refactoring is a way of cleaning up different parts of a program with a lot of well-planned thought, making future maintenance easier.

Understanding the overall hierarchy of PERFORMs helps greatly in top-down program understanding and should be the first step in major refactoring tasks.  Control/DCD may also be used here to complete this task with the Forward Tracing Hierarchy it produces.

Choose Marble Computer for Your Refactoring Needs

Refactoring is best done in small steps, where each step is reviewed carefully, and testing may also be done here to ensure that no changes to the result of the program have occurred during the refactoring process. Contact Marble Computer today to learn more about our refactoring assistance.

Scroll to Top