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