|
The Basics
At first, I found it very confusing to get started with Java on OS/390. As an old mainframer, there were tons of new concepts to learn that have crept into OS/390 over the last several years. They include:
I'll briefly explain each of these things from my point of view. I hope this isn't too elementary for you. Please let me know if I should put in more detail here or expand on the information in another area of the site.
This page explains the mainframe side of things. I also use several development tools that I like.
OS/390 Unix System Services (USS)
Current versions of OS/390 provide something called the OS/390 UNIX Kernel as part of the OS/390 system itself. This allows programs that were designed to run on UNIX to also run under OS/390 on the mainframe. When programs call UNIX APIs, those APIs are now also supported under OS/390 USS.
In addition, USS provides a shell environment. This will be familiar to UNIX users and programmers. It's sort of like TSO on the mainframe. It listens for you to type things and then it goes and executes commands or programs. It also allows you to write shell scripts which are sort of like TSO CLISTs and REXX EXECs.
To enter the USS shell environment, you have several options. From TSO or ISPF option 6, you can type OMVS and you will be taken into the shell environment. Or, you could type ISHELL which will take you into a kind of menu interface which lets you perform lots of shell functions. Another interface is available via the UNIX rlogin and telnet facilities. Do not confuse telnet with tn3270. The latter allows you to telnet in using a 3270 protocol. The vt100-like regular telnet interface is a separate service and needs to be set up by your systems programmer on a separate port. That will allow you to telnet in to the shell UNIX style.
To make matters a little more confusing, USS used to be called OpenEdition MVS. Some of the old manuals and parts of the new manuals still refer to this old name.
USS supports an entirely new file system for OS/390 called the Hierarchical File System (HFS). This is a separate file system which coexists with the traditional file system, now called the MVS File System and which contains MVS Data Sets. The HFS is just like your PC file system with a hierarchical series of directories and files. There are also symbolic links which contain a "link" to another file. In USS, the path separator is a forward slash (/) -- the key below the question mark -- rather than the backslash (\) used on the PC. Usually, you will have a "home directory" assigned to you by your administrator. This is traditionally /u/username.
There is JCL support provided for accessing HFS files, including the keywords PATH, PATHDISP, PATHMODE, and PATHOPTS. You can find out more about these keywords by checking out the JCL manuals on our manuals page.
Java for OS/390
This is the OS/390 version of Sun's Java Development Kit (JDK). As of today (31-October-2002), the currently supported releases are
 The IBM Developer Kit for OS/390, Java™ 2 Technology Edition for OS/390 product (SDK1.3.1), and
 The IBM SDK for z/OS, Java 2 Technology Edition, Version 1.4
IBM's OS/390 and z/OS Java site has all of the details about the JDK, how to get the code, how to get maintenance, FAQs, links, and all kinds of other good stuff. Java for OS/390 and z/OS is free.
The 1.3.1 release will requires at least OS/390 v2r8 or z/OS. It will be serviced through December of 2003. The 1.4 release will run only on z/OS v1r4 or z/OS.e v1r4 or higher. It will not run on OS/390 or on z/OS or z/OS.e releases below 1.4. It will be serviced through December of 2004. You can tell which version of Java you have installed by typing "java -fullversion" or "java -version".
The Java SDK includes a compiler (called javac) which takes a java source file as input and creates a java bytecode file as output. If you compile into the HFS, the suffix of the bytecode file is ".class". This bytecode file produced by the compiler does not contain executable 390/zSeries instructions. It requires the Java Virtual Machine (JVM) at runtime. You invoke a bytecode class for runtime execution by typing
java classname
To improve performance, most Java runtimes also include a just-in-time or JIT compiler and Java for OS/390 and z/OS is no exception. Java for OS/390 and z/OS works pretty much like java for any other platform. Performance and reliability have steadily improved with each PTF and release.
The JVMs are called "Persistent Reusable VMs" and have a more sophisticated architecure than JVMs built for other platforms. For most applications, this really doesn't matter since the JVM is started once at the beginning of a process and torn down at the end. This model was not acceptable for CICS and DB2 which needed to create a JVM for every java transaction or stored procedure and then tear it down at the end. So, IBM created a reusable JVM architecture that can usually be reused after a transaction is finished. If it is corrupted to the point where it can't be reused, a new JVM can be initialized quickly. You can read all about the PRJVM here and here.
Visual Age for Java, Enterprise Edition for OS/390 (now deprecated)
This was a product, separate from Java for OS/390, which installs on the mainframe and provides the following features:
 A high-performance compiler to convert Java bytecode into optimized and native OS/390 executables,
 A remote debugger that lets you debug Java native (object) executables on the OS/390 from the convenience of your workstation,
 A performance analyzer to help you understand and tune your host-compiled Java applications for improved performance,
 The jport Utility to help you verify the portability of your Java code to the OS/390 UNIX® or the CICS® server environments,
 A runtime library that implements the Java APIs as fully compiled native objects and provides for memory management ("garbage collection") and other system routines.
