I am sorry for incorrect syntax in the example I posted. I am glad that you were able to figure it out from the documentation.
Original Message:
Sent: Mon March 30, 2020 07:58 PM
From: Scott Fagen
Subject: Issues with putting /usr/include/metal into EDCC (CCNDRVR) JCL
Hi Milos,
I'm not sure when the "multiple files in OPTFILE specification" support was added, but it's not apparent on my system. With this EDCC step:
//METALCMP EXEC EDCC,
// INFILE='SSAF.METALC.C(TSTENTRY)',
// OUTFILE='SSAF.METALC.C.ASM(TSTENTRY),DISP=SHR',
// PARM.COMPILE='OPTFILE(MYOPT, CMNOPT)'
It doesn't matter if I have the space before CMNOPT or not, the compile always gives this warning and fails, because most of the options are in the second file. Here is the warning:
WARNING CCN0465 'SSAF.METALC.C(TSTENTRY)':0 "OPTFILE" requires at most "1" sub-option(s) to be specified. "2" were
given.
It is not apparent from the z/OS 2.4 books that this is even an option for OPTFILE:
//METALCMP EXEC EDCC,
// INFILE='SSAF.METALC.C(TSTENTRY)',
// OUTFILE='SSAF.METALC.C.ASM(TSTENTRY),DISP=SHR',
// PARM.COMPILE='OPTFILE(DD:MYOPT) OPTF(DD:CMNOPT)'
//MYOPT DD DSN=SSAF.METALC.METALC.OPTIONS,DISP=SHR
//CMNOPT DD DSN=TCR.D1R1M0.METALC.OPTIONS,DISP=SHR
Just for grins, I tried the following:
//METALCMP EXEC EDCC,
// INFILE='SSAF.METALC.C(TSTENTRY)',
// OUTFILE='SSAF.METALC.C.ASM(TSTENTRY),DISP=SHR',
// PARM.COMPILE='OPTFILE(MYOPT)'
//MYOPT DD DSN=SSAF.METALC.METALC.OPTIONS,DISP=SHR
// DD DSN=TCR.D1R1M0.METALC.OPTIONS,DISP=SHR
which resulted in a most obtuse:
18.28.45 JOB08300 IEC141I 013-20,IGG0191A,TSTENTRY,COMPILE,MYOPT-0002,B028,SW0006, 449
449 TCR.D1R1M0.METALC.OPTIONS
18.28.45 JOB08300 IEC141I 013-20,IGG0191A,TSTENTRY,COMPILE,MYOPT-0002,B028,SW0006, 450
450 TCR.D1R1M0.METALC.OPTIONS
18.28.46 JOB08300 IEC141I 013-20,IGG0191A,TSTENTRY,COMPILE,MYOPT-0002,B028,SW0006, 451
451 TCR.D1R1M0.METALC.OPTIONS
followed by all kinds of compilation errors because the second dataset in the DD is not read.
I'm guessing this is because the two options datasets don't share the same attributes.
So this ends the saga.
------------------------------
Scott Fagen
scottf@21csw.com
Original Message:
Sent: Thu March 26, 2020 02:44 PM
From: Milos Lalovic
Subject: Issues with putting /usr/include/metal into EDCC (CCNDRVR) JCL
Scott,
You can easily achieve what you described by specifying a list of USS files and data set names as sub options of LSEARCH and SEARCH options inside an options file. The size of the command line is not an issue since you would be using an options file. If you need a different content for each developer, you could supply two option files, one that contains LSEARCH for individual developer and the other that has LSEARCH/SEARCH options for data sets/USS files common to all developers.
PARM="OPTF(MYOPT, CMNOPT)"
. . .
//MYOPT DD *
LSEARCH(/my/headers)
/*
//CMNOPT DD *
LSEARCH("//'COMMON.HEADERS.+'")
SEARCH("//'SYS.HDR1.+'" "//'SYS.HDR2.+'" /common/project/headers)
SEARCH("//'CEE.SCEEH.+'" "//'CEE.SCEEH.SYS.+'")
/*
The two option files are processed in the order they are found on the PARM statement, so in my example the content of MYOPT will precede the content of CMNOPT.
------------------------------
Milos Lalovic
Original Message:
Sent: Thu March 26, 2020 02:00 PM
From: Scott Fagen
Subject: Issues with putting /usr/include/metal into EDCC (CCNDRVR) JCL
Milos,
The use of concatenated datasets/paths is a tried and true method for allowing different developers to have similar but not the same macro concatenations. For example in assembler:
//SYSLIB DD DSN=SCOTT.PROJECTX.MACLIB,DISP=SHR <= The macros I'm working on right now
// DD DSN=TEAM.PROJECTX.MACLIB,DISP=SHR <= The latest version of the macros as promoted by the team
// DD DSN=TEAM.PRODUCTX.MACLIB,DISP=SHR <= The latest version of macros at the product level
// DD DSN=SYS1.MACLIB,DISP=SHR <= The latest version of the system macros
The last three DDs could be supplied to the entire team from a single place and INCLUDEd into each individual's JCL used to compile their code for either SEARCH or LSEARCH, assuming that SEARCH(SYSHDR) and LSEARCH(USERHDR):
// ... EXEC EDCC ...
//USERHDR DD PATH=/u/scott/projectx
// INCLUDE MEMBER=USERHDR <= this would be a set of DDs that are defined for the team and might be a mix of DD DSN and DD PATH statements
Can you suggest a way to achieve the same result, the programmer specifies their header libraries at the front of the (L)SEARCH and then some externally defined set of other datasets/paths are added afterwards...something like:
LSEARCH(/u/scott/projectx,'SCOTT.PROJECTX.H', <some variable statement here>)
It probably couldn't be done in the options file, something on the PARM statement?
Hmm...a SET statement from an INCLUDEd JCL member that set up a variable called &LHDRLIST. that could go into the JCL PARM might work but would be very limited in terms of the length...
Thoughts?
Scott
------------------------------
Scott Fagen
scottf@21csw.com
Original Message:
Sent: Thu March 26, 2020 01:08 PM
From: Milos Lalovic
Subject: Issues with putting /usr/include/metal into EDCC (CCNDRVR) JCL
Hello Scott,
You can find information about concatenated files in the section "Partitioned and sequential concatenated data sets" of the z/OS XL C/C++Programming Guide.
The use of concatenated data sets for header file processing is discouraged because a proper header file will not be included if the header file that exists with or without suffix is referenced from the source being compiled. The most obvious example is a C++ source including <iostream> but the first header data set contains the <iostream.h>.
The recommended approach is to use the SEARCH option which you already tried successfully.
------------------------------
Milos Lalovic
Original Message:
Sent: Wed March 25, 2020 10:26 PM
From: Scott Fagen
Subject: Issues with putting /usr/include/metal into EDCC (CCNDRVR) JCL
Hello,
I fought with this one for a few hours today. I'm trying to build a "header file concatenation" that includes /usr/include/metal in my JCL. It doesn't seem that the compiler understands that it is there when I put it on a DD card in the concatenation specified in the SEARCH(...) parameter.
So here's the snippet of JCL:
//METALCMP EXEC EDCC,
// INFILE='SSAF.METALC.C(TSTENTRY)',
// OUTFILE='SSAF.METALC.C.ASM(TSTENTRY),DISP=SHR',
// PARM.COMPILE='OPTFILE(''SSAF.METALC.OPTIONS'')'
//COMPILE.SYSHDR DD DSN=CBC.SCCNSAM,DISP=SHR
// DD PATH='/VERSYSB/usr/include/metal',PATHOPTS=ORDONLY
// DD DSN=SYS2.ZOS24.SIEAHDR.H,DISP=SHR
// DD DSN=SYS1.SIEAHDR.H,DISP=SHR
//COMPILE.USERHDR DD
// DD DSN=SSAF.METALC.MACH,DISP=SHR
// DD DSN=SSAF.METALC.H,DISP=SHR
// DD DSN=TCR.D1R1M0.MACH,DISP=SHR
// DD DSN=TCR.D1R1M0.H,DISP=SHR
I've also tried all the following in the PATH DD with the same results:
// DD PATH='/usr/include/metal',PATHOPTS=ORDONLY
// DD PATH='/VERSYSB/usr/include/metal'
// DD PATH='/usr/include/metal'
The compile always fails with (at least) the following two messages:
WARNING CCN3296 SSAF.METALC.C(TSTENTRY):2 #include file <metal.h> not found.
ERROR CCN3205 CEE.SCEEH.H(STRING):26 Language Environment standard C headers
cannot be used when METAL option is used.
Correct your header search path.
My options file (SSAF.METALC.OPTIONS) contains the following for the SEARCH parameter:
NOSEARCH
SEARCH(DD:SYSHDR)
However, if I remove the PATH='/usr/include/metal' from the DD concatenation and change the OPTIONS file to have the following SEARCH parameter, the header files in the path are located successfully and the module compiles successfully.
NOSEARCH
SEARCH(/usr/include/metal,DD:SYSHDR)
Is there something incorrect about including a path in the DD concatenation for the system header files? If so, where is that documented?
Thanks,
Scott
------------------------------
Scott Fagen
scottf@21csw.com
------------------------------