IBM Mainframe Forum

Posted: **Thu Dec 19, 2013 8:32 pm**

Time to pop my head over the parapet!
Being holiday season most of the real COBOLlers are away leaving me - newish to COBOL - to pick up the pieces when a production program failed in testing (well, it was my new program that was proving a feed to this other program). What I eventually found was that a SUBTRACT seemed to be not being executed i.e. the variables involved were unchanged from before to after. This is replicated in the following snippet. Test A is how it is in production and test B is how I am going to fix it.

Can anyone explain WHY nothing appeared to happen? Just reading it all values should end up being 0. The answer could be in the assembler code but I have not gone there yet - I am not hot on assembler, in fact, just above zero!

Select all

working-storage section.
01 a-table.
05 number-1 occurs 2 pic 9999v99 comp-3.
77 i pic 9 comp.
77 j pic 9 comp.
*==========================================================
procedure division.
a000-mainline section.
move 2 to i j
* Test A
move +10 to number-1(2)
display 'I: >' number-1(i) '<; J: >' number-1(j) '<'
subtract number-1(i) from number-1(j)
number-1(i)
display 'I: >' number-1(i) '<; J: >' number-1(j) '<'
* Test B
move +10 to number-1(2)
display 'I: >' number-1(i) '<; J: >' number-1(j) '<'
subtract number-1(i) from number-1(j)
subtract number-1(i) from number-1(i)
display 'I: >' number-1(i) '<; J: >' number-1(j) '<'

Output:
From test A:

Select all

I: >001000<; J: >001000< Before subtract
I: >001000<; J: >001000< After subtract

From test B:

Select all

I: >001000<; J: >001000< Before subtract
I: >000000<; J: >000000< After subtract

The key to the problem is that it is the same piece of storage being referred to for all variables involved.

Posted: **Thu Dec 19, 2013 8:55 pm**

If you want to see what is happening, make the COMP-3 field signed. PIC S9999V99.

That first example of code is horrible.

As a replacement I'd suggest:

Select all

MOVE ZERO TO number-1(i)

I and J have the same value. The result of subtracting a field from itself will always be zero. So why subtract, and why do it more than once (zero minus zero is still zero).

For your first example, 10 was subtracted twice from the same value (originally 10), ending up with -10. No sign on the field, so it "seems" to retain its original value.

I think it is terrible to have the same value for different subscripts on the same field in the same statement. It is just plain asking for trouble, and when trouble responds, it'll be when the idiot who wrote if and all their colleagues are away for Christmas....

Posted: **Thu Dec 19, 2013 9:10 pm**

Hi Billy

It is only a snippet from a mickey mouse to demonstrate the problem. There are 2 indicies because the table is being processed from both ends at once and at this point they co-incide. and, yup, just looked at the original code, and the variables are unsigned so that would explain it. Me being a PL/1 person all this signing is "vulgar" PL/1 knows when a vale is negaitve by looking at the sign nibble. 35 years of not having to worry about signs takes a bit of getting rid of!

I'll get the "idiot" to look at the variable declarations in the new year.

Posted: **Fri Dec 20, 2013 4:19 am**

It is not just the definition which needs to be considered (unsigned fields and subtraction don't mix unless what is being subtracted is known to be smaller). When the subscripts "cross" (actually in the case when they are the same at the moment that they cross), that data should not be modified (likely, anyway). Perhaps someone recently changed to an odd number of entries in the table? Perhaps it has been quietly pickling something for a while...

Posted: **Fri Dec 20, 2013 2:58 pm**

I think that whoever wrote that bit of code didn't consider the case of the subscripts being the same. As to the signing, think it may be to do with the function of the program - it is switching grains of rice from incoming buckets into outgoing buckets where each bucket can be in or out so it is lowering the level ion some buckets, emptying others, increasing others and starting yet others. So no bucket can go below zero - when it is empty you start taking rice from another bucket. This particular scenario had 1 input bucket to be emptied, 2 new output buckets and one input bucket that was to have some grain taken out so it was in/out. Prior to this run the re had been limited - if any switching and we only had 3 active buckets whereas we now have 4. The code allows for 25.

IBM Mainframe Forum

Possible Error in Subtraction!

Possible Error in Subtraction!

Re: Possible Error in Subtraction!

Re: Possible Error in Subtraction!

Re: Possible Error in Subtraction!

Re: Possible Error in Subtraction!