PE>>> Well one of the problems was bad dates coming in, and Tobruk changing

 PE>>> them to worse dates!  Now it barfs instead.  I tried looking for the

 PE>>> message you sent me about the origin of the messages with bad dates,

 PE>>> but couldn't find it.  I have sent netmail to the board
that generated

 PE>>> the one that I was looking at. BFN.



 PM>> Shouldn't Tobruk just pass the message through without trying to do

 PM>> something with the dates?



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

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

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



Surely you just need to look at the header information. Why reconstruct it?



 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.



If you're going to stop Tobruk every time you get a bad date you're not
going to get very far!



The C++ error handling I've got is similar to what you use, although it has
the ability to handle multiple messages and, of course, uses an error
object. I also use a warning system (which is just the error system by
another name) which allows me to write out messages without stopping the
run.





Paul



--- GoldED/2 2.42.G1114