Re: Additional RPGLE Enhancement Requests

Thanks for your interest Hans!

>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.
>
Again, this would not be a significant enhancement nor should it be
difficult to do.  It is just a minor irritant.  Perhaps Connections 2000
(www.conn2000.com) will modify their RPG IV conversion aid to provide this
capability.

Bob Cozzi wrote:

>>No way! That would not be something I would favor. (I would have said that 
>>this suggestion sucks, but I'm much more mellow now. <g>)
>>The CONST keyword easily identifies the item as a constant. That stupid "C" 
>>in column what-ever-it-is should be optional, and NOT inserted into 
>>converted code. I my opinion

If Bob's suggestion is to eliminate the requirement for the "C" in whatever
column if appears if the CONST keyword is specified I agree.  My point was
if you code the "C" in whatever column,  you currently DO NOT NEED to code
the CONST keyword.  You can just code the character value enclosed in quotes
or the numeric value as is.  Just like in display file DDS, when you code a
constant on a screen, you do not code the keyword, you just code the
constant enclosed in quotes.

>>
>> 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?
>
I thought at some point in time PERRCD defaulted to 1 only when CTDATA is
specified. If you defined a pre-execution time table or array, you had to
specify the PERRCD parameter because CTDATA is not specified.

I just retested this and PERRCD does default to 1 even if CTDATA is not
specified.  Boy, you sure do work fast Hans!  

Bob Cozzi wrote:

>>Agreed. And the CTDATA keyword should be optional for compile-time data. 
>>The PerRcd keyword without any FROMFILE etc. tells the compiler enough. 
>>CTDATA only causes us to have to recompile when the compiler tells us we 
>>forgot to put it in for a compile-time array.

I agree.  You should not have to code the CTDATA or PERRCD keyword AT ALL
for a compile time table or array.  If the FROMFILE and TOFILE parameters
are not coded, the table or array should default to CTDATA PERRCD(1).

>
>>
>> 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)
>
*NEXT is even better and accomplishes the goal, eliminating database
dependencies.  Of course, the length of the field combined is still
hardcoded.  What happens when the combined lengths of Field1, Field2, and
Field3 change to something other than 30.  We still have to manually change
the length of the field combined.  That still remains an unnecessary
database dependency.

Please do not misunderstand, if *NEXT is easy to do, please do it even if we
still have to hardcode the length of Combined.  You can tackle that problem
later.

RPG IV should NEVER require you to code a database dependency.

>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.
>
Please! Please! Please!  (John Carr will also like this one.)
>
>>
>> 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.
>
Again the problem is you can not define a field in an externally described
data structure and use it as a subfield in another data structure.  I
suppose you could argue we could rename the fields in the externally defined
data structure using the PREFIX keyword and define the real field in another
data structure like the renamed field in the externally defined PREFIX
renamed data structure.  This is still a pain and adds unnecessary
complexity to the code making it more difficult to understand and thus more
difficult to maintain or modify.

If you do provide this capability, please make sure DSPPGMREF shows the file
used in the LIKE definition.  (See following item #6.)
>
>>
>> 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.
>
No problem with this as long as you give us the STOP op code to delete an
activation group.
>
>>
>> 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.
>
Again, we do not personally need the SUFFIX capability.  I was just amazed
at how many seminar attendees requested this function.  It just goes to show
no matter how much one thinks they understand what MOST people in the field
are doing, no one individual will ever know what EVERYONE is doing.

The SUFFIX keyword is more meaningful than a negative prefix.  My guess is
the people who want the capability would take it any way you can provide it.
>
>>
>> 11.  You support multiple overlaying arrays.  That is an absolutely
>>      wonderful and extremely 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.
>
What about multi-dimensional arrays?
>
>>
>> 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.
>
GOTO *ENDSR, EXITSR, or EXIT - it doesn't matter as long as I don't have to
use a tag name.  If you do provide GOTO *ENDSR instead of EXITSR, you will
probably be crucified by the structured purist crowd.  If you provide EXIT
instead of EXISTSR, System/3 RPG II people might be offended.  EXITSR is the
most politically correct op code for this function I have seen so far.
>
>>
>> 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.
>
Yes! Yes! Yes!
>
>>
>> 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


Charlie Massoglia, Massoglia Technical Consulting, Inc.
PO Box 1065, Okemos, MI 48854, USA
517-676-9700  Fax: 517-676-1006  EMAIL: cmassoglia@voyager.net
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *