Re: 5250 to Web Interface / Application Modernization

This is my last comment one this topic - I'm really surprised that neither Scott or Brian has said anything because I know that they know the answers better than I do - that said.

While you may understand how OA is _often_ used Nathan (i.e. when refacing existing 5250 programs) it is also abundantly clear that you don't understand how it _can_ be used.

The simple fact of the matter is that OA enabled products have allowed many customers to give new life to their 5250 apps - in some cases buying them the time to re-do the apps "properly". It has enabled programmers with no web skills to develop forward looking apps while still using many of their existing skills. I know of many cases (as I'm sure do Profound, Rocket, Freshe, and others) where the IBM i would probably not be a presence in the shop any longer if it were not for their products. If a shop has the time, skills, and budget to redevelop everything then of course they can produce a better more efficient app. But that's not the reality most shops face and to pretend otherwise is just silly.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 10, 2019, at 2:29 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

On Tue, Apr 9, 2019 at 6:51 PM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

The "UI" debate rages on ...

Your post included a lot of thoughtful input, Mark.

Some 5250 developers express concerns about learning HTML, CSS, and
JavaScript. I'd like to alleviate those concerns and suggest that they'll
enjoy it very much because it provides a surge to be able to improve the
user experience and functionality of your applications. After learning a
little, you begin to see how you were shackled by the 5250 and display-file
paradigms.

Under the display-file paradigm, a typical thing is to assign "attributes"
to input and output elements on a screen, condition those attributes with
indicators, then write server-based codes to set the indicators on and off,
according to the effect that you want to implement.

Under a browser client-server paradigm. UI elements have a broad range of
inherent attributes that may be dynamically modified during run-time via
JavaScript by referencing the element's ID or name. For example:

element.enabled = false;

Might be coded to disable an element's input capability, and cause the
element to become shaded.

Under the 5250 paradigm you must engage the server in order to achieve a
similar effect, which in my opinion is a waste of I/O and other server
resources. Use a little bit of JavaScript and you end up with a lot more
efficient and intelligent use of local resources.

One complaint with OA handlers is that the size of the data streams that
are exchanged between client and server increase so much, along with server
processing. An interface that once appeared snappy due to minimalist 5250
data streams, lag after implementing an OA handler. OA data streams
effectively perform full page at a time updates.

It makes a lot more sense to use local resources for UI effects,
asynchronously request minimal server resources when the DB is required,
and perform minimal UI updates via the response.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com