Re: using a defined constant to dimension an array

Simon wrote:
>This is a known problem.  It's on my list of "How could they miss this?"
>And they know who they are :-)  The problem is caused because the RPG
>compiler parses the procedures before it parses the global definitions so
>as far as it is concerned any mainline D-specs don't yet exist. (Yet it
>handles F-specs OK ....)

No, the problem is that within a procedure names are assumed
local until the end of the procedure is reached.  Then, if
there are any names undefined, they are searched for in the
global scope.  Since the parameter of DIM must (prior to V5R1)
be previously defined, coding a global constant name for DIM
will always result in an error since the name is not considered
defined within the procedure until the end of the procedure is
processed.

>
>I believe it has been fixed in VRM510.  No PTFs will be provided for
>earlier releases because the change is supposedly too big.

Correct.  There is a mechanism within the compiler to defer
specific checks until all names involved are fully defined.
For V5R1, we finally "bit the bullet" and implemented the
deferable check for the DIM parm, as well as a couple other
similar keywords.

>
>This is up there with:
>     o No pointer arithmetic in VRM310
>     o %TRIM, &TRIML, &TRIMR not accepting an optional trim character
>     o %CHAR not handling numeric data in VRM420
>     o INZ(*SYS) and INZ(*JOB) not working for DATE data types defined
>as data structure sub-fields in sub-procedures
>     o others that escape my memory at the moment

Here are a couple of my favorite "How could they?":
- specifying external names as normal RPG names, and not as
  character literals (results in inconsistencies in the
  language as well as complications in compiling)
- allowing comma as decimal point, which prevented use of
  comma as parameter separator (there were good reasons,
  but just not good enough as far as I was concerned)
- not allowing expressions as keyword parameters (this was
  due to implementing the keyword processing in the compiler
  before the expression parser)

But then, as they say, hindsight is 20/20.

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---