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