Patch 5 to the 3.6.2 release is identified by the build date of 17-DEC-2025 and includes the
fixes in the previous patches.
Patch 4 to the 3.6.2 release is identified by the build date of 19-SEP-2025 and includes the fixes in patch 3, patch 2, and patch 1.
It includes the following updates:
- A new Java property, jcclml.txnisolation.exception, that directs how the Loader handles the case when a JDBC driver throws an exception from the getTransactionIsolation() method. The exception generated by the JDBC driver can be seemingly unrelated to the getTransactionIsolation() method, though the method name always occurs within the traceback from the exception. For example, one version of the Postgres JDBC driver throws the exception:
org.postgresql.util.PSQLException: This ResultSet is closed.
...and the traceback contains the method name several calls down on the stack:
at org.postgresql.jdbc2.AbstractJdbc2Connection.getTransactionIsolation(AbstractJdbc2Connection.java:903)
The property/value pair can be defined in either the Java properties file (see control file directive "java~properties~<file>" in the documentation) or using the Java command line logical name (see logical name "JCC_LML_JAVA_COMMAND_LINE" in the documentation.) The property need only be defined in either the property file or the command line logical, but not both. If it is defined in both locations, the definition in the property file value is used.
jcclml.txnisolation.exception
Values (not case sensitive):
- FAIL
- Report exception and the Loader will exit as in previous versions. (default, if not specified or an invalid value is specified)
- TRANSACTION
- Attempt to continue using transaction semantics. AutoCommit will be disabled and isolation level will be set to Read Committed. If disabling AutoCommit fails, the exception is reported and the Loader will exit. If setting Read Committed fails, the exception is displayed, but processing continues.
- NOTRANSACTION
- Attempt to continue as if the JDBC driver and/or data store does not support transactions. The Loader will not attempt to disable AutoCommit or set the transaction isolation level. Further, it will not start or commit transactions. If the target data store does actually support transactions, AutoCommit will commit each statement sent to the target. Whether this results in a valid replication is driver and data store dependent and should only be used in consultation with JCC Support.
e.g.
"java~properties~<file>" entry:
jcclml.txnisolation.exception=transaction
OR
"JCC_LML_JAVA_COMMAND_LINE" value:
$ define JCC_LML_JAVA_COMMAND_LINE "-Djcclml.txnisolation.exception=transaction"
- A new ability to specify JDBC target URI connection strings.
JDBC connection strings have become more complex and lengthy over time as more features are added in JDBC and the target data stores. The Loader has been enhanced to allow an entry in the Java properties file to declare the target URI (see control file directive "java~properties~<file>".)
To enable this feature, the control file "output" keyword "<output target>" parameter can be specified as "property:[property name]". If the "[property name]" is omitted, the value jcclml.targetURI is used.
NB: All of the properties in the properties file are passed to the JDBC driver connection method. It is recommended that any property name chosen for this feature start with "jcclml." to ensure that the property value is not interpreted as related to some layer of the JDBC driver.
e.g.
Control file:
output~jdbc~synch~property:~record
"java~properties~<file>" entry:
jcclml.targetURI = https:jdbc:bigquery://www.googleapis.com/bigquery/v2:443;\
ProjectId=protean-bazaar-123456-b5;OAuthType=0;\
OAuthServiceAcctEmail=jcc-bq-lml-test@protean-bazaar-123456-b5.iam.gserviceaccount.com;\
OAuthPvtKeyPath=/LML_BIGQUERY/KEY/protean-bazaar-123456-b5-a018a70a8aa4.json;
OR
Control file:
output~jdbc~synch~property:jcclml.GBQtargetURI~record
"java~properties~<file>" entry:
jcclml.GBQtargetURI = https:jdbc:bigquery://www.googleapis.com/bigquery/v2:443;\
ProjectId=protean-bazaar-123456-b5;OAuthType=0;\
OAuthServiceAcctEmail=jcc-bq-lml-test@protean-bazaar-123456-b5.iam.gserviceaccount.com;\
OAuthPvtKeyPath=/LML_BIGQUERY/KEY/protean-bazaar-123456-b5-a018a70a8aa4.json;
JCC LogMiner Loader 3.6.2-p3
Patch 3 to the 3.6.2 release is identified by the build date of 23-MAY-2025 and includes the fixes in patch 2 and patch 1.
It includes the following updates:
- Bug fix for memory corruption in control file processing for three Kafka keywords.
The bug effects the following control file keywords:
KAFKA~TOPIC~
KAFKA~MetadataTopic~
KAFKA~HEADER~
When the JCC LogMiner Loader parses the Kafka directive, it produces an internal representation that is used later. If the length of the internal representation string ends within 2 bytes of the next memory alignment location, random data can appear at the end of the string at runtime or it may be truncated. Itanium uses quadword memory alignment. The internal string length depends on what values are specified.
For example:
kafka~Topic~'aa-bbbbbbb-cccc-ddd-eeeeeee_cccc-ffff.ggggggg.hhh.iii.',Table_Name
Results in a string of 64 characters, ending on a memory alignment boundary. At runtime, the end of the string would be overwritten which would result in invalid values for Kafka Topic in this example. A similar example could use MetadataTopic or Header keywords.
The only possible work-around is to increase or decrease the string by one or two bytes.
- Bug fix for incorrect initial setting of the Kafka clientID when using JCC_LML_PREEMPTIVE_CONNECT feature.
When using the JCC_LML_PREEMPTIVE_CONNECT feature and connecting to a Kafka target, the clientID is initially incorrectly set as clientId=<LoaderName>-0 due to the thread number value not yet being set in memory. This problem occurred for all threads other than 0, but thread 0 was affected. The problem manifested with the following sequence:
- thread 0 would connect with clientID=<LoaderName>-0
- thread <n> would connect with clientID=<LoaderName>-0
- thread 0 would receive an exception invalidating its batches of data
- thread 0 would disconnect and reconnect with clientID=<LoaderName>-0
- thread <n> would receive an exception invalidating its batches of data
- thread <n> would disconnect and reconnect with clientID=<LoaderName>-<n>
The exceptions generated in thread 0 and other logs were all similar to:
[2025-05-22 06:02:50,367] ERROR [Producer clientId=KAFKA_XML-0, transactionalId=KAFKA_XML-0] Aborting producer batches due to fatal error (org.apache.kafka.clients.producer.internals.Sender:306)
org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.
No tested versions of Kafka have shown any data loss.
The following list of Kafka versions were tested:
- 1.1.0
- 2.0.0
- Confluent 4.1.2
- Confluent 7.6.1
The incorrect setting of the Kafka clientID has been corrected.
- VirtualColumn JCCLML_AERCP value incorrectly truncated
When specifying the VirtualColumn JCCLML_AERCP, the output value was incorrectly truncated at 28 characters.
This has been corrected.
JCC LogMiner Loader 3.6.2-p2
Patch 2 to the 3.6.2 release is identified by the build date of 1-SEP-2021 and includes the fixes in patch 1.
It includes the following updates:
- Add a feature to preemptively attach to the target datastore during the LML initialization phase; for the first thread, this is before the CLM process is instantiated. This can be useful to detect issues connecting to the target immediately on startup as well as mitigating issues with targets that take a particularly long time to process connection requests. The feature is disabled by default to maintain backward compatibility. The feature is enabled by defining the logical name JCC_LML_PREEMPTIVE_CONNECT to the value "1"; any other value explicitly disables the feature.
JCC LogMiner Loader 3.6.2-p1
Patch 1 to the 3.6.2 release is identified by the build date of 13-AUG-2021.
It includes the following updates:
- Remove the dependency on the CMA$TIS_SHR shareable image in the AXP ST variant executables. This allows the ST kit to run on versions of AXP OpenVMS 7.x that have installed the CMA$TIS_SHR shareable image with GS version 1.3 or earlier. OpenVMS 7.x systems that have installed the CMA$TIS_SHR shareable image with GS version 1.4 or higher may run the standard variant executables.
- Change to the JCC_CREATE_LOG_MINER_OPT_FILE utility where it failed to detect whether the database functions from the VMS_FUNCTIONS.SQL procedure were defined in the database.
- Change to the JCC_LML_CREATE_CONTROL_FILE utility to detect whether the database functions from the VMS_FUNCTIONS.SQL procedure were defined in the database. Added is the detection of an IDENTITY column in a table to use as the Loader MapKey if neither a Primary Key constraint or a unique index is defined on a table. Added translation of a DCL symbol of the format JCCLML_<table name> where if the value is "IDONLY", will set the replication mode to "insert,delete" for the table.
