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?

Echomail gets routed to new destinations, so gets a new net and node put in
there for each message.

 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!

So I noticed!  :-(  I've contacted all the originators of bad dates in the
packet I was looking at and have kludged around the problem.

 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 error
 PM> object. I also use a warning system (which is just the error system
 PM> by another name) which allows me to write out messages without stopping
 PM> the run.

Are you planning on releasing the code?  One potential problem I have at
the moment is that if I have successfully opened a file, and then a problem
occurs whilst processing, then I need to close the file.  Now if closing
the file could cause other errors, then I will have a check for ALLOK. 
However, that is for the OLD problem, I really wanted ALLOK to be
"yes, everythings OK so far in the close-file processing".  BFN.

Paul

--- GoldED/2 2.42.G1114