🚀 go-pugleaf

I saw this all the time when I was using JPI v 1.17 (or was it 1.14?) on
my floppy-only portable system.  It seemed to occur when the disks were
almost full and I was editting a large file.  The editor writes out some
temp files and if it can't, it croaks taking the disk with it.  Not a
very robust design.  Swapping disks is also a definite No No since the
editor leaves files open and with the way DOS works that means when you
swap disks the old disk's FAT is written over the new disk.

On my Big System I have had the JPI editor die and trash the files I was
editting three times (in about a year) though it doesn't trash the whole
harddisk (thank goodness!).  It is obvious when this happens as the
files on the screen are all jumbled up.  If you immediately re-boot
without doing anything else the copies on disk probably won't be trashed
(though any changes are, of course, lost).  I did this the last two
times successfully.  If the files do get trashed (as mine did the first
time when I quit from the editor), run CHKDSK and save the disk area it
finds as files.  These files will have the correct source in them though
it will be all mixed up.  I managed to piece my source back together
from these and what was left in the "real" files.  It happens so
infrequently that I haven't been able to see any pattern as to when it
happens other than the files I was editting were very large.

I only use 2.0 for a couple of programs that can't be compiled with 1.17
so I don't know if it suffers from the same problems.  2.0 won't work on
a floppy-only system; it's just too large.

- Bill Seurer         Programming Support   IBM Rochester, MN
  Prodigy: CNSX71A    Internet: seurer@rchland.vnet.ibm.com