xenic wrote:
How did the last GetEnv get a value of 9999 unless that value had been copied to ENV: during the boot process??
I changed the value of MYVAR in ENVARC: with "echo >ENVARC:MYVAR 1111" and confirmed that value with "type ENVARC:MYVAR".
The last "GetEnv" had to get the value "9999" from somewhere and I'm saying that it got the value in ENV: that was copied there during
the reboot.
The way ENV: works is like this ...
When a variable is accessed via the ENV: device, and it is not already there, the corresponding path to the file is locked in ENVARC:
and the copy of the variable is created in ENV: if it actually exists in ENVARC:
The reason your test did what you observed, is because something in the startup-sequence scanned that particular
directory level, this causes a directory preload, because just returning an empty directory would be somewhat sub-optimal.
Here's some of my comments from the env-handler source code, for the ExamineDir() function.....
/*
** We can't scan objects that aren't there yet, so, if this directory has not been preloaded before,
** we have to do it before we itterate the list of possible objects. cjw.
*/
If you broke the startup-sequence at the boot cli and did the same test, it would likely work as you expect,
providing some RTF_AFTERDOS module doesn't also do an ENV: directory scan.