RE: Using RPG /Free how do I get an ISO variable into a non-date 8,0 variable in *USA format

Hi Joe!

>> Unless you write your own procedure/function to do these
>> sorts of common date manipulations.  What goes on inside
>> the function (MOVE) is irrelevant to the fact that you
>> can use your own function Exactly The Same Way you
>> would use an IBM BIF.
>
>The problem with this statement is that now I have to
>write a BIF to do what already works in previous code.

I'm feeling goofy today so I'll kick in one more comment.

In my opinion, using MOVE to fiddle with dates has never been a good idea.
At least not a bare MOVE.  Let's say that I have some program that has
several dates on the panel: order date, ship date, received date.  For
whatever reason, the panels still use decimals and not date fields, so we
need to convert back and forth.  The simple way would be to do three MOVEs
and be done with it.

But then your company is acquired by a European firm, and they like to see
their dates in a different format.  Those MOVEs need to be tracked down (all
of them) and wrapped in some IF/ELSE or SELECT statements.  Then, testing
reveals some odd proclivity on the part of North American users to type the
dates in "wrong" so we need to add error checking.  Track those MOVES down
again and add some error handling.

Sounds Very Much like a job for a subroutine call in RPG III.  Which is
exactly what it ALWAYS should have been.  Now, all the date conversion
happens in a single bit of code, preferably /COPYed in.  Which is exactly
what we used to do for similar "utility" functions back on System/3 RPG II.

>This is added work on my part, with zero return on
>my investment.  I have to not only write the BIF,
>but also debug it to make sure it handles all the
>situations that same way that the original code did.

Au contraire, mon ami!  For, if I skipped the debugging/error
handling/multiple format allowing parts before (naked MOVE), I am now in the
land of "pay me now, or pay me later."  The reward on that investment is
more robust code, and more easily maintained code, since it's all in one
place now instead of scattered piecemeal throughout the various and sundry
programs that make up the application.

>It is not reasonable to do that just to use a new
>version of the compiler.

New Development (we ARE talking about new code, right?) really should be
re-written, not merely translated from an older dialect to a newer one.
THAT provides zero return on my investment.  If I am going to use /free, why
not make the code better (more robust, easier to maintain) instead of merely
re-hashing its appearance?

>Let's take an example.  I write code for an ERP manufacturer.
>In the next release of our package, I go to my boss and say,
>"it's going to be too difficult to support order policy X"
>or "order policy X doesn't fit in with where I see the
>package going".

What Toronto have done is closer to releasing NEW and DIFFERENT function at
the expense of moving older working function into the new framework.  More
like trying to wedge version 1 BOM functions into the version 2 interface.

>This is EXACTLY what has happened with the MOVE
>opcode in freeform RPG.

Here's my take on that, and it's worth every penny you paid for it.

1) The entire argument is Very Reminiscent of the perennial
   favourite "The Cycle Rules/Sucks" debate.  Some people
   care for the cycle, some don't.  My guess is that some people
   will simply never really care for /free.  Not a problem.
   Don't use it, and feel better about life.
2) /free is closer to a new language than it is to RPG II.
   I really prefer to drop the RPG II baggage behind altogether,
   but the political realities are not going to let that happen.
   As it is, _this_ debate has probably stunted further development.
3) Should Toronto feel motivated to implement MOVE as a free form
   operation/BIF (and they very well might be!) I humbly suggest
   naming it with a realistic name (and I am not kidding):
   MoveAndConvertDataTypeAndFormat hits most of the high points.
4) We didn't LOSE anything; we GAINED new functions.  Not all of the
   new functions map directly to old functions.  Providing new function
   while allowing use of existing function is a very reasonable way
   to allow me to embrace new ideas at my own pace.
5) Relying on the compiler to solve business problems is a dangerous
   precedent.  The compiler should provide me with tools to write
   my own solution to my own problems.  There is a reasonable
   argument that date conversions are business problems which
   depend on the nature of the application.  Reasonable people
   (which does not include me, of course) can honestly debate where
   the line should be drawn.  A similar argument exists around the
   new IFS function and the new XML functions and CGI and...
6) I would argue that the entire date functionality was never fully
   implemented in the compiler in one fell swoop (and it's still
   coming out...)  Early adopters already wrote their functions to
   slide between decimal and date.  Later adopters are waiting for
   the compiler and that's OK _for them_.  But don't hold us ALL
   back because some folks don't need that new functionality.  If
   somebody TODAY wants to do these date manipulations and INSIST
   on /free, then they are more akin to an early adopter, and will
   need to do more work than those who follow.

Best regards to all and I'm outta here.
  --buck