RE: DIM question (Was MOVE/MOVEL and %Scan)

[boldt@xxxxxxxxxx]

Charlie wrote:
> In V4R4 the following will not compile:
>
> D  array2                      S                      dim(%elem(array1))
> like(array1)
> D  array1                      S            7P  2  dim(12)
>
> Prior to V5R1, the argument of a built in function used on the
> DIM, OCCURS,
> OVERLAY, or PERRCD keywords in D-specs must have been previously
> defined in
> the source.  That is the first time we have had serial dependence of
> definition in RPG.  That restriction has been eliminated as of V5R1.

Joe wrote:
>To be fair, though, Charlie, this is also the first time we have been able
>to define expressions as arguments to those keywords.  The compiler folks
in
>effect added a preprocessor to allow these definitions.  The first
>implementation was a single-pass preprocessor, which is quite a bit easier
>to write than one that allows non-serial processing.  So, "eliminating the
>restriction" was actually a neat bit of coding.

I've got a few nits to pick:  First, RPG does not allow ANY expression
as parameter to D-Spec keywords.  But you can code any BIF as
parameter to any D-Spec keyword, provided it has a value computable at
compile time.

Second, BIF's have been allowed as D-Spec keyword parameters since
V3R1 of RPG IV.

What's new in V5R1 is the ability to specify a parameter for certain
D-Spec keywords that's not been defined previously in the program.
This was especially important for D-Specs within procedures.  Due to
the way scoping is handled in procedures, almost all names used
within a procedure are not officially defined by the compiler until
the end of the procedure.  As a result, you could not apply the same
nice proper coding techniques within procedured that you could in
the global D-Specs, such as BIF's or constant names on DIM.

We did not add any extra passes to the processing.  What we did was
take advantage of an implementation design in the compiler where
certain diagnostic checks can either be done immediately, or be
deferred until all dependent names get defined.  (You might have
noticed that in the way diagnostics are listed in the compile
listing.)  It was just some bit of work we kept putting off from
release to release.

>To my mind, my concern about the MOVE/MOVEL issue notwithstanding, the
>additions to the RPG language have been nothing short of remarkable.  The
>integration of the Java language is another area where the compiler
writers
>have shown an incredible ability to merge new technologies with legacy
>constructs.  And perhaps that's why when I see something that really isn't
>necessary that I get a little upset.  The RPG language has the ability to
be
>one of the premier binding languages between business applications and
>middleware, and I hope the compiler team continues with their great work.
I
>just hope it's not at the expense of the core ability of RPG, which is and
>always will be business application design.

Again nitpicking:  The way new technologies are enabled by RPG isn't
through any great magic.  New technologies are generally used from
RPG programs using program or procedure calls.  You've been able to
call other programs from RPG code for decades.  Procedure calls
(either to bound modules or to service programs) have been part of
the RPG IV language since V3R1.  Nothing else in the language is as
important as a "binding" mechanism.  As long as other programs can
be called from RPG, and as long as middleware API's can be called
from RPG, all the "new" technologies are accessable from RPG
programs.

The Java integration in particular provides some conveniences.  But
it's not really something you couldn't do before, and although
calling Java is now a bit easier, it's still important to understand
how Java works.

But by the same token, the "new" technologies are also accessable
from many other languages as well.  Is RPG best at it? I wouldn't go
so far as that.  As I've suggested before, for most iSeries
programmers, RPG is the best language because it's the language they
know best.  Business applications can be and are written in many
other languages as well.  And the fans of those other languages will
insist that their language is the best.

But I do agree with one thing.  As a compiler writer, the changes
we've been able to shoe-horn into the RPG language are quite
remarkable.

Cheers!  Hans

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