|
You are on a dream project. Envy.
And I’m write there with you on 5250 for personal use.
Jay
On Apr 11, 2019, at 10:15 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
Tell me about it. I'm renovating an old ERP system with service programs and even though the renovation is early stages, it's already giving us benefits in de-duplication of code and easier debugging. As we continue to move business logic into service programs, we'll be able to write external interfaces without breaking a sweat, and still leave the 5250 interface where it's best suited. To this day I prefer 5250 terminals on shop floors; it's a lot easier to mash an F-Key than click a mouse. :)
On 4/11/2019 9:08 AM, Jay Vaughn wrote:
I really wish rewrite was a practical option for most shops because you sure can write some really nice, clean, efficient, modular code with ILE and sql these days on the i.
Jay
On Apr 11, 2019, at 10:01 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
I've avoided this conversation while it was in the "high simmer" stage. Now that it's cooled a bit, I'll offer my own two cents. This is not an attempt to argue against anyone's position, it's just my observations. Remember my background covers most of the bases: I was the manager of architecture for the world's largest AS/400 software company (yes, it was long enough ago that we called it AS/400), I wrote the first book on converting 5250 interfaces to browsers, I wrote an automated conversion product that is still in production today, and I've worked in various capacities in end user shops. So I think I've seen most of the angles of this particular conversation and may perhaps provide a slightly unique viewpoint. That being said, I don't think anything I'm about to say is revolutionary.
1. There's a very different goal for a software shop and an end user shop. Putting on my tool creator hat, the ultimate solution is always to encapsulate the business logic in stored procedures and attach that to the database, enforcing the business rules either through controlled access or database triggers. (And THAT is a discussion I'm definitely going to stay out of). Then you write your application interface using direct the database access provided. At that point, you can use any UI technique you'd like, from web services to mobile apps.
2. Reality is that most shops will never get there, for various reasons. My favorite ask on that is whether or not you need remote browser access to maintain your chart of accounts. Most folks (especially the accountants and the auditors) shudder and twitch at that thought.
3. So you have a fundamental question: reface or rewrite. There's a third option, replace, and that's the one we as the Guardians of the IBM i want to avoid as much as possible.
4. Refacing is a tenable solution. This includes everything from IBM HATS to third-party screen scrapers. It has a wide variety of advantages, from time to market to ease of use. But because you use 5250 opcodes, it does tend to lock you into the 5250 paradigm. With enough effort, you can break out, but at that point you're losing some of the other benefits.
5. Rewriting is the architecturally purer approach. The disadvantage there is the initial cost. There's a lot of learning curve that may or may not have direct ROI, and a lot depends on how easily you can separate your business logic from your user interface. Existing midrange code runs the gamut there. Once you get everything in place, it's much easier to develop new applications that behave the way that modern users expect. And at the end of the day, I think that's what will best extend the platform's usefulness: being able to work and play cleanly with the rest of the world.
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. I don't know how well OA-enabled programs work and play with screen-scrapers, but I have to believe they've put some thought into it. The easier that interface is, the more OA lends itself to that sort of approach.
7. And that's my final point. Even given the arguments above, there is no "best" solution, it's going to depend on the shop. One man shop where the IBM i is already slated to be replaced? Go with the cheapest screen scraper you can find. Semi-custom software shop with lots of clients? A rewrite is almost always a better solution, just from a control standpoint. However, most shops fall somewhere between those extremes and you're going to have to decide what's best based on budget, business goals and personnel. You can, for example, use OA as an initial approach and build your way up.
What do the corner office folks think about the IBM i for the future? You won't be able to get the money for the more involved approaches if you can't guarantee the IBM i as the long term solution. You may have to start with something quick to validate the i's value proposition and then move on.
Ah, it's a fun discussion!
--
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
--
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
midrange.com
