Re: RPG IV and CF-spec "keep it IBM"

Bob,

>Geeze!

You took the words right out of my mouth.

>I mean come on! Even John Carr (who
>originally suggested "CF") doesn't think it is a necessary feature.

Is it "necessary"?  Of course not.  I've been writing RPG code for
about 20 years and have also managed to get the job done.  But then IF
was not "necessary" either, although I think the addition of IF did
make maintenance easier by eliminating the need for complex indicator
groupings.

Ironically, it is the addition of IF/DOx/SELEC etc which is what has
made the CF spec really desirable.  Until we could "nest" operations,
there was no need to be able to ident.  The columnar structure did
still force other limitations though, like using shorter names for
arrays and indices so they'd fit, and non-intuitive syntax for
operations which needed more than two operands (like XLATE), which
also pose their own field name length "opportunities".

>I mean, "most" people that answer the
>question are going to want the CF spec.

Hmmm, did "most" people want sub-procedures?  I highly doubt it.  To
use your words, "Geeze!".  "Most" people don't even use RPG IV yet,
let alone sub-procedures.

Yet, _IMHO_, sub-procedures are the single best improvement to the
language yet.  Of course, this needed EVAL as a prerequisite.

Do "most" people use compiler directives like /DEFINE?  Pointer
arithmetic? ALLOC?  I trow not.

RPG programmers are notorious for being slow to embrace new (and
better :) techniques.  If you could get enough RPG programmers' heads
out of the sand to answer the surveys, I could nearly guarantee that
"most" of them would not even want many of the features already added
to RPG IV  (or quite possibly even RPG IV itself).

Where's the beef?  Shops that are so inclined can continue to write
their code in RPG III, or set a shop standard disallowing use of
certain RPG IV features.

Just don't ask me to go to work for one of them.

>Don't get me wrong, I'm prefer natural expression syntax than the
>limitations that traditional RPGII style code provides. But I just don't see
>how supporting:
>
>RPGIII
>RPG IV
> and
>RPG IV with CF-spec
>
>is going to encourage IT Managers to supporting moving to RPG IV.

This is a non sequitur, Bob.  If a shop has not yet moved to RPG IV,
then there is no reason for them to be concerned with supporting RPG
IV both with and without the CF-spec.  Just go straight to the
CF-spec. <grin>

And for shops already using RPG IV, just setup a PDM option to convert
source to CF.  If a program needs maintenance, just convert it then
maintain it.  There is no need to "support" both in any given shop.
If a vendor ships you RPG IV source w/o CF, it is a slightly different
story, but even then you can run the source through a converter prior
to the differencing and merge process.

Personally, I don't even "support" RPG III anymore.  If I have to
touch a program, the first step is converting to RPG IV (presuming the
shop allows use of RPG IV, and I don't have a client who doesn't).
And if/when I get CF specs, I'll convert a source to it prior to
performing any maintenance.  So, at least with my current client base,
I'll still only "support" one RPG variant, plus some legacy RPG II.  

>I feel we need an architecture for RPG. We need many poorly designed
>features corrected, we need consistent designs and several new features
>before we effectively turn RPG IV into CL II.

Often times, "poorly designed features" cannot be corrected and still
maintain backwards compatibility.  OTOH, IBM does a pretty good job of
doing what they can in this regard.  An example:  in RPG II days, if
you had a Demand file, the EOF indicator for a READ operation was not
reset prior to the READ, so you always *had* to do a SETOF prior to
the READ.  But IBM couldn't just change it, so we got Full Procedural
files instead.

Besides, who says we want to turn RPG IV into CL II?  CL is a control
language, for goodness sake, and IMHO should only be used for job
control and rarely the job itself.  

You make it sound like, if IBM adds CF-spec, they won't have the
resources left to do anything else.  Kinda like when we had to spend
$100 of a $100 survey budget when they asked for priorities from us.
But they have already made it clear this is not the case, and that
adding CF was actually farily trivial and in fact is working in the
lab.  So I don't see where it will have a significant impact on IBM's
ability to address other new features.

I think the IBM resource/budget issue is a relatively minor issue,
given Hans comments in the forums.  And as far as shop standards go,
leave that up to the shop.  Some shops don't allow primary files, or
MR, or internally defined printer files, or whatever.  Others may not
allow pointers or user spaces or sub-procedures or CF.

So what?  If it is relatively simple for IBM, and "most" people that
responded to the question asked for it, then why shouldn't they add
it?  Even you said you "prefer natural expression syntax than the
limitations that traditional RPGII style code provides".

Why not let the shop decide?

Doug
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END