• 1 reply
  • Latest Post - ‏2011-03-08T17:26:19Z by SystemAdmin
1 Post

Pinned topic Incredibly frustrating trying to solve IBM Linux on System Z s390 issues...

‏2011-02-24T03:37:15Z |
I am at a loss as to where to go to get smarter about IBM System Z Linux s390.

Is this the right place?

I am a Java programmer. I write code that works beautifully on Intel HW running RHEL 5. When I move the same code to IBM System Z Linux s390 it doesn't work. There is an enormous community of people using the Sun/Oracle JVM so it's dirt simple to get help. Google searches yield useful results.

I can't find any decent size community of people that use J9. Where do I go? Is this the right place? Who else is using these computers? Are there just a handful of them in the World?

My current problem has to do with making SSL connections from within a Java app to another server. Some security update that the admins installed broke the functionality.

My code works on Intel RHEL 5 systems using the Sun/Oracle JVM when I supply this option:

What's the equivalent option I need for the J9 JVM?


$ java -version
unjava version "1.6.0"
Java(TM) SE Runtime Environment (build pxz6460sr9-20101125_01(SR9))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux s390x-64
jvmxz6460sr9-20101124_69295 (JIT enabled, AOT enabled)
J9VM - 20101124_069295
JIT - r9_20101028_17488ifx2
GC - 20101027_AA)
JCL - 20101119_01

$ uname -a
Linux localhost 2.6.18-238.1.1.e15 #1 SMP Tue Jan 4 13:35:45 EST 2011 s390x s390x s390x GNu/Linux

$ cat /proc/cpuinfo
vendor_id : IBM/S390
  1. processors : 2
bogomips per cpu: 3722.44
features : esan3 zarch stfle msa ldisp eimm dfp
processor 0: version = FF, identification = 0CEE95, machine = 2097
processor 1: version = FF, identification = 0CEE95, machine = 2097
Updated on 2011-03-08T17:26:19Z at 2011-03-08T17:26:19Z by SystemAdmin
  • SystemAdmin
    101 Posts

    Re: Incredibly frustrating trying to solve IBM Linux on System Z s390 issues...

    I think the security update your admins have installed is possibly the TLS renegotiation MITM attack documented here by RedHat:
    "To address this issue, the IETF TLS working group has defined a TLS protocol extension that allows safe session renegotiation. This protocol extension is described in RFC 5746, "Transport Layer Security (TLS) Renegotiation Indication Extension"
    The RFC 5746 implementation in the IBM Java Runtime Environment
    Support for RFC 5746 in the IBM Java Runtime Environment (JRE) was introduced upstream in versions 5.0 SR12-FP2, and 1.4.2 SR13-FP6.

    The renegotiation behavior in the patched IBM JRE packages:

    a patched client can connect to and renegotiate with a patched server.
    a patched client can connect to, but cannot renegotiate with an unpatched server.
    a patched server allows patched clients to connect and renegotiate.
    a patched server allows unpatched clients to connect, but not renegotiate.

    The following properties can be used to change the default renegotiation behavior: can be used to enable or disable renegotiation. Multiple values are recognized, including:
    NONE (default value) - only secure renegotiation with peers that implement RFC 5746 is allowed.
    ALL - both secure and insecure renegotiation is allowed. controls whether RFC 5746 support is required during the initial TLS/SSL handshake. Valid values:
    OPTIONAL (default value) - RFC 5746 support is not required during the initial handshake.
    CLIENT, SERVER, BOTH - RFC 5746 support is required for client sockets, server sockets, or both client and server sockets respectively.

    For additional details, refer to: "