Java 8 and JDBC on OpenVMS 8.4 IA64.

[Cedric_P]

Hi there,

 I am experiencing some runtime issues with Java programs trying to connect on Oracle databases from OpenVMS. Any JDBC code is ending on a access violation crash. The Java version has been changed recently from 6 to 8 and the latest Oracle kit has been installed to match it. The JDBC programs were working correctly with Java 6 and Oracle client 10. The test program below is working with Java 6.

JDK8 release notes: https://www.hpe.com/global/java/documentation/1.8.0/ivms/docs/release_notes.html

 Architecture: HP Itanium IA64

Operating system: OpenVMS 8.4

Java runtime:

  java version "1.8.0.03-OpenVMS"

  Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)

  Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)

Oracle client libraries: Oracle 11.2.0.4 (latest version on this OS)

The Oracle database version is not relevant since the program does not initialize the JDBC driver properly. Entering wrong database SID is leading to the same crash.

By the way, I had to set a logical ORA_TZFILE to get the ProC precompiler to work... the problem looks connected to the timezone/time settings ("ORA_TZFILE" = "DISK$DEV_APP_DSK:[ORACLE112.HOME.oracore.zoneinfo]timezlrg_9.dat").

Even the test program called JdbcCheckup.java (https://docs.oracle.com/cd/E11882_01/java.112/e16548/getsta.htm#JJDBC28057) is crashing:

$ show log JAVA$CLASSPATH
   "JAVA$CLASSPATH" = ".:/jdbc_lib/ojdbc6.jar:/jvmlib/aurora.jar:/ohjlib/jta.jar:/ohjlib/jndi.jar:/orlib/ordim.jar:/orlib/ordhttp.jar:/olib/lclasses15.zip:/njlib/netthin15.jar:/rjlib/aqapi.jar:/rjlib/jmscommon.jar:/slib/translator.jar:/slib/runtime12.jar:/slib/runtime.zip:" (LNM$PROCESS_TABLE)

$ java -jar jdbc_lib:ojdbc6.jar
Oracle 11.2.0.3.0 JDBC 4.0 compiled with JDK6 on Thu_Jul_11_15:43:23_PDT_2013
#Default Connection Properties Resource
#Thu Aug 24 08:10:00 BST 2017

$ java -version
java version "1.8.0.03-OpenVMS"
Java(TM) SE Runtime Environment (build 1.8.0.03-vms-rc1)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b02, mixed mode)

$ java JdbcCheckup
Please enter information to test connection to the database
user: xxxx
password: xxxx
database(a TNSNAME entry): xxxx
Connecting to the database...Connecting...
OpenVMS stack trace:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  %SYSTEM-F-ACCVIO (0xc) at pc=69DD320, pid=545382929, tid=2070802112
#
# JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0.03-vms-rc1)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b02 mixed mode OpenVMS-ia64 )
# Problematic frame:
# C  [libocijdbc11+0xb0]
#
#
#
# An error report file with more information is saved as:
# /sys$scratch//hs_err_pid545382929.log
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000002C, PC=000000000110F160, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
java$jvm_shr  frame_ia64  compiled_sender_sp
                                        210934 0000000000004220 000000000110F160
java$jvm_shr  frame_ia64  sender_sp     210924 00000000000034E2 000000000110E422
java$jvm_shr  vmError  report           212479 0000000000002F22 00000000021243A2
java$jvm_shr  vmError  report_and_die   212934 0000000000007312 0000000002128792
java$jvm_shr  os_vms_ia64  condition_handler
                                        198396 0000000000000E02 0000000000FA7882
                                             0 FFFFFFFF804A6AE2 FFFFFFFF804A6AE2
----- Above condition handler called with exception 0000000C
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000008, PC=00000000069DD320, PS=0000001B
----- End of Exception message
                                             0 FFFFFFFF80498E92 FFFFFFFF80498E92
