I used to work for SIAC on what was then the "Common Message Switch" and
you're quite right.
At the time we had the "FCS", the gold book of "Floor Communication
Standards" and anything that violated the "rules" was thrown out.
At one time I even had a tool that would go back through the log tapes and
pull a specific message so that we could find out whether the input was
bogus (it was, an extra linefeed kept a 2nd txn from being forwarded to the
floor).
Input format checkes are important and you MUST force compliance to input
standards. The more you allow deviations of the input format the more
overhead you throw into a system to compensate for formatting freedom...
and there are limits. Realize that lengthening the code path here is not
usually a good idea for both performance AND stability.
I've had enough experiences going through txns during afterhours processing
where they had to be plucked out so it could be posted manually-- all
because something was wrong with the input format and the processing
program didn't handle that added exception.
If you start handling exceptions you'll never stop.
Most exceptions are *problems*; a wild memory pointer is a *problem*.
(That's why S/390's have a "Problem" state,. right?)
--------------------
John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322
Adsumo ergo raptus sum
MacOS X: Because making Unix user-friendly was easier than debugging
Windows.
IBM Certified: IBM AIX 4.3 System Administration, System Support
http://packrat.tampa.ibmus2.ibm.com/~soupjrc/
Backup: Toby Schmeling {813-356|697}-5233
----- Forwarded by John Campbell/Tampa/IBM on 10/29/2003 09:54 AM -----
Dale Strickler
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
lesoft.com> cc:
Sent by: Linux on Subject: Re: [LINUX-390] Memory
access faults.
390 Port
<[EMAIL PROTECTED]
ST.EDU>
10/29/2003 09:31
AM
Please respond to
Linux on 390 Port
At 09:25 AM 2003_10_29, you wrote:
>I agree completely, but I come from an Assembler background where you HAD
>to sanity check EVERYTHING. The volume of "buffer overflow" issues in C
>programs boggles my mind. Even after I started
>coding in C, I still maintained a similar level of paranoia regarding
>input validation. It's not like it's all that hard to limit the size of
>what you accept, folks!
Lint helps find these things in C very well! (And others you others you
most likely have not thought of... 8-)
>But some languages make it hard to implement certain kinds of checking
>properly. I've seen, for example, Cobol programs fail with 0C7 errors
>because some file field that was supposed to contain
>packed data doesn't. Certain assumptions are made, but occasionally
>things go wrong.
>
>So what SHOULD the application do about something like that? The answer
>goes back to that point I made in an earlier item about data
>integrity. If you don't KNOW what the field is supposed to
>contain, stop everything, report the failure, and let someone fix it. It
>seems inconvenient, but in the long run, often it's the safest course.
This is good *IF* it is not a critical system. If the application is
moving billions of financial transactions around the world and it costs
brokers millions of dollars for every minute of down time just "stop
everything, and let someone fix it" is not a good answer. The application
needs to identify the failure point, establish what is likely good or bad
data and charge ahead. (After leaving a solid trail of bread crumbs for
someone to follow....)
- Dale
