This document describes Algorithm #1 for processing transactions. It simulates a single file update using sample data. There are three possible cases when comparing a master key to a transaction key: 1) master key less than transaction key, 2) equal keys, 3) master key greater than transaction key. The algorithm outputs master records, makes changes for matching keys, and flags non-matching keys. It is noted that this allows only one transaction per account per day, so the algorithm needs modification to resolve this limitation.

1. Algorithm #1
CHANGE transaction;
one transaction per master record

2. Assumptions
• Let the sentinel value be equal to 999
• Let there be a function Get_Next_Master defined as
follows:
if eof(master)
master_key = sentinel
else input next master record
• Let there be a function Get_Next_Trans defined as
follows:
if eof(trans)
trans_key = sentinel
else input next trans record
Prepared by Perla P. Cosme 2

3. Let’s simulate the SFO using
Algorithm #1
We shall use the same example as what we
presented previously.
Prepared by Perla P. Cosme 3

4. The First Algorithm
CHANGE transaction; one transaction per record
MF 3 6 10 11
TF 1 3 4 11 17
C C C C C
Prepared by Perla P. Cosme 4

5. Get_Next_Master
Get_Next_Trans
While NOT (master_key==sentinel AND trans_key==sentinel)
if (master_key < trans_key)
{ output master record to new master file
Get_Next_master
}
else if (master_key == trans_key)
{ make a change in the master record
output master record to new master file
Get_Next_Trans
Get_Next_Master
}
else
{ print “no matching record in the master file”
Get_Next_Trans
}
Prepared by Perla P. Cosme 5

6. Analysis
There are three (3) possible case that we can
identify when comparing the master key and
the transaction key:
2.Master key < transaction key
3.Master key = transaction key
4.Master key > transaction key
Prepared by Perla P. Cosme 6

7. There is no transaction
Analysis
for the master record,
hence, it will just be
copied or written to the
new master file.
There are three (3) possible case that we can
identify when comparing the master key and
the transaction key:
2.Master key < transaction key
3.Master key = transaction key
4.Master key > transaction key
Prepared by Perla P. Cosme 7

8. When master key is equal
Analysis
to transaction key, that
means that the record
exists, and hence, we can
implement the CHANGE
There are three (3) possible cases that we can transaction.
identify when comparing the master key and the
transaction key:
2. Master key < transaction key
3. Master key = transaction key
4. Master key > transaction key
Note: Among the 3 cases above, it is only in case #2
above where we are allowed to change. Why?
Prepared by Perla P. Cosme 8

9. When this condition
Analysis
holds true, that means
that the transaction is
invalid because you
cannot change a record if
the record does not exist
There are three (3) possible case that we can in the master file.
identify when comparing the master key and
the transaction key:
2.Master key < transaction key
3.Master key = transaction key
4.Master key > transaction key
Prepared by Perla P. Cosme 9

10. Something to Ponder
If this is the type of transaction that we have as
depicted in Algorithm #1, that means we can only do
one transaction per account per day.
But this is not a realistic situation – because we
never want to be restricted on having only one
deposit or one withdrawal on your ATM account per
day.
Question:
So, how do we modify the algorithm in order to
resolve the problem?
Prepared by Perla P. Cosme 10

11. Solution:
Proceed to Algorithm #2
Prepared by Perla P. Cosme 11