Re: free-format move *USA date value to 6-digit numeric in YMDformat

Bob,

why not make the compiler an independent
> thing that could be ported to say OS/400 V5R1 or Linux or FreeBSD or AIX?


I believe there is also a substantial runtime involved, and I suspect many
of the service routines they contain (especially DB related) are rather
dependent on tight coupling with OS services which would not port readily to
*nix.  So porting back to VxR1 seems to me much more likely than *nix but
even so where is the justification for IBM?  Why divert the resources to
porting, creating PTF distributions, and more importantly testing?

The bottom line is we used RPG III for years and years ( a decade? ) before
> any enhancements were introduced except ..


And that is a good thing?  I trow not.  We were fairly productive in RPG III
(or even II) in spite of itself, but the language shortcomings were glaring
to say the least.

So why do we need enhancements on each and every release?


Because we still have more to go to catch up to the rest of the world.  :)

More seriously, it seems like the combination of the language used to write
the OPM compiler plus the constraints of the RPG III column widths made it
hard to introduce add significant enhancements. One of the side benefits I
remember being mentioned during the period leading up to RPG ILE is that the
rewrite into C++ would be a major factor in the ability to start offering
significant enhancements to the base language.  And the extra column widths
didn't hurt either, not to mention the expanded factor 2 style.

In my view, IBM is making RPG IV harder and harder to learn to use
>

I vehemently disagree.  Does adding features mean there is more to learn?
Sure, but that is the price of progress.  I'll gladly learn how to list
multiple key fields in a CHAIN operation for the ability to not require a
KLIST declaration.  Oh wait, that isn't in V5R1 so I guess you wish we
didn't have it yet?

I see no reason to withhold enhancements until the next VxR1 boundary, nor
do I see the justification for IBM to PTF enhancements back to the previous
VxR1 boundary.  (With one exception:  I was very glad to see the PTFs for
*SrcStmt and to a lesser degree *NoDebugIO PTF'd back to V3R2.)

For those who must be source compatible back to a given level (eg software
vendors or multilocation companies at various release levels), you may have
to go back farther than V5R1 anyway.  And there is nothing saying you must
use the new enhancements if the shop standards are to be compatible with
VxRy.  But why make those who have the ability to take advantage of new
features wait for V6R1?  Just because you can use a simpler syntax in V5R3
for the date conversion of the thread topic, doesn't mean you still can't
use the V5R2 syntax if you already knew that or had source using it.  Unlike
some unnamed languages, RPG is very good at being backward compatible.  But
why object to there being a new, easier way?  In the specific case of date
conversions, I wrapped those into service program routines back in V3R2 so
you just have simple functions to call with names reflecting their purpose.
IMHO, anytime you find yourself needing to nest multiple BIFs or perform
multiple calculations to convert something, it is a prime candidate for a
subprocedure.  Preferably in a service program if it could be commonly
useful.  I've long maintained that the addition of subprocedure support is
the single biggest enhancement to RPG and will probably always be so.  IMHO.

Historically, I think many RPG only programmers settled into a comfort zone
with RPG III and the fact it didn't evolve for years on end.  Overly
simplified, I think they just don't want change.  And that can add up to
only one outcome...

Doug