Re: Convert from free to fixed

On 2010/9/29 8:55 AM, Larry Ducie wrote:

... The process
continues from the next line of code as if nothing went wrong. You
can't beat that!

Larry, it can be dangerous to set the action parameter to resume at the next instruction. The process doesn't continue from the next line of high-level-language code, it continues from the next low-level machine instruction. Whatever low-level instruction that happens to be at that release and PTF level. There's no guaranteed upward compatibility for what the next machine instruction is.

Say you have a decimal data error while the right-hand-side of an assignment is being evaluated. If you continue at the next instruction, eventually you are going to hit the instruction where the right-hand-side is stored in the target of the assignment. What exactly is going to get stored? Who knows, but it might be more invalid decimal data, which may or may not be the same as the original. Or, it may be some new value that isn't invalid decimal data any more, but also isn't anything meaningful.

I found out about this behaviour when someone was using a condition handler to duplicate the function of IGNDECERR(*YES) in RPG III. In one release it had worked as they wanted, with a zero being placed in the result of the assignment from a packed variable containing blanks (x'404040'). In a later release, they found that instead of a zero, they were getting values like 404 and 40404 being placed in their result fields. And when they added and multiplied those values, instead of getting the zeros they wanted, they were getting gradually more huge values.