On Fri, 28 Mar 2014 12:19:33 -0500, Chuck Arney <ch...@arneycomputer.com> wrote:

>The problem is that the compiler is not locating the header files that are
>included in the source program.  My understanding from the manual is that
>the compiler PARM SEARCH controls the library search sequence used for
>system headers and the PARM LSEARCH controls the search for user headers.  I
>have tried every combination of coding absolute paths, DDnames and PARMS
>that I can come up with and the thing just refuses to work.  The most simple
>case I can see is to specify the compiler PARMS NOSEARCH,NOLSEARCH.
>According to the manual with these parms, the compiler should search the
>libraries/directories defined in the SYSLIB DD concatenation for system
>headers and search the libraries/directories defined in USERLIB DD for user
>headers.  Using those parms with the SYSLIB and USERLIB DDs the compiler
>does not find the #include header files which are certainly contained in the
>libraries pointed to by the two DDs.  I have tried much more complex options
>using both PDS libraries and ZFS directories with no success.

I ran into similar problems when trying to set up a job to compile for Metal C, 
I ended up coding NOSEARCH followed by SEARCH for the correct list of 
libraries.  For example,

//CC        EXEC EDCC,
// INFILE='XXXXXXX.SRC.C(RXMETAL)',
// CPARM='OPTFILE(DD:CCOPTS)'
//COMPILE.CCOPTS DD *
METAL
LIST
SOURCE
NOMARGIN
NOSEQUENCE
OPT(3)
ARCH(10)
TUNE(10)
LOCALE
NOSEARCH
SEARCH(/usr/include/metal/,//'SYS1.SIEAHDR.H',//'XXXXXXX.SRC.H')

ref: http://mainframe.elevengestures.com/using-metal-c-instead-of-spc/

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to