libocijdbc11 eooconn  Java_oracle_jdbc_driver_T2CConnection_t2cSetSessionTimeZone
                                        614935 000000000000D320 00000000069DD320
                                             0 000007FDAFDB8C12 000007FDAFDB8C12
                                             0 000007FDAFDCB282 000007FDAFDCB282
                                             0 000007FDAFDBEB00 000007FDAFDBEB00
                                             0 000007FDAFDBEB00 000007FDAFDBEB00
                                             0 000007FDAFDBEB00 000007FDAFDBEB00
                                             0 000007FDAFDBEB00 000007FDAFDBEB00
                                             0 000007FDAFDBEB00 000007FDAFDBEB00
                                             0 000007FDAFDBEA40 000007FDAFDBEA40
                                             0 000007FDAFDBEA40 000007FDAFDBEA40
                                             0 000007FDAFDBEA40 000007FDAFDBEA40
                                             0 000007FDAFDBEA40 000007FDAFDBEA40
                                             0 000007FDAFDBEA40 000007FDAFDBEA40
                                             0 000007FDAFDB8472 000007FDAFDB8472
java$jvm_shr  javaCalls  call_helper    212066 0000000000002782 00000000016067C2
java$jvm_shr  os_vms  os_exception_wrapper
                                        227376 0000000000015612 0000000000E79552
java$jvm_shr  javaCalls  call           211976 0000000000008ED2 000000000160CF12
java$jvm_shr  jni  jni_invoke_static    218218 0000000000010122 0000000000C60E22
java$jvm_shr  jni  jni_CallStaticVoidMethod
                                        219419 000000000005A1C2 0000000000CAAEC2
java$jli_shr  java  JavaMain             27488 0000000000006092 000000000023ED92
java$jli_shr  java_md_solinux  ContinueInNewThread0
                                         28260 0000000000001662 0000000000244A92
java$jli_shr  java  ContinueInNewThread
                                         29273 000000000000A5B2 00000000002432B2
java$jli_shr  java_md_solinux  JVMInit
                                         28320 0000000000001802 0000000000244C32
java$jli_shr  java  JLI_Launch           27282 0000000000002D42 000000000023BA42
java  main  main                         27156 00000000000004E2 00000000000204E2
java  main  __main                       27120 00000000000002E2 00000000000202E2
PTHREAD$RTL  THD_THREAD  thdBase        245262 0000000000005BF2 FFFFFFFF844D4E72
PTHREAD$RTL  THD_INIT  pthread_main     245041 00000000000006B2 FFFFFFFF8448A6B2
                                             0 FFFFFFFF80B336D2 FFFFFFFF80B336D2
DCL                                          0 000000000007D072 000000007AE39072
%TRACE-I-END, end of TRACE stack dump

Thank you for your help,

Best regards.

Cedric Pion

AZISOFT SA

[H.Becker]

This looks like a problem in the shareable image libocijdbc11, supplied by Oracle. There doesn't seem to be a generic problem with Java 8 and JDBC.: they work (for me) with rdb and sqlite. You probably want to get in contact with the Oracle support people.

[Cedric_P]

Hi, thank you for your answer.

I have posted a service request with Oracle. They are investigating-

I think it is more on the Java 8 JDBC side : the same program works fine with Java 6 on the Oracle 10 client or on the Oracle 11g installation. However, with Java 8, it does not work with any of those Oracle kits.

Regards,

Cedric

[H.Becker]

# Problematic frame:
# C  [libocijdbc11+0xb0]

and

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000008, PC=00000000069DD320, PS=0000001B ...

seem to indicate a problem in the libocijdbc11 image, which I assume is a JNI, which in VMS terms is a shareable image. Java 8 on VMS requires JNIs to use 64-bit pointers, Java 6 required 32-bit pointers. From the stack dump it's not obvious to me, whether that is the underlying problem or not. From what I see, the ojdbc6.jar contains byte code generated by a Java 6 compiler. The Java 8 JVM can run such byte code: the JDBC jar should work.

Regarding 32-/64-bits, you need to have two versions of the JNI, one for Java 6 and one for Java 8. And someone has to ensure, that Java uses the corresponding JNI. This may be as simple as defining a logical name pointing to the correct image.

[Cedric_P]

Yes indeed, Oracle tech guys confirmed that 32b/64bits issue:

"There is a major difference between JAVA 8 and earlier versions of JAVA. In previous versions, when calling native routines, all pointers passed in were 32-bit, even though JAVA itself was a 64-bit image.
With JAVA 8, all pointers appear to be 64-bit.
Since we point LIBCLNTSH and OCIJDBC11 at 32-bit images, the pointers are bogus in 32-bit land, and we ACCVIO. "

I am looking forward to receiving a solution from them: something like a 64b compiled set of libraries.

Thanks for your help.

Cedric