Is Java on (z)Linux different from Java on z/OS?
There was a question on StackOverflow about Java on different platforms, and how to identify the platform. The question especially asked for Java on z/OS and Java on Linux on IBM Z Systems (zLinux). (How to distinguish Java on z/OS from Java on Linux on z/OS?)
The following is a very brief desciption of Linux, Linux on Z Systems, and z/OS, that was written to help understand the differences between the operating systems and runtime platforms. It is simpified in many aspects to keep it reasonably short.
Linux, and Linux on Z Systems
Linux is a UNIX-like operating systen that was first developed for Intel based systems (I think). Later, it became available for other hardware platforms, IBM Z Systems hardware being one of them. The Linux which runs on IBM mainframe hardware, or IBM Z Systems, is called Linux for System Z, or Linux on IBM Z; I'll call it zLinux hereafter for brevity.
Linux is Linux, no matter what platform it runs on. This is mostly true for: How you install it, how you configure it, how you run it, what API is provides, etc. Differences might exist when it comes to hardware configuration, or booting. This is especially true for zLinux.
Since the APIs are the same across, it offers source code portability, on an application level. And I consider the Java JVM an application in this context. Simplified this means, you take the source code, run it through the compiler that produces binaries for the target platform, and you're done.
What you optionally can do, is code optimization for the target platform, possibly to spead up things. In that sense the Java JVM for zLinux might work differently under the covers than the Java JVM for, say, an Intel PC platform (I actually don't know, if this is the case or not). But this would not matter to Java applications.
Running Programs on UNIX (e.g. Linux)
A program running on a UNIX system runs as process. Simplified, the term process includes control structures, and the virtual address space (memory, process image). To run another program, some program already running needs to fork(), then exec(). This will create a new process for that program.
The UNIX kernel does process management (programs runs as process), dispatching/undispatching onto/from a processor, memory management, file system management, priority management, user and group management using numeric uid, and numeric gid, etc., etc.
z/OS
z/OS is one of IBM's mainframe operating systems, which run on IBM Z Systems hardware. Though running on Z Systems, like zLinux does, z/OS has not much in common with a Linux, or UNIX system. Installation, configuration, and running z/OS couldn't be more different.
z/OS MVS (without z/OS UNIX System Services)
MVS, born in 1964, is a component, or part, of any z/OS system. Its kind of like what the kernel is to a UNIX system. MVS provides the APIs that programs running on z/OS call. I call such a program an MVS program here. These APIs, again, are completely different to UNIX APIs. So, even though the hardware is the same, binaries are not exchangable. You cannot easily port a UNIX program into a z/OS MVS program; you have to rewrite from scratch.
MVS does task management (programs run as tasks), dispatching/undispatching onto/from a processor, memory management, data set management (MVS does not understand "UNIX file system"), priority management, user and group management using alphanumeric userid, and alphanumeric groupname, etc. etc.
z/OS UNIX System Services
In the early 1990s, IBM wanted to make it easier to port popular UNIX programs to z/OS, so the added UNIX APIs, and called this part (finally) z/OS UNIX System Services, short z/OS UNIX hereafter. This came out in 1994. z/OS UNIX is another component of z/OS (also called OMVS). It is not a full UNIX kernel, but only adds to MVS what is required by UNIX, what MVS does not aleady have, foremost, process management, numeric uid, and gid, and a UNIX-like file system.
IBM added everything required to become an xOpen and Posix compliant operating system. Now, you don't have to rewrite the UNIX program to run it on z/OS, you can more or less easily port it. There still are differences to cope with, foremost the dreadfull EBCDIC - ASCII difference. But API calls are 1:1, provided the program only uses compliant APIs.
Running Programs on z/OS
There are three kinds of programs:
- Programs that know nothing about UNIX, only use the MVS APIs, and deal with MVS data sets for I/O. Let's call them MVS programs.
- Programs that were ported from UNIX, or written by someone who only knows UNIX, which know nothing about MVS, only use the UNIX APIs, and deal with UNIX directoies and files for I/O. Let's call them pure z/OS UNIX programs. (Well, this category does nor really exist, see *) below).
- Programs that know both MVS, and z/OS UNIX, which call MVS, and z/OS UNIX APIs, and deal with MVS data sets, as well as with UNIX directories, and files. Let's call them mixed mode pograms.
*) Every program needs memory, and every program wants to become dispateched on the processor eventually. Memory management, and task management is provided by MVS, not the UNIX kernel, so unknowingly, the program calls MVS APIs under the covers. Conclusion: There is no such thing as a "pure z/OS UNIX program". That leaves us with categories 1 and 3, only.
All of those programs are stored as program objects, and reside either as member in a load library (data set), or as file in the UNIX file system. When run, the executable is loaded from either source in to an MVS address space, and is started as a task. All programs are managed as MVS tasks, have got all the MVS attributes, plus in case 3 above, also have UNIX attrributes (process id, uid, gid, etc).
A program of type 1, becomes type 3 at runtime as soon as it makes a call to a UNIX API. So, there is no such thing as a wall, or boundary, or subsystem. It's all MVS programs, that may also be UNIX programs at the same time.
Java on z/OS
The Java JVM that runs on z/OS is no exception. It has been ported to z/OS, and since this was easier, as z/OS UNIX program (well "mixed mode program", as you should know by now). It has been optimized for the hardware and the specifics of z/OS in many aspects. But to Java applications it is not different. Java applications are not binaries, so the same Java byte-code runs on any Java JVM (with exceptions).