Msg: 6628 *Conference*

06-27-96 17:41:29

From: RON WIESEN

To : ALL

Subj: RAMPAC DIAGNOSTIC IS HERE

The Rampac Diagnostic, RD, is in the Upload area of this BBS. It has something
to offer for everybody - even folks who don't own a Rampac can RUN it for video
game amusement. There's a lot of BASIC code in RD you can "lift" and use for
general purposes in your own programs. Also RD uses a lot of "tricks" that you
can use in your own programs - do you use BASICs "free file buffer" (#0) that
always (even where MAXFILES=0) exists?
 
RD is a good aid to Rampac file recovery. It doesn't "fix" anything but it'll
diagnose any kind of "trouble". A printer is recommended, but RD diverts stuff
to the screen if no printer is attached or if the printer becomes unready. RD
is easy to use, has on-screen graphics, and an extensive Help system.
 
The MERGE files RD1OF2.DO (9,928-byte) and RD2OF2.DO (9,217-byte) make up RD.BA
(16,051-byte) which is a large BASIC program file. With at least 25,650 bytes
of memory free in the laptop, you build RD.BA and save it as follows.
 
* Put only RD1OF2.DO into memory
* Use BASIC statements:
  NEW
  MERGE"RD1OF2
  KILL"RD1OF2.DO
* Put RD2OF2.DO into memory
* Use BASIC statements:
  MERGE"RD2OF2
  KILL"RD2OF2.DO
  SAVE"RD
* Copy RD.BA someplace safe such as to diskette
 
Documentation file RD-DOC.DO (21,230-byte) is provided but not needed because
RD is made under the assumption that you will not have any documentation the
day you discover "trouble" with your Rampac. RD is made under another
assumption - due to stress: you'll probably attempt file recovery before using
RD, so when you do use RD you'll need its Help system. But if you have the
documentation on hand then you're likely to calm down, use RD to plan file
recovery, and use RD afterwards to confirm file recovery.
 
Periodic use of RD is recommended. Nuances of RAM100.CO, NPL.CO, N-DKTR.BA, and
various database uses of a Rampac can leave a Rampac in less than perfect
health. For example, I mistakenly attached a Rampac that had content organized
as files (wrong Rampac) and used a database application which assumes an
entirely different organization of Rampac content. By the time I realized my
mistake the Rampac content was altered. Then using RAM100.CO the extent of file
"loss" was noted and I used N-DKTR.BA to recover the file content. But
N-DKTR.BA doesn't set sectors "free" in quite the same way that RAM100.CO
considers them free where it reports total free volume. This nuance went
unnoticed for months. It just seemed that the Rampac was becoming "filled" at a
faster than normal rate. So I used RD and it showed many "reserved" sectors
which in fact were wasted volume to RAM100.CO. It was easy to "touch-up" the
Rampac directory so that these sectors became "free" and then RAM100.CO
reported more free volume.
 
RD is also fun to watch. Periodically use the F1 command of RD and sit back and
watch RD graphically trace the sector-to-sector linkage of each file. Over time
you can literally "see" progressively more bizarre patterns of fragmentation
that result from "updated" files. It's fun!