Additional RPGLE Enhancement Requests

Hi Charlie!  Thanks for the list!  I do have some comments and questions
on some of the items.  Most, we've seen before.

Charlie Massoglia, Massoglia Technical Consulting, Inc. wrote:
> If you are logging suggestions, how about taking care of the following, most
> admittedly minor, irritants:
>
> 1.  CVTRPG should drop the CONST keyword when converting a named
>     constant.  It's worthless.  (This should be trivial - please
>     fix it.)

CVTRPG was never meant to be a "pretty" product.  It's main goal is to
get old programs converted to the new syntax.  Since it achieves its
goal reasonably well, we have no plans to enhance it significantly.

>
> 2.  PERRCD should ALWAYS default to 1, not just when CTDATA is
>     specified.  (This should be trivial - please fix it.)

Could you clarify this point?


>
> 3.  DIM keyword should be optional when using ALT.  It should default
>     to the DIM specified on the primary table or array.  (This should
>     be trivial - please fix it.)
>
> 4.  Permit arithmetic in the %SUBST function in D-specs, e.g.
>
>     D  Combined     30A
>     D   Field1         %SUBST(Combined:1:%SIZE:Field1)
>     D   Field2         %SUBST(Combined:%SIZE(Field1+1):%SIZE(Field2)
>     D   Field3         %SUBST(Combined:%SIZE(Field1+Field2+1):%SIZE(Field3)
>
>     Where Field1, Field2, and Field3 are fields from an externally
>     defined file defined the F-specs.
>
>     Or better yet, permit concatenated definitions
>
>     D   Combined       %CONCAT(Field1 + Field2 + Field3)
>
>     This is more than a minor irritant.  It is not possible currently.
>     It is, however, one of the few database dependencies which still
>     exists in RPG IV.

I agree 100%!  We should allow all constant valued expressions in
D-Specs, not just built-in functions.  The reason we don't have this
in RPG IV is because we implemented D-Specs and built-in functions
before implementing expressions.  Fortunately, when expressions fell
into my lap, I designed the code so that we could in the future recode
keyword processing to use the same parser as we use for expressions.
It's not an easy thing to do, but it is, at least, feasible.

I push for this at every opportunity.  Unfortunately, the benefits are
hard to quantify.  For many problem scenarios that could easily be
solved by this enhancement. there is a more direct solution that would
be easier to implement.

For example, to take your example above (which I believe overlays
externally described fields consecutively over some subfield), this
could be achieved by something like the following enhancement:

    D  Combined         30A
    D   Field1                 OVERLAY(Combined:1)
    D   Field2                 OVERLAY(Combined:*NEXT)
    D   Field3                 OVERLAY(Combined:*NEXT)

So, unless we have more compelling reasons for full expressions in
D-Specs, it will probably have to wait a while.

BTW, we also want to relax the rule that requires OVERLAY to overlay
a subfield.  We are thinking at least of allowing a subfield to overlay
the data structure name.


>
> 5.  Permit INDIVIDUAL fields to be externally defined without having
>     to define an externally defined data stucture.
>
>     D   Temp2   S      like(field2:filename1:optrecfmt1)
>     D           DS
>     D   Temp4          like(field4:filename2:optrecfmt4)
>     D   Temp3          like(field3:filename1:optrecfmt1)
>
>     where filename1 and filename2 are not used at all in the program.

I also push for this when I can.  But the alternative of defining fields
LIKE subfields of a BASED EDS is already available.


>
> 6.  Permit the name of an externally defined file to optionally show
>     up in DSPPFMREF output.
>
>      D dsname   E DS    EXTNAME(filename)  LOG(*YES)
>
>      where filename is NOT defined in F-specs.
>
>      Or just make it always show up.  It is understood this may be
>      non-trivial and may require Rochester cooperation.
>
> 7.   Permit a file to be read sequentially by key WITHOUT requiring
>      the file to be defined in the F-specs to be keyed.  If you want
>      to use OPNQRYF on the DSPOBJD outfile QADSPOBJ (or any other
>      outfile), you must define a dummy logical file to compile the
>      program.  This does not make sense.  It is understood that you
>      would probably not permit random access, SETLL, SETGT, or any
>      operation which requires a key list to be used on this file.
>
> 8.   You finally gave us $SCAN in addition to the SCAN operation.
>      We have both CHECK and CHECKR.  What about SCANR and %SCANR?

It is our intention to provide more built-in functions in the future.
You are more likely to see new BIFs than new opcodes.


>
> 9.   When are we going to be able to code ANY CRTBNDRPG or CRTRPGMOD
>      parameter in the H-spec?

I'm sure you already know that this is coming!


>
> 10.  PREFIX(M2:2) is wonderful.  I can't tell you how may people asked
>      for a suffix capability in the RPG IV seminars I have done.  Most
>      people name every field in a file using the same characters, e.g.
>      MBNAME, MBCITY, MBDATE, etc.  I had no idea how many people use
>      the standard NAMEMB, CITYMB, DATEMB, etc.  How about the following:
>
>      PREFIX(M2:2:*SUFFIX) to replace the last 2 non-blank characters
>
>      or PREFIX(M2:0:*SUFFIX) to add the suffix after the last non-blank
>      character.

Hmmm!  This suggestion is new to me!  Someone else suggested a SUFFIX
keyword.  Another alternative is to allow negative values as the 2nd
parameter to indicate suffix.


>
> 11.  You support multiple overlaying arrays.  That is an absolutely
>      wonderful and extermely powerful function.  I can't tell you
>      how many people asked in the RPG IV seminars I have done whether
>      we can now specify more than one alternate table or array.

I'll note the suggestion, but unfortunately, this would not be easy to
implement.  We never foresaw the need to go beyond 1 alternate array
or table.


>
> 12.  You added the ALLOC and DEALLOC operation codes to replace the
>      calls to the dynamic storage allocation APIs.  These APIs and
>      the new op codes are used by VERY FEW people.  EVERYONE who
>      begins coding RPG IV in a true ILE environment has to call
>      the end API to delete an activation group.  How about finally
>      giving us the STOP operation code?  (This should be trivial -
>      please fix it.)
>
> 13.  We have ITER and LEAVE to exit a do loop.  How do we exit a
>      subroutine without doing a GOTO.  What above an operation code
>      to GOTO *ENDSR just like ITER does a GOTO ENDO and LEAVE does
>      a GOTO ENDO+1.  I have no idea what to call the op code.  I
>      just know we desparately need it.  (This should be trivial -
>      please fix it.)

I like GOTO *ENDSR.  I know one or two structured programming purists
may object, but I know how darn convenient it is to leave a "structured"
construct prematurely.


>
> 14.  Since ALLOC and DEALLOC can be used to extend an array at
>      execution time, what about simply defining an array as
>      extendable, e.g.
>
>      D  Array      S       10P 2    DIM(50) EXTEND(50)
>
>      with EXTEND defaulting to EXTEND(%ELEM(Array))

Run-time allocation of array elements is high on our priority list.


>
> 15.  Ditto multiple occurance data structures.
>
>      D  MultDS      DS              OCCURS(50) EXTEND(50)
>
> These are just a few suggestions which immediately come to mind.
>
> Thanks in advance.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, hboldt@vnet.ibm.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *