>Write it into a file and read the file created by the child in the parent process when the batch job completes. This lets you "suck down" the result - you read it from a file and then blow it away when you finish.

Oh, Ok, I suspected that, we do it the same way. One problem with writing to a file at login time is that the file could be deleted or altered after the login. OTOH it is easy to implement.

>In the login script, you could create an environment variable using the value rather than writing a file, and then use GETENV() to read the result from Fox rather than look for a file and read it. The problem with using GETENV() to do this by shelling to DOS within an app is that you do not reinherit modifications to the environment made in children spawned by RUN; it takes a significant amount of code to hand off the STDIN of the current process to the STDOUT of the child, have the child write to STDOUT, then read STDIN and modify your environment so that you maintain the correct environment context. A file is lots easier to do; not quite as neat, but infinitely simpler to construct and maintain, at relatively low cost.

Under Novell OS we create an environment variable for the userId in the system login script. Then we use getenv() to get the variable in FPD/FPW/VFP applications. The environment variable is visible from all applications.

Under Novell the userID or MAC address were a kind of system variables, so creating them was simply an assignment statement in login script. In W2K it looks like we need to work harder to get them. It feels strange that now on 100% MS OS it is harder to communicate between the network OS and the station OS.

Under W2K, we are not sure what type of variable to create, but we'll run some tests. We ran the following on a station Novell / XP / VFP6 (can't connect to W2K server yet):

loShell = createobject('wscript.shell')
loEnv = loShell.Environment('system') && OR 'user' or 'volatile' or 'process'
loEnv.item("NEWVAR") = "Some Value"
? getenv("NEWVAR")
loEnv.Remove("NEWVAR")

Getenv() returns an empty string in the VFP session that created NEWVAR, but if we start a new session of FPD/FPW/VFP it returns "Some Value". I guess that is what you expect because the first VFP read the environment when it started? And, if we do it in the the login script then all apps will see the variable?

Sorry for the long post and thank you.