Browse Prior Art Database

Installation mechanism for EJB resources

IP.com Disclosure Number: IPCOM000014831D
Original Publication Date: 2001-Oct-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 44K

Publishing Venue

IBM

Abstract

Disclosed is a design for managing the installation of certain resource definitions into a CICS system which avoids certain difficulties associated with the need to invoke a Java Virtual Machine as part of the installation processing: The standard method for installing resource definitions into a running CICS system is for the Resource Definition Online (RDO) infrastructure code to read the definition record from the CICS System Definition (CSD) file and invoke the appropriate CICS domain gate for each resource. The domain code then adds the new resource to its state and passes it to the Catalog Domain to record for warm restart recovery. In some cases, Directory Manager is also used to record the new resource. However in the CICS implementation of Enterprise JavaBeans (TM) (EJB) support there are cases where it is necessary to invoke a Java Virtual Machine (JVM) as part of the resource installation process. These are: CorbaServer install where a directory on HFS (Hierarchical File System, the MVS implementation of the Unix (TM) file system) needs to be created (or emptied).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 3

Installation mechanism for EJB resources

Disclosed is a design for managing the installation of certain
resource definitions into a CICS system which avoids certain
difficulties associated with the need to invoke a Java Virtual
Machine as part of the installation processing:

    The standard method for installing resource definitions into
a running CICS system is for the Resource Definition Online (RDO)
infrastructure code to read the definition record from the CICS
System Definition (CSD) file and invoke the appropriate CICS
domain gate for each resource. The domain code then adds the new
resource to its state and passes it to the Catalog Domain to
record for warm restart recovery. In some cases, Directory
Manager is also used to record the new resource.

    However in the CICS implementation of Enterprise JavaBeans
(TM) (EJB) support there are cases where it is necessary to
invoke a Java Virtual Machine (JVM) as part of the resource
installation process. These are:

CorbaServer install where a directory on HFS (Hierarchical
File System, the MVS implementation of the Unix (TM) file
system) needs to be created (or emptied).

DJAR install where the deployed jar file has to be read, the
deployment descriptor parsed and the metadata information for
each bean in the jar stored.

In the latter case it is also required that the installation
is atomic, i.e. either all the beans are installed, or none
(in the failure case).

    These cases cause a particular problem in the situation
where resources are to be installed automatically during CICS
initialisation (so-called grouplist install). This is because
invoking a JVM is CPU intensive so that CICS initialisation can
be significantly delayed if there a number of resources to be
installed. There are also other problems associated with the
install processing during initialisation. Some of these are:

JVM failure tolerance. If the JVM processing a resource
installation during initialisation fails, then the CICS region
can fail to initialise although the error only affected one
resource.

Unavailability of required facilities. Now that the metadata
is being held in memory only this is a less important factor,
but some installed resources (e.g. program definition for
DFJIIRP) are required before a JVM can be invoked. This
creates a possible race between this resource installation and
the EJB resource installation which requires it.

    A performance issue arises because of the use of core CICS
to store definitions and other information which is required by
Java code running within a JVM at runtime. It is relatively
expensive to make a call across the Java-to-CDURUN interface to

1

Page 2 of 3

obtain, for example the bean metadata, although this is also less
significant now that metadata is being held in memory.

    Another problem which arises as a result of using JVMs for
part of CICS processing is that for efficiency, information about
CICS installed resources is sometimes cached within a JVM, for
example the bean metadata representing the deployment data...