On Wednesday 07-31-1996 , SAM EWALT  wrote to ALL about 
' GeoLan '
Hello Sam,
SE> "GeoLan", "GeoRim", "GeoSwitch", and "GeoStax".
SE> 
SE> Am I correct in assuming that this is a Geos
SE> licensee?
I don't think there's any connection. Geoworks doesn't own "Geo" or
"Ensemble". I've seen GeoStar on something, but can't remember
where/what.
Regards
Doug
dfitzpat@axionet.com
Delta, BC, Canada
___
 X KWQ/2 1.2i X
--- Maximus/2 2.01wb
Hi, Charles.
I'm really not at all convinced that this statement was accurate.
CL>> -=> Pearls of Wisdom from Anne Page on 30 Jul 96  20:28:00 <=-
But I liked it a lot! 
CL>> AP> presently has 1896 data records in it.  Each
CL>> AP> record has 13 fields,  ...
CL>>   That's pretty big, OK.
That was *before* I did the changes for the issue I mailed yesterday.
Now I have 1938 records.
CL>>   My problem has had nothing to do with printing.
Okay.
CL>>   I haven't noticed any problems with speed degradation.
I would have been surprised if you had.  When I started printing from
GeoFile the 25 pages of 3-across 30-to-a-page laser labels on my HP4L
the other day, I timed it so I could be more precise in what I was
saying here. All pages were sequenced 3 at a time as "text only fastest
way" and I did a save after each print sequence for security (mine!)
so that, if my imagination is accurate, GEOS could release those 3
pages from RAM when I queued up the next 3 and ordered them to be sent
to the HP4L.  I have no technical knowledge upon which to base my
theory, but my experiences with Reportpack on the old IBM Displaywriter
Textpack IV dedicated word processor (circa 1984) and then with my
PerfectFiler on my Kaypro IV CPM Computer (also circa 1984) gave me
the idea that what is ordered sent to the printer goes into RAM and
stays there with the new order adding to what is already being held
there if no save is done after the first order prints and that
eventually one will run out of available memory and get a lockup.
Applying this theory to GEOS when I first started using GeoFile, I
noticed that after printing a few pages and asking for the next few
GEOS scrolls the database and rewrites the screen before starting
the print and that what then shows in the screen is the first of the
next queued pages. So, not knowing if it had "put back" what it had
already printed, I decided to encourage the process with a save
between queues.  This may or may not be necessary, but I feel more
secure doing it, and my personal comfort zone while doing labels
is important to me. 
Anyway, I timed the output the other day, and here's how it worked
with the 25 pages of labels.  The result, which I have known for
years but never had actually timed except to know intuitively that
the end of the label run took longer than the beginning, was that
it took less than 2 minutes to get the first 3 label sheets in my
hand.  It took almost 8 minutes from the moment I queued the last
3 sheets to the time when I held them in my hand.  So I think the
assembly to print speed is definitely connected to the position of
GEOS in the database when output of a lot of information is being
processed.  Even with my manual saves after each set of 3 pages is
printed, GEOS gets slower and slower the further down the 25 pages
it goes.  It took between an hour and a half and two hours to get all
25 sheets printed, but that's because of my regular manual saves.
Had I just kept asking for 3 more pages or queued up several sets
of 3 at one time, it would have been a shorter time frame, but I
have nightmares about locking up or being thrown out with a KR-09
or KR-07 midway through the printout. Whether that is a valid fear
or not is immaterial.  I have it, so I deal with it by saving.
My actual label has 4 typed lines.  The first line is the "status"
of the copy.  It either has a subscription code number or says
"SAMPLE-______" with the blank being the person's breed of dog
or says "SAMPLE-FORMER SUBSCRIBER", etc.  The second line is name,
the next is street, and the last is city, state, and zip.  Each
of those things is coming from a separate field.  So GEOS is getting
the data from 6 of the fields and, even though I am working with
approximately 750 marked records in a label format layout, GEOS is
still having to move through a 1900+ multi-fielded database to give
me what I want.
CL>>   Just to be sure, I checked my handles settings.
After seeing Terri Ferrier's message, it dawned on me that I never did
get around to asking if you had a bunch of TSR's.  I agree with her
that your problem might be connected to that or the other things she
mentioned.
CL>>   However, the type of error which I have written about occurs when
CL>>   trying to open a GeoFile.  It goes through the motions of opening
CL>>   normally and then hangs up before completely opening.  At that point,
CL>>   I am stuck.
Now that I understand this, I tend more and more to think Terri is
on the right track with her advice to you.  I've been watching for
your reply to her about TSR's but haven't seen anything yet.
                                        Anne Page
 * SLMR 2.1a * The longer you keep your temper the more it will improve.
--- QScan/PCB v1.16b / 01-0075
---------------