Indexed File I/O using $QIO

[Leo A. Parks]

Where can I find information regarding reading/writing an indexed file using SYS$QIO.
If there are examples it would be helpfull if they are in FORTRAN.
Thank you

[abrsvc]

I would think that indexed file access would be much easier from Fortran directly. Any particular reason for wanting to use QIOs?

Also, the standard particulars are necessary here as well:

Hardware type
VMS Version numbers
Fortran version
etc.

Thanks,
Dan

[Hein van den Heuvel]

>> Indexed File I/O using $QIO

Why?

Could is be that you mean 'system services' such as SYS$GET, not $QIO?

If you read an (indexed or other) RMS file with QIOs then you will have to do a good bit of de-coding to get to useful data.

I have created several C example reading indexed files with $QIO for tuneing check purposes and such. Those are available as freeware, at symposia. I'll should get you a better link to more examples, but for now this oldie might do:
http://www.digiater.nl/openvms/freeware/v30/rms_tools/src/sidr.c

Actually... is uses SYS$READ, not SYS$QIO

For an extensive Fortran example you may want to check out Fekko's DIX:
http://www.oooovms.dyndns.org/dix/

More importantly... what are you really trying to accomplish? Why QIO ?

Hein

[Leo A. Parks]

Thanks for the replies.

Maybe I should have provided a little more info.
The reason I want to use SYS$QIO is for the ability to queue the I/O request and not have to wait for completion (while the requesting process does other operations). This is a realtime function that shouldn't be held up waiting on file-I/O.
I already have that functionality for sequential-file access (using SYS$QIO), however I "inherited" that code and can't find support information in the various VMS manuals.
I realize there are other methode I can use, but I really want to use SYS$QIO if possible.

Thanks again for your responses.

[abrsvc]

There are alternative methods that can be used to accomplish this functionality without direct use of QIO calls. Perhaps a conversation directly wouldmake this easier. Where are you located? Shoot me an Email with contact info so we can discuss.

Dan

dansabrservicesATyahooDOTcom

[Hein van den Heuvel]

>> The reason I want to use SYS$QIO is for the ability to queue the I/O request and not have to wait for completion (while the requesting process does other operations).

Sorry, but you are mistaken.
You can NOT reasonably expect to write records to RMS Indexed files with SYS$QIO.
If you would know how to do that, you would not be asking here, trust me.

You _can_ however simply ask RMS SYS$PUT to go Asynchronous by setting the RAB$V_ASY bit (the low bit in the RAB$L_FOP field).
You can have only 1 active operation per RAB, and need to use SYS$WAIT to synch back up if need be, notably to get the status back.

You can connect up multiple RABs (FAB$B_SHR. FAB$V_MSE = 1 )

While not extremely complex, this is still somewhat tricky for folks who have not programmed in this area before.
Therefor anyone is really well advised to obtain some training / consulting to get going on this task for a first time.
( The way you asked the question so far suggests that this applies very much. :-)

>>> This is a realtime function that shouldn't be held up waiting on file-I/O.

You may prefer to implement a server.
Just stick any record to be added into a mailbox, read in server, log to sequential file if needed, add to indexed file at your leisure.

This is notably MUCH more efficient when multiple writers are involved, and speed is an issue. It probably also give you a better place, and timing, to deal with error situations.


You may also want to investigate WHY a file IO is perceived to be too slow. Perhaps it can be tuned to stay in the realtime realm?

>>> I already have that functionality for sequential-file access (using SYS$QIO), however I "inherited" that code and can't find support information in the various VMS manuals.

Look again. It is all there.
Your focus should be on how they communicate how much data is there. (Lock? EOF?)
I suspect they are doing simple BLOCK writes, not RMS records IO.

>>> I realize there are other methode I can use, but I really want to use SYS$QIO if possible.

Sorry, but you are wrong.

fwiw, i just finally put some of my freeware on EISNER/DECUSERVE
http://www.encompasserve.org/~hein/freeware.html

I should eventually flesh that out some.
My submission to the OpenVMS Freeware are stale and did not make with to V8.0.

Good luck!
Hein van den Heuvel ( at G Mail )
HvdH Performance Consulting.

[Hoff]

>The reason I want to use SYS$QIO is for the ability to queue the I/O request and not have to wait for completion (while the requesting process does other operations). This is a realtime function that shouldn't be held up waiting on file-I/O.

Which can also lead to an application design where the real-time process isn't hitting the files. Where performing I/O would involve a logger process or a logging server or where the real-time processing dequeues the data by writing the packets into a shared memory ring buffer, or whatever else might be appropriate to maintain the required performance.

Real-time and files (beyond maybe a "dumb" journal file) isn't a good nor particularly easy mix, in my experience. Particularly when there is multi-processing going on with any of the files, or when file maintenance is needed, or various other topics.

The standard RMS $get and $put calls can also operate asynchronously, if you really want to access RMS files using overlapping accesses. (Unfortunately, mixing overlapping access into files can also lead to locking and other untoward events; stuff that can stall an RT process, and can lead to cases that are subtle, and difficult to duplicate and debug.)

Been there, wrote that (in FORTRAN/Fortran, BASIC, C and assembler), and acquired whole sets of the scars.

Based on my experience, I'd toss the stuff to a logger, or logging, or... Whatever it took to get the file stuff decoupled from the real-time processing, and to get the files out of the RT code-paths.

>I already have that functionality for sequential-file access (using SYS$QIO), however I "inherited" that code and can't find support information in the various VMS manuals.

The $qio programming interface likely used here is virtual I/O into a sequential file, and that generally doesn't do indexed file access. (Not easily.)

The documentation on $qio and sequential access (record or block) within a file is scattered between the I/O User's Reference Manual and a few other spots in the documentation including the Guide to OpenVMS File Applications manual, with most of the API support material located in the IO$_ACPCONTROL chapter of the I/O manual.

>I realize there are other methode I can use, but I really want to use SYS$QIO if possible.

Recognize how that statement might be interpreted by anyone that might subsequently review this decision or that might subsequently be charged with maintaining this code, too. You're seeking to write and maintain a whole pile of Fortran $qio code when an easy alternative is already available and likely fully meets the stated requirement.

Put another way, you're basically seeking to create and maintain your own record structures and your own RMS indexed file replacement. In an RT context. That's one of those creeping projects that often turns into a bigger project; one that starts out small, and sooner or later...

Here's an quick intro to the file system and I/O models on VMS, if you're not already familiar with the various layers:

http://labs.hoffmanlabs.com/node/357
http://labs.hoffmanlabs.com/node/114

And FWIW, there is no single definition for Real-Time; the particular responsiveness requirements and penalty for missing an event within an application can vary widely

And FWIW, Fortran can perform direct access into RMS indexed files, so that I/O path is also available for a logging application. That support can keep the code in the logger easier to maintain and manage.

[Leo A. Parks]

To all who replied to my request for information:

Thank you the assistance you provided. I do appreciate it.

Leo a. Parks

[Robert Gezelter]

Leo,

As has been said, QIO & RMS indexed files: Just say NO.

Asynchronous RMS operations work quite well, and have all the proper support to avoid accidents, this is highly recommended. Been there, done that more than a few times.

- Bob Gezelter, http://www.rlgsc.com

[Leo A. Parks]

Thanks to all who responded.

I am using Fortran reads and writes in a seperate process.