RE: interesting /. story on RPG

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: James Rich
>
> On Thu, 21 Feb 2002 rob@dekko.com wrote:
>
> > And to mention, what if your RPG program uses:
> > - a screen with DDS.
> > - an externally defined file, but no SQL
>
> Interestingly enough, I wrote a screen DDS to ncurses convertor.  It was
> far from complete but sure was cool to see my 5250 screens in my xterm.  I
> also wrote a file DDS to MySQL convertor.  Ran the convertor on both the
> screens and the files, filled the tables with data, and wrote a little
> customer maintainance program on my linux box.

Unfortunately, that's just what the Unix cowboy did, and that's how he sold
management.  Now, add just a few things we normally do on a day-to-day basis
in a real application:

1. A subfile, with pageup and pagedown support
2. A message subfile for errors

My guess is your ncurses and MySQL solution is going to become a little bit
more difficult.  If you manage to get even close to that, add a few more
features: SFLFOLD, popup windows, KEEP and ASSUME, and SFLNXTCHG are a few
good ones for starters.

Oh, and don't forget the support for things like CSRLOC and SFLRCDNBR.

My point is that the low-hanging fruit of any application - that is, the
simple file maintenance programs - are often easily converted.  It's not
until you start going after the difficult prograns that these conversion
efforts fail, and that's when you really begin to appreciate the differences
between the operating systems.

You said something in your other post about MONMSG:

"MONMSG doesn't need to even exist.  In unix all programs return a value to
the shell after completion, even if they end abnormally.  I've only seen
MONMSG used to check if some error occurred.  In unix checking the exit
value of the command run will do the same."

I don't think I agree with this.  The concept of returning an error code and
checking for it seems to be a step backwards, in my opinion.  MONMSG acts a
lot more like the higher-language concept of an exception handler than it
does the old-fashioned technique of testing a return code after every call.

I guess my point is that there really is no good reason to make OS/400 look
like Unix and if I had to choose, I'd rather make Unix look like OS/400.  Of
course, if I really did have to make that choice ever again, I think I'd
choose door number three, death by fireants.

Joe