Please use speaker notes for additional information!

Please use speaker notes for additional information!
Sequential Update Please use speaker notes for additional information! This slide show deals primarily with the logic of a sequential update.

Update Sequential Updating 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 should 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. SORT: The master file is in some kind of order - the usual order is by identification number. The transaction file must be in the same order as the master file. The sort program sorts the valid transactions and creates a sorted valid transaction file. UPDATE: The update program uses the sorted valid transaction file to update the master file, creating a new master file and reports. In a maintenance update there can be add, change or delete transactions so records can be added to the new master, changed on the new master, or deleted so they do not appear on the new master. The update program completes the updating maintenance cycle. 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.

Edit Program Sort Update Program
Steps to update Sorted Valid Trans Valid Trans Data Edit Program Sort Errors can be put on disk, printed, interactively corrected or any combination of solutions. Update Program Master File New Master File Errors Trail Note that prior to doing the update the Valid Transactions need to be in the same order as the master file. In sequential processing you are going to be stepping through both files one record at a time and processing them together. Therefore, they must be in the same order! 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.

Sequential Update Logic
Chart showing the logic of the sequential update. For additional information see the notes and read about the logic of sequential updates from some other source - book in the library, source on the Web etc.

Sample files OLD MASTER 121... 123… 222... 234… 333... 345… 444...
456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER ERROR REPORT For the purpose of this demonstration, the identification number on the old master file will be MID and the identification number on the transaction file will be TID. The first record from each file is read. MID =121, TID = Therefore MID = TID. Since the transaction code is a C, the change is made in the work area. Since the transaction has now been handled, a new transaction will be read.

A record will now be read from the old master file.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121... ERROR REPORT We are assuming that the C transaction with TID=121 caused some changes to be made in the work area and that the old master 121 that is written to the new master will include these changes. MID = 121 and TID =124 therefore MID < TID. When this happens we write the old record (in this case complete with the changes that were made based on the previous transaction) to the new master. A record will now be read from the old master file.

A record will now be read from the old master file.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123... ERROR REPORT In this case we are basically copying 123 to the new master. There were no transactions for 123 so the unchanged record is written to the new master. MID = 123 and TID =124 therefore MID < TID. When this happens we write the old record (in this case it is a record that has no changes) to the new master. A record will now be read from the old master file.

Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444...
456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124... ERROR REPORT An ADD can be made when there the TID does not already exist on the old master. We know that when the MID is greater than the TID. MID = 222 and TID =124 therefore MID > TID. Now we need to check the transaction code. It is an A. This is the situation where it is valid to ADD a record so the information from record with TID=124 will be written to the new master. Since this transaction has now been processed, a new transaction will be read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124... ERROR REPORT If you were sure that there was only one change allowed per id, you could write the record after making the change. But, since we are allowing multiple changes per id we have to read the next transaction and find out whether it is a match or not. If it matches the master, another change will be made. If it does not match the master, the TID will be now be greater than the MID so the changes will be written. MID = 222 and TID =222 therefore MID = TID. When we check the transaction code we find that it is a C and matching identification numbers is what we need to make a change. The change will get made in the work area. Since this transaction has now been processed, a new transaction will be read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124... ERROR REPORT Again we do not write because there could be still another record with TID=222. MID = 222 and TID =222 therefore MID = TID. When we check the transaction code we find that it is a C and matching identification numbers is what we need to make a change. The change will get made in the work area. Since this transaction has now been processed, a new transaction will be read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222... ERROR REPORT Be sure when you write the old master you write from the area where the changes were made. MID = 222 and TID =333 therefore MID < TID. This means we should write the old master record - complete with changes from the two transactions - on to the new master file. Since we have not processed the new transaction but we are done with the master, we will now read another master record.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… ERROR REPORT Note that this time we are simply copying the old master to the new master - no changes were made since there were no transactions for this record. When writing the code, you have to be very careful to setup the old master record and/or write the procedure division code so that if changes have been made they will be written but that records without changes will be processed correctly as well. MID = 234 and TID =333 therefore MID < TID. This means we should write the old master record on to the new master file. Since we have not processed the new transaction but we are done with the master, we will now read another master record.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… ERROR REPORT Note: You can only delete a record if a matching record exists on the old master. Deleting is actually doing nothing. I do not want to write the old master to the new master. The act of not writing deletes it. This is a strong argument for having an additional report that is a paper trail - you want a trail of records - especially those that are deleted. You could choose to make the error report a combination of errors and deletions and write the trail of the deleted records there. MID = 333 and TID =333 therefore MID = TID. This means that a delete is valid Since a delete involves dealing with the master and the transaction, we read a new record from each table.

