Wrong value returned by SYS$FAO

[John Travell]

What am I missing ?
I am trying to print out a list of all of the process PID's in the system, using BASIC.
The problem is that SYS$FAO is returning the ADDRESS of the variable, not the CONTENT. (see the source code in the attachment)

Environment: OpenVMS V7.3-1, Basic 1.5.

In sys$library:basic$starlet.tlb the sys$fao function specifies the p1 parameter as "ANY BY REF", whereas the system service reference manual suggests that it should be by value.

If I comment out my 'include STARLET from basic$starlet' and include specific function definitions for the system service calls I am making, I get compilation errors at the sys$getjpi call. If I leave the code as is, sys$fao prints out the 32bit p1 space address of the variable proc_pid.

I have verified both in SDA and the debugger that proc_pid does contain the correct PID value for the last process examined, and that the value returned by sys$fao is the address of proc_pid.

fwiw, switching to using lib$getsyi does not appear to be an option as this code is a small subset of what I am doing, with several other items in the item list array.

Again, what am I missing ? I cannot find any patches obviously relevant to this problem.

[Ian Miller.]

John,
in this line
fao_stat = sys$fao (faoctl$,,faoout$,proc_pid)

is proc_pid being passed by reference when it should be passed by value? I don't really do VMS BASIC so I'm guessing.

[John Travell]

Ian, That is precisely the issue.
I did say : "In sys$library:basic$starlet.tlb the sys$fao function specifies the p1 parameter as 'ANY BY REF', whereas the system service reference manual suggests that it should be by value."
I think this is the problem, I think there is an error in sys$library:basic$starlet.tlb, but I cannot believe that I am the only one to trip over this, so the question is essentially:
Should the SYS$FAO function in basic$starlet.tlb specify
EXTERNAL LONG FUNCTION SYS$FAO &
( &
STRING BY DESC, &
WORD BY REF, &
STRING BY DESC, &
ANY BY REF &
)
or should it be:
EXTERNAL LONG FUNCTION SYS$FAO &
( &
STRING BY DESC, &
WORD BY REF, &
STRING BY DESC, &
ANY BY VALUE &
)
So, if this is an error in the text library it is not going to get fixed now.
How do I work around this issue, so that even though the library is (believed to be) wrong I still get the correct answers in my program.
Patching the library is NOT an option.
Can anyone who know BASIC well please advise me. Have I got an error in my fao call ?
is there some obscure syntax where I can tell BASIC to pass the value instead of the reference ?
If the answer it to remove the
%include "starlet" %from %library "sys$library:basic$starlet"
and uncomment the
EXTERAL LONG FUNCTION SYS$...
lines, then how do I fix the subscript error in the sys$getjpi call...
JT:

[Robert_Boyd]

Have you tried using LIB$SYS_FAO or LIB$SYS_FAOL to see what happens with the description of that set of routines?

Robert

[Hein van den Heuvel · Accepted solution]

Just some ramblings!

There are no pointer variables in BASIC, so there is no easy derefence in BASIC, like a C * construct. You can 'cheat' with a little subroutine, but that's not worth the efforts.

In this particular case you HAPPEN to be able to call SYS$FAOL instead of SYS$FAO and be done with it.

You might prefer the parameter list option in general.

I agree with you that it seems too big a bug to be, but it might just have gone unnoticed untill now. And I further agree that it is not reasonable to expect the library defintion to change overnight.

BASICally... (sic) too many basic programmers do not bother with the proper declares and jsut use 'external long function sys$fao' and spell it all out on the call.

Or they use the easier LIB$FAO... calls.

And BASIC programmers just use BASIC PRINT USING to format their data... they don't need no stinking system services.

And SYS$FAO is a pain in the rear for basic programmers, due to the by value aspect. They need to watch out using LOC on dynamic versus static strings. The one returns the address of the descriptor, the other the address of the data pointed to by the descriptor.


Hope this helps some,

Hein.

[Duncan Morris]

From a very old (V1.1) BASIC starlet definition...

EXTERNAL LONG FUNCTION SYS$FAO &
( &
STRING BY DESC, &
WORD BY REF, &
STRING BY DESC, &
LONG BY VALUE &
)

so, it looks as though the definition was changed sometime between that (1994) version and your V1.5 version. Cannot lay my hands on an intervening version just now.

[John Travell]

Thanks, it works correctly with SYS$FAOL.
Perhaps someone can check if it is still an issue in Basic V1.6, if so a word in the ear of whoever maintains BASIC might help.
If I am the first person to find this bug it cannot be a big enough issue for a formal escalation, even if I had a contract!

[John Travell]

Closed after points added....

[Hein van den Heuvel]

I'll poke someone who knows someone who knows basic from the engineering perspective.

Hein.

[Robert Brooks_1]

John wrote . . .

In sys$library:basic$starlet.tlb the sys$fao function specifies the p1 parameter as "ANY BY REF", whereas the system service reference manual suggests that it should be by value.

----

In the SDL source ([STARLET]STARLET.SDL)for system service definitions, there is this
entry . . .

{ Backward compatible definition of service for basic
iflanguage bas basic
ENTRY SYS$FAO ALIAS $FAO PARAMETER (
CHARACTER DESCRIPTOR NAMED CTRSTR IN TYPENAME CHAR_STRING,
WORD UNSIGNED NAMED OUTLEN OUT DEFAULT 0 TYPENAME WORD_UNSIGNED,
CHARACTER DESCRIPTOR NAMED OUTBUF OUT TYPENAME CHAR_STRING,
ANY NAMED P1 IN TYPENAME VARYING_ARG
) RETURNS LONGWORD TYPENAME COND_VALUE;
end_iflanguage bas basic;

I'm not sure how the above will format, but the important part is that there is the absence of the "VALUE" keyword for the definition of the last parameter.

Oddly, this definition was purportedly "fixed" back in 1996 to be compatible with the definition for SYS$FAOL.

-- Rob