RPG Open Access

[giduturi]

Hi,

Just wanted to check something on the RPG Open Access. I have the following questions:
1. Why did RPG OA not gained popularity?
2. What are the issues with RPG OA if there are any ?
3. How tough is it to implement RPG OA to handle Native I/Os.
4. Are there much shops using RPG OA ?
5. How hard is it implement RPG OA in a very old Legacy RPG Applications.

[tomliotta]

I don't know any answers, but I'll throw in a bunch of comments for a start. Others can refute, confirm or go in completely different directions. Maybe answers will be out there.

1. Popularity? You can ask the same thing about almost every advance in the "AS/400-OS/400" series for almost three decades. I recall many developers needing almost to be dragged from the 'Programmer Menu' (see STRPGMMNU) to PDM. RPG III (or RPGIII-style, i.e., fixed columns, etc.)) is still common enough. I have two older model 170s and a fairly nice model 515 at home; it's almost trivial to use a 170 as my interactive front-end into the 515 back-end if I wish. Yet it took a lot of sites a long time to see how relatively inexpensive interactive front-ends could be used to reduce the "interactive tax" when it became big news. Partly related to that but also providing its own advantages, WDSC was available for a long time, followed by RDi. Yet SEU survives all over the world. I wouldn't be surprised if a majority of printed reports still don't use compiled PRTFs, relying on QPRINT or QSYSPRT. Query/400 still seems more "popular" than QM. I'm not sure how many sites even make use of source files with record lengths >92.

The list will be long if others want to add to it, but that's as far as I'm interested in it. (I could go on, and on with it.) In comparison, RPG-OA seems on par to me.

2. Issues? About the only issue I can think of is a limited set of basic examples. That's actually got me thinking again about creating a few. True, various articles exist already; but maybe a slightly different slant is possible. In short, the main "issue" is that its potential isn't demonstrated enough, and when it is, it's done in style that assumes very progressive developers. As much as I appreciate that, I wonder if a large bunch of developers might like to see it done "RPGIII-style" so that it looks like it's actually compatible with existing code rather than requiring a new style of coding.

3. Tough? IMO, it's not as tough as rewriting a reporting program to output to a .CSV rather than to a printer, or rewriting a simple display to communicate with a browser. Much of it is not easy. It takes study and practice. But seriously, after creating just a couple proof-of-concept tests, it can almost become obvious (as long as you also learn how to write to a .CSV or whatever). But in many ways, native I/O is the biggest target by far. It's hard to imagine any use, say, to modify an existing SQLRPGLE program to make it do native I/O instead, or a current set of programs that do browser work to do DSPFs. It's not clear what is being asked.

To me, it seems maybe just a notch above trigger programs as far as "tough" goes.

4. Shops? Probably hard to say. May depend on whether that counts only in-house or counts any acquired utilities or products. I've seen it used, but only a very tiny sampling of shops.

5. Hard in legacy? As above, that's a big part of why it exists. Legacy code is possibly where it's most expected. For the most part, actual changes to legacy code itself is pretty much just adding a keyword to affected F-specs. That's the absolutely trivial part. But the work is in writing the new programs that the keyword calls. Coding procedures for OPEN, CLOSE, CHAIN, etc., isn't too different (in difficulty) from different coding for INSERT, UPDATE, DELETE, before and after.

[jtaylor___]

#1. I just don't think there's a large market for it. The hardcode 5250 folks are going down with the ship. Those devs who want to move beyond 5250 have already done so using other methods that have been available for a long time.

IMHO, YMMV, my WAG, and all that stuff...

[Scott Klement]

1) It seems to me that you are wrong here... it is very popular as a way of interfacing to more modern screens.

2) Question is too broad. What do you mean by "issues"?

3) Again, the question is too broad. It can be very easy or very hard, it depends on what you are implementing and what it does. Remember, OA is just an interface... what the OA handler does can be just about anything. So some things might be tough, some might be very simple.

