In <007401beb306$3bbd7400$3f32fea9@errol>, on 06/10/99
   at 07:58 AM, Errol <[log in to unmask]> said:

>Greetings All,
>At the office we run an old DOS stock control program on a 486
>Cyrix 66mHz machine with 8meg's ram.
>The lady who punches the data in is so fast that she causes the
>computer to freeze about 3 times a month.

>I suspect that this may have something to do with her filling the
>keyboard buffer ?

Additional info from private message from Errol:
------------------------------------------------
the program (called Ascent) has a main menu which calls individual
and separate modules to perform a particular stock control
function.  Within each module there are also separate functions
available. The core of the program is based very much on d-Base.
I personally feel that the machine is getting "behind itself"
while one module closes down and the next one opens up, while this
is going on my lady is already typing data for the opening module.
-------------------------------------------------

That's about par for the course. Normally DOS programs to not like
"type ahead" inputs. This has nothing to do with the speed of the
typest, but does require that input cease until the program is
ready. What is probably happening is one of two things:

1. some characters are getting eaten by the "closing" module as
part of it's cleanup. 2. the type ahead buffer is overfilling,
leading to loss of some charaters.

In either case, the newly starting module gets an unexpected input
and does not process it gracefully. Very typical. A full buffer
problem would be corrected by a keyboard enhancement program
(expanded buffer).

Since this is a DOS program, i assume it's a bit old, and was
originally written to run on a slower machine. A pentium class
processor would make the code run slightly faster, but not much
since the pentium is optimized for 32 bit code. I understand that
the AMD K6 is a bit better for DOS. If the closing module is
accessing the disk, then you have even more problems. You could
get a smart caching disk controller, with a big cache. A really
fast disk might help too, but again that might not be enough. If
you are using an older (under 1 GB) drive, you could replace it
with a newer drive. That would get the access time down to the 10
mS range, from about 20-30 mS.

jan lambert

If at first you don't succeed, destroy all evidence that you
tried. -----------------------------------------------------------
[log in to unmask]
-----------------------------------------------------------

                Curious about the people moderating your
                   messages? Visit our staff web site:
                     http://nospin.com/pc/staff.html