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!