I/O on VMS

[Gary_167]

Hello, does anyone know what is the largest single I/O VMS can do?

[Willem Grooters · Accepted solution]

IIRC, record IO (using RMS) has a limit of 32K bytes per IO. You may be able to do MUCH more if you bypass RMS - but I wouldn't recommend that.

Willem

[Keith Parris]

The 'HP OpenVMS I/O User's Reference Manual' at
http://h71000.www7.hp.com/doc/732FINAL/aa-pv6sf-tk/aa-pv6sf-tk.PDF says, in reference to Logical I/Os:

"Non-DSA disk devices can read or write up to 65,535 bytes in a single request. DSA devices connected to an HSC50 can transfer up to 4 billion bytes in a single request. In all cases, the maximum size of the transfer is limited by the number of pages that can be faulted into the process' working set, and then locked into physical
memory."

(DSA devices would be those on MSCP-speaking controllers.)

[Jan van den Ende]

Talking about impressive numbers....

Let's start a competition: who can DEMONSTRATE (verifiably) the largest transfer?


<8-])

jpe

[Hein van den Heuvel]

Willem wrote...
> IIRC, record IO (using RMS) has a limit of 32K bytes per IO.
> You may be able to do MUCH more if you bypass RMS - but I wouldn't recommend that.

This is not exactly right.
The operative word being 'record IO'.
The maximum RECORD size is close to 32K, but the actual IO size can be up to 127 blocks (of 512 bytes) for sequential files and 63 blocks for indexed and relative.

RMS is also willing and able to do unbuffered IO throught he SYS$READ and SYS$WRITE calls with a max of 127 blocks (16 bits unsigned) for the 'normal' RAB. On Alpha, by using a RAB64' you can specify an 32 bit size for up to buffer size up to 2**31-1 bytes. This may be limited by the targetted device.

http://h71000.www7.hp.com/doc/731FINAL/4523/4523pro_032.html#read_service_routine

Wim recommends against not using RMS but that really depends on the application. For 'records' in a file, RMS can help a lot. (that buffering, sharing, transparently handling records crossing buffer boundaries, read ahead, file extents for writes and so on).

Even for blocks in a file you may want to use RMS record mode (with UDF records, to get read-ahead / write-behind).
But for minimal CPU usage, you may want to go down to block IO through SYS$READ / SYS$WRITE and there are several good reasons to use the VMS native IO function: SYS$QIO(W).

If you need further help, then please describe you application/intended use in more detail.

Also... if yo think about going low level then be sure to check out the IO Reference manual: http://h71000.www7.hp.com/doc/732FINAL/aa-pv6sf-tk/aa-pv6sf-tk.HTMl

Hope this helps,

Hein.

[Willem Grooters]

Hein,

My mistake, you're right on record size vs. IO size - which doesn't have to be the same.
On bypassing RMS: yes, it depends. If your application doesn't have to interact with 'native'(RMS-using) applications, I think it's Ok to bypass RMS. But otherwise? What about locking, journalling....

(I'm not that familiar with low-level issues of RMS, thanks Hein for the link)

[Keith Parris]

In a discussion on comp.os.vms recently (entitled "Split I/Os to contiguous file???"), a couple of people pointed out that the UCB field UCB$L_MAXBCNT indicates the maximum size of transfer (in units of bytes) that the device will support. Rob Brooks gave this example there for an HSG80-attached disk:

"$ ANAL/SYS
SDA> read iodef
SDA> SHOW DEVICE $1$DGA12
[stuff appears on screen]
SDA> EXAM UCB+UCB$L_MAXBCNT
UCB+00190: 00000000.00020000 "........"
SDA> EVAL 20000 / ^D512 ! bytes per block
Hex = 00000000.00000100 Decimal = 256"

I took a brief look at the listings for DKDRIVER and DUDRIVER for 7.3-2.

DUDRIVER seems to have had an upper limit of 2^24 bytes introduced at 6.2 to work around a problem related to path switching. And for a disk served by the VMS MSCP Server, the maximum seems to be 127 blocks.

The default for DKDRIVER seems to be 127 blocks, but it can do as high as 256 blocks if the port hardware can support it.