Re: Replacing IIS with iSeries 400

Joe,

I'm quite calm re the technical stuff, I'm waving my arms and shouting
because this is exactly the type of generalization that YOU would not
accept.

While you use 'rarely' & 'chances are' later in your paragraph the clear
message of  the opening sentence is 'don't look at a 4GL' (and remember this
is a recommendation to someone who asked an innocent question).

Your responses (re code generators, not 4GLs) confirms to me that you are
not talking from a position of knowledge on this subject. IMHO your issues 1
to 6 don't merit comment as they to not relate to modern 4GLs.

Finally, your 2 panel question can be easily handled in LANSA using 'on
condition' logic and never looking at a line of generated code (and the
dropdown list can be dynamic from DB2). By the way in our shop we don't even
save the generated code, never mind change it, and that includes code for
web sites that seamlessly use CommuniGate Pro for automatic emails and XML
to exchange data (2 way) in real time with remote NT servers (and the sites
can be served from IIS or WebSphere without changing a line of code).

Regards,
Mike Dunnion
www.mdc.ie

-----Original Message-----
From: Joe Pluta <joepluta@PlutaBrothers.com>
To: midrange-l@midrange.com <midrange-l@midrange.com>
Date: 01 October 2001 19:45
Subject: RE: Replacing IIS with iSeries 400


>> -----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.
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>
>