Almost 10 years ago, I converted an application using 7 data spaces into one
using a single shared memory object. As Gord has pointed out, the CPU
advantage was negligible though I feel it is very difficult to benchmark the
effect. The real advantage was a reduction in error rates because of the
management of the 7 alets and the inadvertent use of an alet where it was
not needed. As far as isolation is concerned, memory objects are just as
isolated and much more manageable than data spaces. Basing isolation of a
common data space on the alet value is no more isolation than basing the
isolation of a common memory object on the amode.   

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. 

So the question is not a question of CPU performance but a question of do
you have an application that is architected or can be architected to take
advantage of the advanced features offered by memory objects? In my current
application, I use local, shared and common memory objects. I place most
(about 70%) of the code in one these common memory objects and page protect
them.  I can't think of any instance where I would chose a data space over a
memory object.

Kenneth

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Gord Tomlin
Sent: Monday, January 20, 2014 10:23 AM
To: [email protected]
Subject: Re: Dataspace versus common area above the bar

On 2014-01-20 04:38, John Blythe Reid wrote:
> I just wanted to sound people out about converting a dataspace  to a 
> common area above the bar. The main interest is the effect it would 
> have on CPU usage.
>
> To put it into context, the dataspace is used for a set of tables 
> which are used by the application programs. There are around eight 
> thousand tables currently occupying about a gigabyte of virtual 
> storage. This is a large installation with excess of 700 million 
> transactions per month plus a heavy batch load. The application programs
make extensive use of these tables.
>
> Whenever an application program needs an element of one of the tables 
> it calls a standard assembler module which uses access register mode 
> to search the table in the dataspace and then returns the requested 
> element to the application program.
>
> If the set of tables were placed above the bar then access register 
> mode would not be needed as the tables would be directly addressable 
> in 64 bit addressing mode.
>
> It all seems much simpler so, at first sight, it would be expected to 
> use less CPU. A reduction in CPU would be the main justification for 
> doing the conversion.
>
> I would be very interested on anyone's opinion on this subject.
>
> Regards,
> John.

I did some tests of a very similar scenario, expecting to see a significant
performance gain. The actual results showed a reduction in CPU usage of
about 1-2%. We decided that the gain was small enough that we were better
off continuing to enjoy the data isolation provided by the data space.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

----------------------------------------------------------------------
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

Reply via email to