Re: 5250 to Web Interface / Application Modernization

I've been watching this thread a little - I think I have something to consider here, about OA.

First a level set, which some here know about. In 2011, I think, I wrote an article, __Open Access for RPG Special Report: What It Is, How It Works, and Hands-On Experience__, in System iNEWS.

Being on the CAAC (COMMON America Advisory Council) and the ISV Council while at RJS Software, I'd been hearing about OA from the start.

I've since done a handler for converting native I/O for data to SQL technology.

So I'm going to posit that OA is simply one thing - a way to allow the RPG developer to work with non-standard resources while allowing the use of standard RPG I/O operations.

OA __preserves__ the underlying architecture - the RPG engine is still running as always, making requests of the various system resources to do things like read data from tables, write to tables, read/write with screens or reports.

This does not change when using OA techniques - the only changes, IMO, is that these RPG requests are diverted to the handler, which has to communicate with RPG the same way the system does without the handler.

So I'm not sure how this fits with terms like "incrementally towards a newer architecture" - I believe that OA itself is __not__ that newer architecture.

Whady'all think? Can OA be used to prolong the use of IBM i in a company? Perhaps, maybe even probably. Maybe it can, by using things like web services in a way that a different architecture or technology could use outside of RPG some day.

And OA is not limited to UI - I have focused on its use with database, as have others.

And on a slightly different tack, a software vendor said, we know how to use system APIs, I don't think we need this. And that is maybe right for a vendor - but vendors are not the final audience for this, users are.

OK, enough said, best to return to my main tasks.

Regards
Vern

On 4/11/2019 12:01 PM, Nathan Andelin wrote:

Joe,

I've always enjoyed your thoughtful, clear, and indirect writing style,
which for me is uniquely persuasive. You summarized 3 broad options:

1. Reface.
2. Rewrite.
3. Replace.

Then you delineated a 4th:

4. Refactor.

The only thing I can think of that you may have missed is:

5. Retain the status quo (assuming that display files and 5250 emulation
works for some).

I'd like to request further clarification on one of your OA assertions,
which for me is like returning to a mine field, given some of the heavy
hitters who have been following this discussion.

6. From what I've seen, OA is a true hybrid. Since it acts as a

mediator between the 5250 opcodes and the user interface, you can reface
an existing program and then replace some of it with "newer" code, and
thus move your code incrementally towards a newer architecture.

>From my perspective OA replaces IBM i workstation data management with an
OA handler, replaces the 5250 data stream with JSON or XML or something
comparable, replaces DDS display files with JSON or XML or comparable
syntax, replaces the 5250 emulator with a JavaScript applet (for lack of a
better word). Although you're replacing IBM's implementation with newer
versions, all of the same canned architectural components are still there,
namely:

1. Server-based display files contain I/O elements, positioning,
attributes, subfiles, etc.
2. Workstation data management.
3. Proprietary data streams.
4. Browser-based emulator that transforms proprietary data streams into
browser DOM objects.
5. Traditional op-codes EXFMT, WRITE, READ, ETC.

In your earlier writing you liked to distinguish between "server-client"
which was your label applied to IBM's workstation data management vs.
"client-server" which was applied to "newer architecture".

Given my observations about OA architecture and implementations (1-5, etc.)
How is that incrementally moving toward a newer architecture?