PE>>> Well Tobruk interprets the whole header, and then
reconstructs it.  It

 PE>>> needs to use some of the control information (specifically
the "to"

 PE>>> net and node). It then reconstructs the control block.



 PM>> Surely you just need to look at the header information. Why reconstruct

 PM>> it?



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

 PE> in there for each message.



Ah, I didn't realise that the destination address was used in echo mail. I
though it would just pick it up from the packet header. Still, you don't
need to fiddle with the date field.



 PE>>> The date was being checked and was being flagged as bad,
but I wasn't

 PE>>> checking the return code.  You wouldn't believe how easy it is to

 PE>>> stick in error-handling with PDS0001.  I just whacked in an

 PE>>> "errorSet" into dtsplit, and didn't do any more
work, and processing

 PE>>> dutifully stopped even though I wasn't checking the return code. Of

 PE>>> course, because I wasn't checking the return, processing continued a

 PE>>> bit longer, but as soon as it reached the next ALLOK, it gracefully

 PE>>> terminated, displaying the proper error message.  BFN.



 PM>> If you're going to stop Tobruk every time you get a bad date you're not

 PM>> going to get very far!



 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.



It doesn't have to be a kludge. Just move the date field from the input
record to the output. After the problems I had interpreting date fields, I
decided to write a more more forgiving version of dtsplit.



 PM>> The C++ error handling I've got is similar to what you use, although it

 PM>> has the ability to handle multiple messages and, of course, uses an

 PM>> error object. I also use a warning system (which is just the error

 PM>> system by another name) which allows me to write out messages without

 PM>> stopping the run.



 PE> Are you planning on releasing the code?



The code is part of my packet sorter. When I get around to finishing the
documentation (real soon now!) I'll upload it. If anyone wants it before
then they're welcome to it.



 PE> One potential problem I have at the moment is that if I have

 PE> successfully opened a file, and then a problem occurs whilst

 PE> processing, then I need to close the file.  Now if closing the file

 PE> could cause other errors, then I will have a check for ALLOK.

 PE> However, that is for the OLD problem, I really wanted ALLOK to be

 PE> "yes, everythings OK so far in the close-file processing".  BFN.



You'd have the same problem with my code, although there is a way around
it. I keep track of the number of messages, so you could check to see if
this number has changed during the processing. The problem is if you fill
up the message buffer it won't accept any more messages so this isn't fool
proof.



I have hit this problem in my code. I have a message logging object
(actually, yet another error object by a different name - maybe it's time
to change it's name to something more general) where I accumulated messages
to write out to a log file at the end of the program. I had to make sure
that all errors were displayed and cleared before writing the logged
message as I could have got error from the file functions during its
processing. I still haven't come up with a nice solution.





Paul



--- GoldED/2 2.42.G1114