Operating System - OpenVMS
1748144 Members
3818 Online
108758 Solutions
New Discussion юеВ

Re: Writing to disk using SYS$QIO

 
MButler
New Member

Writing to disk using SYS$QIO

I'm trying to write to disk asynchronously. SYS$QIO seems like a good option. However, I'm having a very difficult time figuring out how to specify the file on the device that I wish to write to. From what I can tell in the documentation, argument p3 to SYS$QIO should be the "disk address"-- but how am I to get that? Any suggestions or examples?
23 REPLIES 23
Hein van den Heuvel
Honored Contributor

Re: Writing to disk using SYS$QIO

QIO to a disk is 'never' a good option.
QIO to a file on a disk is RARELY a good option. If it is 'that important' then perhaps you should be looking at $IO_PERFORM

Anywat, iF you want to go the all QIO route, then you need a QIO ACCESS first. See ACP section in DRIVERS reference manual.

More typically folks use RMS to open the file but set the UFO OPTION in the FAB. This will return a CHANNEL in the STV field which you can ue for a QIO(w).

HOWEVER... please consider your exact goals and skills. You may find that RMS SYS$WRITE / SYS$READ\, using the RMS AST / SYS$WAIT options is even more easy still.

AND, more than 1/2 th time I saw folks thinkg they needed QIO, they really just needed to learn more about RMS and WRTIE-BEHIND and/or DEFERRED-WRITE + SYS$FLUSH.

SO... if you need more help than this reply offers, then pleas ebe sure to be more clear about the problem you are trying to solve, and we may be able to help better.

Good luck!
Hein.
Hein van den Heuvel
Honored Contributor

Re: Writing to disk using SYS$QIO

Here is a tiny RMS - UFO - QIO example, for a specific QIO fucntion which is not directly avaibale in RMS. The powerful IO$_ERASE.

When playing with QIO, and VBN's, the $DUMP/BLOCK=(START:x,COUNT:y) will soon become your good friend.

Hein.



#include iodef
#include rms
#include stdio
#define FILE_SIZE 24
main()
{
int status, channel;
struct FAB fab;
short iosb[4];

fab = cc$rms_fab;
fab.fab$l_fna = "TMP.TMP";
fab.fab$b_fns = strlen(fab.fab$l_fna);
fab.fab$b_fac = FAB$M_GET | FAB$M_PUT;
fab.fab$l_fop = FAB$M_UFO;
fab.fab$l_alq = FILE_SIZE;

status=sys$create(&fab);
channel = fab.fab$l_stv;
if (status & 1) status = SYS$QIOW(0, channel, IO$_WRITEVBLK | IO$M_ERASE,
iosb, 0, 0, 0, FILE_SIZE*512, 1, 0, 0, 0);
if (status & 1) status = iosb[0];
if (status & 1) status = SYS$QIOW(0, channel, IO$_DEACCESS,
iosb, 0, 0, 0, 0, 0, 0, 0, 0);
return status;
}


Hein


Robert Gezelter
Honored Contributor

Re: Writing to disk using SYS$QIO

MButler,

I will heartily agree with Hein!

There is almost NEVER a need to do QIO to the disk. Asynchronous RMS access works quite well. I have been using it extensively for many, many years, particularly with other AST-based logic.

Is there a particular reason why QIO is being considered as opposed to RMS in an asynchronous fashion?

- Bob Gezelter, http://www.rlgsc.com
Robert Gezelter
Honored Contributor

Re: Writing to disk using SYS$QIO

MButler,

I should clarify something. A historical note is digression is appropriate.

When it was popular to run RSX-11 executables using the VAX-11 AME (still available if I recall correctly), it was a not infrequent happening to corrupt one's disk by "reassigning" IO from the terminal to the disk. Of course, TERMINAL QIOs generally had a zero P3 [hence the corruption: say goodbye to one's boot and home blocks].

Hence, the reason to recommend sticking with RMS. RMS will do the actual QIO operations with the XQP, gaining access to a particular file, and then do the QIO operations to access the data. This is far safer than writing one's own code in all but extremely rare occasions [ALMOST NEVER].

- Bob Gezelter, http://www.rlgsc.com
Hoff
Honored Contributor

Re: Writing to disk using SYS$QIO

The sys$qio works nicely, and IO$_WRITEVBLK is your best choice, and the usual approach here involves the Virtual Block Number (VBN), and the VBN of a file starts at one. The VBN runs from the first block of the file to the last block. And I'm here referring to disk blocks, and not to records within files.

The VBN pieces and using Virtual I/O gets around what the folks here are discussing; IO$_WRITELBLK and WRITEPBLK are (if you miss your intended block target) a good way to corrupt your disks. At its simplest, you perform a file-open and obtain a channel number, and then use whatever combination of READVBLK and WRITEVBLK operations and ASTs needed.

Hein's references to sys$read and sys$write and to the block-oriented operations in RMS are another way to avoid the risks of errant $qio operations.

If you're tossing full-on logical I/O, that's another discussion. And you'll need the Logical Block Number (LBN) for your target block. And writing to LBNs is at the programming level of rolling your own volume structure. (Yes, it's possible to do LBN writes entirely within an existing file structure, but that's, um, somewhat unusual.)

I've posted up a fairly generic RMS library for use from C applications.

It's been my experience that most decently-tuned RMS applications are reasonably fast. Yes, you can go faster, but that's usually more work than a quick pass through what RMS gives you.

Here's some reading material:
http://64.223.189.234/node/357
http://64.223.189.234/node/114
http://64.223.189.234/node/617

The pointer to the example C code download is in the above topics.

John Gillings
Honored Contributor

Re: Writing to disk using SYS$QIO

MButler,

Don't use $QIO. RMS services are a much better way to talk to disks. They'll be easier to use and perform significantly better than you will be able to achieve (remember, the RMS folk have had more than 30 years to get their code right!).

I would strongly urge you to modularise this data store. Consider the application view of the data and design an API that defines the set of required operations. You're then free to implement those operations independently of the application.
A crucible of informative mistakes
GuentherF
Trusted Contributor

Re: Writing to disk using SYS$QIO

"SYS$QIO seems like a good option"

Why do you think that is so? Did/do you know all the other options of accessing data on disk with OpenVMS?

/Guenther
Robert Brooks_1
Honored Contributor

Re: Writing to disk using SYS$QIO

I'm trying to write to disk asynchronously. SYS$QIO seems like a good option.

--

What's your language of choice? It's almost a certainty that using the language-specific I/O interface would suffice. Most DEC languages have DEC-specific extensions that allow for the use of some RMS features without resorting to using RMS directly.

If that not, then using the RMS services would almost certainly be easier/better/more maintainable than using QIO(W).

That one can do I/O via QIO doesn't make it the right thing to do. With proper privileges, one can do I/O by allocating their own IRP's and queueing them directly to a device UCB, but that doesn't make it a great idea, either.

-- Rob
Steven Schweda
Honored Contributor

Re: Writing to disk using SYS$QIO

If you get desperate for more disk QIO
example code, Info-ZIP UnZip uses some (in
[.vms]vms.c). UnZip version 6 (still not yet
released, but available in "BETA" form) even
includes support for ODS5 extended file
names. (I hope.)