ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/CPM/ZCPR33/S-Z/ZEX-PPIP.NOT

Text File | 2000-06-30 | 6KB | 135 lines

Note for Howard Goldstein from Rick Charnes regarding problems
with aborting PPIP with ^C entered at the keyboard while inside
ZEX403

Way too late, Nov. 18, 1988

Howard, this is the strangest thing I've ever seen.  I mean the
absolute strangest.

I finally traced down why I wasn't able to get a ^C entered at
the keyboard while in a ZEX file to abort PPIP.  Here it is:
because I run the program PROTECT.COM just previous to PPIP.
WHAT????, you say.  What the hell does that have to do with the
price of tea in China?  I know, I know.  My sentiments exactly.
I still can't figure it out, but it seems to be true.  Have
ZEX403 patched to XSUB OFF (my other settings are:

MSUP ON
PSUP OFF
IPSUP ON
QUIET ON

if they are relevant) and try two tiny ZEX scripts, one
consisting of one line only:

PPIP A*.* BACKUP: /AE      ; (I assume any DIR: is OK)

and the other should be only two lines long:

PROTECT //
PPIP A*.* BACKUP: /AE

That's all.  The PROTECT command can have any parameter; it can
be protecting some file(s) or not, but oddly enough even just
running its help message seems to be enough to get it to do its
weird stuff.

Now run both scripts on some directory where you have a couple of
files beginning with A, and try to abort the PPIP run.  You won't
believe your eyes.  The first script aborts PPIP fine and the
second one doesn't.

It's completely impossible but I have no other explanation.  The
simple running of PROTECT.COM seems to trigger something
somewhere that prevents ZEX from feeding the ^C to PPIP.  Well,
actually I don't know for sure that that's the correct
explanation; I may be assuming something.  I'll say only that the
running of PROTECT.COM seems to keep PPIP from being able to be
aborted while both are in a ZEX file.

And it only happens inside ZEX.  If you run the same two commands
on the command line, or from inside an alias, PPIP aborts fine
after PROTECT.COM is run.  And PROTECT.COM has also to be run
from inside the ZEX file for the abort to fail.  If you run
PROTECT simply from the command line, then run the ZEX file with
nothing in it but PPIP, then PPIP aborts fine!  One last
strangeness: if any (third) command -- even a resident! -- is
issued between PROTECT and PPIP in the ZEX file then PPIP _will_
abort properly.  TOTALLY bizarre!

It reminds me of something I saw in FOGHORN the other day.  I
quote at length from November 1988 FOGHORN, an article entitled
_WordStar 4 Revisited_ by one Steven Wilcox:

       Since reviewing WordStar 4 in the January 1988
       issue of FOGHORN, I feel compelled to do a brief
       follow-up after reading other reviews and comments
       over the past few months.

       I read with interest Robert Highley's instructions
       in the June, 1988 issue of FOGHORN ("Invoking
       Proportionally Spaced Printing with WordStar")
       concerning proportional printing with WS4.

       [My interest in h]is article was prompted by my
       observation of WorStar's inconsistency in
       producing proportionally spaced text; sometimes it
       would work, but other times it would output the
       bizarre right-ragged format described in Robert's
       article.  Significantly, these differences in
       output would show up on exactly the same file from
       one day to the next, and occasionally even during
       the same session.

       I scoured the manual to ensure I was setting the
       dot commands and printer correctly - and I was.

       After a week or two I finally realized that proper
       output occurred after using (now get this!) the
       file utility NSWEEP during a computing session.  I
       didn't necessarily have to use it on the file
       being printed, or even that file's disk.  In fact,
       I didn't have to do anything with NSWEEP; only run
       it, exit from it, then run WordStar.

       This doesn't mean NSWEEP holds magic powers over
       WS [typical computer users' secular rationalism -
       rc], but rather that NSWEEP is probably
       initializing a critical memory location.  Remember
       that both WordStar and NSWEEP occupy or overlap
       the same memory locations while running.  When one
       program ends and the next starts, the latter is
       written over the first in memory.

       If the second program fails to initialize a
       particular byte in memory, it ends up using
       whatever the first program left there.  After
       power-up, this supposed unitialized location in WS
       would contain a zero.  After running NSWEEP, it's
       undoubtedly something else that works.  Programs
       other than NSWEEP may produce that same results,
       but I haven't had the time or interest to explore
       that possibility.

Sounds pretty much like what's going on with me, eh wot?  Except
I have the added ZEX403 factor.

Anyway, you come up with your own explanation.  All I know is it's
the strangest thing I've seen this side of the U.S. public's
political attitudes.

A quick solution, of course, before we (who?) do the dirty and
fun work of finding out exactly what's going on, will be for me
to replace PROTECT.COM with any of the more recent utilities such
as SFA or Carson's FA.  However, I mourn that many of our newer,
DOS-based utilities have dropped the feature that so many of
Conn's classics had of accepting a file list parameter.  That's
why I used PROTECT in the first place.  In the BACKUP.ZEX that I
use all this for I always set some files to "archived" because
for various reasons I don't want PPIP to back them up, and
PROTECT's file list abilities work very well for that.  Now I'll
have to reinvoke FA for each file I want not archived.

Anyway, happy ZEXing...