Problem:
To debug and fix a problem, Micro Focus needs a minimal portable demonstration test case capable of reproducing the problem (in other words, a "demo").
Resolution:
Micro Focus cannot fix bugs based on verbal descriptions. A simplified source code demonstration is required, which can be compiled and run, and can re-create the problem symptoms.
Screen shots show problem symptoms on end user's machines, or it might be possible to dial in or use a Net Meeting to witness a problem, and this is valuable information when debugging, but not enough information to actually fix the problem.
The problem must be recreated and studied on machines at Micro Focus, so Micro Focus engineers can debug it in the presence of the Micro Focus internal product source code.
Trying to work based on a verbal description, Micro Focus engineers might study the product's internals and find a discrepancy that seems related to the symptoms, and produce a fix, only to discover it wasn't the right thing -- that after installing the fix, the end user's system still shows the original symptoms.
A source code demo provides a clear definition, and also later acts as the QA test case -- the demo becomes the way of testing whether the problem is indeed fixed.
The demo should be minimized or "cut down", that is, it should contain only those few lines of code necessary to re-create the problem. Parts of the application that are not related to the demonstration should be removed.
Cutting down the demo is a procedure of step-wise refinement that strips away complexity and eliminates factors that are uninvolved, until the problem's root cause is uncovered. This procedure is necessary and must be undertaken by someone. The best agents to perform this cutting-down are engineers familiar with the application, because they can do it faster and more reliably.
In our experience, customers frequently and fortunately discover the root cause of the problem during the process of cutting down the demo.
The execution flow of control should be traced up until the point when the problem occurs, then all pieces of the application not referenced up to that point should be removed (COBOL programs, data files, data-items and procedure division statements). This is done piece by piece, and after removing each piece, a person should recompile and run the demo to make sure it still has the ability to reproduce the problem (if it doesn't, perhaps the piece just removed is involved in the problem).
When possible, all dependency on non-COBOL modules (such as database or C code) should be removed. In a place where a call (such as a SQL call or a C call) would have populated a COBOL data item or items (and where this is necessary to set up the problem), an equivalent MOVE can be substituted to populate the data items with similar values. If the problem simply cannot be reproduced when the non-COBOL modules are removed, then the problem may be caused by those modules and not by COBOL.
The demo source code should include all dependencies necessary for compilation (such as COPY files). The demo should include instructions on how to compile (including what compiler directives and flags to set), and how to run or invoke the demo (including what run-time arguments to specify), and how the symptoms of the problem should be expected to appear.
The demo can be packaged as a .tar or .zip file, and attached to the incident through the Supportline web interface. A person logs into http://supportline.microfocus.com, then under Assisted Services > My Open Incidents, clicks on the pertinent incident, then clicks the Add icon under Attachments; this will allow files to be uploaded. Then the incident is automatically placed in "Callback" status and the Supportline engineer assigned to the incident is immediately notified.
