Another Upgrade Issue: The TDB

Updated: Sep 21, 2018

by David Hallberg

Although I have blogged before on issues that might be overlooked during a Millennium® upgrade, a recent discussion with a client revealed another issue: one with the transaction database (TDB). A common oversight in this area might need a simple fix.

The TDB is a flat file found on each Millennium application node that tells the executables (application servers) what transactions they can process and if the transactions are Request/Reply (RR), Reliable Delivery Message (RDM) or Remote Procedure Call (RPC). Let me start with some background on these three types:

  • With RR transactions, the clinical information remains intact even if the transactions are lost or discarded. For instance, using CPM Script to retrieve or read data from the database is an RR transaction. If the transaction is lost, the person asking for the information just has to ask for the information again.

  • An RDM transaction is like an order. If the client crashes or the application executable or application node fails, there has to be a mechanism in place to recover or replay that transaction when the system is fully functional again.

  • The RPC transaction was added with Millennium 2007.x. It allows the Java servers and Java client applications to process transactions originating from both the local hardware and remote calls. It was the first extension to the Common Request Model in quite some time.

Until recently, the TDB was a connection-based service. PowerChart or the front-end application connected directly to the TDB’s port. The TDB is now a shared service. The TDB server communicates with Citrix servers and fat clients over a network port that it allocates when it starts up. Once the communication port is selected or opened, the TDB server tells the Millennium Service Manager on the application node which port it will be listening to for incoming transactions (requests). The Citrix servers and fat clients must be on the same code level as the application node so that when PowerChart or any front-end Millennium application starts up, it will connect to the Service Manager and be told what port to use to connect with the TDB.

I have found that sometimes during an upgrade, the fat clients or outlying Citrix servers are overlooked. In the case of the TDB, fat clients and Citrix servers that aren’t upgraded might be connecting to the wrong port. If a connection fails because the TDB was not listening on that port, the Service Manager logs a message stating that event CMB_ServiceUnavail1Net occurred. The service name (such as TDB_SYSTEM@PROD) is logged, the Citrix server or fat client’s TCP/IP address is included, and the port the client was trying to communicate with is logged. You can see these messages by looking in the cmb_0000 message log and search for the event CMB_ServiceUnavail1Net.

An example would look something like this:

The message under the Record column indicates that the Citrix server or fat client whose TCP/IP address is is trying to communicate with the TDB on port 1240. Because this happened after a Millennium upgrade, the client just has to use tracert or traceroute (depending on your operating system) to find out how far the problem server or client is from the application node, i.e., how many network router hops you have to make. The Citrix server or fat client needs to be scanned for components after the Millennium client upgrade in order to be in sync with the newer application node code. This is the most common problem and is simple to correct.

Prognosis: Reviewing message logs after an upgrade can highlight issues that make Millennium appear unusable or unstable to the clinicians whose Millennium servers or fat clients have not been upgraded.

  • Grey LinkedIn Icon
  • Grey Twitter Icon
  • Grey Facebook Icon
  • CernerUsersIcon

4500 West 89th Street

Prairie Village, KS 66207

Phone: 913.649.1024

© 1995 - 2020 Softek Solutions, Inc.

All rights reserved.

Cerner®, Cerner Millennium®, and Cerner Smart Hospital® are all registered trademarks of Cerner Corporation, or its subsidiaries or divisions, registered in the US and other countries, and Softek makes no claim in or to the same. Cerner Corporation is not affiliated with Softek and does not endorse or sponsor our products or services.