Re: [open-cobol-list] COBOL85 Test Suite

[Vincent Coen]

The facility you have created is a terrific idea that hopefully will allow access to mysql etc without the need for the heavy training or use of a DBA in the smaller sites that would like to use rdbms.

As the test in cobol85 are the NIST suite then we cannot change them and still comply with the US DOD regulations in that a Cobol compiler must pass these test and that means without changes to the code other than what is allowed regarding 'Implementer' variation, etc and that will cover scripts.

I would suggest that you examine the scripts and see if they can be adjusted prior to running a given test or series to cover all compliance with a note in the test readme explaining the changes and what is required to make use of these functions, if you intend to offer your changes for use within the SF files system and if so will it have an option within configure to include/exclude (see previous comment)?

That way any government agency can use the GNU Cobol compiler as it will pass all of the required mandatory tests.

Vincent Coen





 On 13/12/13 17:50, Joe Robbins wrote:

I was wondering if anyone has advice about a particular aspect of the COBOL85 test suite.

 

I have implemented a module in fileio of GNU COBOL that stores INDEXED files in a database accessed via ODBC. Having finished the code and tested with some (simple) internal test programs, I came to test it using the COBOL85 test suite distributed with OpenCOBOL / GNU COBOL. And a conundrum of the test suite that has bugged me for a while has now become clear.

 

Some programs in the suite test work on the assumption that a data file will not be found by the program. For example IX218A.CBL has this comment block:

 

 
001400*  1.  THE  FUNCTION  OF THIS PROGRAM IS TO CHECK THE SEQUENTIAL  
001500*       READ  STATEMENT FOR A NOT EXISTING OPTIONAL INDEXED FILE. 
001600*       THE  READ  STATEMENT WITHOUT AN OPEN STATEMENT FOR SUCH A  
001700*       FILE  MUST CAUSE THE AT END CONDITION AND THE FILE STATUS 
001800*       CODE  10. THIS CODE IS CHECKED HERE. THE NAME OF THE FILE 
001900*       IS  IX-FS1.  THE  AT  END PHRASE IS SPECIFIED. THAT MEANS  
002000*       THAT  ANY USE AFTER STANDARD EXCEPTION PROCEDURE MUST NOT 
002100*       BE EXECUTED.                                               
002200*                                                                 
002300*  2.  ANOTHER  FUNCTION  OF  THIS PROGRAM IS TO CHECK THE START 
002400*      AND  THE  RANDOM  READ  STATEMENTS  FOR  A  NOT  EXISTING  
002500*      OPTIONAL  INDEXED  FILE.  BOTH  ATTEMPTS SHOULD CAUSE THE 
002600*      FILE  STATUS CODE 23. THE INVALID KEY PHRASE IS SPECIFIED  
002700*      AND  THE  USE AFTER STANDARD EXCEPTION PROCEDURE MUST NOT
002800*      BE EXECUTED. THE NAME OF THE FILE IS IX-FS2.              
002900* 

                                                             

The code operates on the (false) premise that running "make clean" will remove all the test data files at the start of the run because the working directory is made a-new. But if the files are somewhere else (for example in a database) then tests like IX218A fail.

 

This explains some problems I had earlier: our production environment (on LINUX) always declares a value for COB_FILE_PATH. If this is set when the COBOL85 tests are run, then many tests will fail.

 

So the question I have is this: how immutable are the COBOL85 test programs? Would it be acceptable to insert a COBOL call to DELETE FILE at the head of the program code? Or if that is problematic, would it be OK to edit the parent scripts? Or should we just make a note (in the release docs) and leave things as they are?

 

Regards:    Joe Robbins

 

P.S. I have at the same time implemented "SPARSE KEYS" with the COBOL clause:

 

                           ALTERNATE RECORD KEY key-2 SUPPRESS WHEN ALL X"00".

 

 which someone requested a while back. (The ALL value can be any char.)

 

 

 

Joe Robbins
address@hidden
 
www.bawtry.net