@USER0 being reset to 0 unexpectedly. UV11.4

We use @USER0 for an application-level constant.  We set it in the LOGIN paragraph & it should remain constant.

I've seen it sometimes - but not always  - get set to 0 after/while? I've used/exited(?)/re-entered(?) RAID.  I haven't pinned down what triggers  it.

Ironically, the reassuring thing is that RAID is disgustingly buggy.  I've had problems in RAID that don't happen when real users run things for real.  So it's probably ok in production.  Probably.

Anyone else seen something like this?

Chuck, 

I do not know any situation where RAID could clear out the @USER0 variable. 

Could it be you did an EXECUTE of the program from within the program, and were up a level?

i.e.

> CT BP SETUSER0 GETUSER0 CHECKUP

     SETUSER0
0001 @USER0 = 1

     GETUSER0
0001 PRINT "@USER0 = ":@USER0

     CHECKUP
0001 EXECUTE "GETUSER0"

>SETUSER0
>GETUSER0
@USER0 = 1
>CHECKUP
@USER0 = 0

Note the variable is still set for the main execution level.

>GETUSER0
@USER0 = 1

Thanks, Mike.

If I EXECUTE a program from within a program,  @USER0 is preserved.

Per the documentation, @USER0-4 are all supposedly stacked, therefore not preserved between execution levels , but they do seem to behave non-stacked, i.e.  they remain set.  So maybe that is where the bug is.

(For those listening in, Basic Cmd Ref, Appendix E says "The EXECUTE statement initializes the values of stacked @variables either to 0 or to values reflecting
the new environment. These values are not passed back to the calling environment. The values of nonstacked @variables are shared between the EXECUTE and calling environments. All @variables listed here are stacked unless otherwise indicated.")

@USER0 has always behaved as if non-stacked.  I don't recall ever checking the documentation, at least in recent decades.    But the doc does not say it is non-stacked.

 I've been taking advantage of @USER0 remaining set.  Maybe I shouldn't trust that.

I still don't know why RAID would  matter.   There is an EXECUTE 'SELECT [file]..."  inside the pgm I was RAIDing.  But that SELECT did not involve @USER0.

Furthermore, it is only after I exit RAID  that I've noticed @USER0 sometimes being "0".  That is, \\it messes up at the original execution level.

i'm missing something somewhere.

When I run your SETUSER0, GETUSERO, CHECKUP,  I get the same results as you, Mike.

------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------

Thanks, Mike.

If I EXECUTE a program from within a program,  @USER0 is preserved.

Per the documentation, @USER0-4 are all supposedly stacked, therefore not preserved between execution levels , but they do seem to behave non-stacked, i.e.  they remain set.  So maybe that is where the bug is.

(For those listening in, Basic Cmd Ref, Appendix E says "The EXECUTE statement initializes the values of stacked @variables either to 0 or to values reflecting
the new environment. These values are not passed back to the calling environment. The values of nonstacked @variables are shared between the EXECUTE and calling environments. All @variables listed here are stacked unless otherwise indicated.")

@USER0 has always behaved as if non-stacked.  I don't recall ever checking the documentation, at least in recent decades.    But the doc does not say it is non-stacked.

 I've been taking advantage of @USER0 remaining set.  Maybe I shouldn't trust that.

I still don't know why RAID would  matter.   There is an EXECUTE 'SELECT [file]..."  inside the pgm I was RAIDing.  But that SELECT did not involve @USER0.

Furthermore, it is only after I exit RAID  that I've noticed @USER0 sometimes being "0".  That is, \\it messes up at the original execution level.

I think @USER variables are stored in the environment so they're preserved when any program is run. That means if you run three programs in a proc or paragraph @USER0 will keep any set value between them. It also works that way across program calls or programs run with the PERFORM command.  The EXECUTE command however creates a new environment to run the executed statement so all the @USERx variables are set to 0.

So if you want to pass values to sub-programs using @USERx variables either run them, call them or perform them. Don't use EXECUTE.

This is on Universe. I don't know if the other flavors work this way.