Using check operations
After a read or write call, control is returned to the user as soon as the requested operation has been accepted. In other words, there is no need to wait for this operation to be completed.
Before a read or write operation is initiated, however, the system waits for the preceding read/write operation (if any) to terminate (i.e. implicit check-and-wait operation). Similarly, when a close operation is requested, the system waits for the last read/write operation to terminate.
Thus, after the last in a series of read/write operations, a check operation is necessary only if the file is not immediately closed again or if, in the case of chained I/O, reading is continued until the end-of-file condition is reached (bit IDMFIB or IDMFEF of sense byte=1) and the number of blocks transferred is not equal to 0.
Example
In an EAM file, 3 read operations are performed. The file is not closed after this, because it is still required for later I/O operations. However, these I/O operations are not requested until after processing of the blocks that were read has been completed:
READ CHECK/WAIT Wait for termination of the last I/O operation. . . Processing of the blocks that were read . Further I/O operations
Changing processing characteristics
The following specifications are observed when opening or reopening a file:
chained/non-chained input/output
number of blocks to be transferred.
If one of these values is to be changed during processing of the file, the following actions are required:
Close file
Modify fields in MFCB
Reopen file
The value for the number of blocks to be transferred should be changed if, for example, fewer blocks are to be transferred in the last write operation than was specified when the file was opened.
Example
99 blocks are to be written to an EAM file. Chaining is to be used, with 15 blocks being transferred per write call (byte IDMFNHP in the MFCB). The following operations are then requested:
OPEN (new file) -> WRITE -> WRITE -> WRITE -> WRITE -> WRITE -> WRITE -> CLOSE *) -> REOPEN -> WRITE -> CLOSE
*) | After 6 write operations, there are still 9 blocks to be written. The file must therefore be closed and then reopened, this time with a value of 9 set for the number of blocks to be transferred. |
Overlapping input/output
A reduction in processing time can be achieved by means of asynchronous I/O operations:Once an I/O operation has been initiated, control is immediately returned to the program in order to enable other processing to take place in parallel with the physical I/O. The next I/O operation is then initiated using a second I/O area that does not overlap the first, and so on. Figure 1 illustrates the overlapping of processing and input operations.
Sequential read with chained input/output
Chained I/O is used most effectively for sequential reading if
a multiple of 3 is selected as the number of blocks to be transferred (3 x n);
the block number selected is in the form: (3 x n) + 1 (e.g. 1, 4, 7 ... )
Note
In order to support NK4 pubsets (in later operating system versions), EAM users are requested to convert chained processing to the blocking factor 2 or a multiple of 2. In this case, odd block numbers (BLOCK#) should be specified for direct I/O operations, i.e. 1, 3, 5, ...
A program converted in this way is downward compatible, which means it can run in earlier versions.
Figure 1: EAM – overlapping input/output
Handling object module files with EAM
Each job can process exactly one object module file. If bit IDMFOO of the option byte is set, all operations relate to the object module file. The actions involved in opening or reopening a file are illustrated in the following diagram:
Figure 2: Actions when an EAM file is opened
Figure 3: EAM – sequence when opening an object module file