View previous topic :: View next topic
|
Author |
Message |
Kmr.deepakcs
New User
Joined: 11 Oct 2013 Posts: 37 Location: India
|
|
|
|
HI experts,
All we know soc-7 comes when we do some arithmetic operations on non numeric data or we just move garbage data like spaces or / to comp-3 like that...
Every one faces this abend and i have seen many posts related this issue.
But my question is, can we avoid soc-7 by using preplanned code or approach.
May be checking numeric before any arithmetic operation....
As I know checking by ISNUMERIC FUNCTION in cobol.....
but is there any best way to avoid this abend......
Deepak kumar |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
The S0C7 abend can be avoided by appropriately checking every numeric value before using it in calculations. It is one of the few completely avoidable system errors, if the programmer uses the right techniques. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Validating DISPLAY-NUMERIC data is performed internally (by the compiler) using a "TRT" (Translate and Test) Assembler instruction. However, validating PACKED-DECIMAL data is performed internally by using two "TRT" instructions, one to validate the numeric-portion of the data and the second, to validate the sign-byte (nibble).
One slight idiosyncracy when validating both DISPLAY and PACKED data, is to ensure the sign portion of the data matches the field definition.
If for example, a PACKED field is defined as S9(07) COMP-3, but the sign-nibble is an 'F', then the NUMERIC test will fail, because the "TRT" table built by the compiler expects a valid sign-nibble, other than a neutral 'F'.
Just a heads-up to avoid raising false positives.... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Testing numeric fields for NUMERIC depends on compiler option NUMPROC.
If NUMPROC(PFD) is used, the data should "conform to PICture" for the test to be true.
For NUMPROC(NOPFD) installation option NUMCLS comes in to play. If NUMCLS is ALT, then A through F will be valid for a sign, otherwise conform to PICture.
When testing a PIC X for NUMERIC, only an F in the sign position is valid.
I go for testing all inputs to the system as being valid and let the rest rip.
If there is something which must not fall over, test all the numeric fields at once, rather than intermingle with the business logic, so that the program is still "readable".
There is also Language Environment abend-handling. I fear to mention it, in case happy souls "turn off" all the abends and let programs continue without any thought or planning.
Kmr.deepakcs, you need to do some experiments. It is a lot more difficult to get a S0C7 than you indicate. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
As Robert says, best way to avoid S0C7s is to insure all numeric fields are validated when entering the system. This type of validation should be done up front instead of making all the downstream programs do redundant (and unnecessary) checking. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
If you are reading input from something external (data prep, other system, etc) every field should be validated before trying to use the data.
If you are reading "the master file" (i.e. managed by the application), field validation should Not be done. If an invalid field is ever discovered in a "master file", it should be fixed in the code writing the invalid data. |
|
Back to top |
|
|
Kmr.deepakcs
New User
Joined: 11 Oct 2013 Posts: 37 Location: India
|
|
|
|
@dick
Thanks for reply..
Dick I know we can use isnumeric function in cobol before moving any data....can you suggest any other method of data validation techniques...
Thanks for help...
Deepak kumar |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
can you suggest any other method of data validation techniques |
That depends upon the data. If it is a date, you can validate the month as well as the day of month. The application may impose its own validation rules (such as tax amount must be between X% and Y% of the invoice total). However, data validation -- other than the most general discussion -- is not really a good discussion topic for a forum since data validation is extremely dependent upon the application and hence needs to be discussed within your organization. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
can you suggest any other method of data validation techniques... |
For every field of data there are rules as to what thie field may contain. The number of these is nearly unlimited.
You and your organization need to define the rules for each and every field and then code must be implemented to ensure the content is valid. The is no such thing as a COBOL statement that says "validate". They must all be specifically spec'ed, written and tested |
|
Back to top |
|
|
|