Re: Optional Parms in Sub Procedure

This is a funny discussion,



“It's funny, because almost every customer asks for it, and then quickly
decides not to use it.” says Scott, I would say they dreamt about it, but
that has been a dream we have heard about for years, “the magic wand” that
just turned 5250 RPG (how old the code may be) into GUI RPG, the same dream
RPGOA was marketed around – “New RPGOA will connect your existing 5250 code
to your mobile device” – that is marketing BS because it indicates “without
any work to be done”.



Whatever middleware we put between RPG and a browser an old 5250 buffer
simply doesn’t have the data, functionality and attributes needed for GUI –
it is as simple as that and RPGOA doesn’t change that fact!



This discussion is also contradictory. RTNPARM is a V7.1 technical feature
very few programmers will ever come close to and certainly not typical
RPGOA 5250 buffer programmers that typical will buy their handles from one
of the (few) ISV’s that makes RPGOA middleware. Remember that RPGOA also
was marketed to programmers so they were able to continue to code as they
is used to, fixed format RPG CHAIN, UPDATE and EXFMT and maintaining 5250
style programming doesn’t really add up with advanced service program /
procedure programming.



Let’s face it there are a lot of old school RPG programmers that may
benefit from RPGOA and a preprogrammed handler that they can use on a
‘don’t ask, just do it’ basis. YIP’s and multi-language programmers will
typical prefer the service programs / procedures approach since this mimic
classes and methods that they are used to in order to expand capability in
basic Java, C and even javascript.



Not to offend anybody (despite disagreements), I don’t consider anybody in
this tread as “old school programmers”, they (the old school) typically
never appears in web based very technical forums like midrange.com.



But we should also remember that OA isn’t a mainstream programming method,
it is only seen in IBM I/RPG and nowhere else and there is nothing an OA
handler can do that a service program / procedures can’t do.



The biggest problem the IBM I and RPG community always has had is the lack
of continuously education and modernization. We are trapped in backward
compatibility that hasn’t forced programmers to update their skills and
working methods, it has paradoxically been too easy to upgrade while
companies like Microsoft has forced that upon their programmers by
continuously removing backward compatibility.



IBM could easily has made incentive to upgrade (RPG) code, instead of
announcing the RPGOA first as a payable feature and keeping SQL as a
payable feature, they should instead have split the RPG compiler up and
made backward compatibility a payable feature in new releases, features
(like QS36F, OCL and RPG II and even SNA) should have become more and more
expensive as times gone by and thereby motivating customers and programmers
to move on.



Every ISV (like myself) has the same problem – how long do we support
customers in OS back level before they have to pay, not on a mutual common
SWMA, but for specific designed back level support and paid by the hour by
them?


On Sat, Sep 21, 2013 at 12:35 AM, Scott Klement
<rpg400-l@xxxxxxxxxxxxxxxx>wrote:

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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.