CA Endevor

Expand all | Collapse all

Processors: BPXBATCH OMVS C++ compile?

Jump to Best Answer
  • 1.  Processors: BPXBATCH OMVS C++ compile?

    Posted 04-14-2016 10:45 AM

    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',                         
    //      PATHMODE=SIRWXU,PATHOPTS=(OWRONLY,OCREAT,OTRUNC)
    //STDERR DD PATH='&SPATH/serr',                         
    //      PATHMODE=SIRWXU,PATHOPTS=(OWRONLY,OCREAT,OTRUNC)
    

     

    Here is the source for the cxpmaskendvr.scp:

     

    #!/bin/tcsh                                                   
    # script to compile xpmask in z/OS OMVS Mainframe             
    #                                                             
    set HOME='/shared_application/cpp/dasg'                       
    # the compiler                                                
    set CC='c++'                                                  
    # 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 '                                 
    set INCOPTM=$HOME'/inc/optim'                                 
    set INCAPP=$HOME'/xpmaskdev/inc'                              
    set INCSYS="//'TTAT.TS2.DB2.SDSNC.H'"                         
    set DSNAOCLX="//'TUAD.TS2.DB2.V10R1M0.B.SDSNMACS(DSNAOCLX)'"  
    # the basic folders containing the code                       
    set SRC=$HOME'/xpmaskdev/src'   
    set OBJ=$HOME'/xpmaskdev/obj'                                    
    # xpmask.so lives here                                           
    set BIN=$HOME'/bindev'                                           
    set MAIN='libxpmaskendvr.so'                                     
    # ---------------------------------------------------------------
    # Step 1: Compiling source code                                  
    # ---------------------------------------------------------------
    echo 'Application Source Code:  '$SRC                            
    echo 'Application Header Files: '$INCAPP                         
    echo 'Compiling code'                                            
    # create temporary objects in OBJ                                
    cd $OBJ                                                          
    rm -f ./*.o                                                      
    $CC -I$INCAPP -I$INCODPP -I$INCOPTM -I$INCSYS $CFLAGS $SRC/*.cpp 
    ls -l $OBJ                                                       
    echo 'Linking code: '$MAIN                                       
    cd $BIN                                                          
    chmod -R 777 $BIN     
    $CC $LDFLAGS $MAIN $OBJ/*.o "//'TUAD.TS2.DB2.V10R1M0.B.SDSNMACS(DSNAOCLX)'"  
    ls -l $BIN                                                                   
    chmod 777 $MAIN                                                              
    #                                                                            
    cd $HOME  
    

     

    Clueless.

    Thanks!

    Karen



  • 2.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 04-17-2016 10:04 AM

    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.



  • 3.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 04-21-2016 01:15 PM

    Hi, Karen! Did Mat's suggestions help you? Could you come back at let us know?



  • 4.  Re: Processors: BPXBATCH OMVS C++ compile?
    Best Answer

    Posted 05-05-2016 05:04 AM

    Hi Karen,

     

    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.



  • 5.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 05-05-2016 08:02 AM

    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..

     

    Thank you,

    Phon



  • 6.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 05-05-2016 09:04 AM

    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!

     

    IBM Manuals

    CONTENTS "z/OS V1R2.0 C/C++ User's Guide" IBM Library Server



  • 7.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 05-12-2016 02:04 PM

    How have you and the user made out with this, Karen? Come back and let us know!



  • 8.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 10-06-2016 07:49 PM

    Hi all, 

    Progress to report:

    ite areound syslmod works (based on 3rd pos of proessor group in my case)

    IF 'U" syslmod points to uss path

    Else

    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.

     

    Thanks!

    KT



  • 9.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 10-06-2016 08:43 PM

    what is your next card after

    //'TTAP.TS2.DB2.SDSNC.+')

     

    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



  • 10.  Re: Processors: BPXBATCH OMVS C++ compile?

    Posted 10-06-2016 09:08 PM
    Our Java compile processor is for the entry stage of each path and the compile time input source code must be in the same entry stage.  The source code is moved to the final stage along with the executables, but without deleting from the entry stage, or else they bring the source code back to the entry stage for the next round of updates.  In your example maybe it is possible to place that source code in TSO libraries instead of, or in addition to, USS.  The search input for c++ can also be a DD (off-hand I am not sure the name, maybe SYSLIB or USERLIB) which allows monitor=, but in my experience it doesn't always find the input, I do not why know why.  So I execute the c++ compile step three times, once with DD to monitor inputs, once to create expanded source, and once to actually compile.