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

But Bob... we are paying for the reliability ........ lol....  please note 
sarcastic tone was used in here.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
709-576-8132
rpower@xxxxxxxxxx
http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




Robert Cozzi <cozzi@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
2005/12/29 10:53 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

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






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