Hello from a member of the CABAL. I can think of one possibility of a use for a Data Space instead of using above the line storage. As a type of "protection". With a program in AMODE(64), an errant pointer __might__ corrupt something. As in, you mean to update one area above the line, but overflow (array index overflow) into a different area, or even below the area if the index is negative. If these are relatively large areas, you __might__ consider using a Data Space so that if a program "overruns" or "underruns" its allocation, it will possibly get an S0C4. From which it __might__ be able to recover with an ESTAEX. I don't see how it could corrupt data in the other data space. That's just a thought. Perhaps use of "guard pages" would be as effective and easier to manage. I've not tried that. And a guard page might not catch a really bad index value, like -1. Used in an address calculation, that would be a really large offset.
Again, just a thought. Perhaps not as useful as I imagine. 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 Assembler List > [mailto:[email protected]] On Behalf Of John Gilmore > Sent: Monday, March 05, 2012 1:59 PM > To: [email protected] > Subject: Re: DataSpace & LOAD > > You can 'extend' 64-bit storage too, essentially without limit. > > There is no longer any rationale for defining new data spaces. As > usual, there may be good reasons for keeping some of those you already > have in use. > > John Gilmore, Ashland, MA 01721 - USA > >
