> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Paul Gilmartin > Sent: Tuesday, July 24, 2012 10:16 AM > To: [email protected] > Subject: Re: Authorized Rexx Assembler Function > > On Tue, 24 Jul 2012 10:05:00 +0300, Binyamin Dissen wrote: > > > >:>Why have such a special list rather than merely verifying > that the program > >:>resides in an APF authorized library and was linked with AC=1? > > > >Because a program expecting to be a job-step task may be > spoofable, allocate > >storage in a key where parallel tasks can update it, etc. > > > Sigh. I keep forgetting (wishful thinking?) what a primitive > OS z/OS is; > that it provides no simple way a program can protect its storage from > meddling by others. z/OS still thinks it's running on a s/360. > > -- gil
I don't understand where you're coming from on this one gil. In UNIX, if you use threading, you can't protect one thread's storage from corruption by another thread. That's what TSO is doing, in UNIX terms. Or do you want TSO to do fork()'ing like a UNIX shell? But, even in z/OS, if you have an address space running multiple processes (which is possible, tho difficult), you have the same problem. z/OS has far superior memory protection than what I know of in UNIX. It basically does not have protect keys. It's protection is based on page tables so that each process run in a separate address space, with the kernel memory being "shared" (like LPA). As I understand it, the kernel's memory is protected via the page tables by being marked as "read only" in the user process's copy. So, once in kernel space, everything is running key 0. Unlike z/OS which separates subpools by protect key and then runs different subsets of the "kernel" in separate protect keys. E.g. "data management" runs in protect key 5 (IIRC). So "data management" functions cannot corrupt the storage of other system memory. Also, remember that we are talking about TSO. An archaic piece of software, which IBM has just seeming lost interest in. Imagine what could be done if the non-APF user code ran in a subspace, like CICS uses. Or run the APF code in protect key 10 (or maybe 9), instead of 8. This is all technically possible. And much more CPU efficient that spawning other address spaces. Which would be another way to run APF code. Instead of a parallel TMP and using STATUS STOP, have TSO use ASCRE to create another address space which would run the APF authorized code. z/OS is far superior to UNIX in many ways. It's just that some of the common applications, especially TSO, have not been upgraded to take advantage of the newer ways of doing things. Likely because it would cost money which would never be recouped. TSO really needs to be rearchitected or replaced. IBM would probably love it if all TSO users would go to RD/z. Which seems, from my reading, to be far superior to TSO. But it is also more expensive. I would also adore it if IBM would make a version of ISPF which was designed to use the X protocol instead of TSO TGET/TPUT/TPG. Hum, I wonder how TSO Session Manager works. And whether _it_ could be enhanced to connect to an X server instead of using 3270. Oh well, I'll never figure it out. I don't have: (1) a C compiler, to easily do X; (2) the available CPU to do the development; and most imporantly (3) the talent (which is why I play "Angry Birds" et al. any more). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