This was a mainframe product. Its product number is 5655-JAV. Do not confuse this product with Visual Age for Java, Enterprise Edition for Windows which was product number 31L1885 for version 2.0 and 41L1323 for version 3.0 and 00P7778 for version 3.5. The names are similar so this creates a lot of confusion. In addition, the mainframe product included a copy of the Windows product so that was one less copy for you to have to license on the desktop.
You ordered VAJ EE for OS/390 through your regular mainframe software ordering sources. It came on a tape. There was a charge for this product. You can read an overview and description about the product from IBM here.
To make things more confusing, this product had, at various times, also been called HPJ, High Performance Java, and High Performance Compiler for Java, and various other names.
In order to take full advantage of the features of VAJ EE for OS/390, you also needed to use VAJ EE for Windows as your desktop IDE. You needed to add an option to the Windows product called ET/390 which is the Enterprise Toolkit/390. This option provides for powerful integration between between the desktop and mainframe products. For example, you can write java code on the desktop, compile it on the desktop, and run it on the mainframe. The output from the mainframe was captured and rerouted back to your desktop. This was pretty cool.
I don't even know if this product is sold anymore. The introduction of the PRJVM and the vast improvements in the JIT compiler have obsoleted need for natively compiled java code. Also, this product was based on JDK 1.1.5 (or thereabouts) and hasn't been updated since, to my knowledge. I don't know anyone that uses this anymore.
PDSEs, PDSes, Program Objects, and The Binder
In the old days, we had the Linkage Editor which took object modules and other load modules as input and produced an executable program in the form of a load module residing in a Partitioned Data Set (PDS). In order to support the long names and more robust constructs of C, C++, and Java, we now have a new type of executable program called a program object. A program object is created by the Program Management Binder, usually just called the Binder. The Binder is compatible with, and looks almost like the Linkage Editor, except that it provides additional functionality and removes some restrictions of the Linkage Editor.
Program objects reside in a new type of dataset called a Partitioned Data Set Extended (PDSE) or in USS files instead of in PDSes. A PDSE is like an extended version of a PDS and allows for long alias names and automatic reusing of deleted space with the need for a reorg. Program objects cannot reside in a PDS. However, the binder can create both load modules and program objects depending on whether its writing to a PDS or a PDSE or USS file.
Before the Binder was in full swing, certain object modules produced by the C and C++ compilers had to be fed through a program called the Prelinker and then the output of that was, in turn, passed through the Linkage Editor. The Prelinker did things like cross-referencing long names to made up shorter names that the Linkage Editor could handle. I've never seriously used the Prelinker because the Binder handles everything that the Prelinker and the Linkage Editor did plus more and does it better. The Prelinker and Linkage Editor are going away so I wouldn't use them for native Java programs or for C or C++ programs which will interface with Java.
|