przemek@psuvaxg.BITNET.UUCP (02/03/87)
My (FORTRAN) program writes graphics to the tektronics terminal.
It does so by assigning a channel to something and QIOW to this channel:
int2 = sys$assign('ugdevice',ddacn,,) ! hook for file output
if(.not. int2) int2 = sys$assign('tt',ddacn,,) ! if not file, terminal
.........
sys$qiow(,%val(ddacn),.....)
Now, when I 'assign a.a ugdevice', it bypasses first sys$assign (int2 is appa-
rently non-zero, second assign takes place, with the effect that output goes
to the terminal (tt)). If I 'assign dua0:[pzk]a.a ugdevice', the ddacn channel
is assigned to (probably) dua0:[pzk]a.a , but now the sys$qiow returns non-zero
status.
Could anybody explain this to me?
My goal is to redirect the output of the program to the file.
I am relatively new to VMS, so please don't say it should be obvious :^)
przemek@psuvaxg.bitnet
psuvax1!gondor!przemekcarl@CITHEX.CALTECH.EDU.UUCP (02/04/87)
>My (FORTRAN) program writes graphics to the tektronics terminal. >It does so by assigning a channel to something and QIOW to this channel: > int2 = sys$assign('ugdevice',ddacn,,) ! hook for file output > if(.not. int2) int2 = sys$assign('tt',ddacn,,) ! if not file, terminal >......... > sys$qiow(,%val(ddacn),.....) >Now, when I 'assign a.a ugdevice', it bypasses first sys$assign (int2 is appa- >rently non-zero, second assign takes place, with the effect that output goes >to the terminal (tt)). If I 'assign dua0:[pzk]a.a ugdevice', the ddacn channel >is assigned to (probably) dua0:[pzk]a.a , but now the sys$qiow returns non-zero >status. >Could anybody explain this to me? >My goal is to redirect the output of the program to the file. >I am relatively new to VMS, so please don't say it should be obvious :^) But it IS obvious: SYS$ASSIGN assigns a channel to a DEVICE, not to a FILE. When you 'assign a.a ugdevice', the first call to SYS$ASSIGN returns the error code SS$_IVDEVNAM, which has the associated message text: "%SYSTEM-F-IVDEVNAM, invalid device name": i.e., A.A is not a device. When you 'assign dua0:[pzk]a.a ugdevice', SYS$ASSIGN assigns a channel to DUA0:. However, when you try to write to the device using SYS$QIOW, it turns out that you don't have the privs to write directly to the disk (and a good thing, too; if you had, the file structure on the disk would have become unreadable). You've got three choices: 1) You can use the QIO disk ACP interface (not recommended for a neophyte); 2) You can use calls to RMS (somewhat easier for a neophyte, but also somewhat complex and probably not necessary); or 3) You can use the FORTRAN OPEN and WRITE statements to do the I/O (probably your best bet).
LEICHTER-JERRY@YALE.ARPA.UUCP (02/04/87)
My (FORTRAN) program writes graphics to the tektronics terminal.
It does so by assigning a channel to something and QIOW to this channel:
int2 = sys$assign('ugdevice',ddacn,,) ! hook for file output
if(.not. int2) int2 = sys$assign('tt',ddacn,,) ! if not file, terminal
.........
sys$qiow(,%val(ddacn),.....)
Now, when I 'assign a.a ugdevice', it bypasses first sys$assign (int2 is
apparently non-zero, second assign takes place, with the effect that
output goes to the terminal (tt)). If I 'assign dua0:[pzk]a.a ugdevice',
the ddacn channel is assigned to (probably) dua0:[pzk]a.a , but now
the sys$qiow returns non-zero status.
Could anybody explain this to me?
My goal is to redirect the output of the program to the file.
I am relatively new to VMS, so please don't say it should be obvious :^)
You have one major problem and at least one minor problem here.
Major problem: The "assign" in SYS$ASSIGN and the "assign" in a DCL ASSIGN
command are very different beasts, bearing little relationship to each other.
DCL ASSIGN creates a logical name - it makes something that looks like a
device name translate into something else. SYS$ASSIGN allocates a channel
connected to a physical device. The only relationship between the two is
that SYS$ASSIGN will attempt to translate the "device name" given it as a
logical name produced perhaps by DCL ASSIGN.
SYS$ASSIGN creates a channel that goes to a DEVICE, NOT a file. You can do
I/O this way to terminals, but NOT to files; that's a lot more elaborate.
(To do I/O to files, you first assign a channel to the disk, then open a file
on the channel. This is an elaborate process that is almost never used -
instead, you use RMS calls that combine the two actions for you.)
The QIO interface is not particularly device-independent on VMS. Getting a
program that uses QIO's to write either to a graphics device of some sort
or to a disk file would be a significant undertaking. It also isn't necessary
in most cases - like yours: RMS exists exactly to do that for you. It will
write to either the terminal or a disk file, using the same calls. So, for
that matter, will the FORTRAN I/O system, which uses RMS. (If you were trying
to talk to a private driver for some kind of fancy graphics controller, things
would be much more complex.)
From just the fragment of code above, it's difficult to provide specific
advice, but I suspect you'll have to step back and figure out exactly what
it is you are trying to accomplish and re-design the way you are doing I/O.
Use the highest-level interface that solves your problem with acceptable per-
formance; it may be the FORTRAN I/O system, RMS, RMS with block I/O calls, or
maybe even QIO's - though I think it rather unlikely.
Finally, as to the minor problem: It doesn't show up in your code, which is
correct, but in your comments, which evince a misunderstanding of VMS status
values. A return of 0 from SYS$QIO would be an error (well, technically a
warning). A success would be a return value of 1. In general, the bottom
bit of a return value is 1 for successes, 0 for failures - the bottom 3 bits
give a severity, and the rest of the value defines the exact status. (There
are plenty of distinct successful status values!) All this is discussed in
the documentation - try the system services reference as a start.
-- Jerry
-------McGuire_Ed@GRINNELL.MAILNET.UUCP (02/04/87)
Now, Carl, I think your reaction was in poor taste. Not only are you unlikely to make a friend that way, I disagree with your assertion that it is obvious that SYS$ASSIGN assigns channels to devices, not files. Anyone who has only used the I/O operations built-in to a HLL would assume that you can assign a channel to a file on a device using SYS$ASSIGN, because that's the way it works with HLL channel assignment. I do agree completely that one should stick with the HLL I/O statements unless it is very difficult or impossible to get from here to there with them. The next step is indeed RMS, and then the ACP QIO interface. I wish the original posting had explained why the author had given up on FORTRAN I/O. Ed