RE: DIM question (Was MOVE/MOVEL and %Scan)

> From: Paul Raulerson
>
> But you CANNOT make money on System/36 applications today.
> You probably will NOT make money on AS/400 green screen apps tomorrow.
> Certainly most people WILL NOT make money on AS/400 green screen
> apps tomorrow.
>
> So find a solution. I sure as hell have not been able to.

But Paul, this is what's really killing me.  The answer is already there!
Write your business logic in RPG, and then attach it to the user interface
of your choice.  The problem isn't that there is no solution, just that we
aren't using the tools we have.

I can name four viable alternatives off the top of my head:

1. Brad Stone's e-RPG.  If you don't want to have anything to do with Java
or servlets, this is a fast and effective way to put a browser interface
onto your existing code.  This requires HTML knowledge, but if you plan on
using a browser, you have to have this knowledge anyway.

2. Nathan Andelin's HTTP framework.  While similar to Brad's approach,
Nathan's has some significant differences that may make it either more or
less suitable for your situation.

3. Use a client/server design to communicate with a thick-client written
either in VB or Java.  This is a more ambitious approach, but I've been
teaching these methods for years now.  The beauty of this approach is that
you can literally attach to any user interface without changing your
business logic in any way.

4. Use my PSC400 product to take your existing 5250 programs and attach a
browser interface.  It's a relatively expensive alternative, but you can
continue to develop and test your programs from the command line as standard
interactive programs, but yet they also run using a browser interface - WITH
NO ADDITIONAL PROGRAMMING.  This is ideal for people who want to web-enable
without having to learn a whole new set of tools to do so.

Each of these solutions runs your business logic in batch, which means you
can run your production programs on much cheaper hardware because you can
use a much smaller interactive feature.  Personally, I think option three is
the goal we as a community need to move towards, but any of the other three
will move you along that road.  This is in contrast to the screen scrapers,
which will only buy you a temporary reprieve, and an expensive one at that,
since the underlying programs still run interactively.

It's up to us.  If we can use the tools we already have to provide a viable,
productive architectural approach to business application development, then
perhaps the RPG folks will see that RPG needs to be focused on what it does
best - namely, encapsulate business logic.  At the same time, we can provide
the killer application interface that will position the iSeries as the
server of choice, entirely independent of the business logic.

The alternative is that IBM will, at the behest of a very vocal part of our
community, continue to turn the iSeries into a plug-and-play database server
for Windows .Net applications.  And at that point, we all lose.

So, take up arms, everyone!  Design client/server architectures!  Write
modules!   Write servers!  Learn HTML!  Put graphical front ends on your
existing programs!  Avoid direct SQL access to your database!  Encapsulate
your business logic!

Or else we truly will be flipping burgers, or at least doing the software
equivalent, writing VB clients that do direct SQL to DB2 and uploading MRP
requirements from Excel spreadsheets.  Or porting our RPG applications to a
Linux machine.

Not a pretty future.

Joe