Programs were written and compiled mostly on my computer using Fujitsu COBOL85 v3.0. This dealt with all syntax errors and major run-time errors. None-the-less, programs were periodically sent to Computeach for compilation using Merant/MicroFocus COBOL v2.4.17. In addition to my own early test data files, more extensive Computeach test data was also used. More subtle program bugs were often identified at this stage. Since much of the development was performed on my home PC, very early program listings are not available. For the sake of convenience, the majority of test runs produced text files instead of actual paper print outs to test program runs. Hence early print outs are not always available either.

Relatively minor differences exist between these two compilers with respect to coding requirements. For example, when using the sort utility, the work file must be assigned to SORTWRK01 when compiling with Fujitsu, and 'WORK-FILE.DAT' (used in the coding herein) for MicroFocus. Also, when an alphanumeric character is moved to a numerically defined print item, while Fujitsu compiled programs printed the item, MicroFocus compiled programs resulted in a run-time error that aborted the program run (see Program 1 development).

During development of these programs general modifications to the programs included improvement of comments with the code listing. Hyphens were used to guide the eye to where the comment lay, specifically indented with the relevant piece of code. The use of letters to indicated error types was latterly changed to numbers to avoid confusion with record type codes. Attempts were made to standardise the layout of each program listing in order to achieve consistency in style and appearance. These changes were best performed once all 4 programs had been written.

Included in this section are program listings that were compiled by MicroFocus, and where relevant, program print outs, also produced by the MicroFocus compiled programs.

All program error report printing did not make use of the LINAGE clause within the FD of the print file due to problems with the Fujitsu COBOL compiler.

Three attempts to compile and run were made before achieving a successful program run.

The first program run (compiled 27-Jul-00) resulted in a run-time error due to non-numeric data being moved to a numerically defined print item (line 48400). This problem was solved by implicit redefinition, whereby the print items in question were given a top level (05) definition that was numeric, but if data is found to be non-numeric it is moved to the lower [alphanumeric] level (03). For example, see line 2020 and 2030 of the final version of Program 1 (pp1.4).

The second program run (compiled 07-Aug-00) reported a subscript being out of range, resulting from the picture description being PIC 9 rather than the required PIC 99.

The third program run (compiled 15-Aug-00) produced a print out but some valid records had been rejected. This was because the modulo checking paragraph MOD-CHECK was not always correctly calculating the check digit for comparison with the record's check digit. This was the result of the definition of the item W-REM (which holds the remainder of the product sum divided by 11) as PIC 9 (rather than PIC 99). This resulted in truncations when the remainder was 10 or 11, therefore never producing check digits of "X" or "0".

Early versions of Program 1 had attempted to use a single PERFORM VARYING loop to calculate the sum of products in the MOD-CHECK paragraph. The method used relied on 4 digit numbers being moved into a table defined as OCCURS 5 TIMES where the remaining unused element would be zero and would appear in element number 5. However, this strategy proved unreliable, and possibly dependent on the compiler used. Hence, the solution used in the final version, while still using a single paragraph, calculates the sum of products using weight tables for either 4 or 5 digit codes.

The earliest versions of Program 1 attempted to print the address lines individually. This was later removed and used only in Programs 2 and 4 where the printed reports required formal representations of all customer details. Detection of address lines that exceeded 30 characters (perhaps due to missing ";" delimiters) was also abandoned since the extensive coding did not appear to be justified for a relatively minor error.

Lastly, the multiple error code had originally been written to a table, where spaces were added when a error flag was false. Prior to printing the spaces were then removed. This was changed to a simpler method using a series of IF THEN statements that, when the error flag is true, the appropriate error code is moved to a table and the subscript incremented by 1 (see SET-ERROR-CODES in the final version).

Being a relatively straightforward program, only a single error was detected on compilation by MicroFocus (compiled 07-Aug-00), this being a missing period at line 1200. Once corrected the program produced the expected report print out. The method for printing additional address lines was adopted here, although early versions attempted to test for address line truncations (as mentioned for Program 1) using the COUNT IN clause within the UNSTRING statement. This was removed since it was felt unnecessary. No early print outs are available.

Although the most complex of the 4 programs, Program 3 produced an erroneous run on compilation by MicroFocus on a single occasion (05-Sep-00). The error in this version of Program 3 resulted in some records being written twice to the new customer mast file (a print out of which is included). The error report produced the expected output using Computeach test data (print out included) The contents of the new customer master file, using Computeach test data, are included following the program listing. The error report itself produced the expected results (not shown). This problem resulted from the condition of the IF THEN statement (line 52100 of MicroFocus compilation listing) that treats deletion and creation records as a new customer (by which time the record has been written to the new file). The returns to DO-CUS-TRANSACTIONS where the record will be processed and written again. Simply removing "...OR (NOT I-TYPE AND NOT-R-TYPE" remedied the problem.

A large amount of time had been spent attempting to write a working program prior to compilation. The main problem appeared to be how to deal with multiple transactions for a single customer. At first it seemed that once a transaction had been performed (when the customer code from the transaction record equals that from the customer master record) then both files would then be read for the next record. Of course the relevant record is no longer available to be processed. This appeared to be best solved by the use of a flag to detect when a new customer code has been read from the transaction file and so now allow the next customer master file record to be read. While this solution appeared to work (compiled successfully on MicroFocus 05-Oct-00; listing included), it was later realised that a more simple method could be employed to achieve the same result. What was required was to place the READ-TRANS-FILE and READ-MAST-FILE paragraph calls in the right places. In addition, the updated (or otherwise) customer record was only written to the NEW-FILE immediately before the next customer record is read from the MAST-FILE (see Program 3 solution).

Although the purpose of Program 4 is relatively straight forward, initial test runs on MicroFocus compiled programs presented problems relating to the number of debtors that should have been detected. This was due to a misunderstanding whereby I had assumed that only customers with a negative balance actually owed money, and only those whose negative balance exceeded their allotted credit limit (having multiplied the balance by -1) was a debtor. Once it was realised that negative balances indicated a customer with a credit balance (and all others had a debit balance) could the problem be corrected. Indeed, until this point Program 3 was subtracting transaction costs from issue transactions (and vice versa) creating a serious balance calculation error. The first compilation and run of Program 2 (11-Sep-00) also failed to start a new page when the line number was greater than 40. This was due to the omission of the line WRITE PRINT-LINE FROM BLANK-LINE AFTER PAGE. The program listing and printed output are included.

The second compilation on MicroFocus (20-Sep-00) essentially produced a good print out except for the detection of debtors (see above). Listing and print out are not included. The final compilation (01-Oct-00) produced the expected results using my own and Computeach test data. The only modification that was made to the program following this was to calculate and print the outstanding balance of debtors alongside their record. Also changed was the printed warning symbol for debtor records from "CD>" to ">>>" for the sake of simplicity.

See Introduction section for printed output for the final version of each program (using my own test data), and Sections 1 to 4 for printed listings of the final version of each program.

_____________________________________