Since the master has been dealt with, a new master is read.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345... ERROR REPORT Essentially in determining what to read, you read from the file where you have dealt with the record. If you have dealt with the master record, you read a master record. If you have dealt with the transaction record, you read a transaction record. If you have dealt with both, you read both. MID = 345 and TID =350 therefore MID < TID. This means that 345 will be written to the new master. Since the master has been dealt with, a new master is read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345... ERROR REPORT 350… When MID > TID (in this case MID=444 and TID=350), that means that we have passed the place on the master where 350 would be if it existed. Since 350 does not exist on the master, the transaction is invalid. MID = 444 and TID =350 therefore MID > TID. We need to check the transaction code. Since it is a C the fact that they are not equal means that this is an invalid change. The change error is written the error report. Since the transaction has been handled (as an error), another transaction is read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345... ERROR REPORT 350… 444... Because MID=444 and TID=444 you cannot add the record. There is already a record with identification number 444 on the master file. MID = 444 and TID =444 therefore MID = TID. We need to check the transaction code. Since it is a A, the fact that they are equal means that this is an invalid change. The add error is written on the error report. Since the transaction has been handled (as an error), another transaction is read.

Since the master has been dealt with, a new master will be read.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345… 444... ERROR REPORT 350… 444… The pattern should be emerging here that we always deal with the smallest record. If the master is smallest we deal with that. If the transaction is smallest we deal with that. If they are the same, we deal with them together. MID = 444 and TID =450 therefore MID < TID. Since the master is the smallest it will be processed. That means that 444 is copied to the new master. Since the master has been dealt with, a new master will be read.

A new transaction record will be read.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345… 444... ERROR REPORT 350… 444… 450... You can delete something unless it exists. The fact that the MID is 456 and the TID is 450 means we have passed the place where 450 would be on the master - therefore we know that 450 did not exist on the master and the delete is an error. MID = 456 and TID =450 therefore MID >TID. In this condition, a Delete is invalid. Therefore 450 is written to the error report. A new transaction record will be read.

Another master record will be read.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345… 444… 456... ERROR REPORT 350… 444… 450... I am using 999 as an EOF indicator. I have made the last record on each file have an identification number of When both files reach 999, I know that processing is complete. MID = 456 and TID =999 therefore MID < TID. Since the master is less it will be copied to the new master. Another master record will be read.

Another master record will be read.
Logic continued OLD MASTER 121... 123… 222... 234… 333... 345… 444... 456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345… 444… 456… 512... ERROR REPORT 350… 444… 450... Note that once the transaction file has reached the 999 the only thing to do is copy the remaining old master records onto the new master. Note: MID will always be less than TID. If the master file had reached the 999 record first, the only valid thing you could do is process the Add records by writing them to the New Master and process Changes and Deletions as errors. When the old master is at 999 the only possible relationship is MID > TID and the only thing that is legal in that situation is an Add. MID = 512 and TID =999 therefore MID < TID. Since the master is less it will be copied to the new master. Another master record will be read.

456… 512… 999... TRANSACTIONS 121… C 124… A 222… C 333… D 350… C 444… A 450… D 999... NEW MASTER 121… 123… 124… 222… 234… 345… 444… 456… 512... ERROR REPORT 350… 444… 450... This way of testing makes it easier to write the logic because you are constantly checking the relationship between MID and TID anyway. If the files do not physically contain 999 as a last record, you can move 999 to the MID or the TID when the file reaches EOF by including the move in the AT END clause. MID = 999 and TID =999 therefore MID = TID and more importantly they both = This means that end of file has been reached on both files and processing will terminate.

Please use speaker notes for additional information!

Similar presentations

Presentation on theme: "Please use speaker notes for additional information!"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Please use speaker notes for additional information!

Similar presentations

Presentation on theme: "Please use speaker notes for additional information!"— Presentation transcript:

Similar presentations

About project

Feedback