James,
In hindsight, wouldn't fewer people get caught if the default was
eval(r)?
Barbara can correct me if I am wrong here, but IIRC the eval(r) and
*RESDECPOS options were not originally available in RPG ILE. So code
written prior to its introduction could potentially start behaving
differently just because you recompiled the program after the default
rules changed.
Unlike MS, in my experience IBM takes that very seriously and goes to
great lengths to maintain backward compatibility. To get new rules
you must change the source. Hence the option to add eval(r) on an
expression level basis, or *RESDECPOS at the header level.
There are times I think this is almost taken to a fault, but I would
rather they did that than start forgoing backward compatibility just
because they think the new rules make more sense. The classic example
to me is the old RPG II/III handling of the EOF indicator on the READ
opcode for a Demand file (not Full Procedural). Unlike virtually
every other opcode, it did NOT first reset the indicator prior to
performing the READ.
So you HAD to manually reset the EOF indicator prior to a READ when
using a demand file, or it could appear EOF occured when really it was
due to the indicator been set elsewhere in the program. Over the
years, I debugged numerous programs which boiled down to the original
programmer not realizing that was the case, and I have *never* seen a
program that relied on that fact in order to function correctly.
But IBM still didn't change the behavior with demand files, because
programs could start acting differently when recompiled. If they did,
chances are they would be acting right for the first time. :)
I was really glad when full procedural file READs started doing that
right. Of course, now I don't like resulting indicators at all. But
the point is that in general, for rules to change the source must
change.
Doug
midrange.com
