what will happen if max range of loop is junk?

[apjohn1986]

One PL1 program is failing due to infinite looping. It seems like the max range is not set properly. What will happen if x has junk values in the below code? program will abend (S0C7) when value moved to x or infinite loop?

x = <value returned from another module>;
Do i = 1 to x WHILE(a = b);
...
end;

[Akatsukami]

A S0C1 or S0C4 abends (translated to oncodes 8091 or 8094) are likely; the program may overwrite code with data (causing a S0C1) or address storage not belonging to the enclave. Other S0Cx abends are possible, including S0C7 (I once got a S0C6), but are considerably less likely than S0C1/4.

[prino]

One PL1 program is failing due to infinite looping. It seems like the max range is not set properly. What will happen if x has junk values in the below code? program will abend (S0C7) when value moved to x or infinite loop?

x = <value returned from another module>;
Do i = 1 to x WHILE(a = b);
...
end;

Give the declares of i and x, without those there is no way of telling what would happen. And for what it's worth infinite, loops can only occur if i

• is declared as PIC 'whatever' (And if you use PIC variables in loops you deserve what you get ), or
• you modify i inside the loop (and then you also deserve what you get )

[apjohn1986]

i is bin(15) and x is fixed bin(31)

There is no increment of i inside loop

[prino]

i is bin(15) and x is fixed bin(31)

Sigh...

And you still don't realize what's wrong...

[apjohn1986]

What's wrong?

This is working fine if value from sub module is valid. question is what if that's junk

[Akatsukami]

What will happen if the value of x is greater than 32,767?

[apjohn1986]

Yeah got the point.

But there is a correction in my previous statement. x is bin(15) only, the field assign value to it is fixed bin(31)

[Akatsukami]

So then the first two bytes of the transmitting field will be truncated, yes? Of course the truncated value will be valid -- every bit pattern in a 2s-complement binary variable is a valid number -- but it will be incorrect. However, since the value is valid, there will be no problem with the DO loop.