Java Virtual Machine (Known Issues)

You can edit, debug, and compile COBOL applications to JVM byte code (.class files) so that they can be run on a Java Virtual Machine. The following limitations and restrictions apply:

Environment:

• The XML Preprocessor, and XML Extensions are not supported in JVM COBOL. XML PARSE/GENERATE are supported.
• Currently, JVM COBOL is only supported on System z running Linux 390 when the JIT compiler is restricted to use only the cold level optimisations.

  This can be done by specifying 'cobjrun -Xjit:optLevel=cold ProgramName' (or 'java -Xjit:optLevel=cold ProgramName') to launch the program. For more information, see the topic Selectively disabling the JIT in the Java SDK documentation available on IBM's Web site.

• There is a known issue with IBM’s JVM support for the Java™ Attach API which causes the API to leak semaphores under certain conditions. If you are running IBM’s JVM on AIX and Redhat or SUSE Linux on z390, this can cause your machine to run out of semaphore space resulting in the machine running slower or causing intermittent failures.

  To determine whether you are experiencing this issue, type the following at the command line to check the number of semaphores that start with the 0xa1 prefix:

  "ipcs -s -r | grep 0xa1 | wc –l"

  If this number is very high and keeps growing you need to follow the cleanup procedure described in the "IBM Developer Kit and Runtime Environment Diagnostics Guide", "Chapter 19. Attach API problem determination", ftp://public.dhe.ibm.com/software/dw/jdk/diagnosis/diag50.pdf

  You can disable the Java™ Attach APIs to avoid the issue. Note, however, that when Attach API is disabled, it will not be possible for other Java application to attach to your application and features such as jtop, jstat, jconsole, JMX agents, JVMTI agents will cease to function.

  The Attach API is enabled by default for Java 6 SR6 and later. To disable the feature you need to set the IBM JVM property com.ibm.tools.attach.enable to "no".

  You can use this property with any Java trigger, or with IBM’s environment variable IBM_JAVA_OPTIONS which allows you to pass extra arguments to the JVM without changing any command lines.

  You can set the variable as follows:

  export IBM_JAVA_OPTIONS=-Dcom.ibm.tools.attach.enable=no

• If a build is producing java.lang.OutOfMemoryError errors, you can try increasing the amount of memory available to the heap. Increase the maximum amount allowed by using the -Xmx parameter in the cobjvm.cfg file, which is located in the etc sub-directory of your installation directory. For example, to set the available memory to 64MB, add the following:

  -Xmx64m

• To specify the location and name of a run-time configuration file for your JVM COBOL applications, use the COBCONFIGJVM environment variable (not the COBCONFIG environment variable).
• The format of a JVM tunables file must be that of a standard Java properties file and not the format used by the native run time.
• COBOL JVM projects require Java 17 or later. Trying to build a COBOL JVM project that targets a version of Java earlier than version 17 while having it installed in Eclipse results in a COBOL syntax error COBCH1561S ("JVM support not found: are you using a supported version of the JRE?"). You can use the Quick Fix command to resolve the problem and link to a supported version of Java:

  1. In Problems view, right-click the row containing the error.
  2. Click Quick Fix. Alternatively, you can press Ctrl+1. This opens the Quick Fix dialog box with a suggested fix for the problem.
  3. Select the fix that replaces the old JRE with a supported JRE version.
  4. Click Finish.

  If a supported JRE is installed on your machine, you receive a message that the JRE has been successfully replaced. If no supported JRE build path is available on your machine, then you need to add it, see Compiling JVM COBOL for more details.

JVM COBOL code:

• You cannot use generics in your JVM COBOL code.
• In JVM_LOAD_NATIVE, the myLibrary parameter must be passed as a literal; it cannot be declared in a COBOL storage section.
• COBOL class package and the directory structure is enforced. You might get errors finding source code.

  For example:

  If a COBOLClass1.cbl is within a package com.microfocus.core then it should be in the Project/src/com/microfocus/core/COBOLClass1.cbl directory. In the case the com.microfocus.core package is mapped to com/microfocus/core directory.

• You cannot pass a JVM procedure-pointer to a native COBOL application.
• A combination of using continuation lines and a source-format of variable has been known to produce screen corruption and sometimes crash the JVM. A workaround is to compile your application with the source-format"fixed" directive, or if that is not possible, set and then unset the directive immediately before and after the code containing the continuation lines.
• You can run some COBOL classes as COBOL JVM applications even when the COBOL class does not explicitly define a main method that satisfies all criteria for JVM, which are that the main method:
  • Is named main
  • Is marked public static
  • Uses the string occurs any arguments

  However, the application must not contain a using clause in at least one static method or in the class itself.

  When all of these criteria are met, the Run as COBOL JVM Application option is available.