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

On Thu, 19 Dec 2002, Joe Pluta wrote:
> >
> > So...  keep using the original code.   If you want things to remain the
> > same so that you don't have to re-debug them, why are you changing the
> > code?  i.e., why convert them to free-form?
>
> With that logic, my code would still be RPG II with internally described
> fields.

Huh?  That's not what I'm saying AT ALL.

You made a comment that if you 'wrote your own BIF' (i.e. a subprocedure)
that you'd have to take the time to debug it and make sure it worked
exactly right.

My point was, if you're converting from MOVE to free-form, and you can't
take the time to debug a simple date manipulation routine, then you
shouldn't be converting it at all.

In other words, you shouldn't be changing the code of a program that
you're not willing to debug.

>
> Are you saying that you want there to be two separate, distinct
> sets of code - freeform and non-freeform?  Any development managers hearing
> this should be cringing.  Even IBM knew they had to provide CVTRPGSRC, even
> if it wasn't very complete.  Have you seen a corresponding tool for
> freeform?  (Linoma's tool, BTW, is very good for this.  But they're a
> partner of mine, so my opinion is biased <grin>)
>

I have absolutely no idea what your point is here.

>
> > But...  nothing was removed.  Instead, new functions were added.   I agree
> > that it is frustrating that you can't do everything yet in free-form.
>
> Man, now you're in full quibble mode.  Does the compiler team pay you?
> <grin>.  Any part of a freeform program that requires /endfree is NOT
> supported by freeform.  Not only that, but between you, me and the wall, I
> have a funny feeling they may remove the /endfree from a future release.
>

The compiler team does not pay me.   But there must be something wrong
with me if I agree with them, right?

>
> > However, I'd rather have the features become available shortly after
> > they're written, then wait 10 years for them to completely add or rewrite
> > every possible feature of the language before it's initial release.
>
> Ah crap.  The %move BIF would take a decent programmer a couple of weeks.
> And if you're not willing to write that BIF, then leave the old syntax in.
> How much work would it have been to support the MOVE instruction as I
> described above?  Allow "MOVE X Y" and deprecate it until the %move BIF is
> available.

Are you saying that they actually REMOVED the fixed-format MOVE op-code
from RPG?   You can no longer code:

/endfree
     c                   move      x             y
/free

If that's true, then I take back everything I said...  If that's what
you're talking about, then I didn't understand.

>
> I notice in your arguments, Scott, that you tend to see things as "all or
> nothing", just like your HTML vs. X argument.
>

I don't know what you mean by that.

> Me, I see opportunities to allow me to embrace new technologies within
> my legacy systems while moving towards rewriting parts of my code - AT
> MY OWN PACE.  Once my compiler vendor starts dictating how my business
> applications should look, then I have some real issues because frankly
> very few compiler architects have a clue how to use a computer
> application to keep a business profitable.
>
> Instead, how about giving us a reasonable solution today while working
> towards a comprehensive solution tomorrow?
>

How is that different from what I said in the message you replied to?