RE: Additional RPGLE Enhancement Requests

I'd like to rebut some of Charlie's suggestions...


On Friday, July 11, 1997 10:01 PM, Charlie Massoglia 
[SMTP:cmassoglia@voyager.net] wrote:
> >Mark Lazarus wrote:
> >> In that case, can we request he put in XOR?  :-)
> >
> >Suggestion noted and logged!
> >
> >Cheers!  Hans
> >
> 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.)


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.


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

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.


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

The use of expressions in ALL of the D-spec keywords is mandatory to me. If 
that doesn't get implemented soon, I can't really continue to recommend the 
use of RPG IV.  As for %SUBST and the others, I agree, but full-expression 
support is much more important to me.


> 5.  Permit INDIVIDUAL fields to be externally defined without having
>     to define an externally defined data structure.
>
>     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.

Agreed!


> 6.  Permit the name of an externally defined file to optionally show
>     up in DSPPFMREF output.

You mean it doesn't do this already?  How silly.

> 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.)

Well, the ability to END a named activation group automatically (like a 
*NEW one does) is a really show-stopper. I could never tell people to take 
advantage of activation groups until this option is added to ILE. It's just 
crazy not having 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 desperately need it.  (This should be trivial -
>      please fix it.)

In subprocedures, it's called RETURN. In subroutines, perhaps EXIT would 
work. If that doesn't offend the EXIT/RLABL crowd.


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

I agree. Without a doubt, this is the kind of thing we really wanted 
anyway. The use of DEALLOC is not more useful that calling the C-runtime 
library to do a malloc. We are RPG programmers, we dont' give a rat's butt 
about pointers and dynamic memory. Give use the D-spec keywords to do this 
easily, and clearly. Please.



And for one of my own....

Please, when we're using a V3R7 machine (for example) and we want to 
compile stuff for V3R1 or similar, allow us to use the non-operating system 
release dependant features of the language. I mean the new preprocessor 
directives are great! But they are totally useless unless everybody on 
Earth moves to V3R7. So what good are they? The don't do anything to the 
compiled code? Why can't my V3R7 RPG IV compiler target V3R1 and use the 
preprocessor directives?  Well, I technically know why, so my requirement 
is, change it.

Thanks!

Bob Cozzi

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