• Subject: Re: CL improvements
  • From: John Earl <johnearl@xxxxxxxxxxxxxxxxxx>
  • Date: Tue, 12 Oct 1999 22:59:04 -0700
  • Organization: The PowerTech Group

Tim,

I can think of several good reasons for enhancing CL, Beginning with that goofy
CPF0864 message.  Once you reach the end of a file you're stuck?   How lame is
that?  Is it unreasonable to expect to be able to cycle through a file more than
once..... in a non "application" program?   Much of the really lousy CL code 
that
I've seen results from unreasonable limitations in the language.  <watch out 
now,
I'm going to work myself into a frenzy!>

Support for only one file?  That means that you can't throw a prompt screeen up
and validate values from a database file.  You can surely come up with a number
of CL tasks where it would be usefull, and not unnnatural, to use more than one
file in CL.

Date data type support.... that's just basic.   There are a number of data types
that CL doesn't support, but date support is so fundemental to what we do with
data that this is a glaring exception.  As near as I can tell, CL has not gotten
support for new data types simply because CL has been ignored.

And the strongest reason not to ignore CL?  GUI.   Yeah, sure, IBM is driving
everything towards GUI interfaces, but the decision makers on this issue have
overlooked this critical issue:  If a process only has a GUI interface, then 
some
person must always be ready at a mouse whenever that function is to be run.   
The
real beauty of CL is that it can be compiled, batched, and run repetively.  A 
GUI
interface demands an FTE everyday.  A CL program, once compiled and tested, will
run correctly for ever. Replacing CL with GUI is a dastardly plot to keep the
lights in the computer room on forever <g>

Finally, and in all seriousness,  CL is important to AS/400 education.   As an
instructor, I'm convinced that the best and fastest way to teach someone how to
program on the AS/400 is to introduce them to CL first.  But both novice and
expereinced students instantly recognize CL's limitations and rail against them.
It would help tremendously to attract talent to this pool if we could present a
simple, elegant and easy to understand langauge to newbies.   CL is almost that
language, and with minimal amount of work it could be all that we ask for.

And besides, how hard can all that be????

CL is definetly worth updating, and it's past time that IBM devoted the 80 hours
that it should take to the task. <g>

jte

Tim McCarthy wrote:

>         As yes, I agree. But in your own words, CL is a "Procedural
> Control Language for doing the
>         mundane things...This language is NOT primarily for Application
> Programmers,   Its for the
>         Operation Staff." ...hmmm, so why then turn it into an HLL??
>
> TrailBlazer Systems, Inc.
> http://www.softwarejungle.com
> AS/400 E-Commerce Solutions
>
> Chaos, panic, & disorder - my work here is done.
>
> > -----Original Message-----
> > From: John P Carr [SMTP:jpcarr@tredegar.com]
> > Sent: Monday, October 11, 1999 10:51 AM
> > To:   MIDRANGE-L
> > Subject:      RE: CL improvements
> >
> >
> >
> >
> > >Forgive me for being a killjoy here, but do we REALLY NEED these sort
> > of
> > >enhancements in CL? Subroutines? FOR loops? I'd much rather IBM
> > focused
> > >its' efforts elsewhere.
> >
> > Forgive me Tim,  but to the majority of the System Operators, and
> > Systems
> > Programmers, CL is still the only Procedual Control Language for doing
> > the
> > mundane things like Saving Libraries,  other system type functions to
> > be
> > done in batch,  maybe as Subsystem Jobs,  Prestart Jobs,  IPL start up
> > type
> > jobs,  etc.    These people will never learn a HLL nor should they
> > really
> > need to.
> >
> > This language is NOT primarily for Application Programmers,   Its for
> > the
> > Operation Staff.
> >
> > Try running a shop with out CL.
> >
> > IMHO.
> >
> > John Carr
> >
> > +---
> > | 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
> > +---
> +---
> | 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
> +---



--
John Earl                                           johnearl@powertechgroup.com
The PowerTech Group                        206-575-0711
PowerLock Network Security              www.400security.com
The 400 School                                www.400school.com
--


+---
| 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
+---

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2019 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 here. If you have questions about this, please contact [javascript protected email address].