Program 3 forms the more complex program of the suite, and is responsible for processing the validated, sorted transactions (in TB17SD.DAT), referred to as the TRANS-FILE and ultimately producing a new customer master file (NEW-FILE, TB17NF.DAT). The transactions are used to update an existing customer master file, referred to as the MAST-FILE (CUSTMAST.DAT), by comparing customer codes from simultaneously read TRANS-FILE and MAST-FILE. During this process, customer records may be created or deleted. When issue or return transactions are required, customer records are updated. This involves searching a stock master file (Stock-file, STCKMAST.DAT) for the specified part number to obtain item selling price and stock levels. The issue or return transaction is then processed, updating the master file record that is then written to the NEW-FILE. In addition, the Stock-file record is updated to reflect changes in stock levels and item's last movement date. Initiation Control of Program 3 is performed by CONTROL-PARAGRAPH that begins by executing INITIATE-PROCESS. This, as in earlier programs, opens files and printer, and prepares the error report print out. Then both TRANS-FILE and MAST-FILE are prime read. The last process of INITIATE-PROCESS tests the end of both TRANS-FILE and MAST-FILE and sets the EO-BOTH-FILES flag accordingly. The TRANS-FILE record is tested for 'at end' status. When this is the case, HIGH VALUES are moved to the customer code (explained below). Otherwise, the record type flag is set to the record type. READ-MAST-FILE begins by writing the customer master record to the NEW-FILE. This is dependent on the WRITE-OK-FLAG being true (line 003360), which applies in all cases except when a valid deletion is being processed (see below). Following this, the MAST-FILE is then read. Again, the 'at end' status leads to HIGH VALUES being moved to the MAST-FILE record type item. The tally of records within the NEW-FILE is made within this paragraph. File reading Paragraphs READ-MAST-FILE and READ-TRANS-FILE are used to read the MAST-FILE and TRANS-FILE, respectively. READ-MAST-FILE is also responsible for writing the customer record to the NEW-FILE, but only when the condition OK-TO-WRITE is true. This is the default condition of this flag and is only set to false when a valid deletion record is being processed. Immediately following the WRITE statement, OK-TO-WRITE is reset to true. The tally of records being written to the NEW-FILE is also made within this paragraph. Main iteration The main iteration of Program 3 is on MAIN-PROCESS that loops until the flag EO-BOTH-FILES is true. MAIN-PROCESS consists of an EVALUATE statement that tests a comparison between the TRANS-FILE record customer code (T-CUS-CODE) and the MAST-FILE record customer code (M-CUS-CODE). Three possible options are available: (1) T-CUS-CODE is less than M-CUS-CODE. This can only be a valid transaction if the TRANS-FILE record is a creation record. The paragraph CREATE-CUSTOMER move the appropriate fields from the record to a new group (CREATED-REC) which is then written, along with the system date, to the NEW-FILE. 1 is added to the tally of records in the NEW-FILE, and tally of records created. However, if the record is not a creation record then the error code "1" is moved to the error code print item and the paragraph PRINT-ERROR-LINE is executed, indicating a transaction was attempted for a non-existent customer. The next TRANS-FILE record is then read, whether a valid transaction or not. (2) T-CUS-CODE is greater then M-CUS-CODE. This means that no specific transaction should be required. This condition simply writes the MAST-FILE record to the NEW-FILE by calling READ-MAST-FILE.
(3) T-CUS-CODE equals M-CUS-CODE. This indicates that a transaction is to be performed on the MAST-FILE record. To perform this, the paragraph DO-CUS-TRANSACTION is executed. Four types of transaction are possible, tested using an EVALUATE statement: an issue, a return, a creation or a deletion. A creation record will result in execution of PROCESS-C-TYPE which will print the transaction with an error code "2" indicating an attempt to create a customer that already exists. PROCESS-D-TYPE allows deletion of a customer record only if the customer has a balance of zero. Deletion is achieved simply not writing the MAST-FILE record to the NEW-FILE. Not writing the record (within READ-MAST-FILE) is accomplished by setting the WRITE-OK-FLAG to false. 1 is added to a tally of deleted records. When the balance is not zero, the WRITE-OK-FLAG is set to true, and the transaction is printed on the error report with an error code "3" (attempt to delete record with non-zero balance). The paragraph READ-MAST-FILE then writes the customer record to the NEW-FILE and reads the next customer record from the MAST-FILE. PROCESS-IR-TYPE begins by searching the stock file for the required part number. If not found (INVALID KEY) the transaction is printed on the error report with the error code "4" (item not present in stock list). When the item is found (NOT INVALID KEY) first the total cost (quantity * selling price) is calculated, then record type is tested for issue or return type records. For issue records the quantity required is tested against the available stock. If quantity is greater then the transaction is printed on the error report with error code "5" (insufficient items available in stock). Otherwise the total cost is added to the balance of the customer record. Note that balance indicates what the customer owes: i.e. a negative balance would indicate that Zenith Paints owe the customer money. The stock level is appropriately adjusted, along with the last movement date (set to the system date). The movement date of the customer record is also adjusted. For return records the total cost is subtracted from customer balance and the stock level and move date adjusted. Stock levels are not tested in this instance. Calculations for balance and total cost are tested for SIZE ERROR. Since this is a fairly unlikely event, such an error was coded only to produce an error message (along with customer code) that is displayed on-screen during run time for the attention of the operator.
At the end of the EVALUATE statement the next TRANS-FILE record is read.
Error record printing PRINT-ERROR-LINE prints the transactions that cannot be processed. The print items are set up in the same way as described for Program 1 except that PRINT-ERROR-LINE does not use separate paragraphs to set print items for each record type (Program 1 has the added complications of multiple error codes and the need to print an unknown record type), and only 1 error code is ever reported.
Program termination When either TRANS-FILE or MAST-FILE are at an end, an appropriate flag is set to true and the customer code for the completed file is set to HIGH VALUES. This ensures that the remaining file is read to completion as always having a customer code that is less than the customer code of the file that is already at an end. Once the second file is at an end, its 'at end' flag is also set to true. With both flags indicating an 'at end' status the EO-BOTH-FLAG is set to true within the MAIN-PROCESS paragraph (line 003860). This will terminate the iteration for this paragraph and TERMINATE-PROCESS is executed. TERMINATE-PROCESS prints footers on the error report, these being totals of the number of records in the new customer master file, and original customer master file (calculated by adding the number of deleted records to the total record number in the new customer master file and then subtracting the number of created records). Also printed is the total number of records created and deleted. Keys to record type abbreviations and error codes are also printed, followed by the end of report closing message. Lastly, the various files (and printer) are closed. Logic returns to CONTROL-PARAGRAPH where the program is stopped.
Program limitations The main limitation of Program 3 concerns the possibility that a customer is created and transactions for this new customer appear within the same transaction file. Following sorting by Program 2 any issue/return transactions would appear before the creation record for this customer and so would be reported as erroneous. Duplicated deletion records, if valid will delete the appropriate customer record but the tally of total records deleted will be incremented with each additional duplicate resulting in a deleted record number higher than the actual number of records deleted. Duplicated creation records will result in the new customer record appearing once for each subsequent duplication in the new customer master file. A solution to this problem is described earlier (Program 2 limitations). |