MS>> Ok.  ATM, I accept the default of XON/XOFF.

PE> You can't use XON/XOFF with FTS-6 sessions.

MS> What does that mean?

Devil Dialer and RSEND both use the FTS-6 protocol to do the session
negotiation.  If you remember, you sent a CRC as part of that protocol, and
various other binary numbers.  One of those binary nubmers could be XON or
XOFF.  ie, you can't use them for flow control.

PE>>> BTW, I am suspicious about mktime() or localtime() not working,
PE>>> you didn't write either of those yourself did you?

MS>>> I wrote the mktime() & after it calculates the time_t it uses
MS>>> localtime() to put the struct tm into standard form.  I tested
MS>>> my time functions VERY thoroughly - would you like to see the
MS>>> test program?

If only people would listen to me more often!  This is a great opportunity
for you to say "don't you ever get sick of being right all the
time".  I've got this brilliant response I learnt from Blake's 7.

PE>> No, it was just something to think about whilst debugging.

MS>> I just sent you the test program anyway, as a test of rsend.

PE> Probably would have been more useful sending me mktime() itself,

MS> time_t mktime(struct tm *ptm)

MS> day = 365 * (ptm->tm_year - 70) + ptm->tm_yday;

Here's "the" bug.  yday is ignored in mktime().  It's meant to be
operating on mday and mon.

PE> but anyway, there seemed to be something very odd about the
PE> testing, you seem to be setting "secs" to the number of seconds 
PE> since 1970 or something.

MS> What's wrong with that?

PE> It's really meant to be 0-62 or something.

MS> The struct tm that you pass to mktime() can have any values in its
MS> fields and mktime() is supposed to "normalize" these values, before
MS> converting the time to time_t.  

Whilst it is true that it is allowed to, there is no absolute requirement
for it to do so.  In DOS you won't get over 32767 in an integer anyway.

MS>> mktime says sec=820552612

PE> Well, on the assumption that you are attempting to get the number 
PE> of seconds since 1970, like most implementations use,

MS> Yes.

PE> the above number is indeed 2/1/96.

MS> It is? Where did that come from, I wonder. The messages say 1 Jan
MS> 96.

Maybe one of us was using timezone in there somewhere.

PE> Check that mktime() got called with correct parameters, and then
PE> find out why you got 820552612 instead of something closer to
PE> 849823996.

MS> I'll try, but I'm not sure if I understand what you want me to do.

Check the values of year etc in the tm structure, in your mktime()
function, before you start the conversion.  You know that my message dates
aren't 1/1/96, so see if that is what is being passed to mktime.

MS>> mktime says sec=315904080

PE> I'll assume for now that this is the garbage date of "date 
PE> arrived".

MS> Huh? I turned off "date arrived", remember?

You turned it off from being displayed.  It gets calculated regardless. BFN.  Paul.
@EOT:

---