RE: /Free -- A question

> From: rob@xxxxxxxxx
> 
> And I want to applaud all those that have shown restraint and have not
> rehashed the argument that they believe technically it is possible to
take
> new opcodes, etc, put them back into older versions of wcode, MI or
> whatever, and get that to work therefore they believe that tgtrls
should
> only select how the program is assembled, not verify syntax for older
> releases.

And I have to admit, Rob, that's how I was looking at it until Doug made
the simple point that TGTRLS simply selects the compiler, not the
generated code.  And given the fact that I blathered on for several
posts on Tuesday about the old MOVE issue, it seemed appropriate to let
this one rest.  Yes, I'd LIKE to see the compiler generate code that
would run on a V4R5 machine, but the truth is that when you want a ton
of new features like the compiler team has been giving us over the past
couple of years, you're just going to have to live with a little less
backwards compatibility, at least at the binary level.

Note that I still want SOURCE level compatibility - I want to be able to
bring my old source onto a new machine and still be able to compile and
run it.  And by and large, the compiler team has been incredibly good
about that.  My issues with /free should not cloud the fact that I can
still bring a program I wrote in 1990 and compile it on a V5R2 box with
no complaints.  That's a great accomplishment, and the compiler team
ought to be VERY proud of that achievement.

I guess it's just time that we try to move our client base along and get
them into the latest and greatest.  I think most of my client base has
at least moved to V5R1, so perhaps it's time I move my TGTRLS parameter
up to there.

Joe