As mentioned in the overview blog, there are some breaking changes introduced by APAR OA64880/PTF UJ93165. This blog provides the details and a subsequent blog describes the migration steps necessary for existing ODP users.
OMEGAMON® Data Broker
OMEGAMON Data Broker is a plug-in for the Zowe cross-memory server. The latest plug-in requires a server from Zowe 1.28.2, or later.
This is a breaking change only if both of the following conditions are true:
- You are running OMEGAMON Data Broker using a Zowe cross-memory server that you have obtained from a separate Zowe distribution.
- The version of that Zowe distribution is earlier than 1.28.2.
In that case, you need to use a Zowe cross-memory server load module from a more recent version of Zowe.
OMEGAMON Data Provider supplies the Zowe cross-memory server load module from Zowe 1.28.2. For details, see the description of the change “Updated Zowe cross-memory server”.
OMEGAMON Data Connect
Renamed JAR file to odp-server-version.jar
The file data-connect-version.jar has been renamed to odp-server-version.jar. This file is now known as the core JAR file, to distinguish it from mapping extension JAR files.
The lib directory that contains the core JAR file now also contains a symbolic link, odp-server.jar, that refers to the core JAR file. The core JAR file name contains a version. The symbolic link offers a stable file name that avoids the inconvenience of updating references to the core JAR file whenever the version changes.
Previously, a monolithic JAR file implemented the core functions of OMEGAMON Data Connect and the support for each monitoring agent. Now, there are multiple JAR files:
lib/odp-server-version.jar
The core JAR file: a single JAR file that implements the core functions of OMEGAMON Data Connect.
lib/ext/kpp-odp-model-version.jar
Mapping extension JAR files: a JAR file for each monitoring agent supported by OMEGAMON Data Provider, where kpp is the product code for the agent. Each mapping extension JAR file encapsulates the support for a specific agent.
Mapping extensions extend OMEGAMON Data Connect to support different types of incoming data. Mapping extensions consist of Java classes that contain the data and logic required to map binary-format data from monitoring agents to various output formats. These classes are sometimes referred to as mapping classes.
One reason for the introduction of the mapping extension JAR files was to speed deployment of OMEGAMON agent updates. For example, when the OMEGAMON Monitor for z/OS V5.6 was updated to include z16 support, an associated APAR was required by ODP to pick up the service updates. While that process can still be utilized, it is now possible for the OMEGAMON agents to do their updates and ship a mapping extension JAR file to stream those changes, without the need to wait for an ODP service update.
The new OMEGAMON Data Connect runtime option -Dodp.ext specifies the locations of mapping extensions as a comma-separated list of directory paths and individual JAR file paths. The sample JCL procedure and shell script for running OMEGAMON Data Connect set a default value for -Dodp.ext that includes the lib/ext directory under the installation directory and the extensions directory under the user directory. If a mapping extension JAR file for an agent exists in more than one location, then OMEGAMON Data Connect uses the latest version of the JAR file.
Changes to the sample shell script, bin/connect, include the following breaking changes:
New required argument to specify an action
Previously, you could run the script with no command-line argument. Now, you must specify one of the following actions as a command-line argument:
run
Runs OMEGAMON Data Connect, as before.
create
Creates a user directory for OMEGAMON Data Connect containing a sample configuration file copied from the installation directory as a starting point for you to edit.
This is the recommended method for creating a user directory, even if you plan to use JCL to run OMEGAMON Data Connect.
As part of the update/migration process in this blog, you’ll see that this protects your current runtime by copying it over to the new user directory.
New environment variable ODP_CONNECT_USER_DIR
The script refers to a user directory specified by the environment variable ODP_CONNECT_USER_DIR. Set this variable before running the script.
Next Steps
Now that you've read about the changes, you can go implement them. The migration steps are in the manual and in the migration blog. And as usual, if you are looking for more information about ODP, please look at our Master Blog.
#CICS
#db2z/os
#IBMMQ
#IBMZ
#IBMZOS
#IBMAI
#IMS
#Instana
#jvm
#OMEGAMON
#IBMChampion