PE>>> Echomail gets routed to new destinations, so gets a new net and node

 PE>>> put in there for each message.



 PM>> Ah, I didn't realise that the destination address was used in echo mail.

 PM>> I though it would just pick it up from the packet header. Still, you

 PM>> don't need to fiddle with the date field.



 PE> A packet can have messages in it bound for destinations other than the

 PE> person the packet is being sent to.



Sure, for netmail that's true, but for echomail? Surely who ever is
processing the packet is going to foward echo mail based on the echo tag,
not the address in the message header.



 PE>>> So I noticed!  :-(  I've contacted all the originators of
bad dates in

 PE>>> the packet I was looking at and have kludged around the problem.



 PM>> It doesn't have to be a kludge. Just move the date field from the input

 PM>> record to the output. After the problems I had interpreting date fields,

 PM>> I



 PE> That's the kludge.  BFN.



I'd hardly call it a kludge to move data from the input record to the
output record without converting it back and forward between different
formats.



Anyway, I rewrote dtsplit last night so that it can handle dates that
aren't quite up to scratch. I haven't done extensive tests but it appears
to be working. Basically, this version isn't particularly fussy about
spaces and leading zeros. It will even handle a date such as "1JAN94
1:2:3" correctly.





Paul



--- GoldED/2 2.42.G1114