Uncharted waters here. Is anyone executing BPXBATCH to run a compile script (I'm guessing .scp means script)? If so, how are you managing the script? I have an application using C++ (heretofor known as CPP) under OMVS. I have the CPP type ZFS directories and the MVS processor up and running without issue. Now we are moving on to the USS compile phase for their mixed case elements. Here is the sample JCL/.scp they gave me:
//SPATH SET SPATH='
//BPBATCH EXEC PGM=BPXBATCH,
// PARM='sh &SPATH/cxpmaskendvr.scp'
//STDIN DD PATH='&SPATH',PATHOPTS=(ORDONLY)
//STDOUT DD PATH='&SPATH/sout',
//STDERR DD PATH='&SPATH/serr',
Here is the source for the cxpmaskendvr.scp:
# script to compile xpmask in z/OS OMVS Mainframe
# the compiler
# the compiler flags, extend these if needed
# set CFLAGS='-Wc,xplink,-qlanglvl=extended0x -c'
set CFLAGS='-Wc,EXPORTALL,xplink,-qlanglvl=extended0x -c'
# here are the loader flags, extend them if needed
set LDFLAGS='-Wl,xplink -o'
# common accros platforms: ODPP + user's defined headers
set INCODPP=$HOME'/inc/odpp '
# the basic folders containing the code
# xpmask.so lives here
# Step 1: Compiling source code
echo 'Application Source Code: '$SRC
echo 'Application Header Files: '$INCAPP
echo 'Compiling code'
# create temporary objects in OBJ
rm -f ./*.o
$CC -I$INCAPP -I$INCODPP -I$INCOPTM -I$INCSYS $CFLAGS $SRC/*.cpp
ls -l $OBJ
echo 'Linking code: '$MAIN
chmod -R 777 $BIN
$CC $LDFLAGS $MAIN $OBJ/*.o "//'TUAD.TS2.DB2.V10R1M0.B.SDSNMACS(DSNAOCLX)'"
ls -l $BIN
chmod 777 $MAIN
I've seen CPP compiles that look more like regular JCL, and therefore suit implementation as processors more closely - yes you still need to set up 'class path' variables etc, but you should be able to replace the PGM=BPXBATCH with a PGM=CCNDRVR as per the sample at http://www.ibm.com/support/knowledgecenter/#!/SSGTSD_12.1.0/com.ibm.debugtool.doc_12.1/ugdita/eqabus01191.html
I'd be tempted to get that JCL version working, and then convert it to a processor, with the usual component monitoring, list output management, and if required ENUSSUTL to manage/copy USS outputs (so that they can be backed out, shipped etc.)
I know this is the way that our internal C developers manage their generates at CA... their processor however is not a great example to share as it is very site specific and manages multiple versions of C (depending on the processor group) - but if you're stuck I could try and work out a canonical example and post that... Perhaps it could even be added to the supplied sample processors.
Hi, Karen! Did Mat's suggestions help you? Could you come back at let us know?
Our scripts are sh suffixed and our program elements are JAVA, not CPP. Your script above has a fixed location where it compiles everything. We pass variables to the scripts that identify the location of the source code (different ENDEVOR stages, systems, and subsystems have different UNIX paths) which is copied to a JAVA package directory (our JAVA source code always identifies a JAVA package name). Since there are multiple source files per compile, we define a type (JAR) that triggers the compile separate from the type for the source files (JAVA). The type JAR program element is a text file identifying the packages that are being compiled, and the output is a binary JAR. We only compile in the entry stage then we move everything to production. Since this is CPP you will probably need to do this differently, but some of the concepts are probably similar.
Another approach is to have the UNIX development done on another platform using a different SCM tool and then transfer the resulting executables to Z/OS, add them to ENDEVOR, and move them to production. You need to arrange to properly secure the file transfers to ensure that the executables completed the approved SCM process on the other platform. I advise against allowing the developers do the file transfers, it should be SCM staff.
I think any processor example would be a huge benefit, so that we as Endevor Admins are not reinventing the wheel. Any supplied processor from CA, we always have to make it our own in order to meet our standards, but if we can take a proven example and then work from that it cuts our development time exponentially. We greatly appreicate any thing that we can get, especially when you are talking about a new programming language/types that need to be supported by us old mainframe types..
Thanks Eoin! I knew I'd hear from you eventually! The user and I are just coming back to this topic. I was poking around google the other day and found teh C++ User's guide. It says you can use the basic compile jcl to create uss objects (&c1element255..o) . He and I (and the guy who write the script) are going to compare notes to see what we can come up with, I hope I can just tweak the Z/os processor(s) with some ITE around the SYSMOD DD based on processor group. I'll keep everyone posted, but keep those suggestions coming!
CONTENTS "z/OS V1R2.0 C/C++ User's Guide" IBM Library Server
How have you and the user made out with this, Karen? Come back and let us know!
Progress to report:
ite areound syslmod works (based on 3rd pos of proessor group in my case)
IF 'U" syslmod points to uss path
SYSLMOD points to PDSE loadlib.
I have however hit the next wrinkle:
c++ include directories. The sample the user gave me uses the
//OPTIONS DD DATA,DLM=ZZ LANGLVL(EXTENDED) DLL LO GOFF SOURCE LIST NOMARGINS NOSEQ EXPORTALL XREF SEARCH(/shared_application/endevor/&C1SY/CPPINCL/ , << this is giving me heartburn ! /shared_application/cpp/dasg/xpmask/inc , /shared_application/cpp/dasg/inc/odpp , /shared_application/cpp/dasg/inc/optim , /shared_application/cpp/dasg/TestMod/inc , //'SYS1.SCEEH.+',//'SYS1.SCLBH.+', //'TTAP.TS2.DB2.SDSNC.+')
I created the CPPINCL directories as system/type/stage
I do I get past the type directory and search thru all the stage subdirectories without coding all 7 subdirectories?
Right now its only finding the include if I code /CPPINCL/&C1ST (since the include is in the same stage as the program).
Any ideas how to code a root directory like you can code "+" for dataset name nodes?
I've found references to -I and OE in the Z/os manual but only under SEARCH, can't seem to find the doc on those 2 specific options.
what is your next card after
It should be ZZ not a /* otherwise the system thinks everything up to the end is also DD * input.
See the example from the JCL manual
/THIRD DD *,DLM=ED..input data..ED <- the ed replaced the /* card