On 9/20/2013 3:57 PM, Rory Hewitt wrote:
It's not that RTNPARM is *bad*, per se, just that I was hoping for more
useful stuff, like the ability to dynamically specify a null OA handler, so
you could have a single program work with green-screen *or* with OA - THAT
would have been great :)
I don't think this would be as great as you're envisioning... I work
with a lot of customers using OA, that's my job these days. Almost
every customer asks "can I use both OA and green screen at the same time?"
And almost no customer ever uses it.
It can be done with an /if defined() right now. You can use this to
compile two copies of the exact same code in different libraries, one
with HANDLER enabled, and one without. Now, just by adjusting the
library list, you can select which copy you use. Not quite as elegant
as being able to disable it at runtime, perhaps.. but viable enough.
But nobody uses it. Why? Because once you are no longer using a 5250
screen, you tend to start modifying your code to take advantage of the
GUI features. You start adding fields to control things like fonts,
colors, value lists for a drop-down field, buttons bound to named
indicators (instead numbered indicators or *INKx indicators). Paths to
images, coordinates to plot on a graph, etc, etc.
so you end up with lots of additional fields in your record formats.
Trying to keep that in sync with green-screens is a royal pain in the
butt, because you have to add all of the same data types to the same
record formats on the green-screen, and make them all hidden fields (or
similar) and, of course, keep all of the fields in the same sequence in
the record format. If you don't, the GUI screen and the 5250 screen
won't be the same.
Since maintaining two sets of screens like this is very cumbersome, and
it's extremely rare that users actually still want the 5250 screen when
you've added such nice features to the GUI one, customers just never use
this functionality.
It's funny, because almost every customer asks for it, and then quickly
decides not to use it.
Plus, it's not compatible with other ILE languages (as Jon has pointed
out), and it's not compatible with existing %parms code - these are 2
things I used frequently. If I was just writing new code, I'd use it
happily, but a lot of my work involved changing existing code, so I just
never saw the point.
For existing code, you're already using parameters instead of return
values -- or else you've already decided that the normal return value
mechanism is fast enough. In that case, I wouldn't change the existing
routine, but instead, I'd add a wrapper around it that uses a RTNPARM.
That way, if someone would prefer the RTNPARM method, they can use that,
but you don't break compatibility with the existing callers.
And since RTNPARM requires 7.1, you may as well use %PARMNUM at the same
time -- and then it won't screw up %PARMS logic.
I guess I hoped that the RPG compiler would recognize that a large return
parameter is defined and would optimize it 'under the covers' to do this,
without the need for a specific keyword.
That would indeed be nice -- but that's not something the RPG compiler
can do. That would require changing the entire ILE environment, since
it would have to be done for all languages.
And if they changed the ILE environment, you'd need to go through the
process of converting all of the existing programs (much like we did
when updating to 6.1) in order to change that functionality for
everyone. So, while this would be nice, it would also be a rather
painful change.
RTNPARM, however, gives us similar functionality without breaking any
backward compatibility, and can be done entirely within the RPG compile.
So it's a nice compromise.
In general, I feel like I have worked around the assorted RPG limitations
for almost 20 years - I'm used to them.
Yeah, that's kinda how I feel, too. I'm sure you've seen all of the
people requesting stuff like free-format D-specs, etc... I'm always
like "what's the point?" but... it's only because I'm so used to
working around these limitations that it's second nature. To a lot of
people, it's worth something.
midrange.com
