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

I'm guessing they'll tell you that it is supported.

/end-free

 move

/free

<vbseg>


-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Thursday, December 19, 2002 2:42 PM
To: rpg400-l@midrange.com
Subject: RE: Using RPG /Free how do I get an ISO variable into a
non-date 8,0 variable in *USA format


> From: Buck Calabro
>
> 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.  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.

It is not reasonable to do that just to use a new version of the compiler.
What's next?  Remove the %trim function and let me write my own?

The correct answer is that every opcode removed should be, at the minimum,
supported by a BIF in the next release.  If it's difficult, well, guess
what?  Writing compilers is difficult.

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

Somehow, I don't think my manager is going to accept that.  And if my
manager does make that decision, she'll have hell to pay when she delivers
the next release to customers who use that order policy.  Especially when
she tells them we've been kind enough to give the customer the capability of
writing their own order policy, and we suggest that they do so.  Of course,
it's entirely on their dime to write, test and debug this order policy, but
better them than us.

This is EXACTLY what has happened with the MOVE opcode in freeform RPG.  I'd
really like to hear from the manager in charge who made that decision.  I'd
love to hear why this is a good idea, and then put that answer up in front
of the public and see if the public agrees.  I want to see how many managers
are going to want to hear that they ALL have to duplicate the effort of
developing the date conversion MOVE opcode (or any of the other facets of
the MOVE operation that the compiler team has decided we don't need).

Joe


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