I'd just like to thank you all for the superb responses you given to my question. It really has been a great help.
Bye for now, John. On 21 January 2014 00:43, Kenneth Wilkerson <[email protected]> wrote: > Because I've used memory objects for so long, I have not had a reason for > IARVSERV. I read both the description in the macro reference and in the > authorized assembler guide and there seems to be a ton of restrictions and > quirks (such as TPROT). The most notable restriction is the sharing limit > of > 16 pages for an unauthorized address space. However, this limit can be > changed. But because of the ESQA considerations created because the page > tables can map different virtual address for the shared pages, I'm not sure > what would be a practical limit. It does appear to address guard and to > some extent page protection . It also offers the ability to share 31 bit > storage with 24 bit applications (a key point). > > Shared and common memory objects do not have any of IARVSERV restrictions > and do not change my conclusion that performance is NOT the reason to > convert to a memory object. It's the advanced functionality. One reason I > use a common memory object is so I can avoid using CSA and SQA particularly > for code. With the 16 page restriction it would be impractical to share > code > with IARVSERV. And common data spaces cannot execute code. There are no > limits to the flexibility offered by memory objects. I can share any number > of pages. With shared memory objects I can determine which address spaces > have access and which do not. With common memory I can create my own CSA > and > even SQA with some restrictions. > > As Jim affirmed, there is probably little if any performance difference > between data spaces and memory objects. Chose the one best suited to your > architecture. > > Kenneth > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Jim Mulder > Sent: Monday, January 20, 2014 4:13 PM > To: [email protected] > Subject: Fw: Dataspace versus common area above the bar > > >> Memory objects are much more flexible than data spaces. Data spaces > >> are limited to 2GB. Memory objects are only limited by the auxiliary > storage. > >> Memory objects can be guarded and can also be page protected. Data > spaces > >> cannot. Code can execute in memory object but not in data spaces. I > started > >> using memory objects 10 years ago and have nearly forgotten how to > >> use > a > >> data space. > > > Guard pages and protected pages can be created in data spaces using > >IARV64 with TAGET_VIEW=HIDDEN and TARGET_VIEW=READONLY > > I meant IARVSERV, not IARV64 > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > ---------------------------------------------------------------------- > 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 > -- John Blythe Reid, Técnico de Sistemas de z/OS y de Sistemas Transaccionales, Barcelona, España. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
