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

[Robert Cozzi <cozzi@xxxxxxxxx>]

I paid $100 for a 300GB disk drive down at Fry's Electronics.
I paid 20 times that amount for a 70GB drive from IBM for the iSeries.
Don't play the poverty card with IBM--its all B.S.


On 12/28/05 7:01 PM, "Douglas Handy" <dhandy@xxxxxxxxx> wrote:

> 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
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
>