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?
midrange.com
