This is just to verify what I'm 99% I've just discovered that really surprised me in that things don't work the work the way I had always (as in many years) thought (assumed?) that they did. The issue is this: I had always assumed that "Call" ran a batch file in the same process (i.e., same PID) as the caller; whereas a "@Exec...[BatchFileName] ran the batch file in a completely different (new) process (PID), similar to, but much easier to code than, using the "Start" command to run a batch file in that the "output" and return code ("%?") of the started batch file would be much more readily available (and the "/WAIT" option would be implicit), and it would appear that that thought(/assumption) is totally incorrect. Here's a rough idea of what I was trying to do: BatchFileA calls BatchFileB calls BatchFileC ExecStr's BatchFileD Calls BatchFileE Calls BatchFileF, and if BatchFileF issues a "Cancel" command, that returns control directly back to BatchFileC, rather than terminating the whole "chain" of batch files starting at the very "top" (i.e., BatchFileA). And, as I'm sure you can guess, I wanted a "Cancel" command in BatchFileF to terminate up to but not including BatchFileC, and that seems to be very clearly not the case. (And while I wasn't really trying to do this, I had an implicit assumption that "Exit" would essentially do the same thing in these circumstances and terminate the (assumed to be separate from the TCC instance running BatchFileA) TCC instance in which it was executed rather than terminating the TCC instance in which BatchFileA was run). And while using a "Start" command is certainly doable, managing the "communications" between the "Started" code and the code "Starting" that code is somewhat non-trivial in that the only way that can happen, it would appear to me, is to have the "Started" code write its output (effectively including a return code) to a temporary file (@Unique) that is "passed" to it by the code that is "starting" the process (chain of batch files) that would be writing its output to that temporary file, and the "caller" would have to do a "Start /Wait" to run the "called" code, and then read the "output" of the "called" code from the temporary file when the "Started" code terminated. So, multiple questions: Am I correct in this "analysis"? And is there any easier way other than the "Start" command to do what I was trying to accomplish? Admittedly, I could do some "experimentation" to check this out: Was my (previous) assumption that "@Exec..." functions did an implicit "SetLocal" and "EndLocal" on the batch function being Exec'd correct, and that you could therefore not do an "EndLocal VariableName" to pass a "variable" back up to the caller because the caller and the callee had separate and distinct "environments"? And the only basic difference between "Run" and "@Exec..." when executing a batch file is that "Run" can not "read" whatever is written to STDOUT by the executed batch file; the executed batch file must return values to the caller by means of an "EndLocal list-of-variables"? I'd prefer to know this, if possible, before moving on to the task of "rearchitecturing" all of existing my code.