IBM 64-bit SDK for z/OS, V5 - Restrictions and Other Considerations

• Restrictions
• Migration
• Other considerations

Restrictions

• Possible problem using JZOS launcher as a Started Task

  In some rare instances, running the JZOS launcher function delivered in 64-bit SDK5 SR3 (PTF UK18623) as a started task (STC) can result in a protection exception (0C4). Two conditions must be met for this failure to occur:

  1. JZOS is started as a started task
  2. No start parameters are passed to JZOS

  To avoid this possible failure the following command syntax should be used:

  START procname,,,BYPASS
  

  Where "BYPASS" can be any arbitrary nonzero length string. The letters "BYPASS" or even "X" can literally be used. This approach can be used as a workaround for z/OS SDK customers until the fix is propagated to a new service refresh.

  This potential problem does not exist for batch jobs launched with the JZOS function. Some customers have reported that the problem in the JZOS launcher function is intermittent. It can appear after the application of z/OS maintenance.

• SDK V5 takes advantage of enhanced z/OS linkage capabilities (XPLINK) for greatly improved performance. In most common cases, this will be done completely transparently. However, any application code that creates a JVM itself and interacts with the JVM via Java Native Interface(JNI) or any other "call" interface must create the Language Environment (LE) enclave specifying that LE should setup an XPLINK environment. That environment will include an XPLINK specific runtime library and stack format. This XPLINK LE enclave must be in place prior to creating the JVM. There are a variety of ways to accomplish this. They include setting a run-time option (XPLINK(ON)), or recompiling the launching application code to be XPLINK. These options and a description of the XPLINK technology are contained in the IBM Redbook, SG245991. Further details can be found in z/OS Language Environment Programming Guide.

  Note that non-Java applications which are called through JNI subsequent to the instantiation of the JVM can be either XPLINK or non-XPLINK applications. Again, details are given in the above references.

• For cryptographic key generation with IBMJCECCA present:

  If you have installed the IBMJCECCA hardware provider, be sure when generating software keys that IBMJCE is before IBMJCECCA in the java.security provider list.

  For more information see z/OS Unique Considerations for the Java 2 SDK, Standard Edition, V5 and Java Cryptography Extension in Java 2 Platform Standard Edition, Hardware Cryptography IBMJCECCA Overview.

• 
  
• The persistent reusable and shared classes support in the 31-bit, IBM SDK for z/OS, Java 2 Technology Edition Product (5655-I56) is not present in this SDK 5 product.
  
  
• The new I/O (NIO) channels in this SDK and Runtime Environment have a number of limitations, listed in the following table. Click on the defect number to link to the Sun Web site that documents the limitation. To go directly to the bug, you must be a registered member of the Java Developer Connection. To see which bugs have been fixed, you should check the contents of any service refreshes of this SDK and Runtime Environment.

Back to top

Migration

At Version 1.4.2 (64-bit) and Version 5 (31-bit), the IBM Runtime Environment for z/OS contained new versions of the IBM Java Virtual Machine (JVM) and the Just-In-Time (JIT) compiler. If you are migrating from an older IBM Runtime Environment, note that:

• The JVM shared library libjvm.so is installed in directory jre/bin/j9vm. This directory is different, for example, from the Runtime Environment for z/OS for Version 1.4.2 (31-bit), where it is installed in jre/bin/classic. Native applications using the JNI invocation interface might need to add the new directory path to their environment variable or variables in order to locate the JVM dynamic link library.
• 
  
  
• The JVM Monitoring Interface (JVMMI) is no longer available. You must rewrite applications that used that API. You are recommended to use the JVM Tool Interface (JVMTI) instead. The JVMTI is not functionally the equivalent of JVMMI. For information about JVMTI, see JVM Tool Interface (JVMTI) and the Diagnostics Guide.
• 
  
  
• The new implementation of JNI conforms to the JNI specification, but differs from the old implementation. It returns copies of objects rather than pinning the objects. This difference can expose errors in JNI application code. For information about debugging JNI code, see -Xcheck:jni in Nonstandard options.
• 
  
  
• The format and content of garbage collector verbose logs obtained using -verbose:gc have changed. The data is now formatted as XML. The data content reflects the changes to the implementation of garbage collection in the JVM, and most of the statistics that are output have changed. You must change any programs that process the verbose GC output so that they will work the new format and data. See the Diagnostics Guide for an example of the new verbose GC data.
• 
  
  
• Earlier versions of the IBM JRE shipped with a file called rt.jar in the jre/lib directory. From Java V1.4 onwards, this file has been replaced by multiple JAR files that reside in the jre/lib directory.
• 
  
  
• For additional industry compatibility and deprecated api information, see Sun's Java 5 Compatibility Documentation and Sun's Java 5 Deprecated API List.
• 
  
  
• All z/OS Java SDK program products, whether the 31-bit SDK 1.3.1, 31-bit SDK 1.4, 64-bit SDK 1.4, or the 31- or 64-bit SDK 5 products, can be installed and executed on the same z/OS machine. They are independent program products and can co-exist in any combination.
• 
  
  
• The serial reusability feature of the IBM SDK for z/OS, version 1.4.2 (31-bit) and earlier, invoked using -Xresettable, is not supported. If you specify -Xresettable the JVM will issue an error message and will not start. The -Xinitasch and -Xinitth options, which allowed heap sizes to be specified for the resettable JVM, are ignored. You can share data between JVMs in an address space (the old -Xjvmset and -Xscmax options) using Class data sharing between JVMs, a new facility for 5.0. If you specify -Xjvmset or -Xscmax the JVM will issue an error message and will not start.
• 
  
  
• Tracing class dependencies, invoked using -verbose:Xclassdep, is not supported. If you specify -verbose:Xclassdep the JVM will issue an error message and will not start.

Back to top

Other Considerations

Programs interacting with the 64-bit Java product, whether launching the JVM or being called from the JVM through the JNI interface, must be 64-bit programs. Programs dependent on JNI interfaces may require changes at the interface boundary to conform to 64-bit data types. Application JNI routines written in C will need to be recompiled for 64-bit, which may require some code changes.

Back to top