Introduction

This chapter describes the concepts and features of the TDL (Tmax Dynamic Library).

1. Overview

TDL (Tmax Dynamic Library) uses dynamic library linking which an OS provides to support seamless updates of frequently changed application modules.

Such dynamic application modules must be built in the form of shared libraries. The version is assigned during updates using the TDL management tools, allowing both old and new versions to be used simultaneously. A developer must call modules through the tdlcall() function which uses the most recent version of the module to convert the old version into the new version seamlessly.

figure 1 1
TDL(Tmax Dynamic Library) Structure

2. TDL Features

TDL provides the following features.

  • Manages version information using shared memories.

    TDL must maintain information about each library version, which will be stored in shared memories as the information must be used when the Tmax server or client program uses tdlcall(). Accordingly, TDL is available to use in local Tmax clients and $TDLDIR environment variables must be configured.

  • Supports version consistency.

    As TDL updates during operation, the old and new versions can be used concurrently. Applications bound to a transaction or batch applications must use the module with the same version. For this, TDL supports version consistency. There are explicit version consistency and implicit version consistency.

    • Explicit Version Consistency

      Explicit version consistency enables the same version used through APIs such as tdlstart(), tdlend(), tdlsuspend(), and tdlresume().

      figure 1 2
      Explicit Version Consistency

    • Implicit Version Consistency

      Implicit version consistency automatically enables the same version used for applications bound to a transaction. To use this function, TDL parameters must be set to the DOMAIN or NODE clause.

      figure 1 3
      Implicit Version Consistency

  • The recursive call ensures the consistency of module.

    When a user calls a module recursively, module updates must be prevented before calling the function is complete. For this, a module has a reference count, which increases whenever the module is called and decreases when the call is complete. If the reference count is not zero, this prevents the module from being updated or released from memory.

  • Supports various management tools.

    Supports management tools for TDL initialization and updates, information about the shared memory version and status, statistics inquiry, and deleting the older version of files. For detailed information about the management tools, refer to System Management Tools.

  • Supports error logging and backup.

    Can leave logging for errors and information that occur when using management tools and API. To log errors, configure a LOGDIR parameter of the TDL environment file ($TMAXDIR/config/tdl.cfg).

    Supports a file backup service for shared memory to load from the backup file when the equipment fails or restarts. To specify a backup file, configure a BACKUP parameter of the TDL environment file ($TMAXDIR/config/tdl.cfg).

  • Supports a multi-node environment.

    TDL basically supports the TMAX multi-node environment. There are two types of architectures: a master-slave architecture, each with its own TDL environment, and a shared architecture, where TDL is shared across shared disks and other paths. In the master-slave architecture, only one master node must exist among multiple nodes, and the rest must be designated as slave nodes.

    In versions prior to Tmax 5 SP2 Fix#1, tools such as tdlinit and tdlupdate could only be executed on the master node. Starting from Tmax 5 SP2 Fix#2, tdlupdate can be executed in a master-slave architecture. For a shared structure, all nodes use the same TDLDIR environment variable and the tdl.cfg environment configuration file in the same location, and only the node designated as master copies or deletes files in the mod and run directories. In addition, backup files for TDL shared memory are forcibly created and managed, with creation and modification restricted to the master node. Version control for shared memory and modules works the same way as in the master-slave architecture.

    To use a multi-node environment, all nodes must configure the TDL environment. If there is a node that does not use the TDL environment, the RACFILE parameter in the TDL environment file ($TMAXDIR/config/tdl.cfg) must be specified.

    To use multi nodes, racd must be run on all the nodes. For detailed information about racd, refer to Tmax Administration Guide.

  • Supports the TDL domain.

    Multiple TMAX domains can be set to a single TDL domain in TDL. It is necessary for an environment where a TDL module must be used commonly over the domain. But, to use the TDL domain, racd must be used. Accordingly, the DOMAINID and RACFILE parameters in the TDL environment file ($TMAXDIR/config/tdl.cfg) must be specified.

    In particular, the DOMAINID parameter must be specified differently if the TDL domain is different. If the DOMAINID value is not configured, it is automatically set to zero. When the TDL domain is used, racd must be run on all the nodes.

    The TDL domain is closely related with the library version consistency. Explicit version consistency is guaranteed only within the TDL domain. Implicit version consistency automatically makes the consistency maintained per domain if the TDL domain is different.

    figure 1 4
    TDL Domain Composition