×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Steve M's comments are spot on. It will probably be an expensive journey
and you are unlikely to have any recourse should you realize your toolset
is not delivering the promised results. Using a conversion tool will be
expensive, highly risky, and likely involve rework (you'll have to make
manual IU adjustments); doing it yourself will be expensive but the results
will be what you want and the rework will be substantially less. I think
the medium-term costs will be about the same but the expense of
run licenses adds cost every year; the long-term costs will be higher if
there are runtime licenses. So, the big unknown is if you'll get what you
want.
The problem with converting what you have is you'll be facing the same user
and application issues as before but on a new, harder-to-debug platform.
It will be hard to use the conversion tool AND to debug the generated
code. When you look at all that work (including the opportunity to fix
previous design errors) the gap between converting and
rewriting/reengineering becomes much smaller.
Any front-end conversion tool will introduce a vendor-specific "look and
feel" and it may be quite different from what your users expect. An
enormous amount of business logic can live in the HTML and it's foolish to
ignore the capability.
The key non-functional requirement when writing it all yourself is
standardization. i.e., code templates and prototype programs. How? Develop
a comprehensive but not unwieldy style sheet. Document standard layouts
for frequently-used programs by function: selection window, (for data
entry/update and inquiry) prompt and one display, prompt and multiple
displays, prompt and subfile. Remember a 5250 program with multiple pages
may be "better" if it's a single HTML page. A conversion program probably
won't optimize to that level.
Do the same for programs and service programs. Create copy books and use
them.
Don't forget to establish object- and field-level naming standards.
If you do this right, you won't be able to tell who coded a program.
At some point, you should build a few programs from the templates and
prototypes you've designed. It's a reality check to determine if the
templates are good and you should expect feedback from the programmers in
this exercise. Correct/improve/enhance the templates and prototypes...then
try the same exercise again with a set of more complex programs.
When writing it yourself, you can change/standardize field lengths (names,
addresses, and postal codes are often undersized). Change your dates to
data data-types and use functions to convert them.
When you have all this front-end architecture and design stuff done--and
IMO working on this aspect of the project is ultra-fun and
rewarding--you'll have a roadmap for your own team and/or for 3rd party
developers. *By relying on templates, many programmer decisions, coding
inconsistencies, and bad practices are eliminated.* Programs will work in
a known fashion and they'll be easier to debug and enhance. Programmers
wanting to do greenfield development "their own way" is not acceptable:
most engineers define and use standards. Why shouldn't software engineers
use standards too? There's plenty of opportunity for creative coding
within a program template!
Additional points:
1) Doing it yourself gives you flexibility in what and when you develop
specific application functions.
2) It's likely development will go much faster once it gets started.
Defining and verifying the templates will/should take months: remember that
six months' of coding can save six weeks of planning.
3) Conversion tools add to technical debt and you're unlikely to pay it
back: once the app is working, you're going to be pushed to do
something else.
4) It's better to train the users on one UI. Using a converted UI and then
changing it (see the previous point!) to a full-function ("native") UI
means two sets of code, two sets of testing, two sets of documentation, and
two sets of training. "Two" much work!
5) By rewriting, you'll be in control of the server interface
architecture. If your long-term plan includes moving to a non-DB2 for i
database, your design should reflect it, perhaps by designing a data
interface layer that isolates the application from the specifics of the
database.
Finally, having these templates available and gently updated over time
makes new development *much* faster while retaining the look and feel of
the base application.
In the last 30 years, I haven't written an interactive app or batch program
from scratch--I start with a template program.
As an Amazon Associate we earn from qualifying purchases.
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.