1. Algorithm #2
CHANGE transaction;
Several transactions 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. Recall Algorithm #1
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 3

4. We shall delete this line
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 4

5. Get_Next_Master After making the
Get_Next_Trans CHANGE, we suspend
temporarily the writing of
While NOT (master_key==sentinel AND trans_key==sentinel) to the new
the record
if (master_key < trans_key) master file until we can
{ output master record to new master file prove that there are no
Get_Next_master more CHANGE
transaction for that same
} record.
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 …… and we suspend too,
} taking another master
else record because of the
possibility that the next
{ print “no matching record in the master file”
transaction might be
Get_Next_Trans referencing the same
} master record
Prepared by Perla P. Cosme 5

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

7. The Second Algorithm
CHANGE transaction; several transactions per record
MF 3 6 10 11
TF 3 3 11 11 11
C C C C C
Prepared by Perla P. Cosme 7

8. Analysis
There are three (3) possible cases 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 8

9. 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 9

10. 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 10

11. 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 11