Talk:Z/OS

From Wikipedia, the free encyclopedia

A 31-bit mode? Don't you mean a 32-bit mode?

• 31-bit mode is correct. The original OS/360 operating system had 24 bit addressing. After the 31 bit mode was introduced, the 24 bit mode still had to be supported. The high order bit was used to differentiate between the two addressing modes, so they only had 31 bits for the address rather than the full 32. In case you're wondering, the current OS still supports 24 bit addressing mode, and applications are still used that must be run in 24 bit mode. Dave6 19:24, 10 August 2005 (UTC)

Additionally, the high-order bit in a 4 byte address (which is known as a "full word") was utilized to denote the last address in a list of parameter addresses passed from a calling program to a called program. Ergo it was not available for use as part of the address itself. For example: a calling program passes A, B and C to a called program. The corresponding address for each variable is stored in a full word aligned to a full word boundary (i.e. addresses ending in X'0', X'4', X'8' and X'C'). The last address in this list of addresses will contain a value of X'1' in the high order bit to denote the fact that it is the last address in the list of addresses. All of this is part and parcel of what came to be known as "standard linkage conventions".

[edit] "Robust memory protection"?

The article now speaks of z/OS having "a robust memory protection capability generally unheard of in the world of microcomputing". Presumably either "a robust memory protection capability" means something more than "putting each task in its own address space, with shared regions write-protected", or "the world of microcomputing" doesn't include Windows NT or Unix-like systems such as Mac OS X, Linux, BSD, Solaris, AIX, HP-UX, etc., as all those OSes have that level of memory protection, or "generally unheard of" means "generally unheard of in what's left of the world of microcomputing once you exclude modern OSes". Guy Harris 04:32, 14 March 2006 (UTC)

There really exists "a robust memory protection capability generally unheard of in the world of microcomputing" . This refers to the hardware protection key, a unique feature of the early /360 architecture and also of z/OS.

Hardware protection keys eliminate the risk of buffer overflows into kernel space. They isolate z/OS Subsystems from each other, and greatly improve transaction isolation e.g. in the CICS transaction server.

There exists nothing comparable in other platforms. W. G. Spruth 84.57.183.209 22:11, 1 November 2006 (UTC)

Presumably the buffer overflows to which you're referring are overflows in supervisor-mode code; user-mode code should have no write access to kernel space. That also presumably means that not all supervisor-mode code runs with protection key 0. However, that'd protect only against overflows into regions with different protection keys.

Do MVS and its successors use protection keys within a task to protect parts of the task from other parts? (Protecting one task from another should only be necessary with memory shared between tasks when different tasks have different address spaces.) Guy Harris 22:24, 1 November 2006 (UTC)