I had discovered something about GnuCOBOL: it has its own testing mechanism . It looked promising for simplifying the existing tests and getting better error notifications. However after doing a POC I’m now less sure.
At this point I’m not using autoconf tools, but just setting up a test and then using COPY to load the student’s solution in at compilation.
FRAME.COB:
IDENTIFICATION DIVISION.
PROGRAM-ID. frame.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-ARGUMENT PIC XXX VALUE "FOO".
01 WS-RESULT PIC XXX.
PROCEDURE DIVISION.
CALL "source" USING WS-ARGUMENT WS-RESULT.
IF WS-RESULT NOT = "OOF"
DISPLAY "FAIL"
ELSE
DISPLAY "PASS"
END-IF.
STOP RUN.
COPY "source.cob".
END PROGRAM frame.
SOURCE.COB (the student’s solution)
IDENTIFICATION DIVISION.
PROGRAM-ID. source.
DATA DIVISION.
LINKAGE SECTION.
01 LS-RESULT PIC XXX.
01 LS-ARGUMENT PIC XXX.
PROCEDURE DIVISION USING LS-ARGUMENT LS-RESULT.
MOVE FUNCTION REVERSE(LS-ARGUMENT) TO LS-RESULT.
END PROGRAM source.
To pursue this line of attack has some advantages and disadvantages. A considerable simplification of the testing framework is possible. But against that is that the students are now doing something quite different to the current regime. The current regime has the student write a standalone program which is absorbed into a larger test.cob by COBOLCHECK which handles all the testing. With the “simpler” approach the student now has to write a module with red-tape for being CALLed, e.g. USING on PROCEDURE DIVISION and LINKAGE SECTION etc.
I don’t have any COBOL industry experience. I learned COBOL in 1983 and loved it but never got to do anything constructive with it until I helped get the COBOL track here going. What’s the usual deal out there in the “real world”? Do people write standalones or do they learn early how to write callables? What should we be teaching?