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.