Template talk:Unix

Is calling z/OS UNIX System Services a "compatibility layer" accurate?

z/OS is a certified UNIX 95. It is the OS as a whole which is certified as UNIX 95, not just a component of it – the UNIX certification program is for whole operating systems not subsystems of them. Given the whole OS is a certified UNIX, shouldn't it belong in the UNIX section not the compatibility layer section? z/OS has two main APIs – the UNIX API, and the legacy MVS API; the UNIX certification program certifies the UNIX API, it does not care about whether or not the OS also exposes a non-UNIX API. (Quite similarly, the certified UNIX macOS exposes various non-UNIX APIs, such as the Mach API and the OpenStep-derived Objective C APIs, and the UNIX certification program doesn't care about the existence of those other non-UNIX APIs either.) And z/OS UNIX is more than just a compatibility layer, an increasing number of z/OS components and applications run on top of z/OS UNIX – among others, anything written in Java. Mr248 (talk) 08:39, 26 December 2020 (UTC)

I wouldn't call the MVS API a "legacy" API.

There's already an OS that runs on IBM Z mainframes that is probably very close to UNIX 03 compatibility (a similar OS is UNIX 03-certified on x86-64), and to which porting applications from other UN*Xes is probably easier, given that, for example, said OS uses ASCII-based character encodings. I suspect most if not all users of z/OS's UNIX components also have applications that run on the MVS API. They may even continue to develop existing applications using that API, and may perhaps develop new applications using it.

macOS isn't an OS with a "native API" that's an alternative to its UNIX API - file system I/O and networking, for example, ultimately turn into UNIX system calls, not into Mach messages, and the OpenStep-derived APIs use UNIX calls for those purposes. It's best thought of as a UNIX that supports Mach messages as an IPC mechanism. Guy Harris (talk) 10:16, 26 December 2020 (UTC)

@Guy Harris: z/OS Unix is not a mere "compatibility layer" because a lot of z/OS functions depend on it. To give some random examples, Zowe and AT-TLS policy agent. Neither of those are things ported from elsewhere, they are both z/OS exclusive features which need z/OS Unix Systems Services (BPX) to run. Even classic stuff like CICS now uses z/OS Unix (because they added to CICS the ability to run Java code, and the IBM J9 JVM runs under z/OS Unix.) Mr248 (talk) 10:58, 29 December 2020 (UTC)

Even if stuff in the "OS/360 with each job step getting its own demand-paged address space" environment uses stuff from the "compatible with older UNIXes as long as you can handle EBCDIC" environment, it's still an OS with two environments, with software being developed for both environments, unlike macOS, which has only one environment, the "OpENStEP-TNG on top of UNIX" environment.

Also, how much of the stuff in the latter environment is built atop stuff in the former environment? Guy Harris (talk) 20:36, 29 December 2020 (UTC)

