|
it is running interactively.
OK, then it's not because the environment variables are not being
copied to the batch job (see CPYENVVAR keyword on SBMJOB command for
more information).
I think it's perhaps because of the complicated relationships between
SRCSTMF, INCDIR, OPTION, and the INCLUDE environment variable. Note
that I don't use source stream files but I note from the C/C++
Compiler Reference (for VRM610):
Chapter 4. Page 85
2. If SRCSTMF is specified, then the following compiler options
are
ignored:
o INCDIR( )
o OPTION(*INCDIRFIRST)
o TEXT(*SRCMBRTXT)
o OPTION(*STDINC)
o OPTION(*SYSINCPATH)
Note that INCDIR is ignored in this case (seems peculiar behaviour to
me so perhaps the documentation is wrong on this point. It also
contradicts the C/C++ Programmer's Guide). Note also that
OPTION(*INCDIRFIRST) is ignored; this is relevant to the next item
(but also seems wrong to me).
Chapter 4. Page 90
*NOINCDIRFIRST
Default setting. The compiler searches for user include files in
the root
source directory first, and then in the directories specified by
the
INCDIR option.
*INCDIRFIRST
The compiler searches for user include files as follows:
1. If you specify a directory in the INCDIR parameter, the
compiler
searches for file_name in that directory.
2. If more than one directory is specified, the compiler searches
the directories in the order that they appear on the command
line.
3. Searches the directory where your current root source file
resides.
4. If the INCLUDE environment variable is defined, the compiler
searches
the directories in the order they appear in the INCLUDE path.
5. If the *NOSTDINC compiler option is not chosen, search the
default
include directory /QIBM/include.
Note that the only mention of the INCLUDE environment variable is when
*INCDIRFIRST is specified. The documentation implies that with
*NOINCDIRFIRST specified only the source directory and the INCDIR
directories are searched.
Chapter 4. Page 129
INCDIR
Lets you redefine the path used to locate include header files
when
compiling a source stream file. This option is ignored if the
source
file's location is not defined as an IFS path with the SRCSTMF
compiler
option, or if the full absolute path name is specified on the
#include
directive.
Note that the above contradicts point 2 on page 85.
Given that the documentation states that when SRCSTMF is used both
INCDIR and OPTION(*INCDIRFIRST) are ignored then the implication is
that the default behaviour i.e., OPTION(*NOINCDIRFIRST) is in effect.
If that is true and point 2 on page 85 is correct then you cannot use
this combination.
However, it seems to me that ignoring INCDIR and OPTIONS(*INCDIRFIRST)
defeats the point of these things. Perhaps you actually have to
specify OPTIONS(*INCDIRFIRST) to get the INCLUDE environment variable
to be processed?
I note that Dennis said in an earlier append that "the INCLUDE
environment variable is ignored if INCDIR is specified" but I couldn't
find that. Indeed, I found the opposite in the Programmer's Guide:
Chapter 17. Page 206
1. Searches the directory where your current source file resides.
The
current source file is the one that contains the directive
#include "file_name".
2. If you specify a directory in the INCDIR parameter, the
compiler
searches for file_name in that directory.
3. If more than one directory is specified, the compiler searches
the directories in the order that they appear on the command
line.
4. If the INCLUDE environment variable is defined, the compiler
searches the directories in the order they appear in the INCLUDE
environment variable.
5. Searches the directory /QIBM/include.
So, aside from the confusing documentation, it seems what you want
should work and is perhaps failing due to a combination of parameters.
Perhaps also it is "silliness" with regard to the value in the INCLUDE
variable itself. I know some Unix-y stuff expects a trailing colon on
path lists so try adding that. Also, perhaps the use of ./ is
confusing things. Since it just means the current path (.. = parent, .
= current) and since a relative path will start in the current
directory any way perhaps removing that will fix things.
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 / \
--------------------------------------------------------------------
--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-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.