Oh, yea. And taking this way back to what I think was the origin of the question, which was running APF code in TSO, which requires a parallel TMP and the use of STATUS STOP, it might be nice if the parallel TMP code (which is APF, remember) were to change its execution key to "something else". The book says that 2 and 4 are "reserved". Why not use them for TSO APF parallel TMP use? Also, isn't V=R really dead any more? Would that free up keys 10-15 for other use?
-- 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 > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of McKown, John > Sent: Tuesday, July 31, 2012 11:43 AM > To: [email protected] > Subject: Re: Authorized Rexx Assembler Function > > I think gil is protesting the fact that spawn() can run > multiple, logically separate, processes in a single address > space. And so a errant program in one process can overwrite > the storage in another process. Of course, the simple way to > avoid this problem is to remove the "shared" bit (extattr -s > ~/bin/my-program) from the program which you don't want > running in a shared address space. > > Many may not do this due to IBM's "warning" that process > creation is "expensive" and that will run up your CPU usage > and increase response time. > > UNIX has the same problem when some application starts > multi-threading (akin to z/OS ATTACH multitasking). Most of > the time, this is not used to run "random" user supplied > code, but only specific code written by the same > programmer/team. So the chances of a memory overwrite are, > hopefully, less. > > With the death of V=R regions, I wish IBM would open up using > keys 10-15 to user code. It might make some sense for > multiuser servers which need to run user supplied code. > > -- > 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 > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Steve Comstock > > Sent: Tuesday, July 31, 2012 11:17 AM > > To: [email protected] > > Subject: Re: Authorized Rexx Assembler Function > > > > On 7/31/2012 9:27 AM, Paul Gilmartin wrote: > > > Storage protection in other OSes: > > > > > > On Mon, 30 Jul 2012 22:09:07 -0600, Steve Comstock wrote: > > >>>> > > >>> 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. > > >> > > >> I never saw an answer from you regarding my question for > > some examples > > >> of how other non-primitive OS's provide a "simple way a > program can > > >> protect its storage from meddling by others" > > >> > > > We're both familiar with UNIX, which classically runs each > > process in > > > a separate address space. How much simpler or more effective > > > could it be? Likewise z/VM. > > > > Yes, well, each batch job runs in a separate address space, too. > > Isn't that the same approach? > > > > Of course the advanced user can meddle with other address space > > storage using authorized services, but that's true for z/OS UNIX, > > too. Every OS has facilities for the authorized user to do anything > > they want / need. > > > > But for basic applications (batch and TSO, most CICS and IMS), the > > application programmer has his/her storage protected from > meddling by > > other applications automatically by address space isolation. > > > > Guess I'm just not sure what flaw you're seeing in z/OS here, > > compared to other operating systems. > > > > > > > > > > z/OS UNIX (USS) has compromised that classic UNIX model > for reasons > > > of performance, running multiple processes in shared > address spaces. > > > But I suspect (with no evidence whatever) that Linux for z can run > > > a number of processes in private address spaces with better > > performance > > > than USS can run the same processes in shared address spaces. > > > > > > -- gil > > > > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to [email protected] with the message: > > INFO IBM-MAIN > > > > > > > > > -- > > > > Kind regards, > > > > -Steve Comstock > > The Trainer's Friend, Inc. > > > > 303-355-2752 > > http://www.trainersfriend.com > > > > * To get a good Return on your Investment, first make an investment! > > + Training your people is an excellent investment > > > > * Try our tool for calculating your Return On Investment > > for training dollars at > > http://www.trainersfriend.com/ROI/roi.html > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: > INFO IBM-MAIN > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
