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

Rewriting code every 4 years (as you put it) is what keeps you employed.
<tic>
Backwards maintainability is exactly the thing that we're trying to
advocate. If Scott says use %int(%char(datefld:*ISO0)) but if you're on V5R3
then do it this way... That's just bull$hi% not backwards compatibility.
In my view, RPG IV should NEVER be enhanced except on a VxR1 boundary.
This means that enhancements can come out whenever they want, every year for
that matter, but they have to work on VxR1 and later, never "only" on VxR2
or VxR3 and later. 

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Booth Martin
Sent: Wednesday, December 28, 2005 12:46 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: free-format move *USA date value to 6-digit numeric in
YMDformat

In IBMs defense, I will point out the immense size of the ship we are 
driving.

IBM has maintained backward and forward compatibility in an environment 
that prizes change over all else.  The MS solution has to been to write 
the new code and make the old code not just obsolete, but also unusable. 
   Thank goodness IBM has stuck to their values and not left us having 
to rewrite core code every four years or so.

Their need to offer changes while maintaining our code base is, to my 
mind, essential. The fact that they choose to spread the changes over a 
few releases is a small irritant in my opinion.  The upside is that we 
get to see whats coming.




Scott Klement wrote:
> 
>> I mean in V5R1, V5R2 and V5R3 there are subtle "enhancements" to the 
>> language that are all related (such as the example above) in which 
>> partial solutions are introduced in a point release and then the next 
>> part of the solution is introduced in the next point release and so on.
> 
> 
> No kidding.  I'm very tired of these "half-written" features that RPG 
> seems to get.
> 
> At various releases we have had all of the following:
> 
> - Pointers without pointer arithmetic
> - No MOVE in free-format, but no way to convert char to number
> - %char() not converting numbers to character
> - %dec() and %int() not converting character to number.
> - %dec() and %int() not converting dates to numbers
> - DSPLY op-code and requirement for at least a space in the factor 1
> - Read data into a data structure, but only for program described files
> - Read data into a DS, but only if you use the record format name and 
> LIKEREC
> - Prototypes, but no way to pass a data structure.
> - LIKEDS but not with an array.
> - LIKEDS with an array, but no LOOKUP or SORTA
> 
> It just seems like they leave out things that they know people will 
> need. They introduce half of what we need at once, and introduce the 
> rest at some point in the future.
> 
> This leads to poor adoption of the new techniques, because they're 
> awkward at first.  Once they become less awkward, people don't adopt 
> them because they have to remain compatible with old releases.
> 
> It also leads to it being difficult to teach anything, because you have 
> to teach people 10 different ways of doing everything.