[Info-vax] Fortran problem with QIO

[jbriggs444]

On Dec 7, 12:00 pm, Ken Fairfield <ken.fairfi... at gmail.com> wrote:
> On Dec 4, 4:44 am, koeh... at eisner.nospam.encompasserve.org (Bob
>
> Koehler) wrote:
> > In article <5ovfh5l5haviokhcnub9hlphoee7n0c... at 4ax.com>, gerr... at no.spam.mail.com writes:
>
> > > It's already here, in this thread: just look at my yesterday answer to Hein
> > > and you'll find the working program. :-)
>
> >    Yes.  Once again posts cross in the night.
>
> Coming in late to the discussion, sorry...  I did
> a lot of this (calling system services from Fortran)
> in a past life.  :-)
>
> To the OP, you need to know that VAX Fortran
> passes most arguments by reference (address),
> with the exception of CHARACTER variables,
> which are always passed by descriptor (as
> noted by other posters).
>
> The second thing is you need to carefully note is
> for the given system service, i.e., SYS$QIOW,
> check the argument passing *mechanism* and
> match your call from Fortran to that.
>
> CHARACTER arguments to system services
> are almost always passed by descriptor, so
> just pass a "normal" from Fortran.

Yes.  Note that system services like "simple" string descriptors.
Unlike the LIB$ routines, they don't have an extensive prologue that
can parse all the multitude of descriptors there are.  In particular,
variable length string descriptors will not work.  Fortunately,
Fortran uses good old basic fixed length string descriptors when
passing character values.

However, $QIO[W] wants its buffers passed by reference with the length
passed separately.  So you need to go with %REF rather than defaulting
to %DESR when passing buffers declared as character.

>  Scalar
> arguments, especially input arguments like
> falgs or bit masks, are almost alaways passed
> by value, so need a %VAL(...) in the Fortran
> call.  Finally, arguments passed by reference,
> or described as "the address of...", also need
> no special treatment in the call from Fortran.

Agreed.

Note that the ASTPRM parameter is a bit special.  It's not
particularly well documented until you realize that the type of the
parameter is irrelevant as long as you treat it the same way in the
AST routine's formal parameter list as you treat it in the actual
parameter list in the call to $QIO[W].  My practice was always to
allocate a data structure for the $QIOW call containing the IOSB and
whatever other information I wanted and then pass its address as the
ASTPRM. i.e. %REF(this_call_data)

> Setting up structures (item lists) can be a little
> different: if a item is described as the "the
> address of a word to receive...", or similar,
> you'll need a %REF on the right side of the
> assignment, IIRC.

%REF is specifically for subroutine and function calls.  It even works
for computed values or literals iirc.

    e.g. call my_sub ( %ref(2+2), %ref('foobar') )

%LOC is what you use to populate item lists with address values.  As I
recall, the compiler doesn't let you get away with using it on
expressions or literals.  The compiler is good about noticing that an
item has been used with %LOC and will automatically treat the object
as volatile.  [So if $GETJPI fills in your jobname buffer
asynchronously, your mainline code will look for the update in memory
rather than optimizing the reference away].

   e.g. jpi_itemlist(2) = %loc(jobname_buf)