Update / Merge Program

Program Overview:

Before this program is used it is imperative that the sorted file used has been produced by the Sort program (494792P2.exe), and prior to this has been validated by the validation program (494792P1.exe). If this is not the case then the outcome of this program is not guaranteed to be in anyway reliable or useable, and the Customer Master file created can not be trusted in any shape or form.

The sorted transaction file from the Sort Program (494792P2.exe) is used to update a Customer Master file, and create a new generation of that master file. Reference is made to an indexed sequential Stock master file for pricing information. Transactions that can not be actioned are reported on the printer under suitable headings with an appropriate error message.

The text file which contains the sorted transaction records must be named 494792SD.DAT, the customer master file must be named CUSTMAST.DAT, and both must be located in the same directory from where the update program is located and executed from. The new customer master that is created will be named 494792VF.DAT, and will be located within the same directory as where the program was executed from. This is unless the user changes these default file names by entering additional program parameters at the command line. Below describes how the default file names can be overridden: -

494792P3.exe <sorted file> <customer file> <new customer file> <printer>

The defaults file names are as follows: -

Sorted file – 494792SD.DAT
Customer file – CUSTMAST.DAT
New Customer file – 494792NF.DAT
Printer – PRN

If the user wishes to override one of these files they must also enter the file names of all the files preceding it. For example to override the printer to a text file named test.txt, they must enter the following command: -

494792P3.exe 494792SD.DAT CUSTMAST.DAT 494792NF.DAT test.txt

However if the user only wishes to change the name of the sorted file, they may enter the following command: -

494792P2.exe SORTED.DAT

The overriding of the default file names is mainly for test purposes or where there is a need to do so. Such a need may arise when there is a need update an old master file with some old data, which maybe required to reprint a report. The everyday users of this program need not even have to be aware of this overriding feature.

Update:

