The internal format of the memo pad depends on whether two byte or four byte links are used. You decide which link size to use when you set up the memo pad (with MAKMMO) and your data file. Four byte links would normally only be used when you plan to have more than 65535 memo records, which is the limit for two byte links. Note that you can start out with two byte links and then use the CVTMMO program to convert your memo pad to the 4-byte format.

The following two subsections describe the format for the two byte and four byte formats.

2-Byte Link Format The internal structure of an auxiliary memo file with 2 byte links is  shown below:   R  | Delete | Ptr to    | Ptr to  |   E | marker | end of    | next    |   C | or link| file (ctl | deleted |   N | pointer| rec only) | record  |   O | 1 2  6 | 7       8 | 9    10 | 11             64 | (byte #'s)     +--------------------------------------------------+   1 |]]]DEL  |    (7)    |   (3)   | ]]]]]]]]]]]]]]]]]]| (control rec)     +--------------------------------------------------+   2 | (4) | This is a logical memo record which requir | (text rec)     +--------------------------------------------------+   3 |]]]DEL  |           |   (5)   |                   | (deleted rec)     +--------------------------------------------------+   4 | (0) | es two physical memo records of storage.   | (text rec)     +--------------------------------------------------+   5 |]]]DEL  |           |   (0)   |                   | (end del chain)     +--------------------------------------------------+   6 | (0) | This is another comment.                   | (text rec)     +--------------------------------------------------+   7 |]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]| (eof rec)     +--------------------------------------------------+   8 |]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]| (eof rec)     +--------------------------------------------------+

 

The diagram above may require a little explanation. For one thing, it is not to scale. Each record is 64 bytes long, and each of the pointer fields is two bytes long. The first record of the file is the control record, which contains a pointer to the first end-of-file record in bytes 7 and 8 (record #7), and a pointer to the first record in the deleted record chain in bytes 9 and 10 (record #3).

Record #2 shows a typical text record. The first two bytes are a pointer to the next record for that memo pad, or zero if this is the last record for this comment. In this case, record #4 contains the continuation of this comment. Note that the associated primary data record must contain a #2 in the designated link field (assuming that this is the first physical record of the memo pad for that data record).

Record #3 shows a typical deleted record. The first 6 bytes are marked ]]]DEL, and bytes 9 and 10 contain a pointer to the next deleted record (#5). Record #5 is the last deleted record so it has a zero in the next-deleted-record pointer. Note that the remaining bytes in the record are garbage.

Record #6 contains the first (and last) record of another logical block of comments.

Records #7 and #8 are marked as being at the end of the file by the brackets in positions 1-6.

When the file is initialized, the control record eof pointer is set to 2, and the deleted record pointer is set to 0 (since there are no deleted records). All of the rest of the records are filled with brackets.