Please use speaker notes for additional information! Random update Please use speaker notes for additional information! This slide presentation deals with the logic of random updates.

Update Random Update EDIT: The transactions that will be used in the update must be as error free as possible to prevent corrupting the master file. To assure the integrity of the data, the transactions can be processed in an edit program and only valid transactions should be allowed to update the master file. The output of the edit file includes the valid (good) transaction file which will be processed in the next step. Frequently transaction come in via a screen and the analyst decides that the editing will be incorporated in the update program to provide interactivity. UPDATE: The update program uses the valid transaction file to update the master file itself. No new master file is created, the changes are made to the existing master file. Note that random updating is transaction driven. This means that you read the transaction file and find the master that needs to be updated. When you have processed all of the transactions, the processing is done. Reports become extremely important to provide a paper trail of records processed and also a trail of records that contained errors and were not processed. In a maintenance update there can be add, change or delete transactions so records can be added to the existing master, changed on the existing master, or deleted from the existing master. The method of physically handling deletes varies depending on technology being used.. The update program completes the updating maintenance cycle. Note that back up does not happen automatically in a random update. Copies of the master file and the transaction file need to be made. Frequently the master is backed up directly after the update. It absolutely has to be backed up before the next update. Maintenance updating is used to add, change and delete records from a file in the traditional sense of updating. Production updating is when the file changes because of the daily processing that occurs. Production updates usually have just change transactions. For example a production update would deal with receipts into inventory and sales from inventory where a maintenance update would be concerned with adding new items to inventory, changing the price of an item or deleting an item from inventory. Sequential updating is useful when there is a large percentage of hits between the two files. If you have additions, changes or deletions for the majority of records on the file it makes sense to process sequentially. If you have a small percentage of hits, that is you will be adding, changing or deleting a small number of records then a random update is more effective. Random updating is transaction driven which means when the transactions are processed, the program ends. This is because the master is randomly retrieved for processing because of a transaction. Contrast this with sequential processing that continues until you both the transaction file and the old master file have reached end of file.

Update Program Edit Program Systems flowchart Valid Trans Update Program Data Edit Program Errors Errors can be put on disk, printed, interactively corrected or any combination of solutions. Master File Trail The random update needs to have the data edited, but it does not have to be sorted since the program can handle the transactions in any random order that they come in. If the program has transactions coming in from a screen instead of from a disk file, the program will have to include editing components. Note: Errors can be written to disk, printed, interactively corrected or any combination of solutions. An optional paper trail can also be produced on disk, paper or another medium.

Errors Trail Screen Transactions OR Transactions Random Update Master Program If transactions are coming in as a group from a disk file, they should be edited. If the transactions are coming from a screen, interactive editing should take place in the Random Update Program. The user will frequently try to interactively handle errors on the screen. Errors Notice that the Master is an I-O file which means changes are being made directly to the master. This requires that backup of the master be done prior to running the random update. The backup procedure is frequently executed right after the master has been update. right before the update program is to be run or after any checking that is done after the update of the master. Trail

Random Update Logic The logic of a random update involves attempting to match the record on the transaction with a record on the indexed file. Frequently this involves doing a random read to find out if the record exists or doesn't exist. Based on the results, processing is done. Other techniques can be used that involves processing and reacting to invalid key responses or not invalid key responses.

readTrans process start Read a transaction housekeeping readTrans Y end-readTrans process not EOF loop N wrapup end-process readMstr stop read master housekeeping wrapup Y N successful Note that the reads of both the master file and the transaction file are handled in procedures or subroutines. The reason is that I/O (reading and writing) generate a lot of machine code and doing them just once is more efficient. In addition, including the checking for success is more clearly shown separately. Transactions are being read sequentially. After the read, we check to see if EOF has been reached which means end of processing. The master is being read randomly because of a transaction. When we attempt to read the master we need to have a check to find out if the read was successful and a master was there that matched the id/key that the transaction called for. Again, this processing is transaction driven. open files close files success not success end-housekeeping end-wrapup end-readMstr