When the program is first starting it checks to see if there was a command-line argument given. If there was then the argument is taken to be the name of the sorted transaction file, and an attempt at opening this file is made. If the attempt fails then the program reverts to using the default file name (494792SD.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the EXISTING customer master file. An attempt at opening this file is made. If the attempt fails then the program reverts to using the default file name (CUSTMAST.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the NEW customer master file. An attempt at opening/creating this file is made. If the attempt fails then the program reverts to using the default file name (494792NF.DAT). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If there was another command-line argument given this is taken to be the name of the printer file (where the output from this program is printed to). An attempt at opening this file is made. If the attempt fails then the program reverts to using the default file name (PRN). An attempt at opening the default named file is now made, if this also fails an error message informing the user that the file could not be opened is displayed and the program exits returning the user back to the operating system.

If no command-line arguments were given then all default file names are used.

Updating:

Firstly a record from both the sorted file and the customer master file is read. If either of these reads fail an appropriate error message is displayed upon the screen and the program returns back to the operating system.
A temporary customer record is used within this program to keep track of the current customers balance. A creation customer record is also used within the program; this is used to help ensure that a customer is only added to the new customer master file once.
When the two records have been successfully read in, the customer record’s contents are copied to the temporary record. The main processing loop is now entered. The main processing loop consists of checking the sorted records customer code against that of the customer records customer code.

Customer record customer code is less than that of the transaction customer code:

If the customer code of the customer record is less than that of the sorted record then the only valid transaction type is that of a Creation. If any other transaction type is encountered at this point then the sorted records details are sent to the printer with an appropriate error message (Customer not on master file); also a counter which keeps count of the number of invalid records is incremented.

If the transaction type is that of a Creation, then a check is made to ensure that this customer has not already been created. If the customer has already been created then the record and an error message (Customer already created) are printed and the invalid counter incremented.

If the customer has not been created then the transaction details are transferred in the correct format into the creation record. A flag is set to indicate that this record has been modified; this is to ensure that the current system date is added to the creation record upon it being written to disk. An attempt at writing this creation record to disk is now made, if this write fails then an appropriate error message (Could not write to new customer master file) is displayed to the user and the program returns back to the operating system. If the record was written to disk successfully then both the deletion and modified flags are unset.

Whether a valid or invalid transaction was processed the current sorted records customer code and type are copied into a previous transaction record, which is again used to ensure multiple creations of the customer are not added to the new customer master file. The next sorted transaction record is now read from disk, if the end of file was reached then we set the sorted transactions customer code to a high value (99999) to ensure the remainder of the customer file is processed.

A check is now made to ensure that both the customer file and the sorted transaction file have not ended. If they have not ended then we start the processing loop again. If they both have ended we report to the printer how many invalid records were found. The printer is reset to its default state and all previously opened files are now closed before returning control back to the operating system.

Customer record customer code is equal to that of the transaction customer code:

If the customer code of the customer record is the same as that of the sorted record then the only invalid transaction type is that of a Creation. If the transaction type is that of a creation then the sorted records details are sent to the printer along with an appropriate error message (Customer already on master file), the invalid record counter is also incremented.

If the transaction type is that of a deletion then the deletion flag is set to true, this will be detected when the transaction is to be written to disk. If this flag is set and the customers balance is zero, then the customer is not written to the new master file (as far as we are concerned it has been deleted). If however the customer balance is a non-zero value, the sorted record is sent to the printer along with an appropriate error message (Customer balance not zero), and the invalid record counter is incremented.

If the transaction is either an Issue or a Receipt then an attempt to read from the master stock file is made in order to get the relevant stock price. If the price information could not be accessed then the given stock code was not on the master stock file. If this is the case then the sorted record is sent to the printer along with an appropriate error message (Stock record not on master file), and the invalid record counter is incremented.

When the relevant pricing information has been found the customers balance is adjusted to reflect their payment or expenditure. If it is an Issue transaction then the customers balance is increased by the amount of the stock item multiplied by the quantity they have received. If however it is a Receipt transaction the customers balance is decreased by the amount of the stock multiplied by the quantity they are in receipt of. The changes to balances are made to the temporary customer record, as this will keep track of the customer most recent balance. When a customer balance is adjusted the modified record flag is set so that the current system date is used as the customer’s last movement date.

Customer record customer code is greater than that of the transaction customer code:

If the customer code of the customer record is greater than that of the sorted record then the current customer record is to be written to disk. There is a specific function which is used to write records to the new customer master file. This function is described in some detail below as it performs some important tasks.

The writeRec() function requires the following parameters in order to successfully perform its designated task.

A pointer to the customer record that is to be written to disk.
The record modified and deletion flags.

This functions first task is to get the current system date, because the system dates year is returned as the number of years since 1900, and we are storing the date as a two digit year if the year is greater than 100 we subtract 100 from the year to give us the correct year in two digit format.

A check is now made upon the record modified flag; if this flag is set (any non-zero value stored with this variable) the customer’s last movement date is updated to be that of the time just obtained from the system.

A check is now made upon the record deletion flag; if this flag is set (any non-zero value stored with this variable) another check is made to ensure that the customer’s present balance is zero. If the balance is zero, then this function returns a value which indicates to the calling function that it was successful (SUCCESS = 1). Otherwise the following details are sent to the printer along with an error message informing the user that the customers balance was NOT zero, transaction type (D) and customer code, the function now continues with its execution as described below.

If the deletion flag was not set (it contained a zero value) or the customers balance was not zero, an attempt at writing the customer record to disk is made (in binary format). If this write fails then this function returns a value which indicates to the calling function that it was unsuccessful (ERROR = 0). The main processing loop will then display an error message to the user (Could not write to the new customer master file), and the program is terminated with the user being retuned back to the operating system. If the write was successful then this function returns a value which indicates to the calling function that it was successful (SUCCESS = 1).

Back within the processing loop after a successful write, the next customer master record and sorted transaction record are now read from disk, if the end of file was reached then we set the respective records customer codes (and the temporary customer records customer code if the master customer file has ended) to a high value (99999) to ensure the remainder of the customer file is processed. When the customer record is read in from disk its values are copied to the temporary customer record, and the modified and deletion flags are reset (set to zero).

Design decisions:

I started off with a different logic to how the processing loop worked. It was too confusing to follow the logic and to continue to fix the errors that were appearing. With this confusion in mind and being early in the development of this particular program I had a serious rethink and redesigned the logic to the main processing loop. I feel one hundred percent happier with the main processing loop logic now, as it is much easier to follow and will make the program much easier to maintain in the future.

The decision to place the deletion checking within the writeRec() function was made because it seemed the most logical place to put this checking. If a deletion flag is set then this function checks the customers balance if it is zero then the customers record is not written to the new master file. If the customers balance is non zero then the customer’s record is written to the new master file. It is assumed that if a customer has a negative balance then it too will NOT be deleted.

To start with the file names were hard coded within the program; if any of them were not found then the program would exit. This was changed quite late in the program development, as it would be more practical to allow the user to override the name of any file at the command line (as a command line argument). This way the file names are not hard coded into the program, which makes the program much more flexible. If however a file name is not provided on the command line or there was an error trying to open the given file name then the default file names are used.

Limitations:

The stock master file is not updated after either an issue or receipt transaction. Unless this file is updated by another means, then the free stock levels will not be altered to reflect the issues or receipts that have just been processed. The stocks last movement date of the stock is also not updated to reflect an issue or receipt. Without the stock levels being altered this could lead to orders being taken without the relevant levels of stock being available for despatch.

The reliance upon the user to have previously run the transaction file through the validation program and sort program to produce the sorted file is also a limitation. This is because this program does not do any transaction validation or sorting of the transactions, and so invalid transactions will happily pass through this program and the processing loop will not work as intended as it expects to find the transactions sorted into ascending customer code. The new customer master file (if one is created at all) will certainly not contain a correct version of the customer data, many customers maybe lost if this method of execution is not adhered to.

All of the programs are limited to using a Hewlett Packard printer as all printouts use Hewlett Packard specific escape codes to format the output. If the printer is changed for a different make then this program will need modification and recompilation. The modifications are all contained within the printer.h header file and so should not cause any problems if this task is required.