PE> OK, I'll attach the new PDCOMM as soon as it's written.  If you can 
PE> get the com*test program to work, then you should have immediate 
PE> access to the other programs I have written.

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

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

MS> 1.  I'm not quite sure how to handle errors.  The Amiga crashes
MS> severely (requiring a COLD boot) if pdcommInit() fails & I then go
MS> on to access the serial device.  I wanted to modify comtest.c to
MS> bail out if there is an error in initialization, but I can't see how
MS> to do that, since the error functions aren't available there.
MS> Should I put if(ALLOK) in all my functions?

After calling pdcommInit(), yes, you should do an if (ALLOK) { ... }

I didn't bother with that for the test program.

Hmmm, I didn't do it in RSEND either.  Nevermind, it's meant to actually work!

MS> 2.  I don't know how to do the DTR stuff on the Amiga.  I can query
MS> the state of this line, but I can't see how to set it.  It seems
MS> that DTR is on when the serial device is open & is off when the
MS> device is closed.  ATM, my DTR functions do nothing.

That's fine.

MS> 3.  The Amiga serial device has some features which are not
MS> addressed by PDCOMM.  When the device is opening, you can select
MS> whether to use 3-wire or 7-wire hanshaking, and whether you want to
MS> open the device in shared mode.  While it's open you can
MS> enable/disable XON/XOFF, parity (on/off, odd/even, mark/space), high
MS> speed operation.

parity is covered in the SetParms() call.  Just use the normal CTS/RTS for
handshaking.  Potentially the name you give to pdcommInit() could be
enhanced to accept "SER:2400,3-wire,shared" etc.  I wouldn't
bother with that unless you need it though.

MS> The Amiga serial device supports reading & writing of nul-terminated
MS> strings by specifying a buffer length of -1.  This is complicated by

That is not supported by pdcomm.  Anyone who wants to use pdcomm will need
to do a strlen() themselves.  RSEND does not use this -1 feature so there's
no problem there.

MS> the fact that you use an unsigned type to pass the length.  Also, it
MS> is possible to use the serial device in EOF mode, where you specify
MS> an array of 8 possible chars to use as the end of file mark.

No need for this in pdcomm.

MS> 4.  My other comms programs have used asynchronous IO, so they
MS> basically just sit in a loop waiting for a message from either the
MS> console, the serial port or the timer.  I suppose that this sort of
MS> behaviour isn't possible for the DOS version.

That's right.  You have to change your programming style to make it
event-driven.  PDCOMM is not designed for that, it's designed to get my
old-style-programming programs ported on all my environments easily.

PE> Ok, we'll debug this one first.  READING one of MY messages, where 
PE> you confirmed (via hexdump) that the .msg is correct.

MS>> it prints: Good date = 01 Jan 96 15:25:48.

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 my
MS> time functions VERY thoroughly - would you like to see the test
MS> program?

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

MS> I don't think it's mktime() at fault - MsgEd displays the correct
MS> date when I'm entering a new message, but it screws it up after the
MS> message is saved.

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

PE> Also, are you using a decent strtok()?

MS> I think so...  I'm using the one you gave me.  :)

The only thing guaranteed about that one is that if you find a bug in it
that means it is not conforming to ISO/IEC 9899:1990, I will fix it.

PE> Because the next thing I want to know is what is happening in
PE> parsedate() in date.c.  Can you put in some debug info to find
PE> out what the value of tm_year and tm_mon are, just before
PE> mktime() is called?  Oh, and the input string, too.

MS> Ok.  With unedited messages, parsedate() appears to get the proper
MS> date & parses it correctly.  I just checked all the messages in
MS> Heartbeat.  I'll test it further with the next packet.

But STILL ends up getting it wrong when it comes to call mtime(), right? 
In which case, can you put in some debugging code to print out, in your
mktime() function, a %ld of the time_t value that you created.  Then in
mtime(), print out what the value being passed in is.  (ie the value of
"now").  I want to know if it's the same value.  If it's not,
then it's probably a wild pointer somewhere, will be interesting to track
that one down.

PE> BTW, can you wait until we've debugged this BEFORE starting to
PE> experiment with MSGAPI3X.ZIP.

MS> Good idea!

If it's one thing I hate, it's an unsolved mystery.  BFN.  Paul. 
@EOT:

---