Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong value returned by SYS$FAO

SOLVED
Go to solution
John Travell
Valued Contributor

Wrong value returned by SYS$FAO

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.
13 REPLIES
Ian Miller.
Honored Contributor

Re: Wrong value returned by SYS$FAO

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.
____________________
Purely Personal Opinion
John Travell
Valued Contributor

Re: Wrong value returned by SYS$FAO

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

Re: Wrong value returned by SYS$FAO

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

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Hein van den Heuvel
Honored Contributor
Solution

Re: Wrong value returned by SYS$FAO

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

Re: Wrong value returned by SYS$FAO

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

Re: Wrong value returned by SYS$FAO

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

Re: Wrong value returned by SYS$FAO

Closed after points added....
Hein van den Heuvel
Honored Contributor

Re: Wrong value returned by SYS$FAO

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

Hein.

Robert Brooks_1
Honored Contributor

Re: Wrong value returned by SYS$FAO

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
John Gillings
Honored Contributor

Re: Wrong value returned by SYS$FAO

Additional 2c...

The parameters to $FAO[L] are actually polymorphic. The type and mechanism depend on the corresponding directive in the control string. So there's no universally correct definition in any language for all possible combinations of directives and actual parameters. "ANY BY REF" is general enough to prevent most compilers from complaining, but you'll often need to override the mechanism with the language specific syntax, depending on the exact directive you're using.
A crucible of informative mistakes
John Travell
Valued Contributor

Re: Wrong value returned by SYS$FAO

Noted, but the problem is that BASIC does not appear to offer the programmer any control on whether arguments are presented as 'by ref' or 'by value'.
When I tried specifying 'by value' in the service call I got compilation errors because the mode of the argument did not match the entry in the function.
While I feel this should be corrected, I wonder how many people it would affect. Who else but me is still writing code in BASIC...!
Peter Barkas
Regular Advisor

Re: Wrong value returned by SYS$FAO

Yep, still using DEC BASIC ;-)

The V1.6 definition is the same as V1.5.

As was said earlier it is probably quite unusual for a BASIC programmer to use SYS$FAO as PRINT USING and FORMAT$ are normally used for formatting output.

Also this is certainly not the first time that definitions in BASIC$STARLET have been incorrect. This is not a serious problem as HELP system_services $FAO, for example, shows the correct definition and it is not that onerous to type it in.
John Travell
Valued Contributor

Re: Wrong value returned by SYS$FAO

At least I am not alone... :-)

I cannot see how format$ can cut the mustard when it comes to converting a hexadecimal value into an ascii representation of the hex value.
i.e. hex 1F2E3D4C becomes ascii "1F2E3D4C"
Basic converts it to DECIMAL before formatting the numeric value into ascii.

For this task I do not know of anything other than one of the SYS$FAO family of services that has any chance of getting it right.
JT: