× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Joe

I hear your points. I want to focus on 2 that seem self-contradictory, of course, not casting aspersions your way! :-)

You say to write "...callable code..." - as far as I can see, and I have and am working with it now, that is essentially what an OA handler is, it's just called by the RPG runtime engine. So when you say "It does almost nothing that a CALL can't do." you are exactly right. That doesn't make it a bad thing, IMO. Again, many of us on this list are not the target - vendors such as we are and consultants such as you know how to do lots of things the average Joe-Six-Pack developer doesn't, and might be constrained by budget and politics and time from learning all we have.

So I think it's a viable alternative - it didn't satisfy some of the ISVs when we discussed it with IBM. Like should it have had OVR* functionality. But it does give some opportunities.

Some on the list have climbed on the term "handler" and said they wrote them years ago - I have to say, sure, but those required either subroutine or subprocedure calls, not the standard IO opcodes. Having said that, the way these can work is probably somewhat similar - you have some SELECT construct that acts as a driver for things.

Just a thought - the runtime of RPG is essentially calling to some program that gets the information we now have in the data structures provided. I assume they are not identical, but they have to be related. Those includes have been posted - might be worth a look so that comments are based on knowledge. BTW, that's not a comment pointed at you specifically, it's a general suggestion, since the information is now freely available. Informed discussion here can only be helpful, methinks.

There's also a new manual - quite an improvement over what was already given. Kudos to Barbara, please! I think Jon posted about its appearance this morning.

So let's see where this goes. If it extends the life of this platform, that's cool. If it can give developers a way not to have to say "NO!" in their shop, that's also cool.

There are still issues about pricing, open source, cost of handlers from ISVs, etc. I don't have any idea what the solutions to those are. But it will be an interesting time, I think.

Regards
Vern

On 7/27/2010 4:37 PM, Joe Pluta wrote:
Scott Klement wrote:
At what point do you give up?

You don't.

THE FUTURE OF THIS PLATFORM DEPENDS ON IMPROVING CODE. IT'S NOT
HAPPENING. WHAT CAN WE POSSIBLY DO?

Write callable code that can be inserted into legacy systems.

*THAT* is the point behind RPG-OA.

No offense to the designers, but RPG-OA is just another band-aid. It
does almost nothing that a CALL can't do. In fact, unless you use
free-form access techniques, you're going to use a KLIST, and what
exactly is the difference between a KLIST and a PLIST? Not a lot. In
fact, I'd prefer teaching people to use data structures to pass data
between programs; they're much more flexible.

With RPG-OA, *we* (those that have progressed beyond the 1980s) can
provide handlers to do something modern. And *they* (the majority who
still thinks RPG II was the end-all-be-all of programming languages)
doesn't have to change or learn anything new.

Or you could use a CALL.

With RPG OA we can give them spreadsheets, again without asking them to
learn anything.

Same with GUI interfaces.

We do that today. In my shop, we let them call a program that sends the
data to a data queue to be processed by Java, or invokes a service
program, or whatever. It even works in RPG III.

*THAT* is the point. It's not that RPG OA is a great idea, or is a
modern approach. It's not. It's just that we've given up on RPG
programmers ever changing anything. So we're making it possible to move
beyond 1980's technology without them learning anything.

RPG-OA is a horrible way to modernize code. It's a semi-effective way
to cram a 5250 interface onto an existing program without severe rewrite
(although I'm still unclear on how indicators are handled), and I
suppose there are one or two classes of problems (interfacing to certain
types of XML data, perhaps) where it might make sense, but in general
it's a technological solution looking for a problem.

Seriously, selling RPG-OA because RPG programmers are too dumb or
stubborn is a sign of severe burn-out. Get yourself a vacation and then
teach people how to write callable modules. The answer to writing
better code is the same as it has always been: modular code.

Sorry, I haven't had a lot to offer this discussion since I thought it
was pretty obvious that open access is more or less an extended version
of special files and special files never caught on for good reason (and
I know them well - I used them all the way back in the S/3 days). I see
a few folks love the idea and I didn't want to rain on anyone's parade.
But I couldn't let slide this claim that RPG-OA is the only way to
modernize the code of those stupid, ignorant RPG programmers. It was
many of these same programmers who managed to revolutionize the IT
industry and made possible the jobs of pretty much everyone on this
list. I'll take a solid RPG III programmer who knows MRP backwards and
forwards any day over an ILE expert who doesn't understand the
difference between a credit and a debit.

Okay, enough. Sorry you're not happy with the community. But RPG-OA
won't make it all better.

Joe

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.