ca.portal.admin

Re:Re: Memory cache

Discussion created by ca.portal.admin on May 16, 2006
Kay and Linda,

We went with Memory Cache when we went 16.0 SP1 last May. We had hoped
it would work in local mode as we have a number of long running local
mode batch jobs that could have benefited.

Where is the benefit with Memory Cache as we have both been told and
experienced?

It is true that it is the contents of a database file that gets put
'above the bar', not a database area or a database page. The IDMS system
still sees the database page thru the DMCL buffer. This has not changed.


We first used it to place our Front End Security database completely
'above the bar'. It is small and used to gain access to our IDMS CV. We
only had to set the MEMLIMIT to 25Mb to contain it all. Once a database
page is read it is placed 'above the bar', if you have the memory, and
stays there until you either vary it or the system shuts down. Now if
the database page is in the buffer IDMS has 'direct access' to it
otherwise it goes to 'above the bar' memory to get it rather than to the
disk subsystem. Memory access is supposed to be a magnitude faster than
disk access so there is a benefit. This may not be as great because of
disk caching etc but it is still supposedly faster.

We have benefited because we split our larger database areas into
smaller files a long time ago, mainly so we could restore them to
development database disk pools that may have had a problem restoring
large contiguous files. So the idea of placing files 'above the bar' is
not really difficult to us. As mentioned before IDMS still sees the
database page thru the DMCL buffer so unless you have a buffer the same
size as the file you will get contention and pages swapped out of the
DMCL buffer. Now the seek will go to memory rather than disk. I am not
sure about contention with searching memory that you may have with disk
and the disk subsystem so this benefit may be lessened.

As our experience has increased we have moved selected database files
'above the bar' reducing our I/O. We mainly look at well used areas
including the IDMS message area and have varied them first before making
them defined as 'above the bar' in the DMCL. Use of memory cache for the
CV makes sense as you have very random access that can benefit mostly
from this technique.

The downside of not having the data written to disk has not happened
even though we have had some system abends. We have not suffered a power
failure because we have a UPS on our mainframe so I cannot say that we
had to repair broken chains but we did have a disk subsystem problem
that memory cache sailed thru.

Our experience shows that it can be a benefit if you have the memory,
good disk cache and a UPS for an online system.

I still would like a SYSIDMS parm to allow local mode to push database
pages 'above the bar' but that is unlikely to happen with IDMS being
replaced by MS SQL Server in about 3 years.

Chris Wood
Alberta Department of Energy
CANADA


"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Memory cache
"Kay and Linda,

We went with Memory Cache when we went 16.0 SP1 last May. We had hoped
it would work in local mode as we have a number of long running local
mode batch jobs that could have benefited.

Where is the benefit with Memory Cache as we have both been told and
experienced?

It is true that it is the contents of a database file that gets put
'above the bar', not a database area or a database page. The IDMS system
still sees the database page thru the DMCL buffer. This has not changed.


We first used it to place our Front End Security database completely
'above the bar'. It is small and used to gain access to our IDMS CV. We
only had to set the MEMLIMIT to 25Mb to contain it all. Once a database
page is read it is placed 'above the bar', if you have the memory, and
stays there until you either vary it or the system shuts down. Now if
the database page is in the buffer IDMS has 'direct access' to it
otherwise it goes to 'above the bar' memory to get it rather than to the
disk subsystem. Memory access is supposed to be a magnitude faster than
disk access so there is a benefit. This may not be as great because of
disk caching etc but it is still supposedly faster.

We have benefited because we split our larger database areas into
smaller files a long time ago, mainly so we could restore them to
development database disk pools that may have had a problem restoring
large contiguous files. So the idea of placing files 'above the bar' is
not really difficult to us. As mentioned before IDMS still sees the
database page thru the DMCL buffer so unless you have a buffer the same
size as the file you will get contention and pages swapped out of the
DMCL buffer. Now the seek will go to memory rather than disk. I am not
sure about contention with searching memory that you may have with disk
and the disk subsystem so this benefit may be lessened.

As our experience has increased we have moved selected database files
'above the bar' reducing our I/O. We mainly look at well used areas
including the IDMS message area and have varied them first before making
them defined as 'above the bar' in the DMCL. Use of memory cache for the
CV makes sense as you have very random access that can benefit mostly
from this technique.

The downside of not having the data written to disk has not happened
even though we have had some system abends. We have not suffered a power
failure because we have a UPS on our mainframe so I cannot say that we
had to repair broken chains but we did have a disk subsystem problem
that memory cache sailed thru.

Our experience shows that it can be a benefit if you have the memory,
good disk cache and a UPS for an online system.

I still would like a SYSIDMS parm to allow local mode to push database
pages 'above the bar' but that is unlikely to happen with IDMS being
replaced by MS SQL Server in about 3 years.

Chris Wood
Alberta Department of Energy
CANADA

Outcomes