SETSYSTEMVAL acting strange - VMS

[Walker, Chris]

Bill,

CLI symbols and process table logical names are local to a VMS process.  The
subprocess that is spawned by RUN COMMAND inherits these symbols and logical
names from the parent process when it is created.  Any that are created by
SETSYSTEMVAL before the first RUN COMMAND will be available in the
subprocess.

The snag is that Powerhouse economically keeps the subprocess active (IIRC
it's actually running DCL commands from a mailbox command procedure, so it
sits waiting for more input).  So once any screen in the current Powerhouse
session does a RUN COMMAND, SETSYSTEMVAL becomes useless for defining CLI
symbols.  In practice it's never safe to assume that there isn't already a
subprocess, so it's never safe to use SETSYSTEMVAL to create symbols and
process logicals for a subprocess.

I can think of three possible workarounds:

1.  Use job table logical names.  These are available to any process in the
current job (i.e. belonging to the current login).  You may have to increase
the size of users' JTQUOTA if you make extensive use of this.

2. Set CLI symbols using RUN COMMAND, so they are available in your
subprocess:
	LET T-CMD = 'MDS$MILL_NO:==' + T-MILL
	RUN COMMAND T-CMD

3. Make the subprocess kill itself before you execute SETSYSTEMVAL:
	LET T-CMD = 'STOP/ID=0'
	RUN COMMAND T-CMD
(I can't imagine a situation in which this would be necessary, but perhaps
one exists.)

Chris Walker
Tate & Lyle
London


> -----Original Message-----
> From:	Bill.Michael@ipaper.com [SMTP:Bill.Michael@ipaper.com]
> Sent:	Friday, April 30, 1999 3:43 PM
> To:	        -         (052)powerh-l(a)lists.swau.edu
> Subject:	SETSYSTEMVAL acting strange - VMS
> 
> In Quick (7.10G1), I'm attempting to change a symbol, so that the value
> can be
> used in other screens/reports/etc. It seems to be working "sometimes", but
> not
> consistently.
> 
> For example, if MDS$MILL_NO is set to "338" by my login.com, I can call
> the
> following code in the INITIALIZE procedure of a screen;
> 
>    LET T-CMD = "DELETE/SYMBOL/LOCAL MDS$MILL_NO"
>    RUN COMMAND T-CMD REFRESH SCREEN
>    LET T-CMD = "DELETE/SYMBOL/GLOBAL MDS$MILL_NO"
>    RUN COMMAND T-CMD REFRESH SCREEN
>    IF NOT SETSYSTEMVAL("MDS$MILL_NO",T-MILL,SYMBOL)
>      THEN ERROR "*E* Could not set Mill number. Please contact IS."
>    LET T-HOLD-MILL = GETSYSTEMVAL("MDS$MILL_NO",SYMBOL)
>    IF T-HOLD-MILL <> T-MILL
>      THEN ERROR "*E* Could not set Mill number. Please contact IS."
> 
> Let's say T-MILL is 113. I get no errors, and this appears to work fine
> _in_this_screen_ - but calling a com file using "run command", for
> example, and
> showing the symbol in the com file, still shows 338!
> 
> If I compile the screen and say "go", verify that MDS$MILL_NO is indeed
> 113
> within the screen, then exit, here is what I see;
> 
> QUICK session completed.
> 
> > $SHOW SYM MDS$MILL_NO
>   MDS$MILL_NO == "113"
> > E
> [MICHAEL.SOURCE]SHOW SYM MDS$MILL_NO
>   MDS$MILL_NO == "338"
> [MICHAEL.SOURCE]
> 
> Now, I've deleted the symbol at the local and global levels within the
> screen.
> Then I've created it with the value 113. Where does the 338 come from???
> 
> It appears that QUICK is "storing" symbol values somewhere and "restoring"
> them
> - behavior that should NOT occur, since the whole point of SETSYSTEMVAL is
> to
> change such symbols!
> 
> Bill
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> Subscribe: "subscribe powerh-l" in message body to
> majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.