FastIO sys$io_perform sys$extend

[Benoit GENNART]

I am porting our data-access library to VMS.
I work on the basis of fast_io_copy.c
(block IO, asynchronous IO)
I do not know the final file size when
I create it.

after working a bit on fast_io_copy.c,
I am under the impression that sys$io_perform
and sys$extend are mutually exclusive (not
altogether surprising)
- sys$io_perform works if FAB _fop _UFO
is set
- sys$extend works if FAB _gop _UFO is
not set

Does this mean that the right way to extend
a block/async IO file is to close it,
reopen it without _UFO, extend it, close it,
reopen it with _UFO ?

Thanks in advance.

-- Benoit

[Hein van den Heuvel]

That is basically correct. With fop=ufo, you only use RMS for the file name parsing, lookup, and to assign a channel.
I would not worry about sys$extend though. If you are willing to play with $IO_perform, then using an ACP QIO to extent the file is only a minor side track. Just check te ACP chapter in the VMS IO User Ref Manual. Look for IO$_MODIFY and FIB$V_EXTEND. As a modest example of how to roughly use that, check out for example: http://h71000.www7.hp.com/freeware/freeware50/rms_tools/src/set_nocontig.c

Now if somehow you do choose to go sys$sextent, then be sure to hook up that NAM block on the initial open. That way you can re-open with by-file-id. Much quicker!

btw... that is an active/aggresive port you are considering. Not your average 'c-crtl stream io will take care of me'. Care to hint why you go 'extreme'? What problem are you trying to solve that a vanillay SYS$QIO, or even (64-bit) RMS SYS$WRITE is not deemed good enough? Don't get me wrong, I am all for it, but just would like to understand and appreciate.

Cheers,
Hein.

[Benoit GENNART]

Hein,

thanks for your answer. I'll work
on it. I am also in contact with
Robert Sampson but had not heard
from him yesterday and decided
to try the group route. Note that
appreciate the high level of support
I have received from everybody in
the OpenVMS group.

We already have the CRTL version
running, and this allows us to
work on all (functional/perf.)
aspects of our library, while
at the same time pursuing the
FastIO route, to get the last
bit of performance / scalability
out of it.

My current opinion : despite the
VMS learning curve and not having
any solid results yet, I expect to
get very good performance from VMS
FastIO, which I could not hope
to get from CRTL.

-- Benoit

[Willem Grooters]

btw... that is an active/aggresive port you are considering. Not your average 'c-crtl stream io will take care of me'.


I could think of _at least_ ONE good reason is in that statement:



It may be the aggressive way, it may be difficult and hard to master, but IMHO it is the right way. As an advantage: you learn much more about (the good things of) VMS than just taking the easy route. I like your approach!

Willem