Hello Bob!

Oct 16 17:37 03, Bob Jones wrote to Bo Simonsen:

 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.

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

OH It's only ~ 2 lines on a monitor.. I can do that on a minute I guess.
Does it mean anything that you aren't using a standalized system for typing
(like with all 10 fingers?).

 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.

 BJ> Byte stuffing?  What is performing the byte stuffing?  The telnet 
 BJ> client the user is using?  If so, that is where the problem is.  Yes, 
 BJ> packet sizes have to be stuffed to meet a minimum packet link for 
 BJ> sending over the TCP/IP connection, but that should be transparently 
 BJ> deleted before the application (Maximus) sees the stream.....  I'm 
 BJ> not understanding where the source of the double chracters is comming 
 BJ> from.  

The telnet client is doing it, like my these.. 

 BJ> Now it might be a pointer issue within Maximus on how the code 
 BJ> is handling end of buffer reading.  It may be that Max is double 
 BJ> processing the last character in the buffer due to the way I/O works. 
 BJ>  I've seen this type of problem before with C code trying to handle 
 BJ> reading from a terminal and checking to see if there is any more 
 BJ> characters waiting to be read.  If this is the error, then that would 
 BJ> explain timing issues, CRC errors, upload failures, etc.  Downloads 
 BJ> might work, but protocols that try to ACK/NAK will probably fail.  
 BJ> Hmmmmm.....  This may be the issue....  I'll have to think about this 
 BJ> and then dig into the code over the weekend.

That's absolutety the issue.. 

 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.

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

The client is doing binary, but I the "server" does.. (Maximus)..

Regards,
Bo

--- Msged/LNX 6.1.2 (Linux/2.4.18-586tsc (i586))