RE: Replacing IIS with iSeries 400 -- MIDRANGE-L

> -----Original Message-----
> From: MDC Information
>
> Joe,
>
> I'm a great admirer of your usually logic & well presented arguments but
> this-
>
> >snip
> 'Finally, only as a last resort would I look to a 4GL.  The
> biggest problem
> with a 4GL is that they are rarely open enough to allow serious
> customization, and so you are tied to whatever the 4GL thinks is
> necessary.
> If they don't support the ability to tie a dropdown to an AS/400
> file, then
> chances are the workaround is going to be pretty painful.
> >snip
>
> IS simply CRAZY! Justify that statement please or withdraw it.

Mike, calm down.  I will not withdraw the general statement that 4GL
providers do not provide adequate hooks to customize their generated code.
I think I was pretty clear that I was stating opinion, and even that was
littered with conditionals such as "rarely" and "chances are".  If you have
a specific rebuttal, please post it rather than waving your arms in the air
and demanding retractions.  This isn't a court of law, fer goshsakes, it's a
mailing list.

> Have you ever
> used LANSA? or evaluated it?

I have not used LANSA, but I've seen some generated code.  Also, I have used
numerous code generators over the years and even developed some (for
example, I was on the AS/SET development team).  I have run into the same
problems, to a greater or lesser degree, with every one:

1. Look and feel is standardized, and not particularly easy to customize

This may be the way that controls are placed on a GUI screen, the way menus
are implemented, the way prompts are handled or the colors used, but _in
general_ code generators tend to predefine these choices, and getting around
them is difficult.

2. Generated code is inefficient

This is almost a given, although it differs in degree.  Because a code
generator must take all possibilities into account, unless the designers
have an incredibly good code optimization team, the code _nearly always_
contains some features, be it extra moves, renames, or odd syntax, that is
unnecessary.

3. Generated code is difficult to read

Generated file, field and routine names are _often_ very cryptic.  This is
especially prevalent in RPG III generators limited to six-character field
names.  However, evn in the freeformat environment of C, C++ and Java,
rarely do generated field names make sense.

4. Generated code often uses "cute" code, or obsolete or inappropriate
techniques

Obsolescence is less of a problem in RPG, since the language doesn't evolve
as quickly as some others, but cute code is often a problem.  Some
generators actually generated the old multiply by 10000.01 "technique".
Early versions of AS/SET required two files for every update file: one for
input, one for update, and always used image checking for updates.

5. Modifications to generated code are lost on regeneration

This has been a particularly difficult problem.  Back in the 80's and 90's,
several C generation tools attempted to make "roundtrip" generation a
reality, but nobody ever really got it right.  Some came close, but there
isn't a single tool today that I know of that truly supports roundtrip
modifications, especially those that put a GUI front end on a business
application.  Remove a field from the generated GUI, and on the next
generation, that field is back again.

6. Code generators tend to be relatively rigid in their environment setup

If a code generator thinks that a display file should work with a single
program, and that you should generate a single JSP for that display file,
then you're probably going to be stuck with that paradigm.  This is fine in
many cases, but less than adequate when you want to, say, create multiple
front ends for different user classes, with some fields hidden.  Or perhaps
you want to join multiple screens on one panel, or bypass certain panels.
None of these are handled very well with code generation tools.


> Yes, I'm a '<SHAMELESS ' LANSA addict but I like to think I
> understand what
> the other languages & tools deliver before putting them in the
> 'last resort
> ' box.

Okay, simple question.  I have a two panel application.  The first panel
requires a customer number, and on the second, I have to enter a journal
code.  The available journal code options are based on a combination of the
user ID (entered when the user signs onto the application) and the corporate
customer's class code.

If there is only one available, this field should be a constant.  If there
are 2-4, it should be a radio button.  If there are more, it should be a
dropdown list.

Can I do this easily in LANSA?  If so, then my comment on customization is
not applicable to LANSA.

Joe Pluta
www.plutabrothers.com

P.S. With PSC400, you can do it four different ways, each with a differing
level of complexity and flexibility: pure JavaScript, exposed function and
JavaScript, exposed function and formatting call, or overridden UI class.
Changes to the RPG program that don't change the actual screen layout do not
effect the customized JSP.