RE: IBM getting rid of RPG

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> Joe,
>
> What do you do about

It depends on how much of your user's daily processing is done using
command-line techniques, and how much work you're willing to do to keep each
of these features.    If you can write a display file program to do it, then
you can move it to the web.  Some of them are more difficult than others,
but if you plan to move to the web, you'll have to handle these things
eventually anyway.  The good news is that most things can be handled via an
RPG program:

>      cmd prompting

A display file front end.  The amount of work depends on how many commands
your users use.

>     any ibm cmd like WrkSplf, WrkSbmJob, esp WrkOutq and WrkWtr

APIs exist for all of these.  A single program can be written to handle
these - maybe not easily, but it's a one-time cost.

>     Receiving a break message

A generic break handling program can be written to call an RPG program to
display the message.

>     Exception handling - rpg or cl pgm hits an unmonitored exception msg.
> The ibm default exception handler takes over and wants to prompt
> for Cancel,
> dump or ignore

This is a procedural question: do you want your errors to hang the UI or do
you want to handle them?  If a simple hung browser (followed by a call to
support) is good enough, then there's no problem.  Otherwise, you need to
write a default error handler that talks to a display file.  There are
several alternatives: you can use a PSSR for RPG program errors, you can
bubble up errors and monitor CPF9999 at the highest level, or you can run in
an activation group and use a condition handler.  This question is a tough
one, but it CAN be addressed.  In some ways, this is a "good" problem,
because if your users regularly see exception messages, that might identify
an area that could be use some attention.

> I like your concept, but in practice these situations have to be
> dealt with,
> No?

Yes.  It's just a matter of how much work you're willing to do.  Remember, a
0CPW machine can still run interactive sessions, just at a high price.  If
your systems management is handled by an operator, then the single
interactive session that a 0CPW machine allows is sufficient.  If, on the
other hand, your users do a lot of command-line stuff, then you need to
encapsulate that inside of programs.  It's an unfortunate fact, but one that
I see no way around.

On the upside, it's a one-time cost for most of this stuff.

It's ironic that systems that I as a programmer most disliked - those that
had no command line interface and limited capabilities on the user - turn
out to be the easiest to move to a web interface.  The lesson to be learned
there is that encapsulating "neat features" inside a standard interface is
always the smartest thing to do long term.

>
> Steve Richter
>
> -----Original Message-----
> From: Joe Pluta <joepluta@PlutaBrothers.com>
> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
> Date: Saturday, July 28, 2001 1:55 PM
> Subject: RE: IBM getting rid of RPG
>
>
> >There are ways around the interactive tax.  In fact, I'll be doing a
> seminar
> >on exactly that topic at COMMON.  The basic idea is to modify
> your programs
> >to run in batch and talk to a data queue instead of a display file.  Once
> >you do that, you can pretty quickly attach a user interface, either thick
> >client or thin.  A thick client can be written in VB or Java, or you can
> use
> >a servlet engine such as WebSphere or Tomcat to run your
> applications via a
> >browser.  It's fast, powerful, flexible and relatively painless.
> >
> >This way, your primary business logic is still written in RPG, which I
> >contend is the best language for defining business rules in the business,
> >primarily because of its tight integration with the database.  And, once
> >you've started separating your business logic from your presentation, you
> >can start looking at moving towards a true client/server architecture,
> which
> >is where I believe the iSeries will truly outpace any other platform.
> >
> >Joe

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---