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

LIB$SET_SYMBOL behaviour

 
Willem Grooters
Honored Contributor

LIB$SET_SYMBOL behaviour

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?
Willem Grooters
OpenVMS Developer & System Manager
10 REPLIES 10
Robert Gezelter
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

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

Re: LIB$SET_SYMBOL behaviour

Hoi Willem,

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

Oswald
Willem Grooters
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

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.
Willem Grooters
OpenVMS Developer & System Manager
Willem Grooters
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

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.
Willem Grooters
OpenVMS Developer & System Manager
Hoff
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

Source code reproducer, please?
John McL
Trusted Contributor

Re: LIB$SET_SYMBOL behaviour

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

Re: LIB$SET_SYMBOL behaviour

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.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

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.
A crucible of informative mistakes
Willem Grooters
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

@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 (?))
Willem Grooters
OpenVMS Developer & System Manager
Hoff
Honored Contributor

Re: LIB$SET_SYMBOL behaviour

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.