×
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.
Nothing contradictory about it. Using the syntax of a CHAIN to perform
a generic CALL is simply a bad idea. I'd rather teach people how to do
calls directly from the start rather than try to shoehorn them into the
SETLL/READE functionality available to OAR (or RPG-OA).
As I said, I can see a very narrow set of circumstances where OAR is a
good idea. Most of these center on talking to data repositories that
don't fit the relational model, with XML being the primary case although
I suppose in certain circumstances an Excel spreadsheet might also be
applicable. Anything outside that, though, you're either stretching the
analogy, or else perfectly good tools already exist (e.g., ODBC).
But that's my own opinion. I've done enough cross-platform development
that I'm comfortable with my own assessment of this particular
technology; I'll let you guys debate the pros and cons of an extra-price
module that lets you do calls in a cool new way. It may be a good fit
for some people. I've seen worse technological directions advocated
(often right here).
No, my bugaboo is the elitist mentality that pervades this list more and
more that somehow RPG programmers are stupid and stubborn and can't
learn anything, when in reality the truth is usually just the opposite.
RPG programmers would love to learn new technology, if it really
provided them some benefit. They've been sold bills of goods on
everything ranging from Java to SQL to SOAP to PHP, every one being
touted as absolutely essential to their business and each one being
ultimately more useless than the last (and I'm not saying the
technologies are useless in and of themselves, but that most of them
don't fit most real world shops, not without some serious costs).
Meanwhile, their horrible 20-plus-year-old hybrid RPG II/III/IV systems
are running their businesses and keeping their kids in college. And the
folks on this list are telling them they're too dumb to learn anything
just because they've stopped drinking the "latest shiny toy" koolaid.
What's needed? I could tell you but I'd have to kill you <smile>.
Seriously, though, there are things needed. I could make a list of
about a half dozen practical things, any 2-3 of which would fit most
midrange shops. The trick to make a sale to management is to make sure
that at least one thing provides an immediate visible benefit to the
company (outside of IT!) while the others provide measurable benefits in
the short- and medium-term.
Anyway, this is more than I intended. I just to make sure at least one
person on this list isn't yammering about how old RPG programmers can't
learn new technologies. They can, they just prefer one that actually
make business sense.
Joe
midrange.com
