× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I think the theory of 4GL's (or whatever name we're using) is that the
"code generator" portion is robust and essentially error-free.  A good
code generator *can* check all data elements, and if business rules
are set up properly, subtle logic errors (like adding pounds and
kilograms) vanish.

My bet would be that code generation errors, while not unknown, are
dwarfed by flawed business analyst logic and incorrect business rules
setup.  I suspect the volume and combination of business rules already
set up through 4GL's represents an excellent regression test.

Even the 4GL people would suggest that some tasks are appropriate for
hand-coding.  I believe the main communications program in Extol is
not Synon/Cool2e, and part of the reason Extol is fast is because of
very, very smart design (lots of arrays eliminate those pesky DB
IO's).

When a user-written program blows up on me, I assume it's my problem. 
PTF's and compiler errors are at the bottom of my list.  When I get a
RNF7030 I don't start with the w-code listing.  Doesn't it make sense
to debug at the highest level (language) you can?

In hand-coding, you have incorrect variable names, array index errors,
misplaced do's and endif's, and DSPF management errors.  There's no
rigor in most hand coding other than that supplied by the compiler;
too many programmers code to the standard and forget about the
exeception.  I'm not suggesting there are no undetected logic errors
in 4GL programs; I am suggesting an extremely high percentage of
routine coding and logic errors will be found and identified/corrected
at the design stage and not during user acceptance testing.

-reeve


On 4/29/05, M. Lazarus <mlazarus@xxxxxxxx> wrote:
> Chapin,
> 
>   I must disagree.  Since you can't directly debug an action diagram, how
> would you track down a difficult to find bug?  The only practical way is to
> go into the generated code.
> 
>   As an example I have worked with Progen.  It generates very decent
> code.  It is even documented!  The options you have are fully documented or
> VERY fully documented.  There is no reason that code generators can't
> generate decent, human readable code.
> 
>   -mark
> 
> 
> At 4/29/05 12:03 AM, you wrote:
> >
> >With apologies for jumping in late... I'd just like to take umbrage with  the
> >disparaging statements about generated code.
> >
> >I used Synon/2e (now Advantage:2e) for eight years before I learned  RPG.
> >That was reality for me.  I still use it without viewing the  generated code,
> >and in fact interact with vendor code generated in  COBOL (which I also don't
> >look at).  The "code" I care  about is in the Action Diagram.  The biggest
> >benefit of a  CASE tool is the ability to work at a higher level of
> >abstraction
> >than the 3GL  provides.
> >
> >Just as I don't look at the machine code generated by the compiler, I  should
> >not look at the HLL code generated by the CASE tool.  When I do, it  is
> >because of my ignorance of the CASE tool or a bug in its generater,
> >and  neither
> >should be tolerated.
> >
> >The programmers whom I see looking at generated code are usually looking  for
> >warm-fuzzies about what they just created, or don't understand how the CASE
> >tool works, and are using the generated code to understand what it  does.
> >Neither is an efficient use of their time.   They  should learn how to
> >program
> >IN THE TOOL, not use it to "manipulate code."
> >
> >I have lots of respect for your posts, Rob, and David, and I missed  Peter's
> >original post, so this may not be germane to his original  point.   But, I
> >contend that all of you miss the point  of using a CASE tool when you
> >disparage
> >its generated  code.
> >
> >--Chapin Kaynor
> >   Vermont
> >
> >
> >
> >date:  Fri, 22 Apr 2005 14:54:19 -0500
> >from: rob@xxxxxxxxx
> >subject: Re: Cases  in AS400
> >
> >I agree David.  I used to use AS/SET and that code was,  and still is,
> >ugly.  In fact they still convert 10 character field  names down to 6
> >characters.
> >
> >Sometimes I wonder if they do this  stuff just to discourage you from
> >looking at the generated code, stay the  he!! out, and only use the case
> >tool to manipulate code.
> >
> >Rob  Berendt
> >--
> >Group Dekko Services, LLC
> >Dept 01.073
> >PO Box  2000
> >Dock 108
> >6928N 400E
> >Kendallville, IN  46755
> >http://www.dekko.com
> >
> >
> >
> >
> >
> >David Gibbs  <david@xxxxxxxxxxxx>
> >Sent by:  midrange-l-bounces@xxxxxxxxxxxx
> >04/22/2005 01:47 PM
> >Please respond  to
> >Midrange Systems Technical Discussion  <midrange-l@xxxxxxxxxxxx>
> >
> >
> >To
> >midrange-l@xxxxxxxxxxxx
> >cc
> >
> >Subject
> >Re:  Cases in AS400
> >
> >
> >
> >
> >
> >
> >Peter Vidal wrote:
> > > SYNON?  Ugly code....
> >
> >I think all case tools generate ugly code ... but the  theory is, you use
> >the case tool to manage generate the code, so who cares  how ugly it is.
> >
> >That is, of course, a theory only.
> >
> >Reality,  obviously, is another story.
> >
> >david
> >
> >--
> >David  Gibbs
> >david@xxxxxxxxxxxx
> >
> >
> >
> >
> >--
> >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> >To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> >To subscribe, unsubscribe, or change list options,
> >visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> >or email: MIDRANGE-L-request@xxxxxxxxxxxx
> >Before posting, please take a moment to review the archives
> >at http://archive.midrange.com/midrange-l.
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.