0

I have existing RPG4 programs with green screens, i would like to be able to call the rpg programs with Java and bypass the green screens.

I have done some research on this and IBM OAR (Open Access: RPG) keeps coming up. but i have not found a working example yet.

My goal is to create a web app to collect the the same information and feed it to the back end RPG

any help would be greatly appreciated

Lightning
  • 85
  • 1
  • 6

3 Answers3

3

EDIT

Delete: You can't.

Insert: A beginner will need to master several complex new concepts before tackling this.

END-EDIT

At least, not without changing the RPG program. Web requests are processed by server jobs, which run in batch - they are not connected to a 5250 terminal. Because they aren't connected to a terminal, when the RPG program tries to open the display file, it will fall over because there's no terminal to attach to.

In order for this to work you'd have to alter the RPG program to not try display file I/O if called by a batch process like a Java app (although Java isn't necessary in this web scenario).

One way to change the RPG program is to use input parameters; if you have them, then don't try to open the display file, but stuff the input parameters into the fields where the display file would have done. Since a display file also outputs from the program you'd need to reserve some parameters for the output information as well. This could get very ugly if a subfile is involved, as there would be potentially thousands of parameters.

OAR comes into the picture because one can write an OAR handler that continues to use the same display file I/O operations, but to direct the actual I/O elsewhere, like STDIN and STDOUT for an HTTP type application. Jon Paris and Susan Gantner have written an article called Getting a Handle on RPG's Open Access which you might find helpful. It's in the July 2010 e-edition of IBM Systems Magazine.

Better perhaps is to extract the business logic in the RPG program, implement it as stored procedures which can be called by the web application via traditional ODBC / JDBC. One can write stored procedures in RPG, so that's not as hard as it might seem.

Buck Calabro
  • 7,558
  • 22
  • 25
  • Buck has a point, to use OAR you must have the source to the RPG program. Also note it has to be an RPG IV program. You only have to change a couple lines of code to use OAR, but they do have to be changed. SCreen scraping can be done for program you don't have the source for. – Charles Jun 08 '15 at 19:55
  • Note that an OAR program that handles a DSPF doesn't need an attached workstation session. I modified the [OARDEMO SUBF_HBUF](https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/We13116a562db_467e_bcd4_882013aec57a/page/Open%20Access%20samples) *MODULE to communicate with my user *MSGQ by replacing the DSPLY op-codes with calls to procedure dsplyMQ() that I wrote that used the QMHSNDM API. Submitting the SUBF_BUF *PGM to batch worked cleanly. – user2338816 Jun 09 '15 at 07:04
  • Yes, OAR can redirect the I/O. But using OAR isn't as simple as (say) OVRDSPF; it requires changes (however minor) to the RPG program. – Buck Calabro Jun 09 '15 at 17:12
  • I do have full access to the RPG IV source code i understand we can add parms to the programs. we just have a tremendous number of interactive RPG programs that we want to put a web face on. so if i can find a way to limit how much we change the existing RPG programs that would help i read thru the article by Jon Paris, but i did not see anything about redirecting screen interactions. – Lightning Jun 09 '15 at 17:53
  • This is a very different question to what was asked. See the answer @Charles posted. OAR allows for ANY I/O to be redirected. Jon's article doesn't specifically deal with display files but one needs to start somewhere... – Buck Calabro Jun 09 '15 at 18:00
  • @Lightning, Buck is right, ORA allows for anything to be redirected with just a few changes to the RPG. But you have to buy or build the handler program. ORA just "enables" the use of the handler. Take a look at the tools and the the Modernization Redbook I provided links to. – Charles Jun 09 '15 at 18:11
  • No matter what methods are used, mods must be made to various things. (Wouldn't OVRxxxF HANDLER() be a great addition to OVRxxx commands?) RPG source members w/WORKSTN F-specs might be duped so new OAR *PGMs can be created w/out modding current source. As the method is learned/understood, dupes could be phased out. Often it's just a single F-spec keyword to add, and it can be conditioned with /IF DEFINED(...). The HANDLER() is harder but totally separate. – user2338816 Jun 09 '15 at 23:38
  • Also, the virtual terminal APIs can enable batch control of 5250 programs. However, [**Albert York's TNAPI**](http://www.albertyork.yolasite.com/samples.php) would be easier and another way potentially to avoid changing programs. And of course it's always (almost always) possible to code your own telnet client that runs interactive programs. (It's often tricky saying "You can't" when asked about programming something.) – user2338816 Jun 10 '15 at 08:17
  • Very respectfully, if the general problem of 'I want to webify thousands of RPG programs quickly' were solvable via a programmer utilising a few posts to Stackoverflow, Profound wouldn't be in business very long. I edited my answer to make it clearer. – Buck Calabro Jun 10 '15 at 14:29
  • I think some assumptions are being made here, i am not looking for an easy out, i am just looking for a way to direct input to the rpg without using 5250 screens. I have already done many java applications on remote machines calling back end RPG on the iseries using the jt400.jar. that method has worked extremely well for us. but if i can some how direct input to the programs without gutting the screens that would save some time. i have read on many places that it can be done, but no real info on how to do it. – Lightning Jun 10 '15 at 19:15
  • And more respectfully, I'm lightly pulling your chain, Buck, because it's been 3-4 years since we've communicated more directly. This user ID was going to be temporary as was the anonymity. But it's been handy being unknown considering other time demands. In any case, you answer was good; and the last edit made it better for the future. – user2338816 Jun 11 '15 at 01:35
2

OAR is probably going to be your best bet....

However, every example I can think of that I've seen has resolved around building a handler to replace a printer file (PRTF) or physical file (PF).

Replacing a display file (DSPF) is a whole other ball game. Primarily because the 5250 protocol is an "intelligent" protocol; unlike dumb character type protocols such as used by ANSI/VT100.

It certainly can and had been done. If you have a single basic screen, you might be able to do it. But for a complex application with multiple screens and subfiles you'll probably have a tough time. Especially if you don't have a in depth understanding of the 5250 protocol.

I'd recommend you take a look at one of the vendor toolset designed to use OAR to replace a 5250 screen with a web page. Those vendors have put years of time and effort into developing the handler needed.
http://www.profoundlogic.com/solutions/rpg-application-modernization.html
https://asna.com/us/products/wings

You might find the following publication useful:
Modernizing IBM i Applications

Lastly note that ROA isn't the only option. There's an older technique, "screen scraping" in which your application basically emulates a 5250 terminal. It's simpler than a full ROA handler, but the end result is simpler also. IBM has it's own tool, HATS. And for instance Profound logic also has a tool, GENIE. But you could conceivably build your own screen scraper, the opensource TN5250J would probably be a place to start. But even this would be non-trivial.

Charles
  • 21,637
  • 1
  • 20
  • 44
0

You should use a mix of parsin json on the iseries(this eliminates the subfile problems), one good javascript framework( I've used Extjs) and The Apache server for I.

I've developed a HTTP services framework based on json parameters send directly from the browser using Ajax, processing each request with any ILE language program(mostly rpgle) and returning the result in pure json created inside the program. With this approach, you just send/receive business data, leaving the front-end to the Javascript framework.

Hope this helps. Contact me if you need more help.

Jairo R. Flores
  • 724
  • 4
  • 11