NOS 1.8d again

[Murray_RJ@cc.curtin.edu.au]

   My local AA4RE BBS which sends me mail each night wouldn't work with NOS
1.8d after I installed it two days ago. I wasn't running jumpstart on, since
I wanted to work up to it slowly! Anyway, it seems that the problem was caused
by the change in ax25mail.c, in which the first line (sent to kick the mbox
into action) wasn't being swallowed as before, but NOS tried to parse it. This
sent the whole session out of sync and the BBS spat the dummy and disconnected.

   Rather than simply re-enable the first-line-swallowing in ax25mail.c, I
made it depend on the state of Mbjumpstart: if jumpstart is on, then the line
isn't swallowed. If it's off, then the line which the user enters to kick
the whole thing off is swallowed and never parsed by the mbox. I believe this
is the way it should be; does anybody have any ideas on this?

   I think the jumpstart idea is the way to go in the long run, but I'd like
to retain the original method just in case it upsets something.

   The other major problem concerns the duplicate bulletins I mentioned
yesterday. It seems that the \spool\history file on the machine in question
managed to get a couple of hex 1a characters here and there, after the newline
sequence. When NOS tries to read this it sees the 1a as an end of file, and
stops looking. (This behaviour of fgets() in text mode doesn't seem to be
documented in the BC++ v2.0 manuals [at least I couldn't find it], but that's
the way it works).

   Of more concern is the question of how these 1a characters got there. I must
admit that I even suspected BC++ itself for a while (or at least its libraries),

but the consequences of this don't bear thinking about! Fortunately we
managed to duplicate the problem on my own machine, except that the extra
character wasn't $1A. We'd supplied a BID of "6789_vk6zzz", but the string
which appeared in the history file was "789_v6789_vk6zzz"! And, yes, the
message file contained the line "Message-Id: <789_v6789_vk6zzz@vk6yco>", so
it seems as if mbx_to() actually parses the string that way.

   This is as far as I've got with it for now. The trouble is that it seems to
be intermittent, so the only approach I can think of for now is to stare at
the code and wait for inspiration. I'll keep looking.

   One last thing. It seems as if all commands to NOS (from the net> prompt)
have to be in lower case: upper case gets rejected. I seem to recall that it
wasn't always this way, but approaching senility seems to be causing memory
faults these days. Is there any good reason why only lower case should be
accepted?

 .....Ron

                                 ***
 Ron Murray (vk6zjm)
 Internet: Murray_RJ@cc.curtin.edu.au
     Are we having fun yet?    -- Garfield