Does z/OS enforce memory protection between processes of the same user?

It is often pointed out that each user has their own (virtual) address space in in z/OS; this is said as if it is a good thing, and I suppose it is compared to real mode. But in most modern systems I'm used to most processes (or jobs, in z/OS parlance, I suppose) having their own address space. This Unix approach seems strictly more secure at first glance.

That said, I have heard it claimed that z/OS jobs also each get their own address space, but I haven't seen any official documentation for this. Of course, if a user can only run one job at a time (I haven't checked this), then certainly this would not be an issue. (Aside: Traditionally z/OS must have been used for batch processing, so that might be a reasonable assumption. But, it is 2021, and things have perhaps changed, so knowing about job limitations per user would be good to know about as well.)

You first paragraph isn’t clear as it seems to be contradictory.

On IBM Z you have the hardware and then the operating system. The hardware has a set of features that allow for separate address spaces and the virtual storage of each is protected from other users accessing the data. There are some caveats as IBM Z hardware uses a storage protection key to further identify how storage is protected. The keys can range from 0 - 15 (F) and the keys below 8 are reserved for the OS. z/OS uses this feature such that problem state (user programs) run in Key 8 on z/OS. The hardware also allows a protection on storage so that some storage is readable by all address spaces (generally OS memory) and some are fetch protected meaning you have to have the right key to read the data. All in all its a fairly comprehensive set of capabilities.

On z/OS there are address spaces which have their own virtual memory which is independent and inaccessible (in a controlled way) from other processes. Address spaces can host a JOB (managed by JES) or a system task (Started Task), … in each address space there can be multiple threads of execution.

That said, all this complexity is based on z/OS being a shared model of system resources which is different than Linux. Linux locks their kernel down and controls access through system calls. This actually makes z/OS highly efficient but is also its achilles heel as when things go bad they can go bad for all processes.

the platform is quite secure engineered from the hardware and operating systems to protect data and access. That said, operating systems (all of them) are written by fallible people and any of them can be hacked. z/OS is probably more difficult more so that its not ubiquitous like Linux or Windows.