Hi Paul,

On Jan 01 08:01, 1996, Paul Edwards of 3:711/934.9 wrote:

MS>>> I've got comtest working, but I'm have a few problems.

PE>> Great!  I'll attach RSEND + co to you.

MS>> got 'em, thanks, but you didn't need to send the same version of
MS>> PDComm again.  :)

PE> I checked, and I didn't.  I sent you PDCOM100.ZIP once as far as I
PE> can tell.

Ok, but I already had comtest working before you sent me PDCOM100.ZIP
& I can't seem to find another version of PDCOMM in my download
directory... Anyway, it's not important.

MS>> What I meant is "Should I put if(ALLOK) in my pdcommWriteCh() 
MS>> etc".

PE> No.

MS>> I didn't think it was proper to put if(ALLOK) in comtest.c, since
MS>> this requires error.h, which the DOS version doesn't use.

PE> That's due to poor writing of comtest.c.  That's where the fault 
PE> lies and where the fault should be fixed, not in high-performance 
PE> functions. But comtest.c is designed to be used for 10 seconds and 
PE> then thrown away.

Fine.

PE>> Just use the normal CTS/RTS for handshaking.

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

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

What does that mean?

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?

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,

time_t mktime(struct tm *ptm)
{
    long day;
    time_t sec;

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

    /* Leap days since 1-Jan-1970 */
    day += (ptm->tm_year - 69) / 4;

    sec = 86400 * day + 3600 * (ptm->tm_hour + !!daylight) +
        60 * ptm->tm_min + ptm->tm_sec + timezone;

#ifndef SIMPLE_MKTIME
    memcpy(ptm, localtime(&sec), sizeof (struct tm));
#endif

    /* ZZ("mktime says sec=%ld\n", sec); */

    return sec;
}

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.

What's wrong with that?

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

The struct tm that you pass to mktime() can have any values in its
fields and mktime() is supposed to "normalize" these values, before
converting the time to time_t.  My version cheats, because it does
the time_t conversion before normalizing the struct tm.

PE> FREQ "ANSI_C.*" from 3:711/934 if you are interested in the
PE> exact specs for those suite of functions.

I will (eventually).  I used the references from Plauger's Standard
C library.

PE> Or you can get the source code to PDPCLIB which shows you a real
PE> "live" implementation.

PE>> Or reading a message already-saved by Tobruk, ie a message from
PE>> me, right?  The example you showed above was for that situation.

MS>> Yes, all incoming messages appear to have bad dates.

MS>> MsgEd time conversions
MS>> ----------------------

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,

Yes.

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

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

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.

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

MS>> mktime says sec=315904080

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

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

Michael Stapleton of Graphic Bits
@EOT:

--- Msged/AM 4.00