Browse Prior Art Database

z/OS Cross-Environment Cache Manager Disclosure Number: IPCOM000019277D
Original Publication Date: 2003-Sep-09
Included in the Prior Art Database: 2003-Sep-09
Document File: 6 page(s) / 120K

Publishing Venue



This publication describes a method of caching data in disparate z/OS environments using a middleware package , the Cross Environment Cache Manager (CECM) that runs in its own address space and loads data from a datasource (e.g. DB2, LDAP etc) into a cache that is a z/OS dataspace.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 6

z/OS Cross-Environment Cache Manager

z/OS* applications can run within a number of disparate environments (i.e. IMS*, CICS*, Batch, RRS).

    The environments all have their own unique ways of caching data and indeed different capabilities as to the amount and persistence of the data that is cached.

    For example the nature of the way in which IMS works means caching data would have little value as a single IMS transaction executes independently of other IMS transactions. Cached data is not shared across IMS transactions.

    The functionality for handling the cached data also varies across the environments and so any code written to handle cached data would have to be slightly different for each of the environments. This would involve additional development and testing resources and is particularly relevant when porting code.

    Where large amounts of data need to be cached, performance is a particular consideration in some of the environments.

    Generally, data is cached after it is retrieved by an application for the first time. This makes it immediately available in memory for subsequent access by the same or a different application. Where large amounts of data are concerned, the performance impacts to the transaction could be quite substantial. For example if a number of LOBS(large objects) from a DB2* table were to be cached by a CICS transaction in order to improve the performance of the transaction, the actual result could be a reduction in the throughput of CICS transactions through that CICS region due to a shortage of Dynamic storage.

    This invention provides a middleware package that runs in it's own address space. This piece of software (the Cross Environment Cache Manager) includes:-
1) Commands that will:- - register/deregister data as being preloadable i.e. Data is loaded into the cache as soon as it is registered or when the caching middleware is started up. - mark data as needing to be permanently resident in the cache.
2) Routines that will:- - call tailored procedures to read data from the data-store (e.g.DB2 database)

    Different procedures are preferably provided to read data from the most common data stores like DB2 and LDAP and in addition users can preferably provide their own data read functions.
- move the returned data into a cache that is accessible to all environments. This is preferably either dataspaces or MVS* private storage.
3) A control block in the Cross Environment Cache Manager (CECM) address space preferably holds a pointer that points to the address of the CECM cache and this address is published to all applications via MVS Name Token Services.
4) Cache control routines that manage the data in the cache. This preferably consists of an in-use counter and a least recently used mechanism which will be checked to determine if a piece of data in the cache can be removed to provide more room for other data that needs to be loaded.
5) APIs for use by the applications to retrieve data from the cache. The disparity betw...