"it's still an OS with two environments" => I'd argue that's not really true. It's not something like Windows Subsystem for Linux. In WSL1, a process is either an NT process (which can call the NT API) or a WSL1 picoprocess (which can call the Linux syscall API). A single process can't do both. (WSL2 is even more distinct – it isn't just two different types of processes running under the same kernel, it is two different kernels.) By contrast, there is no strict division between "classic" and "Unix" processes on z/OS. Any MVS address space can become a Unix process by making a Unix system call (this process of becoming a Unix process is called "dubbing"), at any point in time. An MVS address space can sit there ignoring the Unix API for weeks on end, and then suddenly out of the blue call a Unix API and at that point it becomes a Unix process. Developers can freely mix classic MVS API calls and Unix API calls in the same process (indeed, a lot of z/OS software is a mixture of both). Or similarly, a Win32 app can't gain direct access to the WSL Linux filesystem; by contrast, any MVS application can access the Unix filesystem – z/OS can present any Unix file as a BSAM,QSAM,BPAM or VSAM ESDS dataset – if the application accesses the file via a JCL DD statement, you just code "DD PATH='/path/to/unix/file'" in JCL and it can access it. (If it allocates datasets dynamically instead of via JCL DD, SVC 99 DALPATH gives access to Unix files via the classic MVS API.) In Windows, cmd.exe can't access WSL files, by contrast TSO/E can access Unix files just as well as it can access classic MVS datasets.

"how much of the stuff in the latter environment is built atop stuff in the former environment" => some bits are shared, some bits are independent. But do these kinds of implementation details matter? Standardised Unix is an interface, if you are certified as implementing the standard interface correctly then you are Unix, why should what you are doing under the hood matter? Mr248 (talk) 21:39, 29 December 2020 (UTC)

From what I've been able to find, MPE/iX allowed mixing of MPE intrinsics and POSIX calls, and it looked as if "POSIX for OpenVMS" was moving in that direction. Both of them appear to put native and POSIX files in the same name space, with some name space tweaks. I don't know what happened for access to native "structured" files from POSIX - did the raw bytes of the file get exposed, so that the POSIX code would have to look at record lengths etc., or did structured text files get translated to line-oriented text files, or could both be done? I also don't know how POSIX files were shown to the native APIs - again, text files could probably be mapped, but some form of structure might have to be imposed on binary files. VMS's RMS, at least, eventually added a byte-stream text file format, in addition to the older formats.

But I would draw a distinction between all three of those "non-UNIX OS that had UNIX added to it" cases and OSes that started out as UNIX from Day One. The latter don't offer an alternative API with its own advantages and disadvantages, and its own base of software, and the former probably all have places where the POSIX abstraction leaks a bit (e.g., EBCDIC in MVS and z/OS, and the top two layers of the directory hierarchy in MPE/iX).

So perhaps "compatibility layer" wouldn't apply to those cases, but I'd still put them in a separate category from the "UNIX from Day One" systems. Guy Harris (talk) 03:11, 30 December 2020 (UTC)

the former probably all have places where the POSIX abstraction leaks a bit (e.g., EBCDIC in MVS and z/OS – POSIX doesn't formally speaking mandate ASCII, so using EBCDIC isn't strictly speaking a case of "the POSIX abstraction leaks". Now, it is true that the vast majority of POSIX implementations do use ASCII, and a non-ASCII POSIX is unusual, but this is a case of people assuming that if >90% of the implementations of a standard do X, then X must be part of the standard, even though that isn't actually true. (Now, you could argue that POSIX should mandate ASCII, or even UTF-8, and maybe someday the Austin Group might even agree to that, but I don't think we are there yet.)

But I would draw a distinction between all three of those "non-UNIX OS that had UNIX added to it" cases and OSes that started out as UNIX from Day One Why does it matter? Why do we need to make that distinction? What exactly is "UNIX"? The official answer per the current owners of the UNIX trademark, is it is a standardised API, and any system which is certified as implementing that API correctly (and which pays the certification fees) is UNIX, and how the API is implemented, or whatever other APIs may be implemented as well, or the history of the implementation, are all irrelevant. By that definition, z/OS is definitely a UNIX, whereas most Linux distributions are not. Now, we could extend the definition to include systems which implement that API sufficiently well but aren't formally certified as doing so; that would bring Linux in general under the definition, although for trademark reasons maybe that is better described as "Unix-like" than "UNIX". A third, historical definition, is a historic code base deriving from Bell Labs, which would exclude systems which don't historically derive from that code base (such as z/OS or Linux). You seem to be proposing a fourth definition, but I'm not sure why we should use that fourth definition instead of one of these three? Mr248 (talk) 22:56, 30 December 2020 (UTC)

"Now, it is true that the vast majority of POSIX implementations do use ASCII" ...where "vast majority" means "everybody but z/OS", at this point, as far as I know. IBM certainly makes note of this issue in the "ASCII-EBCDIC Issues" section of their z/OS UNIX System Services Porting Guide.

"this is a case of people assuming that if >90% of the implementations of a standard do X, then X must be part of the standard, even though that isn't actually true." Or of deciding that it's simply not worth caring about the one and only exception to the standard, either if they don't need to care about running on IBM Z or if they can just run on Linux.

(BTW, 100% of the POSIX implementations conforming to UNIX 03 or later use ASCII. IBM has several of them, including the only two that conform to the version after UNIX 03.)

"The official answer per the current owners of the UNIX trademark" ...is not the only answer of interest.

Are there any cases where somebody who was choosing a UN*X system, and who had no need for any of the capabilities of z/OS or OpenVMS or HP's MPE, and who didn't have an existing IBM Z/VAX/Alpha/Itanium/HP 3000 system on which they wanted to run a UN*X system, chose z/OS or OpenVMS-with-POSIX or MPE/iX rather than Linux/Tru64 UNIX/Solaris/AIX/HP-UX? If not, then there is a useful distinction to draw between "UN*X from Day One" and "Now with added POSIX!" systems. Somebody might well have a use for something that "looks more like UNIX" but doesn't have the trademark, as they don't want to have to deal with the non-UNIXy parts of a system that might have the trademark but has other stuff that pokes through, whether at the programmer's level, the user's level, or the administrator's level. Guy Harris (talk) 23:44, 30 December 2020 (UTC)