Actually all good points. And if IBM wanted to allow this kind of work, I'm quite certain they could come up with ways to make it safe. Even going further and creating a mechanism to 'spy' as you say, really the ability to share address spaces, between users could be done safely if they really wanted to. (For those who will say so, yes, I know, it can all be done, but as suggested, it could be made to work safely without authorization being needed. If IBM was so inclined.)
Like most computer things, it's just a matter of programming. Whether it's desirable or not, I don't really know. I'd love it. Whether IBM has anybody clamoring for this though, I don't know. Kinda doubt it though. -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, November 17, 2014 9:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual I would presume that a mechanism that permitted an ordinary programmer to create and access his/her own address spaces would automatically limit any access to the initial address space (batch/TSO/Unix) and any address spaces created from it, and prohibit access to address spaces not created by the originating address space. The programmer ought to be able to write and use PC-ss code to perform functions in any of the self-created address spaces, and thus be able to create and test viable client/server programs to perform any envisioned business function. Authorized programs and privileged instructions ought not to be required to build such systems. Accessing address spaces you did not create (i.e., "spying" in other user's address spaces) is not what I imagined or desired. Any such "spying" capability (and much more so any mechanism permitting modification of contents) must of course come with authorization requirements for the security and integrity of the whole system. But who does it hurt if I bollix my own self-created address spaces? That should have no more impact on the entire system than bollixing my own task does now. There are other hard questions, like how to limit how many such address spaces can be created by any one user to prevent "runaway" space creation and virtual page disk space exhaustion, but these are more properly answered by control mechanisms in the operating system, not in the hardware. How to design such a hardware environment is well beyond my capabilities, so I will not try to directly answer that question. I was merely pointing out that I thought that the hardware design which IBM created was not an ideal one from the standpoint of the ordinary (but sophisticated and experienced) application programmer. Not that I expect any of the current design to ever change of course. It is now written in stone. Unix programming "fork" capabilities, shared memory objects and mutex signaling mechanisms provide some of the functional capabilities I described above, but not the full range of course. Peter > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Tom Marchant > Sent: Monday, November 17, 2014 10:06 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Redesigning the Principles of Operation Manual > > On Fri, 14 Nov 2014 18:31:23 -0500, Farley, Peter x23353 wrote: > > >I have often thought it was a mistaken design by IBM that prohibits > >non-authorized programmers from exploiting multiple address spaces > >and instruction-level space-switching facilities. > > How would you propose that such non-authorized programs access only > the other address spaces that they were permitted to access? In other > words, how would you protect the integrity of all address spaces if > unauthorized code were able to access other address spaces? > > -- > Tom Marchant This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
