SOCC abend - COMP-2 usage

Abhinav Chandra · New User Joined: 13 Oct 2012 Posts: 29 Location: India

Need help in resolving SOCC abend for below mentioned piece of code. All the variables in the statements below are COMP-2. -

Bill Woodger · Posted: Tue Oct 08, 2013 1:35 am

What do you have for compiler option ARITH?

Why are all the values COMP-2?

What sort of valid ranges do you have for the figures?

Abhinav Chandra · New User Joined: 13 Oct 2012 Posts: 29 Location: India

Please look for my answers on your above queries.

1. What do you have for compiler option ARITH?
This is I used to find the line thats abending..
or basically for the last run.. this does not has SSRANGE

//COMPILE EXEC PGM=IGYCRCTL,
// PARM=('LIB,RENT,DATA(31),OFFSET',
// 'BUF(32K),OPT,MAP,TRUNC(STD)',
// 'NODYNAM,NOADV,NOTERM',
// 'NUMPROC(NOPFD)',
// 'NOLIST'),
// COND=(4,LT,PRECOMP)

Did compiling it with ARITH will resolve the SOCC ?

2. Why are all the values COMP-2?
Its already defined from a very long time and was performing well earlier.

3. What sort of valid ranges do you have for the figures?
I didn't get you on this, can you please explain what you are looking for.

Akatsukami · Posted: Tue Oct 08, 2013 2:12 am

Abhinav Chandra · New User Joined: 13 Oct 2012 Posts: 29 Location: India

Tried running the job after compiling it with compiler option ARITH(EXTEND), but still getting the same error again.

Akatsukami · Posted: Tue Oct 08, 2013 2:17 am

Tell me, Abhinav-kun, what currency is the fund in that you would expect its previous value to be less than 10^-75 unit? Or do you think that that value is evidence that that variable wasn't initialized, was overwritten by non-floating-point data, or for some other reason has invalid garbage in it?

Abhinav Chandra · New User Joined: 13 Oct 2012 Posts: 29 Location: India

No Akatsukami, the value for the field PREV-FUND-VALUE: -.51872912558109839E-75 is perfectly fine

Akatsukami · Posted: Tue Oct 08, 2013 2:31 am

Robert Sample · Posted: Tue Oct 08, 2013 2:33 am

You have a fund value where 75 zeroes between the decimal point and the first digit is acceptable? I think the first problem is that you have no clue about what valid values for your data SHOULD be -- especially since 25 digits is MORE than enough for any currency currently in use in the world, yet you are claiming 50 more digits are valid data for you.

Show us code initializing (or setting) each of the variables in your equation before the execution of the statements comprising the equation.

Bill Woodger · Posted: Tue Oct 08, 2013 4:35 am

You PREV-FUND-VALUE is negative and absolutely tiny. Miniscule. Unless you apply it to massively enormous values it is effectively zero, just not quite. If you were to divide it by 10 or so, you'd have a number which COBOL cannot support. You do more than divide it by 10, so you get the S0CC.

It may have been working for years, or decades, but the S0CC could probably have happened at any time - maybe.

You have to determine why such an absurdly small value came about.

Why I asked about the ranges that your values may have, was to determine whether floating-point numbers are necessary, and whether they have to be COMP-2, and whether you need the extended precision which ARITH(COMPAT) would give you.

Someone needs to analyse the original business requirement and see how it should be implemented in COBOL. I have never used COMP-1 or COMP-2 for a business calculation. Your calculation is not a complex one, so you'd only require COMP-1 or COMP-2 if the values you are dealing with require a precision which in total is greater than COMP-3 allows - meaning for instance you have to cover 18 digits in front of the decimal place and at least one digit after the decima place (or any combination in total where there are more than 18 digits).

I cannot believe that you have a "fund" in any currency which requires more than 18 significant digits.

If you were only using ARITH(COMPAT) (for years) you should be aware that the precision in all those calculations is limited to a maximum of 15 siginificant digits.

If you in reality don't need more than 15 significant digits, then you will be OK. If you did need more than 15 significant digits, then you have some nasty problem-determination coming up.

You got a S0CC because your value exceeded the size that COBOL can support. For your calculation, there can be nothing correct about that, even if the large figure is a cumulative effect of imprecise floating-point calculations.

Find the business requirement. Find the minimum and maximum value (including positive and negative) of all component values. Decide upon a USAGE (and PICTURE if necessary) based on your findings. If you still decide COMP-2 is the thing for you 1) I'd be surprised 2) you've got some bullet-proofing and evaluation and all that type of stuff.

At least you're not doing lots of these calculations. They're deadly slow, and are going to get slower if you "need" precision and therefore ARITH(EXTEND).

Bill Woodger · Posted: Tue Oct 08, 2013 5:21 am

Akatsukami may have made a good shot. Unless your source fields are COMP-2 on file/DB/interface then the absurdly small value has been arrived at in your program/system. Whilst possible to get to such a small value through many erroneous manipulations, simply trashing it at some point would be by far the simplest - so most likely - way to do it.

So you might have absurd calculations (not your doing, someone in the past) and a bug.

You (or someone in your organisation) are going to have to spend a lot of time and be exceedingly careful to get this fixed properly. It will likely involve accountants and auditors.

Bear in mind, even when you find the bug (if there is one), you can't just use ARITH(EXTEND) if you need the extra precision without the impact-analysis into the previous calculations over whatever period.

If you don't need the precision, then you (very probably) don't need floating-point. If the reason for floating-point is a source value, with a total range of 18 siginifcant digts or fewer, then it can be/should be MOVEd to a packed-decimal, processed, and the result MOVEd back for the output.

A big clue as to whether floating-point is needed is the source fields and any "reported" (print or screen) values.

C/C++/JAVA may be, stupidly, giving you a "double". If this is so, and it is just to have a decimal part, then MOVE to packed, process, MOVE back.

Maybe there are reasons for the calulation requiring COMP-2, but I can't think of any genuine ones, looking at the calculation itself and the data-names.

Akatsukami · Posted: Tue Oct 08, 2013 6:35 am

Abhinav Chandra · New User Joined: 13 Oct 2012 Posts: 29 Location: India

Thanks alot for all your valuable thoughts and suggestions.

jerryte · Posted: Fri Oct 11, 2013 11:03 pm

I suggest to add logic prior to the calculation