To cause deployed JAR files to be defined and installed into a CorbaServer
by the CICS scanning mechanism, place them in the CorbaServer's deployed JAR
directory. (The deployed JAR directory is specified by the DJARDIR option
of the CORBASERVER definition. It is also known as the “pickup” directory.)
When the CorbaServer is installed, CICS scans the pickup directory and automatically
installs any deployed JAR files it finds there. (This automatic scan occurs
regardless of whether the CorbaServer is installed in enabled or disabled
state.)
CICS assumes that a file is a deployed JAR if:
- It has a suffix of .jar (in lowercase).
- Its base filename is between 1 and 32 characters long. By “base filename”
we mean the part of the filename before the suffix, and excluding any file
path. For example, the base filename of the file djardir\myDeployedJar.jar is myDeployedJar.
CICS copies any deployed JAR files it finds in the pickup directory to
its shelf directory and dynamically creates and installs DJAR definitions
for them.
The name of the DJAR definition is the name of the
deployed JAR file on HFS. For example, a deployed JAR file named /var/cicsts/pickup/TheThreeBears.jar results
in a DJAR definition named TheThreeBears.
After the CorbaServer has been installed, you can:
- Add more deployed JAR files to the pickup directory. CICS installs them:
- When instructed to by means of an explicit EXEC CICS or CEMT PERFORM CORBASERVER
SCAN command. (This command works only when the CorbaServer
is in a steady state—that is, when it is in ENABLED or DISABLED state, but not when
it is in ENABLING, DISABLING, or DISCARDING state .)
- Or when instructed to by the resource manager for
enterprise beans (otherwise known as the RM for enterprise beans), which issues
a PERFORM CORBASERVER SCAN command on your behalf.
- Put updated versions of deployed JAR files into the pickup directory.
When you issue a PERFORM CORBASERVER SCAN command (either explicitly or by
means of the RM for enterprise beans), CICS detects that an update has occurred
and updates both the LASTMODTIME, DATESTAMP, and TIMESTAMP attributes of the
installed DJAR definition and the shelf copy of the deployed JAR file, to
reflect the pickup directory change.
Note: - If you use the scanning mechanism in a production region, be aware of
the security implications: specifically, the possibility of CICS command security
on DJAR definitions being circumvented. To guard against this, we recommend
that user IDs given write access to the HFS deployed JAR file directory should
be restricted to those given RACF® authority to create and update DJAR and
CORBASERVER definitions.
- The fact that resource names must be unique in the CSD has implications
for the scanning mechanism:
- Different CorbaServers in the same CICS region must use different DJARDIR
directories. (Otherwise, performing a scan against different CorbaServers
would result in multiple sets of identically-named DJAR definitions, each
set pointing at a different CorbaServer. CICS rejects all such sets of definitions
except the first.)
- For the same reason, you must not place an identically-named deployed
JAR file into multiple DJARDIR directories in the same CICS region.
If
you want to install the same set of beans into more than one CorbaServer in
the same CICS region, you should do one of the following:
- Name the deployed JAR file differently in each DJARDIR directory.
- Use static definitions. That is, create multiple (differently-named) static
DJAR definitions, pointing at the same deployed JAR file on HFS but at different
CorbaServers.
- CICS ignores any deployed JAR files in the pickup directory that have
the same name and the same date and time stamps as currently-installed
DJAR resources. A deployed JAR file with the same name but a later date-and-time
stamp than an installed DJAR is treated as an update.
- You cannot update a statically-installed DJAR definition by means
of the scanning mechanism—you must first discard the static definition. For
example, if you have a statically-installed DJAR definition named myDjar1,
you cannot update it by scanning a deployed JAR file named myDjar1.jar.
- An invalid deployed JAR file is not detected early (when the
pickup directory is scanned), but when the EJB environment attempts to open
it. The DJAR resource for an invalid JAR file becomes UNRESOLVED. CICS outputs
a message to indicate what is wrong with the JAR file. The message is sent
to the CICS log and to the “EJB event” user-replaceable program.
- After every scan of the pickup directory, CICS outputs a message indicating
the number of new and the number of updated deployed JAR files found during
the scan.
To determine which DJAR resources have been dynamically installed by the
scanning mechanism and which statically installed from a CSD or by means of
CREATE DJAR, look at the value of the HFSFILE field returned on an INQUIRE
DJAR command. If the DJAR has been dynamically installed, the value will begin
with the CorbaServer's pickup directory. (You should not put statically-installed
deployed JAR files in the pickup directory.) A DJAR name longer than 8 characters
will also indicate a dynamically-installed resource.