Read Another Child Environment?

[Clay Clear]

I am in the process of beginning, after a long abstinence from
it, to write utilities/doors for the TriBBS BBS software sysops.

The problem is, some of the programs may gravely damage critical
BBS data files, therefore causing the BBS to crash, forcing the
sysop to reinstall it to fix the problem. This problem would
occur *if* the BBS were up and running when the programs are run.
If none of the nodes are up while they run, then it won't be
a problem.

I know that when a node is up, in its own child environment, it places:
TRIBBS=TRUE

So, the question: is there a way for a DOS program to enumerate
the node(s) environment to see if they're up and running? And, is
there a way to detect if the environment even exists BEFORE trying to
read it?

Thanks in advance!


------------------
Clay C. Clear

mailto:[email protected][email protected]</A>

Clay Clear's Software

[Michael Mattias]

In PB-DOS, see ENVIRON$

MCM

[Clay Clear]

Michael,

Yes, that works fine for reading the process's OWN environment.
But, I'm talking about reading OTHER programs' environments from
my programs while the other programs are running. Is there any
way to do this from a PB/DOS program? The TriBBS nodes only set
the TRIBBS=TRUE variable in their OWN, child environment, NOT in
the master, or any other, environment. So, I need to be able to
enumerate OTHER programs' environments.

Thanks.

Regards,


------------------
Clay C. Clear

mailto:[email protected][email protected]</A>

Clay Clear's Software

[Michael Mattias]

I don't understand. MS-DOS only supports one program at time with one environment. SHELLed programs (or programs created as a child process of a DOS program) may have their own environment, but that starts as a copy of the parent environment, and is gone when the child program terminates.

Unless.... do you mean, like, a DOS program in Windows process interrogating the environments of other processes? Sheesh, I wouldn't know where to start to do that.

The problem is, some of the programs may gravely damage critical
BBS data files, therefore causing the BBS to crash, forcing the
sysop to reinstall it to fix the problem

I think you need to look at the system design. Crashes should not damage data files; and even if there is a crash, I would think all you should need to do is recover the data, not reinstall the system.

Of course, programs should't crash to begin with, but for those crashes beyond your control (i.e., someone pulls the power cord), a better system design should be able to handle it. (I know it can be done, because I've done it. And that's how the user certified it: he literally pulled the power cord and insured that all data were recovered).

MCM