Abstract
The port of the Java Developers Kit (JDK) to the OS/390 platform faced the problem of porting to a platform that has different character and numerical types from other platform's implementations of Java. However, the result is cutting edge technology, exploiting the strengths of IBM's "Big Iron" systems. This article relates these porting experiences to give an insight into the advantages and unique characteristics that are encountered when running or writing Java applications on the OS/390 platform.
Background to the port
Back in the spring of 1996, down in the basement of IBM's Hursley house, an 18th century country mansion set amongst the rolling hills of Hampshire, England, we started out to port Java, the hottest new technology, to the OS/390 platform.
We were able to port Sun's UNIX-based Java implementation with relatively few problems to OS/390's UNIX services (also called OpenEdition services). OpenEdition is the certified UNIX "layer" on OS/390, having achieved X/Open's XPG4 UNIX Profile Brand, thereby allowing easier porting of UNIX applications to OS/390.
Porting Challenges
The Java Virtual Machine (JVM) program is an "abstract computer" that runs compiled Java applications or applets. It is implemented in software on top of the operating system. It takes the requests of a Java application or applet and passes them on to the operating system in a form that the operating system can understand. The JVM program itself consists of code written in both C and Java.
ASCII v. EBCDIC
Challenge
An area of consideration with porting any C code from another platform to OS/390 is the difference in the encoding of character data. Many platforms support character strings in ASCII; in fact most TCP/IP based services, including the Internet, and most other platforms that Java has been ported to are ASCII-based. ASCII is so pervasive it is almost considered to be platform independent.
The OS/390 platform though uses a different format called EBCDIC, and this presented one of the biggest challenges with porting the C portion of the JVM program to the OS/390 platform.
Solution
We decided to switch our encoding of character strings in the C portion of the JVM program from EBCDIC to ASCII. This approach involved drawing a virtual boundary around the JVM program, whereby all characters within the program were in ASCII and were only converted between ASCII and EBCDIC when they needed to be, such as when printing to the screen. This enabled the JVM program to operate as though it were running on an ASCII-based platform and circumvented any assumptions there might be within the code that characters were in any particular format.
Implications
Since the JVM program handles the differences between ASCII and EBCDIC, so Java programmers, unlike C programmers, need not be aware of these concerns. Java developers only need to consider this if they are integrating native code written in another programming language such as C, with their Java applications. This technique is called native method programming.
The Java Native Interface (JNI) Specification defines a set of APIs to be used by native method programs as an interface into the JVM program. It specifies the types that should be used on each call. These types refer to types used within the JVM program and, since it is interfacing directly into the JVM program and characters within the program are in ASCII, any characters being passed in must first be converted to ASCII. Routines have been provided with Java for OS/390 that JNI programmers can use for this conversion. Documentation and an example is also provided.
Handling EBCDIC Data
Challenge
Character strings in Java code are not in either ASCII or EBCDIC, but a platform-independent character encoding called unicode. Java as a programming language is unique in having chosen this encoding. Since most platforms don't support unicode, data passed into and out of a Java application must be translated between the local machine encoding and unicode.
Using Java 1.0, Streams were available to read in or write out data, but they only handled binary data that required no translation. They could be used to read in ASCII characters though, because ASCII and unicode are for the most part very similar and therefore translation was often not necessary. They did not however provide the means to read in EBCDIC data.
Solution
New with the introduction of Java 1.1 is the Internationalization feature, which provides National Language Support (NLS). This is good news as far as OS/390 is concerned, since this feature provides the mechanisms to translate between a whole range of different encodings and unicode, thus allowing Java applications to access EBCDIC data. This data could be in existing OS/390 subsystems, such as DB2.
Implications for Java programming
There are nonetheless a couple of points that a Java developer should consider to get the most out of this new feature. First, the application must be coded using the Java 1.1 APIs that support NLS, rather than using the Java 1.0 APIs. Second, the correct APIs for the type of data being handled must be chosen.
To illustrate this point, consider reading from or writing to files. The general rule is to use Streams for binary data that require no translation, and to use Readers and Writers for character data that do require translation. Therefore, to read character data from a file on the local filesystem, use a Reader, which will automatically perform translation according to the platform's encoding. It does not matter whether a file resides on an ASCII platform with text data in ASCII, or on an EBCDIC system with data in EBCDIC; the same Java application can run and read a file on both platforms, without being changed.
At Java 1.0, the lack of Readers and Writers to perform translation from the local encoding to unicode caused difficulties for OS/390. With Java 1.1, these facilities are provided, so care should be taken to ensure that Streams are no longer used for handling character data. By taking advantage of the new Readers and Writers, applications become genuinely NLS-enabled and platform-independent.
Implications for Network programming
These same rules for handling data apply when connecting OS/390 to another system; choose the API to use based on the type of data being handled, but also consider the origin or destination of the data.
In general, text data that is on the local filesystem is considered to be in the platform's local encoding, but data from the Internet will be generally be in ASCII. For example, a URL file read from the local filesystem will be in EBCDIC, but one from the Internet will be in ASCII. When reading data from the Internet therefore explicitly specify the encoding of the data that is being received, rather than allowing the platform's local encoding to be selected.
Text data may also be downloaded in Java archive (JAR) files. Often, all or many of the files a Java application needs can be combined into a JAR file, so that it can be downloaded in a single request. Since it is expected that JAR files will be downloaded from other platforms or the Internet, they are most likely to contain text files in ASCII. Therefore, in keeping with this philosophy, text files within the JAR file should be stored in ASCII. This way JAR files remain platform-independent, in that you can download one to OS/390 from a different platform and it will work, as well as making it easier to release code developed on OS/390 to be used elsewhere.
Emulated types
Challenge
Another platform characteristic that we had to deal with was the different way that the OS/390 platform represents various types namely floating point numbers and doubles. The JVM program requires that floats and doubles conform to the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985), which defines the format of 32-bit and 64-bit floating point numbers and the operations upon those numbers. Native OS/390 floats and doubles are different from this standard.
Solution
The solution was to provide emulation for these numerical types in the OS/390 version of the JVM program. This meant writing code to create and manipulate our own versions of these numerical types that conform to the IEEE standard. As with our ASCII emulation, the JVM program operates internally with these emulated types, only converting between one type and another when needed.
Implications for Java Programming
As with our ASCII emulation, Java developers only need be aware of this if they are coding native methods. As mentioned, Java types must be used on JNI calls. The type "jfloat" refers to a Java float, which is not the same as a native float. The JNI programmer only needs to be aware that these types are different and convert between the two types as appropriate. As an example, it is necessary to convert a jfloat received from the JVM program into a native float before passing it on to a system call, eg. printf. Again, routines, documentation and examples have been provided with Java for OS/390 so that JNI programmers can convert these types.
Implications for Performance
For a user running a Java application, this emulation of floating point numbers and doubles is transparent. However, there is the consideration of performance. It is undoubtedly slower to perform manipulation of floating point numbers in software rather than hardware. With the new Generation 5 (G5) hardware, in conjunction with OS/390 Version 2 Release 6, support for these numerical types has been provided, removing the need for our emulation. This is just one of many performance improvements that have been made, and there will be more to follow, as performance continues to receive high focus both from the Java product and the operating system.
Exploiting the Strengths of the Mainframe
OS/390 has many strengths which have long been recognised - security, reliability, availability and scalability. Java for OS/390 automatically gains the benefits of these strengths. For instance, costs per user can be minimised by one installation of Java for OS/390 allowing a high volume of concurrent users.
Threading
An item worth particular mention is that Java for OS/390 uses the thread support mechanisms of the underlying operating system (in MVS terminology, a thread is a TCB) and as a consequence, Java applications are truly multithreaded. In a multiprocessor environment, threads can genuinely execute in parallel, giving increased throughput and better performance. Work can be shifted from processor to processor to achieve workload balancing and scalability.
Garbage collection
Garbage collection is an area which we have re-designed on OS/390 to improve scalability of Java for OS/390. Garbage collection is a key feature of the JVM program that takes care of freeing memory which is no longer referenced, thereby relieving the Java programmer of this burden. The current model freezes all running threads and then invokes the garbage collector on a separate thread. Only when the garbage collector has finished freeing memory are the threads allowed to continue.
This model is not ideal for a multiprocessor environment such as OS/390. There is an overhead to stopping all threads, and they may be frozen for a lengthy period of time waiting for the garbage collector to complete. Consequently we have designed a new garbage collection model specifically for this environment, which allows the garbage collector to run in parallel with other threads execution. This has not only improved the scalability of Java for OS/390, but has improved the performance of Java applications by allowing threads to continue running even during garbage collection.
Summary
This article has documented some of the characteristics of Java for OS/390. By passing on our knowledge of the internal processing of the JVM program, we hope to give an understanding of why things work the way they do. This will be of particular value to JNI programmers. Java developers on all platforms will also benefit from understanding how to make their Java applications truly platform-independent.
In the 2 years of it's existence, Java for OS/390 has matured and we hope that by passing on the valuable lessons we have learnt, we will give guidance to those looking to unite the benefits of Java to those of the OS/390 platform.
Java TM is a trademark of Sun Microsystems, Inc.
Sally Howard
Revised November 98
| 
