Other Considerations

There are several things of which you should be aware when using multiple-record mode:

1. In multiple-record mode, the client requires more memory than if it has no files open in this mode. In particular, the client requires memory for all the records in the cache from the server. For example, if three files are open in multiple-record mode with maximum record sizes of 100, 250, and 800, and MULTIPLE_RECORD_COUNT is set to "10", the client requires 100 * 10 + 250 * 10 + 800 * 10 bytes of storage for holding all the records from the server. This is compared to needing only 100 + 250 + 800 bytes of storage if these files were not open in multiple-record mode.
2. The server also requires more memory when you use files in this mode. This should not be a significant addition to the usual amount of memory that the server needs, because the server reads all the records it sends and then does not save these records. The server needs only a single large internal buffer to hold the records temporarily. This buffer should have a size of the largest MAXIMUM_RECORD_SIZE multiplied by the largest MULTIPLE_RECORD_COUNT.
3. This mode is inherently subject to race conditions, including those described below. (Note that these are not the only race conditions that you may encounter.) If your application is written in such a way that it will experience race conditions, you should not use multiple-record mode.
   • Condition 1: If two users are accessing a single file, and one of those users has the file open in multiple-record mode, the following situation could happen:
     • User A opens and reads the first record. At this time the server sends multiple records to user A.
     • User B opens the file and writes a record in a location within the record set that the server has already sent to user A.
     • User A never sees that record unless the file is closed and reopened.

     In other words, when the server sends a collection of records to a client, that client now has a snapshot of the records on the server. The client does not query the server about any new records, since this would remove the performance gain of using multiple-record mode.

   • Condition 2: Suppose a user opens the file I/O for exclusive access (or allowing only readers) in multiple-record mode. Suppose this user reads the first record, and then writes a record that is after the first record, but before the last record in the client cache.

     As the user executes READ NEXT, that record never appears. For example, suppose the file has a key that is a PIC 99 data item, and that ten records are sent in each batch. Also suppose that the file has records with keys 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95. The user opens the file and executes a READ NEXT. At this time, the first ten records are in the client cache (records 05, 10, 15, 20, 25, 30, 35, 40, 45, 50) and the COBOL program has record 05 in its record area. Suppose the user then executes a WRITE to write a record with the key of 08 and then executes another READ NEXT. The record that the COBOL program has in its record area is now record 10, not record 08. Again, the client and server will not communicate about this situation, since it would completely remove the performance gain of using multiple-record mode.

   • Condition 3: Now suppose you have the same file as in the previous case, and that the user has executed the first READ NEXT. Suppose the user then executes a REWRITE on record 10 to change data in that record and then executes a READ NEXT. The COBOL program will now have the original data from the file for record 10, not the data that the COBOL program just rewrote.

   Since multiple-record mode is inherently subject to race conditions, you should use this mode only in situations in which you are sure you understand all of the consequences.