Exactly. Thank you. Yes, and COBOL does it more or less right also. It's even worse than what I wrote. I am about convinced I cannot get there from here.
Problem: I want to compile the bulk of my modules by default ARCH(9) (changeable from time to time) but two of them ARCH(5). Should be simple enough, right? (Why? See related thread. I want to deal gracefully with a machine whose ARCH level is lower than my build level. I want my main and the "deal with it" module to be able to run without a S0C1 on any "z" machine.) - You can't do the obvious: put ARCH(9) in OPTF and #pragma options ( ARCH(5) ) in the two because PARM=/OPTF overrides #pragma options -- the main subject of this thread. - I thought I was going to solve it by putting #pragma options ( ARCH(9) ) in a "universal" header and #ifdef around it in the two modules, ... BUT - #pragma OPTIONS is C only and my code is 98% C++. I could make one of the two C and split the other one up so part of it was C, but that still leaves me with no way of specifying ARCH(9) for the bulk of the modules. - Wait! IBM thoughtfully provided #pragma option_override! It overrides what was specified on PARM=/OPTF. It's C and C++. Sounds perfect, right? But no ... it only supports the optimization options, and ARCH is in this compiler's world not an optimization option -- only compact, level, spill and strict. - I am about convinced I can't get there from here. Does my problem seem that unreasonable? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Thursday, November 26, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any clever way to defeat the C compiler's options precedence? On 25 November 2015 at 14:24, Charles Mills <charl...@mcn.org> wrote: > The C/C++ compiler lets you set options globally with PARM= or > DD:OPTFILE (or equivalently on a UNIX command line for those who like > that sort of thing). You can also specify most options *first thing* > in a source module with #pragma OPTIONS. > > The former overrides the latter. It seems to me that is backwards. I > want to compile all of my modules with OPTION FOO, except one module > that I want to compile with OPTION NOFOO. I would like to specify > PARM=FOO globally and specify #pragma OPTIONS ( NOFOO ) in the one > module. Doesn't that sound reasonable? This seems incomprehensively BAD (Broken As Designed). Do other IBM compilers behave this way? Surely this is worth complaining about, even if that process is too slow for your current problem. The High Level Assembler does it about right, as you doubtless know. Quote from the book:: ====== Assembler options are recognized in this order of precedence (highest to lowest): Fixed installation default options Options on *PROCESS OVERRIDE statements Options in the ASMAOPT file (CMS or z/OS) or library member (z/VSE) Invocation options Options on the JCL PARM parameter of the EXEC statement on z/OS and z/VSE, or the ASMAHL command on CMS Options on the JCL OPTION statement (z/VSE) Options specified via the STDOPT (Standard JCL Options) command (z/VSE) Options on *PROCESS statements Non-fixed installation default options You can specify an option as often as you want, and in as many sources as you want. However, this may mean that you have specified the positive and negative form of an option (for keyword pairs), or two or more different values (for a value keyword). These option specifications are "conflicting" options. If all specifications of a particular option are at the same level of precedence, the last specification takes effect, and a warning message is issued. If some conflicting specifications are at different levels of precedence, then the specification at the higher order of precedence takes effect, and (in general) the assembler issues a warning message for each option that is not accepted. A warning message is not issued if the higher level of precedence is a *PROCESS OVERRIDE statement, unless the option cannot be set by a *PROCESS statement. ====== Effectively the above is saying that the equivalent of a C #pragma can be coded so as to override the global or other "per compile" options, except for an option chosen at compiler installation to not be overridable. Probably that's what C needs. HLASM also has an option (PCONTROL) to override the value of various operands of the PRINT statement. PRINT is very widely used, and controls six or so details of what gets shown in the listing. It can be very handy during testing and "for the record" building, but I'm not sure there is a meaningful C equivalent. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