4) Isn't this the same as question 1?

5) RPG OA requires RPG IV. It cannot be used with RPG II or RPG III programs. Calling an RPG OA handler from even the oldest and most "legacy" RPG IV program is extremely easy... it is no different from any other file.

[jtaylor___]

1) It seems to me that you are wrong here... it is very popular as a way of interfacing to more modern screens.

2) Question is too broad. What do you mean by "issues"?

3) Again, the question is too broad. It can be very easy or very hard, it depends on what you are implementing and what it does. Remember, OA is just an interface... what the OA handler does can be just about anything. So some things might be tough, some might be very simple.

4) Isn't this the same as question 1?

5) RPG OA requires RPG IV. It cannot be used with RPG II or RPG III programs. Calling an RPG OA handler from even the oldest and most "legacy" RPG IV program is extremely easy... it is no different from any other file.

Ref #1, what makes you say that?

[Scott Klement]

Ref #1, what makes you say that?

I work for a company who sells an open access handler, and it has been a huge seller. We have hundreds of shops using it, and some of them are software companies who sell their software to hundreds more. Some customers are big companies that are running 10,000+ simultaneous users on it. When all is said and done there are hundreds of thousands of users using our open access solution every day. And we're just one of the vendors in the business that are using it.

Why do you think it's NOT widely used?

[JonBoy]

Hi,

Just wanted to check something on the RPG Open Access. I have the following questions:
1. Why did RPG OA not gained popularity?
2. What are the issues with RPG OA if there are any ?
3. How tough is it to implement RPG OA to handle Native I/Os.
4. Are there much shops using RPG OA ?
5. How hard is it implement RPG OA in a very old Legacy RPG Applications.

I'm a bit late to this thread but I'll add my 10 cents worth.

1. It is very popular as Scott has mentioned. Many vendor products such as Profound's (the one Scott is associated with) and look, Asna, BCD, Rocket, ... all use it for their 5250 modernization products. Where it is not as popular as it should be (in my opinion) is for devices other than 5250 display files. For example - why write to a database file and then copy it to an IFS file with CPYTOIMPF when by using an OA handler you can do the whole thing in one step using the original program. Personally I think that IBM caused this problem in part by charging for the feature for the first two years of its life. This meant that people who were not interested in 5250 modernization were disincented from trying it.

2. The main issue I have encountered when using old programs are two-fold. First it only works for externally described files and so cannot be used for O-spec defined printer files for example. Second overlapping indicator-controlled fields. Imagine an output format with three fields defined. A and B are each 20 long and are output side-by-side when indicator 50 is on. C is 40 long and is output in the same columns if indicator 50 is off. OA will receive all three fields plus indicator 50. It will not know what the DDS "knows" i.e. that 50 controls which field(s) are to be used. This situation can be handled but requires examination of the DDS or (in the case of display files) the file object itself. The OA display modernization tools all take care of this.

3. Trivial. Add the HANDLER keyword and you are done as far as the RPG is concerned. Writing the handler is another matter.

4. Yes.

5. It only works with RPG IV so anything in RPG400 needs to be converted first. Beyond that it is no harder with a legacy RPG app than anything else.

[jtaylor___]

...
Why do you think it's NOT widely used?

I accepted the OP's premise on it's popularity due to the number of articles and online questions/discussions I see on the topic.

[JonBoy]

I accepted the OP's premise on it's popularity due to the number of articles and online questions/discussions I see on the topic.

If you read my post it may help explain it. The majority of usage is undoubtedly through the display file modernization tools - so the discussion would be about the tools - not OA per-se. The other usages, for reasons I mentioned, are less commonly discussed because (sadly) they are less frequently used.

[jtaylor___]

If you read my post it may help explain it. The majority of usage is undoubtedly through the display file modernization tools - so the discussion would be about the tools - not OA per-se. The other usages, for reasons I mentioned, are less commonly discussed because (sadly) they are less frequently used.

True