Databridge 6.6 Service Pack 1 Update 3 Release Notes

Unlike 6.6 SP1 Update 2, which provided containers for both e-modes Delta (LEVEL5) and Eta (LEVEL6), Update 3 provides only an e-mode Eta container.

A container for e-mode Delta is available on-demand, should it be required.

Support for MCP and DMSII SSR level 60.0 (version 19)

Audit files are read without using DBPlus or DMAuditLib

Added DBTwin support for reformatted (redacted) data items.

Host software Hot Fixes and Service Packs are now installed using the same technique as installing the base release.

DBTwin did not correct advance the audit location when tracking updates.

The AUDIT ON PRIMARY option uses the secondary audit file, when available, rather than the primary audit file.

DBSupport is not automatically compiled when the LINKS option changes. This patch requires DBSupport 6.6.2.002 or later.

With DBSupport 6.6.2.002, it is possible to receive a premature notification of a database reorganization.

The second link item in a record has an incorrect error when cloned.

The item offset for a remap of extended variable format data set is wrong.

Remote file reads were not caught.

DBInfo (FindQPT mode) can now be run as a COMS remote window application by using TASKVALUE=6.

Support for Windows Server 2019

Support for SQL Server 2017

Support for Oracle 18c on Windows, AIX, Linux, and Solaris platforms

Developed the Databridge Kafka (big data) Client for Linux platforms. The new component is available in the Kafka folder of the release medium.

The new load balancing algorithm, which was implemented in 6.5 SP1, has completely replaced the old algorithm. This code no longer uses past update rate history in balancing the load, which eliminates the need to maintain this information in DATATABLES.

The SQL Server and Oracle clients work with cloud databases.

To be able to use Oracle in the cloud, the Client was modified to eliminate the need for the GRANT of SELECT on SYS.OBJ$.

The SQL Server Client was modified to use the BCP API during data extraction instead of using the bcp utility. The 6.6 release also supports using the bcp utility as a fallback in case there are problems with the BCP API.

You can make the Client use the bcp utility for all data extractions during a run by adding the /l option to the command line. Alternatively, you can force the Client to use the bcp utility for problem data sets by setting the bit 0x1000000 in the ds_options column of the corresponding DATASETS table entries.

The BCP API combined with multi-threaded updates is considerably faster than using the bcp utility, because it eliminates the use of temporary files and uses BCP API calls to do bulk inserts into the tables.

The SQL Server Client's update processing code was modified to use native host variables instead of character variables, which required the database access routines to do type conversion. This change and the change to use the BCP API were done as a first step towards supporting transparent column encryption (known as "always encrypted"), because the ODBC drivers, which do the encryptions, do not support data conversions.

To increase speed, multi-threaded updates were extended to the data extraction code, which can now run multi-threaded. Both of these are controlled by the parameter n_update_threads.

The clients have the ability to control the order in which data sets get extracted. This is done by using the extract_priority column in the DATASETS table.

The -n option was added to the reorg command to facilitate the handling of DMSII reorganizations in a multi-sourced database environment.

The SQL Server and Oracle Clients were enhanced to recognize database errors that indicate that the connection to the database was lost. Previously these errors were treated as SQL errors, which caused the service to disable the data source. The Client uses exit code 2089 in this situation. The service then periodically tries to restart the client until the database comes back online.

The lower limit for the second value of the "sql_exec_timeout" parameter was reduced to 30 seconds to allow for faster recovery from hung SQL updates.

UNIX clients could hang when a log switch occurred soon after midnight when the parameter logsw_on_newday was set to true.

When recoverable errors occur multiple times in runs that get relaunched by the service, the retry counter does not get reset. This leads to the data source getting disabled when the retry count reaches max_retries (3 by default) even though the client got past the point in the audit trail that caused the error. To mitigate this problem we implemented an unsolicited IPC message that allows the client to notify the service that the client has recovered from the error.

Modified the dbutility error recovery for failed process commands to work in the same way as the service initiated error recovery.

Windows clients did not allow members of the administrator group specified, in the registry, to run the client when their userid did not match the userid in the registry.

The client looped when file security was enabled and the attempt to create a security ACL for the the log file failed.

The SQL Server client got a SQL error when processing a numeric item that did not allow NULL and contained an undigit (i.e. a digits that had a value greater than 9).

The client occasionally creates faulty SQL when updating an OCCURS table without using stored procedures. This happens when one of the rows that is be to stored did not previously exist and the values of one or more columns of the record are null.

The Oracle client generates bad SQL for DELETE operations involving indexes that contain dates, which causes the client to stop. This happens only when the data set is configured to not use stored procedures for doing updates.

The writing of binary configuration files when the string pool area was full resulted in data corruption. This error only occurs when the configuration file has a lot of string data.

The SQL Server client crashes during data extraction when using the BCP API if the last column in a table is an int that has the NOT NULL attribute and its corresponding DMS item is a NUMBER(8). This will probably also happen during update processing as the same code is involved.

Added the parameter sasl_kerberos_kinit_cmd to allow the Kerberos kinit command to be customized to meet site requirements.

The SQL Server client, when run single-threaded, gets a bounds error in some rare situations when processing updates. This happens when the host variable storage requirements for the widest table exceed the computed size for storage block that is used in updates. When using multi-threaded updates, this situation does not occur because each table has its own host variable storage, which is correctly sized.

Increased the size of the text configuration file input buffer to handle lines that are longer than 255 characters for the Kafka client. This change allows the kafka_brokers parameters to accommodate more brokers.

Modified UNIX clients to handle hung queries like the Windows clients do. If the OCIBreak() call hangs, we kill then run using a kill() function. This yields an 8-bit exit code of 137. If the SQLCancel works, the client exits with an exit code of 2058; the 8-bit UNIX exit code for it is 207.

Modified the EBCDIC to ASCII translation code for the Kafka Client to handle special characters (such as double quote) in strings that need to be changed to two-character sequences that use “\” as the force character.

Implemented the configuration file parameter suppress_delete_msgs that when set to True stops the Client from reporting data errors for DELETE operations that result in discards.

The Client ignores such discards, as the target records cannot be in the relational database because they have keys with data errors, they are not included in the discard count and they are not written to the table's discard file.

The service now resets the retry count when it gets a message from the client indicating that it is no longer getting an error. This patch fixes the bookkeeping error of the retry count for relaunched client.

The service occasionally crashed after receiving a BCNOTIFY request to launch a script.

Modified the service to not check the password for a console connection that originates from the 7.0 console, because it does its own password checking and passes the service an empty password.

The Client Manager Service was modified to support the 7.0 SP1 Administrative Console.