Is Java on z/OS and Java on Linux on IBM Z systems distinguishable from each other by os.name and/or os.arch properties? What about UNIX services for z/OS, does it have distinctive Java distribution?
Update 1
My understanding is that z/OS uses dot or colon (?) as path component separator while Unix-like subsystem uses solidus. My expectation is that there is Java for z/OS which uses whatever native C library and executable file format z/OS has, using the dot/colon as separator, while z/OS UNIX subsystem and Linux on IBM Z use POSIX compatible C library and use ELF as executable format. I would expect there to be two different JREs, one for the z/OS Linux and another for the z/OS UNIX service subsystem. My expectation is that the EI_OSABI field in ELF file format header is distinct for Linux and for z/OS UNIX subsystem, thus there should be two different Java distributions.
Is there z/OS Java which runs outside any of the Unix-like subsystems?
Trying to give an overview of how Linux, especially Linux on Z Systems and z/OS are different (or not). I'll need to simplify a lot to be able to keep it reasonably short.
Update 1: Changed some wording to be more clear, and corrected typos.
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.
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 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.
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.
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.
There are three kinds of programs:
*) 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.
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).