Msg: 6653 *Conference*

07-03-96 13:57:48

From: RON WIESEN

To : ROBERT BENSON

Subj: REPLY TO MSG #6652 (RAMPAC DIAGNOSTIC IS HERE)

Regarding "shrinking memory problem" I assume you're talking about my MSG#6730,
paragraph saying "Periodic use of RD...." where I noted how a mixed use of
RAM100.CO with NPL.CO and N-DKTR.BA left a Rampac with content such that
RAM100.CO reports less "free" sector capacity than is actually "unused" sector
capacity.  I touched up the Directory (changed "unused" to "free") so that
RAM100.CO then reported the truth.

Regarding "How does RAMPAC allocate sectors" it's simple: the Rampac is just a
piece of hardware -- it don't allocate no stinkin' sectors man. Allocation is a
matter of software.  So different sofware (RAM100.CO, NPL.CO, N-DKTR.BA, God
knows what else) has a different "point of view" where it comes to the content
of a Rampac.  I explain this in RD-DOC.DO, the Rampac Diagnostic documentation
in the (7)Uploads section.

What RAM100.CO, NPL.CO, and N-DKTR.BA have in common is that they "assume"
sector 000 content is a directory with byte-pairs for (itself sector 000 and)
sectors 001 to whatever sector is the last one equipped: 255 in so-called 256K
Rampac, 127 in so-called 128K Rampac, I think there are smaller capacity
Rampacs as well.  RD.BA assumes sector 000 is a directory also, but: it can
detect other sectors that smell like directories and marks them "a" for
alternate directory; it takes a less stringent point of view for the content of
sector 000 so as not to assume that any particular "software" point of view is
a "correct" point of view.

Let me try to explain the "allocation" from two points of view: RAM100.CO and
N-DKTR.BA. They both scrutinize "directory format" as byte 0 and byte 1 of
sector 000 define said format. I know of no difference in their point of view
here. Assuming they find this byte-pair to their liking, they become confident
about the accuracy of the other byte-pairs in sector 000. For these byte-pairs,
the first byte is a "flag" and the second byte is a "link". I explain this in
RD-DOC.DO, TERMINOLOGY, Flag and Link.  You might want to read it over.

Several values of the flag are "allowed" by "software". The value of zero
defines a "free" sector - all "software" takes this point of view.  For the
value of the link: zero means no additional sectors "continue" a file
link-chain IN THE CIRCUMSTANCE WHERE THE PAIRED FLAG VALUE DEFINES SOMETHING
OTHER THAN "FREE"; and non-zero is the sector number of the "next" sector to
"continue" a file link-chain IN THE CIRCUMSTANCE WHERE THE PAIRED FLAG VALUE
DEFINES SOMETHING OTHER THAN "FREE".

One instance where RAM100.CO and N-DKTR.BA differ concerns "free" sectors.
Note that N-DKTR.BA can set a sector free as a consequence of "fixing/file
recovery", and RAM100.CO sets a sector free as a consequence of "file kill".
N-DKTR.BA sets a sector free by altering the flag byte (zero) and leaves the
paired link byte intact (non-zero). RAM100.CO considers free those sectors
where both the flag and link bytes (of a pair) are zero.  So a sector that "had
some linkage" before N-DKTR.BA sets it free still "has that linkage" and
unfortunately the RAM100.CO point of view is that the sector is not free and
consequently does not include it in reports about "free" capacity of the
Rampac.

For example, say sector 010 has linkage to sector 009 and N-DKTR.BA sets sector
010 free.  The content of sector 000 (directory) respective byte-pair for
sector 010 is shown below.

 byte 20 contains zero   -   flag byte defines sector 010 as free
 byte 21 contains 009    -   link byte defines sector 010 links to sector 009