Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Re: reassignment in VMS
Message-ID: <8702041240.AA13960@ucbvax.Berkeley.EDU>
Date: Wed, 4-Feb-87 07:40:46 EST
Article-I.D.: ucbvax.8702041240.AA13960
Posted: Wed Feb  4 07:40:46 1987
Date-Received: Thu, 5-Feb-87 06:40:17 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 61
Approved: info-vax@sri-kl.arpa


    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
-------