BJ> The office positions required a typing 
 BJ> (speed) test that I passed (with ease on the first try).  [Only 
 BJ> needed 35 WPM for sub office positions.  I passed the required WPM 
 BJ> for some of the perminate office positions.....]  

 BS> Oh that's not mutch, as a programmer you can do it. :) 
 BS> It's only a half of a line on a normal monitor.

In the US, for typing tests, 35 WPM (words per minute) is defined as 5
characters per word, so that is 175 characters a minute.  If I remember
correct, the test is (usually) 5 minutes, and 35 WPM is about 1/2 page of
type written text when double spaced on standard US letter paper, with
standard margins on a (10? 12? CPI) standard typewritter....  The test was
taken on a PC (in a Word window), but the source of the text for the test
was typed up on a type writer....  And on a test like this, each typing
mistake stubtracts 1 WPM from your gross score for your  (normalized?) score.  It is that adjusted score that you have to
have above 35 WPM in this case....

 BS>>>> The file upload doesn't work at all1

 BJ> Can max not find the file for the upload?  What error message is 
 BJ> generated.  I thought this worked under OS/2 as a read of the file 
 BJ> from a local disk.  I remember there are some upload/download items 
 BJ> that don't work from the local console loggin, but I thought QWK 
 BJ> worked based on file names and location....

 BS> Not problem at that kind, CRC errors and so on.. So 
 BS> data isn't beeing send correctly.

 BS>> It should parse double CR, LF and NULL. Also known as 
 BS>> Byte stuffing if it's what I'm thinking of.

Byte stuffing?  What is performing the byte stuffing?  The telnet client
the user is using?  If so, that is where the problem is.  Yes, packet sizes
have to be stuffed to meet a minimum packet link for sending over the
TCP/IP connection, but that should be transparently deleted before the
application (Maximus) sees the stream.....  I'm not understanding where the
source of the double chracters is comming from.  Now it might be a pointer
issue within Maximus on how the code is handling end of buffer reading.  It
may be that Max is double processing the last character in the buffer due
to the way I/O works.  I've seen this type of problem before with C code
trying to handle reading from a terminal and checking to see if there is
any more characters waiting to be read.  If this is the error, then that
would explain timing issues, CRC errors, upload failures, etc.  Downloads
might work, but protocols that try to ACK/NAK will probably fail. 
Hmmmmm.....  This may be the issue....  I'll have to think about this and
then dig into the code over the weekend.

 BJ> There is a CR/LF issue between VT-100 terminals (i.e. Maximus BBS 
 BJ> users), DOS (OS/2 & Win32 also) based Max systems and Unix / Linux 
 BJ> based max systems, so we are probably thinking the same things 
 BJ> here.....

 BS> I hope so.

If it was a CR/LF error, I would expect ASCII text download issues.  From
your other messagaes concerning the error, I am suspecting character
translations, or the user end (telnet) not being set in an 8 bit clean
mode, or some similar fault.....  What I could use is a modified max that
performs the logging we have talked about.....

Any way.....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01