Also, a non-local spawn may not require a new address space if there is one available in the pool managed by WLM for BPXAS.
On Tue, Jul 31, 2012 at 11:42 AM, McKown, John <[email protected]> wrote: > 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
