Sorry I posted the reply to your next before I posted this one, but,.. 
 
 > TH: Okay. But, why would he want to read the who thing? Setting up 
 > TH: some indexes would be simpler and less overhead. 
 
Maybe even disk access isn't fast enough assumimg cache sizes are even 
respectably limited! 
 
Consider the problem of having a ten position Field Day contest operation 
where-in all ten positions have to have access to not only the NodeList, but 
some 1,750,000 records in yet a bigger list.  The object is to instantly, in 
less than one second, recover all the data associated with two records, the 
one you are attempting to contact in the contest, and the closest FidoNet 
SysOp, geographicly, to that place.  The difference between you getting the 
station you decide to call and someone else is often measured in quarters of 
a second in real-time.   Thus ALL the information, as to previous contacts, 
needed contacts, related sites for FidoNet drop-off of the emergency 
'message' that is produced by the contact; all must be done in real-time. 
 
That means sub-second response hour after hour... 
 
Worse, it has to be done for up to as many as at 23 different workstations on 
the LAN, perhaps all in the same exact second! 
 
Until you've done this job and tried it all, you really don't know what is 
really needed in network response times, either, friend..  All together guys 
and gals (yes gals can be REAL good at this!), hit the  key at the 
same time and see who misses that new one!   NOBODY better have to wait! 
 
Top operations people can produce actual contact records of over 120-150 
complete transactions per hour during peak periods of 30-90 minutes straight. 
 More than one such 'run' can be going on at half a dozen positions in the 
network at once!  I can do that myself on CW at the same time I'm running the 
program - with it doing all the comm port I/O to control the station 
equipment as well.... sending CW part by hand with a paddle keyer, part on 
the keyboard from auto-sent text, talk to someone over my shoulder and spurt 
type log data at the same time in-between it all, as can MANY good operators 
who like contests! 
 
    Plus listen to at least two or three telegraph threads in the 
    background laying up the 'mental que' as to who comes next! 
 
You are correct about the index part, but even the index(s) required are way 
over what one usually thinks about committing to memory. 
 
Incidentally, add to that, an administrative output overlay display for the 
whole site in graphics.  In real-time, the 'war' board world map displays 
each contact, the vectors from the site - world-wide - to the remote contact, 
and also to the nearest FidoNet SysOp.. plus the totals for the crew that 
update each time every position makes a new entry! 
 
The approach was procedural in Basic, however Basic DOES have similar code to 
the class approach in C++, if you approach Basic in what I think is a correct 
manner.  Most folks don't, I think.  More important, it is obvious to me, 
even as a woefully immature and fledgling C++ aspirant, that the OO aspects 
of C++ are going to be the only way to meld the horribly complex work that 
was done before, into a graphically oriented adaptation of it, regardless of 
how much memory...   groan ...  it may take. 
 
The real purpose of this is even more subtle.  The tools, required here, are 
exactly the tools needed to manage a full disaster relief communications 
operation, when merged into full double-entry inventory accounting and a 
complete double entry financial statement for the operation at the same time, 
which we can do.  Ask any Army Reserve guy what the problem is in disaster 
relief. What of the water, fuel, money, suplies and then where can you route 
and handle the messages and accounting so you can go back later and recover 
the shrapnel or the bodies... 
 
From experience, one terminal position can handle, at a maximum, only about 
1200 refugees a DAY in such a system, thus a 23 unit C++ network would be 
reauired to process some 30,000 victims from a hurricane down the road, if 
YOUR town had to take them in over the course of just one day! 
 
After EVERY transaction, we can post a completely balanced income statement 
for the entire operation as well as a full double entry balance sheet, at 
least for the incremental on-line work, minus, of course, certain monthly 
closing details...   grin... 
 
Each of these sub-arena's is, in fact, a perfect venue for class, as set 
forth in C++, brought forward into OO from structured Basic work already done 
and tested for years in clinic and hospital records management venues. 
 
It's just that the whole thing is HUGE as to the work to convert it.. and, 
maybe only worth it as relative to the next step - JAVA - from which the C++ 
experience may be the only way to go... 
 
C++, as I see it, has a LOT to face off to in respect to Client-Server, SQL 
and 24X7 data mining work.  It's nice to say C++, but most of the work hits a 
bump in the code where the 4GL OO RAD tool says... 
 
     User code?              yeah...      User code! 
 
On thread.. on topic; what a delightful memorable experience in C++..  :) 
 
Mike @ 117/3001 
 
 
 
 
--- Opus-CBCS 1.73a
---------------