Hi,

Sorry for the long "multi-answer" ...

Am 02.01.2025 um 14:44 schrieb Justin Taylor:
Retrofitting a single program with a modern UI is one thing, but what about
thousands? I see that as the biggest hurdle. You've got teams with the
capacity to maintain and enhance the current program suite, but not enough
to refactor everything.


Slowly and steadily - one program after another. Extract business logic to service programs and make it reusable.

If you change the function of a program it has to be re-tested anyway - so it's OK to make architectural changes without function changes in such cases.

And modernizing the database from DDS to SQL-DDL is doable on a one-file-at-a-time basis, too. Create tables and make the old PF a LF on that table. Then your programs won't notice the change, and you can add new SQL features without disturbing existing code.

Make small steps first - then accelerate more and more.

Am 02.01.2025 um 14:59 schrieb Brad Stone:
It's been 25 years plus since CGI programming has been a viable option.
And it still is. Even longer since ILE has been available to try to
encapsulate functions.

Yeah - but technology shifts on IBM i are happening in "continental drift" speed.

Which isn't bad at all, because it means, you have time to do it if you start early enough.

The other side of the coin is, to me at least, is that users used to the
"fast entry" of green screens wouldn't want a web update, but would
eventually use it after the initial shock.

Not only that - since some years we are writing NEW code with 5250 interface, after the a specific group of users worked on a web GUI for over 10 years, they wanted back to green screen - not only for "speed", but for predictable workflows.

I know a lot of the applications I use for business are all web based now. At first I hated it (and in some cases still do) but I grow to tolerate them.


I can relate - peaceful co-existence is my option.

Am 02.01.2025 um 15:47 schrieb Steve M:
To add to Craig's post - Transportation is the same way. The dispatching
systems have been on green screen for so long, any long-time dispatcher will
refuse to use a GUI.
[snip]
Extremely resistant to any data entry changes.


Since I am from transportation and logistics - yes, it was like that. But today not so much. >95% of all "papers" come in electronically. Even small shippers are using web front ends to notify their shipments. So no - it's not like that anymore.

Am 02.01.2025 um 15:58 schrieb Patrik Schindler:
Well, one could say, that is what one gets when one piles up technical debt over years. But it is also the natural (speak: monetary) way of things.

I wouldn't categorize this as technical debt. Technical debt is making a decision for a solution or architecture knowing, that it is wrong, but doing it anyway.

Not modernizing an application is a business decision. Also a 5250 dialog is not a technical debt - its is an UI decision that was made when nothing else was available - or because you wanted it that way.

If you still write tons of business logic into a 5250 dialog program today - not extracting it into services programs or called programs - that would be technical debt.

Thousands of applications haven't been written in a year, and likewise they can't be replaced by what is essentially a new application in a fraction of that time. And, TBH, there's nothing more frustrating than doing the Sisyphus thing for years to come. That's why I am a friend of not doing it "when there's time", but do it properly as a one-time project.
[snip]
On the other hand, if *the* central application suite of a company must be — more or less — rewritten anyway, this might give way to discussions about getting rid of IBM i. From a boss/monetary point of view, this consideration appearing on the slate is somewhat natural.


This is the problem with "big bang modernization projects" - if you go to your boss and say "we need to re-write the application in 2 years to modernize" he might as well switch to SAP - and another IBM i shop leaves the platform.

So I'm more a friend of "slowly but steadily" - modernization from the ground up. First modernize your database, then extract business logic out of dialog programs into services programs and make it independent from the UI.

If your boss needs quick visible results, than a web-facing tool might be a good solution - then users and bosses see "modern UI" and even as the foundation is still 1980s-style code, you get the time to do the job properly in the background.

For the record: I'm a keen proponent of TUI applications and my view is thus biased/spoiled.

#metoo

I think of TUI/5250 as a really good way to develop a solution fast. Maybe even as a prototype for a later Web-GUI - as long as I think of the UI as "user interface ONLY" - no business logic in the same module - it's pretty future-proof.

Kind regards,
Daniel

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.