# SOCC abend - COMP-2 usage

Author Message
Abhinav Chandra

New User

Joined: 13 Oct 2012
Posts: 29
Location: India

Posted: Tue Oct 08, 2013 1:21 am

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

 Code: COMPUTE NEW-INT-RATE                                                     = INTEREST-RATE                                                       - (FUND-VALUE - TARGET-VALUE)                                       * (INTEREST-RATE - PREV-INT-RATE)                                   / (FUND-VALUE - PREV-FUND-VALUE).

On the further analysis this statement was broken in the smaller segments to find the actual cause of the issue. So the statements below are the same as statement above, just our approach is broken in pieces.

 Code: COMPUTE VALUE-1 = FUND-VALUE - PREV-FUND-VALUE    COMPUTE VALUE-2 = INTEREST-RATE - PREV-INT-RATE  COMPUTE VALUE-3 = FUND-VALUE - TARGET-VALUE      COMPUTE VALUE-4 = VALUE-2 / VALUE-1    COMPUTE VALUE-5 = VALUE-3 * VALUE-4              COMPUTE NEW-INT-RATE = INTEREST-RATE - VALUE-5

It was found that the statement 'COMPUTE VALUE-5 = VALUE-3 * VALUE-4' is causing the S0CC. And based on the displays at time of the abend, here are the values for these variables.

 Code: FUND-VALUE:  .00000000000000000E 00        TARGET-VALUE:  .13484000000000000E 03      INTEREST-RATE:  .76960903639477748E 00    PREV-INT-RATE:  .90367094297093048E 00    PREV-FUND-VALUE: -.51872912558109839E-75

So what will be the solution to this final piece of calculation which is causing S0CC. Any help on this would be highly appreciated.
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

 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

 Posted: Tue Oct 08, 2013 1:54 am 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

Global Moderator

Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

Posted: Tue Oct 08, 2013 2:12 am

 Abhinav Chandra wrote: 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.

A S0CC is an exponent overflow. PREV-FUND-VALUE has a value of -.51872912558109839E-75. Does not that value seem of dubious validity to you?
Abhinav Chandra

New User

Joined: 13 Oct 2012
Posts: 29
Location: India

 Posted: Tue Oct 08, 2013 2:13 am Tried running the job after compiling it with compiler option ARITH(EXTEND), but still getting the same error again.
Akatsukami

Global Moderator

Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

 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

 Posted: Tue Oct 08, 2013 2:23 am No Akatsukami, the value for the field PREV-FUND-VALUE: -.51872912558109839E-75 is perfectly fine
Akatsukami

Global Moderator

Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

Posted: Tue Oct 08, 2013 2:31 am

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

Well, remind me never to entrust so much as a yoctocent to whatever company you're programming for
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8651
Location: Dubuque, Iowa, USA

 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

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

 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

Global Moderator

Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

Posted: Tue Oct 08, 2013 6:35 am

 Bill Woodger wrote: Akatsukami may have made a good shot.

"May"?
Abhinav Chandra

New User

Joined: 13 Oct 2012
Posts: 29
Location: India

 Posted: Wed Oct 09, 2013 12:21 pm Thanks alot for all your valuable thoughts and suggestions.
jerryte

Active User

Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

Posted: Fri Oct 11, 2013 11:03 pm

I suggest to add logic prior to the calculation
 Code: IF PREV-FUND-VALUE < 1.0E-20 THEN MOVE ZERO TO PREV-FUND-VALUE END-IF

This will put an actual zero value into the variable instead of an almost zero value. Choose an exponent that represents for you a zero value. "-20" is being generous
Disclaimer: I have not tested it but I hope you get the general idea.
 View Bookmarks All times are GMT + 6 Hours

 Topic Forum Replies Similar Topics Converting ASCII values to COMP-3 (ZD... JCL & VSAM 2 WER999A - UNSUCCESSFUL SORT 8ED U Ab... SYNCSORT 5 the system or user abend SF0F R=NULL COBOL Programming 0 Need to get an DLI abend like U0200 IMS DB/DC 2 z/OS Modules Usage report using SMF 42 DFSORT/ICETOOL 2
Search our Forums:

 IBMMainframes.com is not an official and/or affiliated with IBM® in anyway Board Rules | FAQ | Downloads | Wiki | SiteMap | Contact Us