Re: AW: Open Access to be generally available as part of the RPG compiler

Kurt

Scott gave you some good thoughts on this in his post. The main benefit is what OA offers to GUI - it can all be done by the regular developer using native opcodes. You do have to have some file on the iseries that "matches" whatever is your remote data source - an MSSQL server or Oracle will put some constraints on this. A web service, maybe less so. An IFS file will have other needs in this regard.

Now there are things you just can't do this way. Sometimes this is because of limitations in the underlying engine - our product does forward-only cursors using ODBC on a middleware PC. That means you don't do SETGT or READPE. At least not that I've tried. So you do a workaround that is close enough.

Yes, i agree, OA is exactly a service program under the covers - that's how my handler works. There's a main driver procedure that checks what the opcode is and calls to the procedures I wrote for each one.

As my boss said when we first heard of this, sounds like a very thin veneer over API calls - or SRVPGM procedure calls. And he is right. But we're not the audience - although this seems more of a vendor thing at first, I don't think it has to be - unless you're talking the 5250 stuff - there's a good reason why there have been relatively few software vendors in that arena over the years.

I think what we have is a way, not just for vendors, to make your own tools - just as you made a wrapper around JDBCR4. The effort and level of knowledge in your shop are a couple factors in whether to go this route, I think.

Now there are things harder to do - like CREATE TABLE statements to the remote database. I do have ideas on how that could be done - you are able, for instance, to pass additional information to the handler - I can see ways to kind of fake out things and pass SQL statements not through the file on the f-spec but through some other means - a reference code in a table, etc. It's a bit of a stretch but not unthinkable.

This whole thing did come out of a requirement by a vendor to IBM - to be able to work directly with web pages from RPG - it got changed along the way to this more general functionality.

So I don't know - another person in these lists - Larry Ducie - did say he'd had some surprisingly interesting results from his experiments. And he's not a vendor - so maybe????

And now that it's included with RPG and the OS, hey, open source has just become an option. That was one of Scott's initial problems with this, as I recall. Him or someone, anyhow.

Regards
Vern

On 2/2/2012 4:40 PM, Kurt Anderson wrote:

I'm glad you posted this Vern. I wanted to ask about using OA to access external databases, but figured I should read up first. But I think you've laid it out pretty well.

My question is this, other than trying to wrap up Scott's JDBCR4 into appearing as native I/O... does OA offer any other benefit?

I think JDBCR4 is wonderful. I've created my own little wrapper around it (at least around its procedures I use) that will log the transactions. With the talk of OA, I've been wondering how it could be used to our advantage in regard to accessing MSSQL.

It's starting to sound like OA is a service program "under the covers." To which I say: "why not use a service program?" This is from the perspective of a non-vendor. I can see where a vendor could put together something and offer it to shops as a programming tool.

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Thursday, February 02, 2012 4:22 PM
To: RPG programming on the IBM i / System i
Subject: Re: AW: Open Access to be generally available as part of the RPG compiler

Hi Scott

I agree with you here, and I also make the same point that Jon does - the buzz has been on 5250 modernization, but that's a really big task that I don't want any part of. We both know of others in the modernization arena that have not used OA with their product line.

An obvious possibility for me is remote databases. You have put together great material on using JDBC - your service program could be the core of a nice handler - just as I've done that with our RPG2SQL product.

One of the things about OA is that you have to work in the mold of native file I/O - this just won't fit many of the new resources, so OAR is not a good thing for those.

So if you can think of getting data from somewhere as a CHAIN, you're in business with OAR, seems to me. And many shops have people that can do this. Or working with IFS files. Again, the things you've put together could be the engine for such a handler.

Hey, there go 2 cases that are not all that unusual - but maybe they are the only 2? I can't think I should believe that. But the imagination of this community will tell the tale.

And I think I'm all for learning new stuff. As you said, however, there is this huge body of code that companies just can't afford to change.
There's no ROI in change merely for change' sake - some of the naysayers seem to be in the latter camp.

Regards
Vern

On 2/2/2012 2:49 PM, Scott Klement wrote:

hi Justin,

-snip-

So that's my opinion, RPG-OA is a great short-term, quick-fix. It's
better than the older technique that involves interpreting the 5250
datastream. But it shouldn't be your end-goal.

Jon Paris constantly makes the point that RPG-OA is useful for other
things besides just user interfaces. He told me this more than 3
years ago, and I've been thinking about it since then. I've found one
or two cases where this makes sense -- but it's extremely unusual.
(And THAT is why I don't think SPECIAL files ever caught on.)

-SK

--
This is the RPG programming on the IBM i / System i (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.