Re: 5250 to Web Interface / Application Modernization

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

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

I'm not an OA expert; "From what I've seen" is meant to convey that.  :)  But OA is a pretty straightforward premise, and what I do know doesn't stray far from the concept - pass 5250 opcodes to the mediator and return responses.

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).

<snip>

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?

The issue is that refacing tools such as mine or HATS or most others rely on the EXFMT being translated directly to a write to the browser and a wait on a POST operation.  OA gives you the ability to refactor that.  It's not a simple process, and it usually requires specific knowledge of the application, but it can be done.

One example: you can without too much difficulty repurpose a customer maintenance program with as a customer update web service.  This requires an initiator and a adapter.  The initiator receives the update request from the web service, makes the parameters accessible within the job, and the calls the OA enabled adapter.  The OA adapter then begins processing requests, such as an initial screen where you enter the customer number.  The adapter grabs the customer number from the global data and returns it with an enter key.  The customer master program continues on doing EXFMTs for the various panels, while the adapter plugs in web request data.

You get the picture.  The OA adapter acts as a conversational interface, changing the aspect of the interaction.  Once that's in place, you can encapsulate the business logic at your leisure, eventually replacing the web service OA adapter with a direct call to the business logic and also changing the 5250 code to call the same encapsulated logic.

It's NOT simple by any means, but it's possible.  It's even possible with some of the more sophisticated third-party scrapers but that entails writing the adapter logic in some third party syntax, whereas with OA you can use ILE RPG (or whatever your language of choice may be).

And once again, let me be clear: I'm not an OA expert or advocate.  It's just that there are really only so many ways to solve a given class of programming problem.  This particular class is the one I'm most intimately acquainted with (along with mechanical source code manipulation) so I'm able to provide general insights.