|
HP OpenVMS Systemsask the wizard |
|
The Question is: For many years I have periodically tried to get my BLOCK IO file access programs to transfer data using DECNet. The result is always the same: the first 126 blocks are read without a problem, then the rest of the data comes over corrupted. These programs have been working fine for many years for local file access. My question to the Wizard: Does Compaq support BLOCK IO over DECNet? I seem to remember reading somewhere it does not. The Answer is : The OpenVMS Wizard will assume use of RAB, and not RAB64. Block I/O is limited by the word size field in the RAB (RAB$W_USZ for SYS$READ and RAB$W_RSZ for SYS$WRITE), so the maximum number of blocks that can be involved in one transfer is 127. To test the transfer, the OpenVMS Wizard used a file that contains integer counts starting with 1 up to decimal 2,097,152 (x200000) in a 16384-block sequential file (128 integers per block). Using this file and this data, it is easily verifiable whether the blocks read contain the data that they should. The OpenVMS Wizard used SYS$READ to read the data -- 127 blocks per read in the first 129 transfers. Then SYS$WRITE to write the data out to a new file. A remote file specification was used for the $READ operations (OpenVMS to OpenVMS). The new file was a perfect copy. Thus an example showing the reported corruption failure will be of interest -- there could well be other activities or other operations causing this limit -- if a reproducer is available, please contact the Compaq Customer Support Center directly. If RAB64 is in use on OpenVMS Alpha V7.0 and later, the buffer size maximum for a block I/O $READ or $WRITE is 2**31-1 bytes -- assuming OpenVMS Alpha to OpenVMS Alpha, of course. This might be somewhat misleading however, as RMS (DAP) will segment larger requests into the message segment buffer size that is supported by the DAP/FAL link -- the OpenVMS Wizard is not particularly aware of customers using RAB64 for remote block I/O, however.
|