How Java effects my job...
        
        If a developer uses a newer version of Java then we support, thier code will not
                run, I will get a Version Mismatch Error
        
        Java is installed and runs under USS, this means...
            I MUST be case senstive in all my paths
            the path starts with the Unix root '/'
            USS is ASCII, there is both 32 bit (up thru Java 8) and 64 bit
            (java 11 or later)
            
        I access USS via TSO command OMVS, this means I need access to USS, and I write 
            Unix commands, developer can also assecc USS via thier devlopment tool
            IBM sells a developer tool named Rational Developer for zSystems
            
        Java SE is installed (by default) under /usr/lpp/java/<version>
           WARNING: IBM provided both a 32 bit and a 64 bit version of each Java release
           up to Java 8, then it is ONLY in 64 bit versions, this location is
           used when running a Java appl, and is called JAVA_HOME
           
        a Devloper will write/compile Java on thier work PC, then upload the compiled
           code to USS, this has a number of impacts:
             Java code is binary, I do not see the sources code on the MF
             Java code is deployed as jar (Java Archive) files (think zip file)
             the Developer has access thier Unix Home Directory, so this is where
                they upload the code, however, this should NOT be where production
                code runs from
                
        the process of moving deployed Java code from the Developer's Home Dir
           to the location it run from in production has a number of impacts
             -> the Log file path
             -> the property file path
             -> any shell scripts path and contents
             -> permissions

        most Java application have more than a single jar file on thier CLASSPATH, 
           during devlopment I create a folder to hold these 3rd party jars, but
           in production???? a shared folder???
           
        I need to keep track of the 3rd party jar in case a security notice comes out
        

        My JCL now has PATH= to access HFS files, and this is case sensitive
        all paths in JCL should be absolute paths (they start at root '/')
        
        
        HFS files/directory have permissions, this is the PATHMODE jcl parameter


        Support Java on the MF needs: a Java Admin to install Java, manage permissions
        setup shared 3rd party frameowrk folders, manage the version of 3rd party framework
        the IRS has a Java Appl Architecture Group (JAAG) 
        
        
        Java code Error messages DO NOT go to JES without an extra JCL step to copy them
        
        
        Java code can exit with ANY return value that becomes the Condition Code of the job step
        
        
        If I have a Unix Shell Script (which I can invoke via JCL) this means changing the 
        files used for I/O in the code, means editing the Unix Shell Script
                
                
        When I invoke Java from anywhere I need to give the full name of the Java Entry Point
         this is in the form of <package>.<class>
         for example: gov.irs.k2.util.Report


        If the Java devloper uses Relative Paths (these paths start w/ the current dir)
        (for example a property file) I need to keep these path the same when I move
        to a Prod Support dir
        
        
        If the Java code does Logging, I need access to the log config file, I need to know
        where the log is going, and what to do when it get huge