Tim...
> TH: TH>Just what are you try'n to do?
> TH:
> TH: MH>Trying to read in nodelist.*
> TH:
> TH: ???
> TH:
> TH: How do you *read-in* a node list? Nodes are the stuff heaps are
> TH: made
> TH: of. Are you reading a file and creating a linked list? This file
> TH: "nodelist"... what's in it?
He'll have to answer for himself, but likely as in FidoNet - NodeList... You
know as in Zone, Net, Node and all that data. At current size of, what is
it, a couple megs in raw form? The older programs make use of it via indexes
of keys, which are binary techniques from disk files. At least my old Opie
does. Programs which prepare these key files, may do the work up in segments
of multiple open files, such as QNODE seems to do, using segments of memory
such as you suggested; upper memory at that...
An observer's hunch here is that he wants to creat a class of Nodelist, whose
members are the various elements or fields of each record entry, so that
other parts of his program may 'inherit the Whole Earth FidoNet' ...
or .... worse..... :)
I considered that sort of technique in an attempt to cross-reference any
amateur radio operators QTH on earth, to the nearest FidoNet node. I wimped
out and used Btrieve to generate the index of some 1,750,000 records and
fifty odd keys needed in my professional system instead. The project was
done to test the use of FidoNet as an emergency communications system in time
of disaster, relative to the United States ham radio Field Day contest
several years ago. I simply merged in the FidoNet NodeList to the whole
Amatuer Radio Callbook data into one huge and more complex NodeList!
1,750,000 + 36,000 nodes was trivial... Incidentally, my P-133 and fast wide
SCSI box took over THREE DAYS non-stop to create the required system in
BTRIEVE 6.15.2 with all the keys... grin...
Now all in memory prior to the disk write... WOW! .... :)
Incidentally, the excercise was HIGHLY successful! Fido - CAN - do that!
Now that I have started work in C++ I can see real ways to use the class
concept to do things I never could have done.. (easily?) in the Basic PD7
arena... but talk about a huge memory model, about 3/4 gig.... phew!
I think I'll expand the thread, perhaps, anticipating what he may find for
other considerations in his vison quest...
I still am having a great deal of trouble handling huge arrays of variable
length strings that "lowly" PD7 with it's municipal memory trash truck easily
did - including, dimensioning them for negative to positive elements. That
let me swap array planes easily in memory for two threads of the needed work
and never worry about the PD7 auto-destructive trash can...
Now in C++ ...
This data will self-destruct in 6 minutes, James....
"But Sir, I'm in C++ mode! at this end!",
as the computer goes up in smoke from the forgotten Byte From Hell!
I keep thinking dit dit dit dah, dah, dah, dah; dit dit dit dah, dah, dah,
dah, every time I go back to the workbench at this... grin...
In C++, try DIM A$(-100 to +100) for variable length strings where the
elements of the array change constantly in the application and six networked
clients (or more) need access to the open file that holds the constantly
changing record of this information at the same time as binary file
operations with full record lock and so on. See how fast you can do that job
from scratch in C++ vs. PD7.... You can code a whole system for that work in
a few afternoons in PD7 friend, right out of the box!
Yeah.. I can envision a *LOT* of things one could do with the NodeList in
memory in C++ that I think he may be thinking about ... :)
I can also envision his frustration at C++ as well - from personal experience
- as I'm still fighting to get to be at the head of my class... :)
Mike @ 117/3001
--- Opus-CBCS 1.73a
---------------
* Origin: Ziplog Public Port (1:117/3001.0)
|