loop establish key read mstr Y N success N change trans Y Y N add delete trans change routine Y Y add routine N change trans add error routine delete routine rewrite master write master delete error routine change error routine Establish the key indicates that the programmer must do whatever the language requires to allow them to use the key to randomly access the file. Remember, success means that a master was successfully read. On this slide I first check to see if there is a master. If there is, a change and a delete are valid. An add is an error since the record already exists. If there is not a master, the add is valid but the change and delete are errors because I cannot change or delete a record that is not there. delete master readTran end -loop

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 222... 234… 333... 345… 444... 456… 512… 121 (trail) Note that the two master files are the same file. The red file to the left is prior to running the update. The brown master is as the update is showing the changes that are made - the results of the update. The after is the file that is kept. Note that the transactions do not have to be in order. We will see this on future slides. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. If a match is found, changes are made to the record on the master and the record is put back on the master with a REWRITE. A trail of the change is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 124... 222... 234… 333... 345… 444... 456… 512… 121 (trail) 124 (trail) Note that alternate logic for the ADD is to attempt the WRITE and let the invalid key clause pick up an attempt to write a duplicate record. If the invalid key clause is not triggered the ADD will be successful. Note that the master files (before and after) start out looking the same. Changes will be made to existing records, records will be added and deleted. Records on the master with no activity will just stay there. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since no match is found and this is an add, the new record is written on the Master using a WRITE. A trail of the add is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 124... 222... 234… 333... 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) The changes on the transaction are made on the master in memory and then the master is rewritten on the master file, thus making the changes. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since a match is found and this is a change, the change is made and the changed Master replaces the original record on the master using the REWRITE. A trail of the change is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 124... 222... 234… 333... 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) The second change transaction for the master record 222 is read and processed. Notice that there is no acknowledgement that there has already been a change. We do not require that the transactions be sorted so each one is dealt with individually. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since a match is found and this is a change, the change is made and the changed Master replaces the original record on the master using the REWRITE. A trail of the change is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 124... 222... 234… 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) 333 (trail) The delete removes the record from the Master file. Note that different languages and systems handle physical deletion differently. The main thing is that the record is no longer available. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since a match is found and this is an delete, the delete is made by removing the record from the Master using the DELETE verb. A trail of the delete is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... MASTER (after) 121... 123… 124... 222... 234… 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) 333 (trail) 350 (error) In this example we are attempting to change record 350. Since that record does not exist on the master, no change can be made. This is an error. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since no match is found and this is a change, no change is made to the master. A report of the change error is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D MASTER (after) 121... 123… 124... 222... 234… 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) 333 (trail) 350 (error) 444 (error) Since the add transaction has a match on the master, the record can not be added since it would cause a duplicate identification number. Again, this could have been handled by attempting the WRITE and letting the invalid key catch the duplicate instead of attempting to find the match by reading the master prior to attempting the write. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since a match is found and this is a add, no change is made to the master. A report of the add error is also made.

The transaction is read Random Update ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D MASTER (after) 121... 123… 124... 222... 234… 345… 444... 456… 512… 121 (trail) 124 (trail) 222 (trail) 333 (trail) 350 (error) 444 (error) 450 (error) In this case, we are attempting to delete a record that does not exist. Obviously this cannot be done. An alternative would be to attempt to do the DELETE without checking and letting the invalid key catch the fact that no record exists to delete. The problem with this is that if indeed you find the match and do the delete, you are doing a blind delete. Most logic calls for some kind of viewing of a record prior to deletion for confirmation. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since no match is found and this is a delete, no change is made to the master. A report of the delete error is also made.

Random Update with unsorted transactions MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 350… C 222… C 124… A 450… D 333… D 121… C 444… A 222… C 999... MASTER (after) 121... 123… 222... 234… 333... 345… 444... 456… 512… 350 (error) In this example, the transactions are not sorted. They are the same transactions as used in the previous example. If the transactions are sorted, then all of the transactions of one Id are grouped together. This might have advantage in some circumstances. With our processing it does not matter. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since no match is found and this is a change, no change is made to the master. A report of the change error is also made.

Random Update with unsorted transations ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 350… C 222… C 124… A 450… D 333… D 121… C 444… A 222… C 999... MASTER (after) 121... 123… 124... 222... 234… 333... 345… 444... 456… 512… 350 (error) 222 (trail) This continues the example using unsorted transactions. The results will be the same, but the order of transactions on the error/trail report will be in the order that the transactions were processed rather than in sequence. This is one argument for sorting the transactions. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since a match is found and this is a change, the change is made and the changed Master replaces the original record on the master using the REWRITE. A trail of the change is also made.

Random Update with unsorted transactions ERROR /TRAIL REPORT MASTER (before) 121... 123… 222... 234… 333... 345… 444... 456… 512… TRANSACTIONS 350… C 222… C 124… A 450… D 333… D 121… C 444… A 222… C 999... MASTER (after) 121... 123… 124... 222... 234… 333... 345… 444... 456… 512… 350 (error) 222 (trail) 124 (trail) I have hopefully shown that the transactions do not have to be in order. I am only going to process the first three transactions in this way. The transaction is read and then there is an attempt made to find the matching record identification number on the Master. Since no match is found and this is an add, the new record is written on the Master using a WRITE. A trail of the add is also made.