× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: using a defined constant to dimension an array
  • From: boldt@xxxxxxxxxx
  • Date: Tue, 3 Jul 2001 09:28:56 -0400
  • Importance: Normal

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.