Category : Batch File Utilities - mostly for DOS
Archive   : ABFS.ZIP
Filename : ADVBAT18.TXT

The keys to the whole technique are:

1. Use CALL to Invoke BATCH files (and programs)

2. Programs (Pascal, "C", even BASIC [yeeeeech!]) can WRITE a
BATCH file like "Reply.bat", just as simply as they can
WRITE any other kind of file.

3. If, by CONVENTION, we expect a program to "leave a message"
in a file named "Reply.bat", we can have the CALLing BATCH
file EXECUTE the "Reply" (via call of course!)

Question:

What would have happened in our example if we used COMMAND /C
to invoke GETIT? .... No change, as GETIT does NOT itself mess
with the ENVIRONMENT! The same is true if we had simply
invoked GETIT by the command line GETIT in the batch file, rather
than CALL GETIT.

But:

What would happen if we then COMMAND /C'ed REPLY.BAT?

OOOOOOOOOOPS! Those SET NAME= statements would modify the
environment COPY owned by REPLY.BAT, and it would be discarded
on our return, leaving OUR NAME= and PHONE= values as nulls!

If instead, we invoked REPLY by just using the line ...

REPLY

rather than CALL REPLY, we have ANOTHER type of problem ...
we NEVER COME BACK TO DEMO_3, as we CHAINED batch files rather
than using REPLY as a subroutine!

But, But:

If we combine our knowledge of starting a BATCH file at someplace
other than the top via %0, (the "restart" trick) we can even
handle the CHAIN problem..........

What if the last line of REPLY.BAT was something like:

DEMO_3.4



Now, the chain invocation of REPLY would end up "returning"
to Phase4 of DEMO_3 ... just like a subroutine return via CALL!

This last trick shows that we can even use this exact technique
in DOS 2.x (where CALL does not exist)!

THINK ABOUT IT ... BATCH FILES INVOKE PROGRAMS, BUT PROGRAMS CAN
WRITE BATCH FILES ... AND THE INVOKING BATCH FILE CAN EITHER
CALL OR CHAIN TO A (newly written) BATCH FILE ..... Hmmmmmm