I have to agree with Tony here. I think that any compiler options should
remain in the H specs. While I agree that the pre/post command option
would take care of this and would ensure that any new compiler options
were supported without depending on IBM, I would much rather have the
consistency of having all of the compiler options in the H specs or none
of them, and I don't see IBM breaking the current behavior of the
compiler by removing that support. I guess I have to ask the question,
is team responsible for the compiler commands different from the team
responsible for the compiler/precompiler? If not, then why can't support
for any new compiler options be added when those options are added?

Actually I am not necessarily in favor of the pre/post compile
commands, the potential for people to put in commands that mess up
something important, i.e. CLRPFM or DLTLIB, is much too great. The nice
thing about the keyword solution for the file problem is that there
would be no need to create a temporary file before or during the
compile. When I compile a program the only thing that should happen is
that my program is compiled, the compiler should not be capable of
permanently changing any object other than the object being compiled. So
I think that there should be definite limits on what commands could be
executed and possibly over the objects they could be executed on. That
being said, it would be nice to be able to include commands to add
constraints to a physical file after it was compiled.

Joe Lee


>>> carolla@xxxxxxxxx 10/13/2004 15:11:30 >>>
I don't believe changing SEU would be a huge deal (for those that
still use it).  What we are talking about here is modifying the
compile module, either way.  You either do it your way and have it run
arbitrary commands are do arbitrary 'stuff' at the top of the source
code, in another specially defined compiler directive section of code,
or you build on what you already have, in the header spec, and/or the
ExtFile() keywords.  I would think that, looking forward, it makes
more sense to build on what's already there.

Either way, you're talking about modifying the compiler.  


On Wed, 13 Oct 2004 16:58:30 -0500, Lim Hock-Chai
<lim.hock-chai@xxxxxxxx> wrote:
> command override is a one time deal (if ibm ever create it and
function as what I have in mind).  After it got created, I can override
any compile command parm.  If ibm add a new parm to the compile command,
you can right away use it in the override command.  A keyword, however,
need to build into the SEU and specific compiler to recognize it.
> 
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Tony Carolla
> Sent: Wednesday, October 13, 2004 4:48 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: Suggestion: File to use when compile
> 
> ... And why would it take longer (10 years) to create a new H-spec
or
> a modified F-spec, rather than a completely new type of animal
> (command override?  command default?)
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l 
> or email: RPG400-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
> 


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.