Algo más sobre Open Access en RPG (y el i 7.1)

Continuando con los anuncios del i 7.1, sucesor actual del AS/400 (perdón, iSeries, etc), Scott Clement publicó el 22 de este mes un artículo en System I Network, que también destaca las principales novedades y virtudes del nuevo sistema. De entre los distintos puntos destacados, nuevamente destacamos las referencias a los cambios en el RPG, fundamentelmente el concepto de Open Access:

Rational Open Access: RPG Edition

The biggest RPG feature of 7.1 is RPG Open Access. Open Access (previously referred to as "Open I/O" in early discussions) makes it possible for programmers to write "handlers" that take the place of file I/O when you use RPG's native file opcodes.

The way George Farr explained it, under the covers, anytime you read or write from a file, RPG actually calls a routine in the OS to handle that request. For example, if you CHAIN to a record in a PF, RPG calls a routine in the database manager that retrieves a record by key. Similarly, when you use EXFMT to display a screen, it calls a routine in the display file management portion of the OS. So while we tend to think of these operations as "reading a file," the RPG runtime is really just calling a routine.

What IBM has done is open those routines up to you. You can now have it call a routine of your choosing rather than one provided by the OS. That way, you have full control over what happens when the program tries to read a file. Will it actually read a file? Or will your code simply calculate the value returned for the fields in the record? It's up to you.

People are excited about this new tool because it makes it possible for existing RPG code to use opcodes like EXFMT, READ, WRITE, etc., against a display file—but they can provide the routines that handle the display I/O. So the routine might decide to display a web page instead of a display file. Or it might decide to communicate with a Visual C++ program running on Windows, and that Visual C++ program might bring up a GUI window.

Third-party vendors are already providing prewritten handlers that RPG Open Access can call. So if you want your RPG programs to output to the web instead of outputting to a 5250 terminal, you can buy a "web" handler from a vendor, pop it in, and your program now goes to the web!

If, in the future, you want your output device to be an iPhone or iPad or Droid, it's just a matter of buying a new handler. The only change required to your RPG program is the F-spec, where you'll need to code the HANDLER keyword to tell it where to call the handler routine.

Unfortunately, I don't really have the space to go in-depth about RPG Open Access. That's something that could easily fill an article by itself. Or several articles! But if you'd like to see a more in-depth technical description, I suggest that you check out the technical documentation on the RPG Cafe.

RPG Open Access is not included with the RPG compiler, however. Instead, you have to purchase it separately from IBM. So, unless you plan to write your own handlers, you're going to need approval for two different costs: Open Access itself, plus whatever the vendor is charging for their handler.

On the plus side, it's available for both 6.1 and 7.1, so you don't even have to wait till 7.1 before you can try it out.

Sin embargo, Scott mantiene sus reservas sobre el alcance de Open Access, cuestionando su verdadero nivel de cambio, al no modificar esencialmente la arquitectura:

My opinion is that Open Access is overhyped. It has been represented as the greatest thing ever and the salvation of the RPG language, and in my opinion that's blown way out of proportion. All it does is enable a new way of calling subprocedures in a service program. Instead of calling them directly, you do file opcodes, and the file opcodes call the procedures.

Plus, the existing SPECIAL file support, although limited, never got a lot of adoption in the RPG community. So why come out with new tool that's almost identical to a tool that's hardly used? Is there really that much demand for it?

Furthermore, from the RPG program's perspective, it's still reading/writing a display file. Even though you may have another device on the other end, RPG doesn't know that, and so it can't take advantage of it. It can't behave like a proper web application, because it's trying to control the flow and act in a stateful manner. It can't behave like a proper GUI program, because it can't take action based on mouse events or what keystrokes a user typed into which custom controls. All it knows is how to read/write data to a display file. And we basically already had the same thing with screen scrapers, didn't we? I realize that Open Access is intercepting the program logic at a different level than a screen scraper would—but other than that, isn't it still doing the same thing? Transforming a DDS-defined 5250 screen into a GUI screen, while tricking the RPG program into thinking it's still 5250?

No obstante, la idea me resulta más que interesante. Poner fuera el destinatario/orígen de una lectura/escritura, abre posibilidades. Es cierto que esto puede ser especialmente útil para terceros proveedores, pero justamente, es probable, desde mi punto de vista, que sea posible sacarle provecho a través de Plex, con la misma licencia, y código basado en patrones.

Más allá de los apuntes sobre Open Access, Scott resume otras novedades, tanto sobre RPG como sobre herramientas de desarrollo, licencias, almacenamiento. Para la consternación de muchos desarrolladores, el entorno de desarrollo basado en PDM, SEU, SDA, RLU, DFU, se acerca cada vez más a su fin. No quedará otro remedio que acelerar el uso de las nuevas IDEs...