× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 01/09/2009, at 2:05 AM, James H. H. Lampert wrote:

It's always been a pet peeve of mine that when compiling a C program
(contrary to the defaults for almost every other compilation), the
default is to NOT spool out a compilation listing.

I hate that too. The error message go to the job log. My guess is because of misguided attempt to emulate STDERR/STDOUT on Unix. Misguided because even on Unix allowing compiler error output to go to stderr/stdout is next to useless and needs to be redirected to a stream file so it can be properly examined in an editor.

I complained about this years ago but of course it was only after it was released and therefore too late to correct.

Is there an easy way to fix that?


Not really. The easy way would be to use CHGCMDDFT to set OUTPUT(*PRINT) which is what I used to do to the C compiler commands prior to V5. With V5 we got the AIX C compiler (which although more compliant with C standards is much worse than the native compiler at diagnosing error conditions--really easy to confuse the parser so it puts errors on the wrong line) and the developers provided a different command interface.

They stupidly chose to make the OUTPUT keyword an element list with the first element being a path name supporting special values *NONE or *PRINT (also *none and *print which is kind of stupid too). Because it's an element list you can't run CHGCMDDFT against it. I can't believe this got past the people who approve CL commands.

What they should have done is add a special value to OUTPUT for *STMF and use a separate parameter for the path name. Much like the existing OUTPUT(*OUTFILE) precedent works. This way we could change the command default to *PRINT but the stream file support would also be available for those who want it.

The easiest way remaining is perhaps to create a PDM option (or Eclipse equivalent) that sets OUTPUT(*PRINT), or perhaps define your own command and CPP that does things properly, or you could use the command exit points to force OUTPUT(*PRINT) if not specified.

For those who care:

This is the flawed definition:

PARM KWD(OUTPUT) TYPE(E1) DFT(*NONE) SNGVAL((*NONE) (*none *NONE)) +
PMTCTL(*PMTRQS) PROMPT(CZX1520)

E1: ELEM TYPE(*PNAME) LEN(3000) SPCVAL((*PRINT) (*print *PRINT)) MIN(1) +
EXPR(*YES) VARY(*YES) PROMPT(CZX1510)
ELEM TYPE(*CHAR) LEN(80) DFT(*BLANK) SPCVAL((*BLANK)) EXPR(*YES) +
VARY(*YES) PROMPT(CZX1830)
ELEM TYPE(*CHAR) LEN(80) DFT(*BLANK) SPCVAL((*BLANK)) EXPR(*YES) +
VARY(*YES) PROMPT(CZX1720)

This is what they should have done instead:

PARM KWD(OUTPUT) TYPE(*CHAR) LEN(1) DFT(*NONE) +
SPCVAL((*NONE ' ') (*PRINT 'L') (*STMF 'S') +
PROMPT(CZX1520)

PARM KWD(STMF) TYPE(E1) MIN(1) +
PMTCTL(P1) PROMPT(CZX1563)

E1: ELEM TYPE(*PNAME) LEN(3000) MIN(1) EXPR(*YES) +
VARY(*YES) PROMPT(CZX1510)
ELEM TYPE(*CHAR) LEN(80) DFT(*BLANK) +
SPCVAL((*BLANK)) EXPR(*YES) VARY(*YES) +
PROMPT(CZX1830)
ELEM TYPE(*CHAR) LEN(80) DFT(*BLANK) +
SPCVAL((*BLANK)) EXPR(*YES) VARY(*YES) +
PROMPT(CZX1720)

P1: PMTCTL CTL(OUTPUT) COND((*EQ 'S'))

The only significant difference is that OUTPUT can no longer be PMTCTL(*PMTRQS) because keywords defined that way can not be used in a later PMTCTL test. However, that minor inconsistency with the other compiler commands outweighs the serious annoyance imposed by the current definition.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.