topic Re: LIB$SET_SYMBOL behaviour in Operating System - OpenVMS

LIB$SET_SYMBOL behaviour

Willem Grooters — Fri, 06 Nov 2009 12:48:11 GMT

VMS 8.3-1H1, PASCAL 6.1-116

When a program is about to end, some data is stored in a symbol:

Status := LIB$SET_SYMBOL ("RESTARTKEUZE",Alf,Table);

then the program exits normally.
The existance of the symbol is checked

$ IF F$TYPE(RESTARTKEUZE) .NES. "" THEN GOTO RERUN

This label marks the line:

$ run ThisProgram

After restart, the symbol is fetched to regain the information stored on exit:

Status := LIB$GET_SYMBOL
("RESTARTKEUZE",Alf,AlfLen, Table );

and the symbol is deleted:

Status := LIB$DELETE_SYMBOL ("RESTARTKEUZE", Table)

Running the program interactively, the symbol is indeed set; it can be examined in DCL, and on rerun the data is indeed retrieved.
Running from a commandfile (@procedure)however, the symbol is set (observered outputting status) but the symbol does NOT appear in DCL: F$TYPE (RESTARTKEUZE) returns "" no matter what has been set in the program. SHOW SYMBOL RESTARTKEUZE issues NOSUCHSYM as well. But LIB$SET_SYMBOL finished succesfully.

There is nothing in the docs that mentions this difference. What have I overlooked?

Re: LIB$SET_SYMBOL behaviour

Robert Gezelter — Fri, 06 Nov 2009 12:57:51 GMT

Willem,

Please forgive me for asking what may be obvious, but I would first want to confirm (by the use of SET VERIFY, if necessary) that the RUN command in the command file is not being executed in a sub-process.

- Bob Gezelter, http://www.rlgsc.com

Re: LIB$SET_SYMBOL behaviour

Oswald Knoppers_1 — Fri, 06 Nov 2009 13:04:11 GMT

Hoi Willem,

What type of symbols are you creating (local/global) and does this DCL procedure use a set symbol/scope command?

Oswald

Re: LIB$SET_SYMBOL behaviour

Willem Grooters — Fri, 06 Nov 2009 13:06:44 GMT

I've done 'funny things' with "run" as a symbol, but that's not the case here:

@@2:RKL> sho sym r*
@@2:RKL> sho sym r*
RDML == "$RDML"
RDO == "$RDO"
REC*ALL == "RECALL"
@@2:RKL>

No subproces either. The command procedure test.com is just:
$!
$ define sys$input tt: ! required for program
$loop:
$ run test.exe
$ sho symbol RESTARTKEUZE ! testing: NOSUCHSYM ???
$ if f$type(RESTARTKEUZE) .nes. "" THEN GOTO LOOP
$!
invoked by $ @test.

Executing each command interactively works just fine.

Re: LIB$SET_SYMBOL behaviour

Willem Grooters — Fri, 06 Nov 2009 13:09:42 GMT

Forgot to add in the original posting:

VAR
... Table : INTEGER := LIB$K_CLI_GLOBAL_SYM;

conform the docs. I tried the constant directly but that wasn't accepted by the compiler.

Re: LIB$SET_SYMBOL behaviour

Hoff — Fri, 06 Nov 2009 13:18:13 GMT

Source code reproducer, please?

Re: LIB$SET_SYMBOL behaviour

John McL — Sun, 08 Nov 2009 21:33:24 GMT

Some thoughts...
- Are you using the normal CLI?
- Is 'alf' a character string descriptior?
- Is the descriptor 'alf' longer than 1024 bytes?
- Are you getting SS$_NORMAL for your calls to LIB$SET_SYMBOL and LIB$GET_SYMBOL or have you only tested the low-end bit?
- Does the program have an exit handler that deletes the symbol before control returns to the CLI?
- Is there anything in the executable image that make it run differently when in batch mode compared to interactively?

Re: LIB$SET_SYMBOL behaviour

John Gillings — Sun, 08 Nov 2009 23:51:22 GMT

Willem,
Testing using three MACRO32 programs.

First is SETSYM, takes 2 parameters, symbol and value. Defines a global symbol returning status in $STATUS.

Second GETSYM, takes one parameter, symbol name. Prints result and returns $STATUS.

Third program DELSYM, takes one parameter, symbol name to be deleted.

My test sequence is:

$ SHOW SYMBOL TEST
$ ! Defining symbol with SETSYM
$ SETSYM TEST VALUE
$ ! Status should be good
$ SHOW SYMBOL $STATUS
$ ! Symbol should exist
$ SHOW SYMBOL TEST
$ ! Reading symbol with GETSYM
$ GETSYM TEST
$ ! Status should be good
$ SHOW SYMBOL $STATUS
$ ! Symbol should still exist
$ SHOW SYMBOL TEST
$ ! Deleting symbol with DELSYM
$ DELSYM TEST
$ ! Status should be good
$ SHOW SYMBOL $STATUS
$ ! Looking for symbol, should fail UNDSYM
$ SHOW SYMBOL TEST

Attached procedure will create the programs and run the test.

Tested on V7.3-2 Alpha and V8.3-1H1 IA64. Both interactive and batch processes behave as expected on both systems.

Please run this test on your system to eliminate the library routines. If it is successful, you'll have to look for bugs in your Pascal code.

Re: LIB$SET_SYMBOL behaviour

John Gillings — Sun, 08 Nov 2009 23:55:10 GMT

Hang on a sec!

$ define sys$input tt: ! required for program
$loop:
$ run test.exe

is the program reading input? Perhaps it's seeing EOF and exiting. This obviously won't work in a batch job.

Add PRINT statements at your LIB$ calls to verify that they're really executing.

Re: LIB$SET_SYMBOL behaviour

Willem Grooters — Mon, 09 Nov 2009 07:07:59 GMT

@JohnML:
"Alf" is a character string of 12 characters; no exit handler; All calls return SS$_NORMAL (checked); the image does not behave differently when run in a command procedure.

JohnG:
The program takes input; but since it's not run in batch, that isn't the problem (it does work normally, it even sets the symbol, but it seemd not to survive image exit: DCL didn't recognize it).

Anyway:

Tried creating reproducer: Just get_symbol, delete_symbol and Set_Symbol with some WRITELN's, but the problem did not re-occur.
Tried creating a reproducer by taking the original sources, struipped all that wasn't needed, and the rpoblem didn't re-occur either.
Took the original program, removed all comments and all external refeernces: similar: Noproblem. Re-enabled external references one by one, and still no problem.

I don't know what caused it, but the problem didn't occur anymore....

(Tried to post the latter part last Friday but it took too long for ITRC to digest (?))

Re: LIB$SET_SYMBOL behaviour

Hoff — Mon, 09 Nov 2009 12:32:48 GMT

What you're describing is usually indicative of a corruption (potentially elsewhere) in the run-time context. These cases are less commonly seen with Pascal applications than with some other languages, but it's possible for these cases to arise in most any non-trivial application. Regardless, I'd look to confirm you're current on your OpenVMS I64 and any Pascal patches and such.