Not really. A z/OS program is allowed to call a pretty arbitrary mix of classical MVS APIs and UNIX system calls. There is no strict separation as such between "classic MVS programs" and "UNIX programs". An MVS task isn't classified as a UNIX process until it makes its first UNIX system call (exception: programs launched via UNIX system calls get classified as UNIX processes even before they start executing) – some programs start issuing UNIX system calls as soon as they start, but a program can run for hours or days as an MVS task, and then suddenly out of the blue start making UNIX system calls, and then at that point the MVS task will be "dubbed" as a UNIX process. (To be a UNIX process, the MVS task needs to be assigned a UNIX security identity – UID and GID – which is the job of the security subsystem – RACF, TopSecret or ACF2 – if the security subsystem isn't configured to assign a UID/GID to that MVS task, all UNIX system calls will fail.)

Compare this to Windows NT, where each executable was marked as belonging to a primary subsystem (Win32, POSIX, OS/2, etc) which is fixed from the time of process startup. In contrast, z/OS offers the flexibility that any MVS task can potentially be "dubbed" as a UNIX process at any time. Or similarly, look at WSL1 in Windows 10 – a process is either a Win32 process which is allowed to call the Win32 API, or a picoprocess which can call Linux system calls, you can't mix Win32 calls and Linux calls in the same process. (You can do it via two processes, one Win32 and one WSL, communicating over IPC; by contrast, z/OS allows mixing UNIX and classic MVS APIs in the same process/task running in a single address space). So the separation between "UNIX" and "classic MVS" in z/OS is actually a lot weaker than in Windows NT, which is why the "personality" term which was used in the later isn't really applicable to z/OS.

Thanks for the overview.