RE: DDS Screens To Java

Scott asked some details about WebFacing:

>How long did it take you to convert everything?

I converted about 5000 (five thousand) display files (containing an average
of 4 record formats each) in about 3 days on a 1GHz Athlon. That results in
some twenty thousand beans and another twenty thousand Java Server Pages.
Give or take.

>We have about 900 display files
>and about 1600 programs and
>are expecting it to take about 6
>years the manual route with 4
>programmers working on it.

The programs remain untouched in the WebFacing process.  They run
interactively like they always did, only they are tricked by OS/400 into
working with the generated Java beans instead of the workstation controller.

>We don't want to take that long ...

Um.  To do what?  I am running the treadmill here trying to get a FIRM
definition of just what management want/expect the end-result to look like.
WebFacing is little more than putting a grey (GUI) screen on the RPG
back-end.  If your application uses 4 record formats to enter a new
customer, then you'll need to have those same 4 'screens' to do it WebFaced.
Why?  Because the RPG didn't change.  That's the benefit AND the trap.
You'll have a browser-based modal RPG application.  If you want a different
look you'll have to put in more work.  So... what do they expect?  What
happens in 'the manual route?'

>so we were checking around with the big
>guys and most of them say about 9 months
>to a year, but management saw the price
>tags and wanted to know if we could go cheaper.

I got the WebFacing conversion done lickety-split.  Websphere was much more
work; much more.  I liken my situation to trying to load Windows XP on a
386sx-33.  It can probably be done, but there isn't a sane person who has
done it.  Help is hard to come by for the simple reason that nobody has ever
done it and nobody else will.  Do what, I hear you ask?  Why, run Websphere
on a 620.  If you want to go the WebFacing route (cheap to build in time and
money) then prepare to spend some money on a brand new iSeries to run it on
as well as all the education you can eat (expensive runtime.)

>I guess they did not take into
>account the time it would take would
>also be costly,much more so than
>paying for the tools.

This is all too common in the midrange world.  Management always seem
willing to spend a year developing some tool to copy spool files to disk in
lieu of spending a thousand dollars to buy it already tested and debugged.
As if my time was worth nothing.  Sorry.  Anyway, this is another round in
the chamber for you to use.  "Well, we can go cheap _here_ but we'll be
paying for it _here_.  There's no free lunch, even in computers."

>We are really looking to see if there was
>an quick/easy/cheap way to do this.

Classic choice:
Fast, Cheap, Good.
Pick any two at the expense of the third.

>If cheap is not an option we will
>probably be able to convince
>management

Good luck!  I feel for you.  In the mean time, visit all the web sites
Nathan mentioned and buy all the books you can.  Spend your own money if you
have to.  It'll put you in the drivers' seat when it comes to these sorts of
discussions.  Get as many opinions/ideas as you can.  The more things you
have to choose from, the better the chance that you will make the best
decision for your company.

  --buck