BS>> I bet if you look in to the storage procedure in 
 BS>> vm_run.c, you might be thinking, "is this right?"

 BJ> Ok.  I'll need to add that file to what I should look at over the 
 BJ> weekend.

 BS> Take a coding weekend :-)

I'm going to try to allocate a few hours to look at the code and see if I
can come up with what's causing the problem.....

 BJ> With the start of the new school year, I have been busier (sp?) than 
 BJ> I expected.  

 BS> So you do actually teach?

No.  I'm working substituting for classified not certified positions within
the school district.  Such items as the (front) office positions, class
room aids (para-educators, instructional aids, student monitors, etc.  The
office positions required a typing (speed) test that I passed (with ease on
the first try).  [Only needed 35 WPM for sub office positions.  I passed
the required WPM for some of the perminate office positions.....]  

 BS>>>> But QWK upload doesn't work well :( 

 BJ>>> Try local console (bin/max -k) mode.  If I 
 BS> remember correctly, this 
 BJ>>> gets around the problem with file transfers and will allow you to 
 BJ>>> test out .QWK format without the file transfer code working.  

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

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

 BS>> Okay, gotta rewrite.. It works _sometimes_ if you're lucky.

 BJ> Save a copy of the upload that works.  And then a copy of a small 
 BJ> upload that doesn't work.  Then use OD to dump out the contence of 
 BJ> each file and verify that both files are what they should be (CRC 
 BJ> wise, etc.).  Once both files are verified as 
 BJ> good, then we know that 
 BJ> the problem is with either the user's program used to upload the 
 BJ> file, the link between the user and the BBS (the TCP/IP path if not 
 BJ> using the local console, direct file read if using the local console 
 BJ> methoid I've mentioned), or with the Maximus BBS code.  I suspect a 
 BJ> number of possible sources of problems.  CR/LF is one.  Non-clean 8 
 BJ> bit data path is another.  Character interpretation - changes by the 
 BJ> user program is another.  

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

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

 BJ> It might be usefull to put a debug log in Maximus to log what the 
 BJ> character stream that Max received was, and then compare that with 
 BJ> what was sent.  Then we can determine if things like ASCII NUL or 
 BJ> ASCII DEL are causing problems, or a CR/LF issue 
 BJ> is there, or if an 7 
 BJ> vs 8 bit TCP/IP path is part of the issue.

 BS> Bingo.

Finally getting towards an agreement on stradegy.....

 BJ> This is just the start of my thoughts on debugging this issue.

 BS> And I follow them.

Good luck.  Let me know the outcome of logging stuff.  We may want to add a
log level of 6 (or what ever the next higher number is) -- or a higher
number -- for sending our debugging stuff to the max log file.  Then we can
control this via the log level in the max control file.....

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01