Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ABEND SOC7
- Thread starter gust1480
- Start date
Hi,
It is most of the time an operation or conversion with a numeric field that doesn't contain a numeric value.
It can me an add, compute but also a move from a zoned field that doens't contain the right value to a packed decimal field.
Manuals from IBM can be found at:
What you have to do is to look up the statement where the program abended. One of the numeric fields in that statement should deliver a numeric value but it doens't contain a numeric value.
Regards,
Crox
It is most of the time an operation or conversion with a numeric field that doesn't contain a numeric value.
It can me an add, compute but also a move from a zoned field that doens't contain the right value to a packed decimal field.
Manuals from IBM can be found at:
What you have to do is to look up the statement where the program abended. One of the numeric fields in that statement should deliver a numeric value but it doens't contain a numeric value.
Regards,
Crox
An 0C7 abend means that 1) A packed decimal field had invalid data and was used in a numeric computation or in an elementary MOVE. 2) There were insufficient high order zeroes in operand 1 of an MP (Multiply Packed) instruction; but this won't happen in COBOL as COBOL is aware of this requirement and aways ensures sufficient high order zeroes.
A valid packed decimal field must have a decimal digit in every half-byte (nybble) except the last, which must not be a decimal digit.
A valid packed decimal field must have a decimal digit in every half-byte (nybble) except the last, which must not be a decimal digit.
Since some Cobol compilers pack numbers before performing any mathimatical functions, the field in error does not have to be Packed Decimal (Comp-3). Most any numeric field used to Add, Subtract, Multiply, divide etc. can cause a S0C7 when the value of the field in not numeric due to the fact that the cobol compiler will pack the value before performing the operation.
Items defined as binary may be handled differently. These are numeric fields defined as "COMP".
Look for an un-initialized numeric field or non-numeric data read in from a file.
etom.
Items defined as binary may be handled differently. These are numeric fields defined as "COMP".
Look for an un-initialized numeric field or non-numeric data read in from a file.
etom.
I have to disagree. Binary (or COMP) are not numeric by definition. Everything in a computer is in binary form.
Every character has a binary representation and can be accommodated (even calculated) in binary form.
Binary fields will not give you a 'math' error (SOC7). You can store and retrieve any character using COMP fields. In fact, on many computers native languages, strings are usually defined as arrays of INTEGERs.
The common error with binary fields is overflow - not really a calculation problem, but a size problem.
Dimandja
Every character has a binary representation and can be accommodated (even calculated) in binary form.
Binary fields will not give you a 'math' error (SOC7). You can store and retrieve any character using COMP fields. In fact, on many computers native languages, strings are usually defined as arrays of INTEGERs.
The common error with binary fields is overflow - not really a calculation problem, but a size problem.
Dimandja
Interestingly enough, the 2002 COBOL Standard allows a program to do an IF NUMERIC test on a BINARY field. To *pass* such a test, the value of the field MUST be within the range specified by the PICTURE clause.
This is quite different from the way that MANY existing COBOLs (including IBM - where S0C7's "live"
treat binary fields - when the TRUNC(BIN) option is specified.
Bill Klein
This is quite different from the way that MANY existing COBOLs (including IBM - where S0C7's "live"
treat binary fields - when the TRUNC(BIN) option is specified.Bill Klein
The behaviour of a program using comp, binary, comp-4 or comp-5 fields is that it has never any problem with any value so in fact working with any value with these definitions will never cause a S0C7 so in a practical way, JSPJSD is right. Oh yeah, TRUNC(BIN) or worse TRUNC(STD) should never be on. IBM advises you to use TRUNC(OPT). BIN or worse STD will give a bad performance and it is not compatible with for example message lengths in IMS DC environment. If you realy want to use a binary field, define COMP-5. That is the better definition.
Regards,
Crox
Regards,
Crox
Actually, IBM documents that TRUNC(STD) is BETTER than TRUNC(BIN) as far as performance goes. According to the Enterprise COBOL "Performance Guide"
"Performance considerations using TRUNC:
- On the average, TRUNC(OPT) was 24% faster than TRUNC(BIN), with a range of 88% faster to equivalent.
- On the average, TRUNC(STD) was 15% faster than TRUNC(BIN), with a range of 78% faster to equivalent.
- On the average, TRUNC(OPT) was 6% faster than TRUNC(STD), with a range of 65% faster to equivalent."
For more details on TRUNC and Performance (along with other performance issues) see:
Bill Klein
"Performance considerations using TRUNC:
- On the average, TRUNC(OPT) was 24% faster than TRUNC(BIN), with a range of 88% faster to equivalent.
- On the average, TRUNC(STD) was 15% faster than TRUNC(BIN), with a range of 78% faster to equivalent.
- On the average, TRUNC(OPT) was 6% faster than TRUNC(STD), with a range of 65% faster to equivalent."
For more details on TRUNC and Performance (along with other performance issues) see:
Bill Klein
In some release letter was documented that TRUNC(BIN) was much improved so that it's performance is much more near TRUNC(OPT). The guide is perhaps a little bit old.
The best prove of course is to test it. We did this last year when we had the last compiler update and TRUNC(OPT) was the fastest; TRUNC(BIN) was near and TRUNC(STD) was bad.
The method to cut digits seems to be to convert to packed-decimal, cut off the extra digits, convert it back so it is very logical that it does not perform good at all.
Regards,
Crox
The best prove of course is to test it. We did this last year when we had the last compiler update and TRUNC(OPT) was the fastest; TRUNC(BIN) was near and TRUNC(STD) was bad.
The method to cut digits seems to be to convert to packed-decimal, cut off the extra digits, convert it back so it is very logical that it does not perform good at all.
Regards,
Crox
From the Enterprise COBOL V3R2 manual (and this is the MOST recent manual - AFTER the TRUNC(BIN) improvements),
"Both TRUNC(BIN) and TRUNC(STD) generate extra code whenever a BINARY data item is changed. TRUNC(BIN) is usually the slowest of these options, though its performance was improved in COBOL for OS/390 & VM V2 R2."
See:
The bottom-line is that either TRUNC(BIN) or USAGE COMP-5 should be used *IF* you know that your binary data will (or might) have values larger than the PICTURE clause - but you should KNOW that these will ALMOST ALWAYS have a 'performance hit" against your execution. TRUNC(OPT) *and* making certain you don't have too large values should be used for "performance sensitive" applications.
TRUNC(STD) should be used if you think your application may be ported to other (non-IBM) COBOL compilers.
Bill Klein
"Both TRUNC(BIN) and TRUNC(STD) generate extra code whenever a BINARY data item is changed. TRUNC(BIN) is usually the slowest of these options, though its performance was improved in COBOL for OS/390 & VM V2 R2."
See:
The bottom-line is that either TRUNC(BIN) or USAGE COMP-5 should be used *IF* you know that your binary data will (or might) have values larger than the PICTURE clause - but you should KNOW that these will ALMOST ALWAYS have a 'performance hit" against your execution. TRUNC(OPT) *and* making certain you don't have too large values should be used for "performance sensitive" applications.
TRUNC(STD) should be used if you think your application may be ported to other (non-IBM) COBOL compilers.
Bill Klein
Gust1480,
this thread seems to have the answer to your question, but you might have a little difficulty in finding it.
You asked 'What is an abend S0C7' and 'What causes this error to appear'.
99 times out of a 100 it will be because your Cobol program has looked at a COMP-3 field which has not got a proper packed decimal value in it. More often than not this is caused by spaces being moved to the level above it. For example:
01 WS-ONE.
03 WS-PACKED PIC S9(9) COMP-3.
MOVE SPACES TO WS-ONE.
MOVE WS-PACKED TO .............
This would cause an S0C7.
Hope this helps.
Marc
this thread seems to have the answer to your question, but you might have a little difficulty in finding it.
You asked 'What is an abend S0C7' and 'What causes this error to appear'.
99 times out of a 100 it will be because your Cobol program has looked at a COMP-3 field which has not got a proper packed decimal value in it. More often than not this is caused by spaces being moved to the level above it. For example:
01 WS-ONE.
03 WS-PACKED PIC S9(9) COMP-3.
MOVE SPACES TO WS-ONE.
MOVE WS-PACKED TO .............
This would cause an S0C7.
Hope this helps.
Marc
- Status