Re: IBM HATS vs. ?

Nathan wrote:

My focus right now is on the development of a new financial accounting database & package, but if we were drawn into a modernization project, my approach would be to let DDS screens go by the wayside, and use relatively little existing RPG code in the final product. I'd generate new applications based on new Web 2.0 UI templates and RPG models, but may cut and paste data validation and business rules from existing source, where applicable.

I'm giving the same advice, but the issue is time to market, if you
will. Management seems to wait until deploying on the web is mandatory
before making it a priority. That tends to mean that the green screen
side of the house has no time to prepare - it's a matter of jump in and
do it now!

The issue with leaving the DDS displays behind isn't so much the UI, but
that the business logic is tightly coupled to the DDS UI (not to mention
to the native I/O in general.) We have code that looks like this:

write sfl
exfmt sflctl

for i = 1 to slfrcdcount
chain item_master
discount code lookup...
set error conditions
endfor

We can dump the subfile in favour of an HTML form but it's going to take
a bit of work to recast that verification loop as a sub-procedure that
can be called from either green screen, ODBC / stored procedure, PHP,
CGIDEV2 or who knows what else.

If we'd been coding in a truly modular way in the past, we wouldn't be
discussing the need for screen scraping, we'd be arguing about Perl vs
PHP vs Grails :-)
--buck