If you wrote your own program to do a merge:
read 1, read 2
if key1 < key2
copy from 1 until key1 not < key2, back to merging
if key2 < key1
copy from 2 until key2 not < key1, back to merging
copy current records on 1 and 2
read 1 and 2
back to merging
I've ignored eof processing above to keep it simple.
It would be possible to read the entire 1 file before the 2nd record on the 2 file, depending on key values.
A simple MERGE in SORT would work approximately like this.
What is going on in the MERGE in the sort is something a bit different, in that there are different stages not outlined in the pseudo-code above.
The records are being changed before the MERGE statement. Each record will be changed before being presented to the processing for the MERGE. Intially a record will be read on each file. The amendment made to each record, and then both records will be presented to the MERGE for processing. The file 1 will have been read first, so it gets the lowest sequence number, with the file 2 record having the next. The MERGE spots this and writes out the first record from file 1, and has to therefore read a new record from that file, which will be pre-processed, getting the sequence number 3. Both current records are presented to the merge. The file 2 is now low, so will be written to output and the next file 2 record will be read, which will get the sequence number 4. Etc.
So, as long as the initial records are read in the order of the files (SORTIN01 first, SORTIN02 second) then the process will work. A quick look at the manual means I need a longer look to confirm how that part of the process is documented