GT.M V5.3-002 — 64-bits on x86_64 Sun SPARC Solaris

Release Notes: GT.M 5.3-002

Legal Notice

August 18, 2008

Revision History
Revision 1.3February 19, 2009

Revision 1.2September 16, 2008
Revision 1.1September 11, 2008
Revision 1.0August 18, 2008

First published version.



                        GT.M Group

                        Fidelity National Information Services, Inc.

                        2 West Liberty Boulevard, Suite 300

                        Malvern, PA 19355

                        United States of America

                     



GT.M Support: +1 (610) 578-4226

Switchboard: +1 (610) 296-8877

Fax: +1 (484) 595-5101

Website: http://fis-gtm.com

Email: gtmsupport@fnis.com 



Table of Contents

Typographical Conventions
Bulletin Overview
Platforms
Migrating to 64-bit platforms
Call-ins and External Calls
Internationalization (Collation)
Environment Translation
Recompile
Rebuild Shared Libraries or Images
Additional Installation Instructions
UNIX
OpenVMS
Database Compatibility for GT.M V5.3-002
General Principles
Database Files
Global Directory
Journal Files
Replication Instance File
Managing M mode and UTF-8 mode
Setting the environment variable TERM
Change History
V5.3-002
M-Database Access
M-Other Than Database Access
Utilities- MUPIP
Utilities-Other Than MUPIP
Error Messages
GTMSECSHRTMPPATH
DBFHEADERR4
DBFHEADERR8
LITNONGRAPH
MMBEFOREJNL
UPDREPLSTATEOFF

Return to top

Typographical Conventions

Command Syntax: UNIX syntax (that is, lowercase text and "-" for flags/qualifiers) is used throughout this document. OpenVMS accepts both lowercase and uppercase text; flags/qualifiers on OpenVMS should be preceded with "/".

Reference Number: The reference numbers used to track software enhancements and customer support requests appear in parentheses ().

Platform Identifier: If a new feature or software enhancement does not apply to all platforms, the relevant platform or platforms appear in brackets [ ].

Return to top

Bulletin Overview

Effective in V5.3-002 GT.M processes on Sun SPARC Solaris are 64-bits, completing the planned support for 64-bit architectures. Henceforth:

  • GT.M processes are 64 bits on - x86_64 GNU/Linux; Sun SPARC Solaris; IBM pSeries AIX; HP Itanium HP-UX and Linux. On 64-bit architectures, object modules generated by GT.M can be placed in standard UNIX/Linux shared libraries by the standard system loader ld.
  • GT.M processes are 32-bits on - x86 GNU/Linux; HP PA-RISC HP-UX; HP Alpha/AXP Tru64 UNIX and OpenVMS. Except for x86 GNU/Linux, on 32-bit architectures, object modules generated by GT.M can be placed in standard UNIX/Linux shared libraries by the standard system loader ld, or be incorporate into standard OpenVMS executable (.EXE) images.

Note that 32- and 64-bits refers to GT.M processes. 64-bit operating system kernels run 32-bit processes (for example, 32-bit GT.M for x86 GNU/Linux runs very well on x86_64 GNU/Linux) and in some cases 32-bit OS kernels run 64-bit processes as long as the underlying hardware supports it (for example, 32-bit IBM pSeries AIX kernels on 64-bit CPUs can run the 64-bit GT.M for that platform).

V5.3-002 introduces more fine-grained critical sections for committing updates to the database. Under heavy update loads, we expect this will improve performance.

This release includes a field test grade implementation of the MM (Mapped Memory) database access method for UNIX/Linux. (The field test designation refers only to the new MM access method for UNIX/Linux. V5.3-002 is a fully tested and qualified, production grade GT.M release that is at least as robust as, if not more robust than, any previous GT.M release).

V5.3-002 provides improved journaling capabilities, enhanced support for Unicode, and various improvements in MUPIP, LKE, and DSE utilities. V5.3-002 also generates more compact code for the Linux on x86_64.

For more information on the fixes and enhancements in this release, see section Change History.

[Note]
Placing databases on raw partitions is no longer supported, and references thereto will be removed in the next update to the user documentation. Although the GT.M team is fastidious about maintaining upward compatibility, in this case, we are aware of no customer who is using GT.M on a raw partition. If you are a GT.M customer using raw partitions for GT.M databases, please contact GT.M Support (gtmsupport@fnis.com) as soon as possible.

Return to top

Platforms

As of the publication date, FIS supports this release on the following hardware and operating system versions. Contact FIS for a current list of supported platforms.

Platform

Supported Versions

Notes

Hewlett-Packard Integrity IA64 HP-UX

11V3(11.31)

-

IA64 GNU/Linux - Red Hat Enterprise Linux

Red Hat Enterprise Linux 5.2

GT.M should also run on recent releases of other major Linux distributions with a contemporary 2.6 Linux kernel, glibc (version 2.5-24 or later) and ncurses (version 5.5-24 or later). We have verified that GT.M passes comprehensive testing on RHEL 5.x on machines that have single cells (no more than 8 CPUs). Multi-cell machines are not considered viable until they certified.

Hewlett-Packard HP-PA HP-UX

11.11

GT.M supports UTF-8 mode and M mode on this platform subject to the following:

[Tip]
While GT.M should support both UTF-8 mode and M mode on this platform, there are problems with the version of HP-UX that we currently use for supporting HP-UX that prevent FIS from testing 4 byte UTF-8 characters in UTF-8 mode on the HP PA-RISC HP-UX platform. FIS understands that the issue is resolved in HP-UX 11.31. At this time, HP-UX 11.31 is not formally supported (as it is untested); however, there is no identified reason that would prevent GT.M V5.2-000 (and above) from working correctly on that newer version.

Running GT.M on HP-UX 11i requires that patch PHKL_28475 be applied to the system. This patch fixes a problem with the lseek64() C library call that GT.M uses. A system without this patch gives fairly consistent database errors of varying types, structural damage, and in general does not work correctly for any but the most simplistic usage. The "swlist -p" command (as root) can be used to determine if this patch has been applied. Note that recent "BATCH" and "GOLDEN" patches may contain this patch therefore your system may already have this patch applied but may not list it separately. Contact an HP service representative for more information.

Hewlett-Packard Alpha/AXP Tru64 UNIX

5.1B

GT.M supports M mode but not UTF-8 mode on this platform.

Hewlett-Packard Alpha/AXP OpenVMS

7.3-1/7.3-2/8.2

GT.M supports M mode but not UTF-8 mode on this platform.

Although OpenVMS 8.3 remains an officially unsupported release until GT.M is tested on it, we are not aware of any reason that GT.M V5.3-002 would not run on it.

If you need to work with external calls written in C with Version 6.x of the Compaq C compiler on Alpha OpenVMS, then you must carefully review all the provided kits for that product and apply them appropriately.

IBM eServer pSeries AIX

5.2/5.3

Since GT.M processes are 64-bits, FIS expects 64-bit AIX configuration to be preferable.

Although AIX 5.2 and 5.3 are the officially supported releases, we are not aware of any reason why GT.M V5.3-002 will not run on AIX 6.x.

[Tip]
While GT.M supports both UTF-8 mode and M mode on this platform, there are problems with the AIX ICU utilities that prevent FIS from testing 4-byte UTF-8 characters as comprehensively on this platform as we do on others.

Sun SPARC Solaris

9 (Update 3 and above) and 10

GT.M supports the deprecated DAL calls in M mode but not in UTF-8 mode.

x86_64 GNU/Linux

Red Hat Enterprise Linux 5.2; Ubuntu 7.10 (Gutsy Gibbon) and 8.04 (Hardy Heron)

To run 64-bit GT.M processes requires both a 64-bit kernel as well as 64-bit hardware.

GT.M should also run on recent releases of other major Linux distributions with a contemporary 2.6 Linux kernel, glibc (version 2.5-24 or later) and ncurses (version 5.5 or later).

x86 GNU/Linux

Red Hat Enterprise Linux 4

This 32-bit version of GT.M runs on either 32- or 64-bit x86 platforms; we expect the X86_64 GNU/Linux version of GT.M to be preferable on 64-bit hardware.

GT.M should also run on recent releases of other major Linux distributions with a contemporary 2.6 Linux kernel, glibc (version 2.3.4-2 or later) and ncurses (version 5.4-1 or later). The minimum CPU must have the instruction set of a 686 (Pentium Pro) or equivalent. Contact FIS for support of older CPUs.

Return to top

Migrating to 64-bit platforms

The same application code runs on both 32-bit and 64-bit platforms. Please note that:

  • You must compile the application code separately for each platform. That is, although the M source code is exactly the same, the generated object modules are different.
  • Parameter-types that interface GT.M with non-M code using C calling conventions must match the data-types on their target platforms. Mostly, these parameters are for call-ins, external calls, internationalization (collation), and environment translation and are listed in the tables below. Note that most addresses on 64 bit platform are 8 bytes long and require 8 byte alignment in structures whereas all address on 32-bit platforms are 4 bytes long and require 4-byte alignment in structures.

Call-ins and External Calls

Parameter type

32-Bit

64-bit

Remarks

gtm_long_t

4-byte (32 bit)

8-byte (64 bit)

gtm_long_t is much the same as the C language long type, except on Tru64 UNIX, where GT.M remains a 32-bit application.

gtm_ulong_t

4-byte

8-byte

gtm_ulong_t is much the same as the C language unsigned long type.

gtm_int_t

4-byte

4-byte

gtm_int_t has 32 bit length on all platforms.

gtm_uint_t

4-byte

4-byte

gtm_uint_t has 32 bit length on all platforms

[Caution]
If your interface uses gtm_long_t or gtm_ulong_t types but your interface code uses int or signed int types, failure to revise the types so they match on a 64 bit platform will cause the code to fail in unpleasant, potentially dangerous and hard to diagnose ways.

Internationalization (Collation)

Parameter type

32-Bit

64-bit

Remarks

gtm_descriptor in gtm_descript.h

4-byte

8-byte

Although it is only the address within these types that changes, the structures may grow by up to 8 bytes as a result of compiler padding to meet platform alignment requirements.

[Important]
Any collation routines require only a recompile, assuming other aspects of their code are 64 bit capable.

Environment Translation

Parameter type

32-Bit

64-bit

Remarks

gtm_string_t type in gtmxc_types.h

4-byte

8-byte

Although it is only the address within these types that changes, the structures may grow by up to 8 bytes as a result of compiler padding to meet platform alignment requirements.

[Important]
Any environment translation routines require only a recompile, assuming other aspects of their code are 64 bit capable.
[Note]
Although any existing M code must be compiled for the 64-bit environment, the source is unchanged from 32-bit environments.

Return to top

Recompile

  • Recompile all M and C source files.

[Warning]
On all Linux platforms, the GT.M compiler fails with a GTM-E-OBJFILERR error when it attempts to place the object modules on an NFS-mounted file system. The workaround is to avoid compiling GT.M on NFS file systems; however you can move object modules to an NFS-mounted system after successful compilation. FIS will address this in a future release. (C9H10-002924)

Return to top

Rebuild Shared Libraries or Images

  • Rebuild all Shared Libraries (Unix) or Shareable Executable Images (OpenVMS) after recompiling all M and C source files.

Return to top

Additional Installation Instructions

For installing GT.M, see the "Installing GT.M" section in the GT.M Administration and Operations Guide.

UNIX

  1. Fidelity strongly recommends installing each version of GT.M in a separate (new) directory, rather than overwriting a previously installed version. If you must overwrite an existing GT.M installation with a new version you must first shut down all processes using the old version. Since GT.M has now been assigned the package name lsb-gtm by the Linux Assigned Names and Numbers Authority (http://lanana.org), it would be appropriate to install GT.M V5.3-002 in /opt/lsb-gtm/V5.3-002 on Linux systems.

  2. Use the MUPIP RUNDOWN command of the old GT.M version to ensure all database files are cleanly closed.

  3. In UNIX editions, make sure gtmsecshr is not running. If gtmsecshr is running, first stop all GT.M processes including the DSE, LKE and MUPIP utilities and then perform kill <pid of gtmsecshr >.

    [Caution]
    Never replace the binary image on disk of any executable file while it is in use by an active process. It may lead to unpredictable results depending on the operating system. These results include but are not limited to the denial of service (that is, system lockup) and damage to files that these processes open (that is, database structural damage).
Additional Information for AIX

GT.M for IBM pSeries AIX requires the Asynchronous IO facility to be available and configured. Before installing GT.M on IBM pSeries AIX, run the following command to check the filesets of this facility:

  • lslpp -l bos.rte.aio

If there are no filesets, then install them from AIX installation media.

Then, use SMIT to configure the Asynchronous IO facility. Use SMIT in one of the following modes:

  • smit aio (for gui mode) or

  • smitty aio (for text mode)

Select "Configure AIO now" which gives a message such as "aio0 has been created". This means that there is no further need of setup at this time.

For system with a "posixaio" option instead of "aio", use SMIT in one of the following modes:

  • smit posixaio (for gui mode) or

  • smitty posixaio (for text mode)

In addition to configuring the aio0 device, select "Change/Show characteristics of Asynchronous I/O" then change the value of "State to be configured at system restart" from "defined" to "available". This ensures that the aio0 device is available when the system is next rebooted.

If you expect a database file to exceed 2GB, then you MUST configure its file system to permit files larger than 2GB. Since journal files can grow to a maximum size of 4GB, you MUST set the journal auto switch limit to less than 2 GB should you choose to place journal files on file systems with a 2GB limit.

OpenVMS

To upgrade from a GT.M version prior to V4.3-001, you must update any customized copy of GTM$DEFAULTS to include a definition for GTM$ZDATE_FORM.

You can ignore the following section if you choose the standard GT.M configuration or answer yes to the following question:

Do you want to define GT.M commands to the system

If you define GT.M commands locally with SET COMMAND GTM$DIST:GTMCOMMANDS.CLD in GTMLOGIN.COM or other command file for each process which uses GT.M, you must execute the same command after installing the new version of GT.M before using it. If you define the GT.M commands to the system other than during the installation of GT.M, you must update the system DCLTABLES with the new GTMCOMMANDS.CLD provided with this version of GT.M. See the OpenVMS "Command Definition, Librarian, and Message Utilities Manual" section on "Adding a system command." In both cases, it is important for each process to match the proper GTMCOMMANDS.CLD with the version of GT.M it runs.

Return to top

Database Compatibility for GT.M V5.3-002

The GT.M database consists of four types of components-database files, journal files, global directories and replication instance files. Whenever you upgrade to a new GT.M release, you may need to execute certain upgrade procedures on one or all four components to make your database compatible with your new GT.M release. For example, although the database and journal file formats remain unchanged when you upgrade an instance from 32-bit GT.M V5.3-002 x86 Linux to 64-bit GT.M V5.3-002 x86_64 Linux, you need to:

  • Upgrade global directory files.

  • For secondary instances, create new instance files and restart the receiver server with the UPDATERESYNC qualifier.

The following subsections describe the upgrade procedures for each of these 4 components. Whenever you upgrade to a new GT.M release, you should always refer to these subsections to check how your GT.M upgrade impacts each database component and then execute the relevant procedures to make your database compatible with your new GT.M release.

General Principles

  • A change in major release identifier (for example V4 to V5) signifies a change in database block format.  Although FIS tries to minimize the effort involved in upgrading, changes in block format may require special procedures and planning.

  • Changes to the database file header may occur in any release.  GT.M upgrades to database file headers as needed.  Any changes to database file headers are upward and downward compatible within a major database release number, that is, although processes from only one GT.M release can access a database file at any given time, processes running different GT.M releases with the same major release number can access a database file.

  • Journal format changes always occur with a major releases numbers, but may occur in any release. Simply create a new backup with fresh journal files. Recovery by one GT.M release, using journal files created by another GT.M release is not supported and is not necessary if you follow recommended procedures.

  • Global directory and instance file changes occur as needed. GDE typically upgrades global directories whenever it opens (and rewrites) an older version.  FIS recommends that you retain readable scripts to recreate your global directories.

  • Instance file formats are recreated with MUPIP when documented in the release notes.  For secondary instances, a new instance file requires the receiver server to be shut down cleanly with the prior GT.M version and restarted with the UPDATERESYNC qualifier the first time using the new GT.M version.

Database Files

From prior to V5.0-000 to V5.3*

To upgrade from a GT.M version prior to V5.0-000, including field test versions prior to V5.0-000, you need to perform a database file upgrade. See Database Migration Technical Bulletin (Database Migration Technical Bulletin) for more information.

[Note]
The global directory in use at the time of database upgrade MUST have a mapping of globals to database files that includes ALL globals that are actually resident in those database files. If you use a global directory that does not map all the global variables in a database file, the database upgrade procedure fails because database certification does not correctly process all the database file. If this happens, a subsequent MUPIP REORG -UPGRADE or a GT.M process can fail with the DYNUPGRDFAIL message after the V5 upgrade.

After you complete the database upgrade procedure, execute the MUPIP REORG -UPGRADE command. This command upgrades all blocks to V5 format and the file header to the current V5.* format.

From V5.0*/V5.1*/V5.2* to V5.3*

No database file upgrade procedure is necessary if you upgrade from GT.M V5.0-000 or later. However, for better database performance on heavily loaded systems and to stop DBVERPERFWARN2 messages in the system log, FIS recommends that you execute the MUPIP REORG -UPGRADE command on ALL the database files after you complete the GT.M installation. On a lightly loaded system, the MUPIP REORG -UPGRADE command may not noticeably improve the performance but it stops DBVERPERFWARN2 messages.

[Note]
When upgrading an existing V5.0-000 or later database, the MUPIP REORG -UPGRADE command upgrades only those recycled database blocks that escaped a MUPIP REORG -UPGRADE operation previously.

Global Directory

Global directory formats differ for 32- and 64-bit GT.M platforms. This means that:

  • The global directory format differs between GT.M on x86 GNU/Linux and that of x86_64 GNU/Linux.
  • On AIX, the global directory format differs between GT.M on V5.3-001 and prior versions.
  • On Solaris, the global directory format differs between V5.3-002 and prior versions.

Furthermore, on Itanium platforms, there is a difference in global directory formats between V5.3-000 and V5.3-001.

Except for the above cases, you do not require a global directory upgrade when moving up from GT.M V5.0-000 or later.

Moving up from a GT.M version prior to V5.0-000, from a 32-bit global directory to a 64-bit global directory, or on Itanium platforms migrating from V5.3-000 to V5.3-001 requires a global directory upgrade. Opening a global directory with the GDE utility program from the latest GT.M version (or the 64-bit x86_64 format for that platform), followed by an EXIT command automatically, even with no other intervening commands, upgrades the global directory.

[Note]
FIS strongly recommends you make a copy of any global directory before upgrading it. There is no way to downgrade a global directory to an earlier format.

If you inadvertently open a global directory in an earlier format, with no intention of upgrading it, execute the QUIT command rather than the EXIT command.

If you inadvertently upgrade a global directory, perform the following steps:

  1. Open the global directory with GDE from the current version.
  2. Execute the SHOW ALL command.
  3. Create a command file, or manually enter the commands corresponding to the output, into GDE from the prior GT.M version.

Journal Files

Always generate new journal files every time you upgrade to a new GT.M release. Your new database cannot share the journal files of the previous version.  Therefore execute a MUPIP SET -JOURNAL command immediately after you upgrade. Since MUPIP cannot recover database files using journal files from a prior GT.M release, FIS recommends backing up database files when upgrading from one GT.M release to another.

Replication Instance File

If you are running a database replication configuration, then you need to recreate the replication instance file using the MUPIP REPLICATE -INSTANCE_CREATE command whenever your upgrade changes GT.M from a 32-bit implementation to a 64-bit implementation (or potentially vice versa on the x86 platform). If your upgrade activity does not change between a 32- and 64-bit implementation then you do not need to recreate the replication instance file. You have to recreate the replication instance file only for the following upgrade scenarios:

  1. On AIX systems, if you upgrade from 32-bit pre-V5.3-001 to 64-bit V5.3-001/V5.3-001A/V5.3-002

  2. On Linux systems, if you upgrade from a 32-bit pre-V5.3-001 to 64-bit V5.3-001/V5.3-001A/V5.3-002 or from a 64-bit V5.3-001/V5.3-001A to a 32 bit V5.3-002

  3. On Sun SPARC Solaris, if you upgrade from 32-bit pre-V5.3-002 to 64-bit V5.3-002.

In these 3 scenarios, your source server process terminates abnormally if you do not recreate the replication instance file. Before recreating the instance file, shut down all receiver servers on other instances looking for updates from this instance, shut down this instance, and then restart the receiver server on this instance with the -UPDATERESYNC qualifier.

[Note]
The UPDATERESYNC qualifier unconditionally synchronizes this secondary instance with the primary.

Unless you are changing from 32- to 64-bits or vice versa, you do not need to recreate the replication instance file. For example, on Linux systems, you do not have to recreate the replication instance file if you upgrade from 32-bit pre V5.3-001 to 32-bit V5.3-001/V5.3-001A/V5.3-002.

Return to top

Managing M mode and UTF-8 mode

GT.M requires International Components for Unicode (www.icu-project.org) version 3.6 in order to enable Unicode support. On a system that does not have ICU 3.6 installed, the GT.M installation only provides support for GT.M M mode.

On a system that has ICU installed, GT.M installs support for both M mode and UTF-8 mode, including a utf8 subdirectory of the directory where GT.M is installed. The following paragraph describes the technique that GT.M uses to separate M mode and UTF-8 mode object files.

From the same source file, depending upon the value of the environment variable gtm_chset, the GT.M compiler generates an object file either for M mode or UTF-8 mode. GT.M generates a new object file when an object file is older than the source file and was generated with the same setting of gtm_chset/$ZCHset. GT.M processes trigger an error if they encounter an object file generated with a different setting of gtm_chset/$ZCHset than the current run-time value.

Always generate an M object module with a value of gtm_chset that matches the value that a process executing that module will have. As the GT.M product contains utility programs written in M, their object files must also conform to this rule. In order to use utility programs in both M mode and UTF-8 mode, the GT.M installation ensures that both M and UTF-8 versions of object modules exist, the latter in the utf8 subdirectory. This technique of segregating the object modules by their compilation mode prevents both frequent recompiles and errors in installations where both modes are in use. You should consider a similar pattern for structuring application object code repositories.

GT.M is installed in a parent directory and a utf8 subdirectory as follows:

  • GT.M executable programs (mumps, mupip, dse, lke, and so on) are in the parent directory, that is, the location specified for installation.

  • Object files for programs written in M (GDE, utilities) have two versions-one compiled with support for Unicode™ in the utf8 subdirectory, and one compiled without support for Unicode™ in the parent directory. Installing GT.M generates both the versions of object files. Note that GT.M generates the object files for utf8 subdirectory if and only if you have a ICU 3.6 installation on your system. You may have multiple versions of ICU installations on your system but GT.M looks only for ICU 3.6 to generate the object files for utf8 subdirectory even if ICU 3.6 is not the current version.

  • The utf8 subdirectory has files called mumps, mupip, dse, and so on, which are relative symbolic links to the executables in the parent directory (for example, mumps is the symbolic link ../mumps).

  • When a shell process sources the shell scripts gtmprofile or gtmcshrc, the behavior is as follows:

    • If gtm_chset is "m", "M" or undefined, there is no change from the previous GT.M versions to the value of the environment variable gtmroutines.

    • If gtm_chset is "UTF-8",

      • $gtm_dist is set to the utf8 subdirectory (that is, if GT.M is installed in /opt/lsb-gtm/gtm_V5.3-001, then $gtm_dist is set to /opt/lsb-gtm/gtm_V5.3-001/utf8).

      • The last element of $gtmroutines is $gtm_dist($gtm_dist/..) so that the source files in the parent directory for utility programs are matched with object files in the utf8 subdirectory.

Use the following instructions to compile ICU on HP PA-RISC HP-UX:

Version: 11.31 (11iv3)

Compiler: cc HP C/aC++ B3910B A.06.12, aCC HP C/aC++ B3910B A.06.15, GNU Make 3.81

  1. Ensure that system environment variable PATH includes the location of all the compilers mentioned above.

  2. Download the source code of ICU version 3.6 for C from http://icu.sourceforge.net/download/3.6.html#ICU4C

  3. At the shell prompt, execute the following commands:

    gunzip -d < icu4c-3_6-src.tgz | tar -xf - 
    cd icu/source/
    chmod +x runConfigureICU configure install-sh
    runConfigureICU --enable-debug HP-UX/ACC --enable-64bit-libs  --enable-rpath –disable-threads
    gmake
    gmake check
    gmake install
    
  4. Set the environment variable LD_LIBRARY_PATH to point to the location of ICU. HP-UX uses the environment variable LD_LIBRARY_PATH to search for dynamically linked libraries to be loaded.

ICU is now installed in the /usr/local directory.

[Note]
By default, ICU is installed in /usr/local. If you install ICU in a different directory, type:
  • runConfigureICU HP-UX/ACC --prefix=<install_path> --enable-64bit-libs  --enable-rpath –disable-threads 
  • Then execute the gmake commands, and set the environment variable LD_LIBRARY_PATH to point to the appropriate location.

Return to top

Setting the environment variable TERM

The environment variable TERM must specify a terminfo entry that accurately matches the terminal (or terminal emulator) settings. Refer to the terminfo man pages for more information on the terminal settings of the platform where GT.M needs to run.

[Important]

Some terminfo entries may seem to work properly but fail to recognize function key sequences or position the cursor properly in response to escape sequences from GT.M. GT.M itself does not have any knowledge of specific terminal control characteristics. Therefore, it is important to specify the right terminfo entry to let GT.M communicate correctly with the terminal. You may need to add new terminfo entries depending on their specific platform and implementation. The terminal (emulator) vendor may also be able to help.

GT.M uses the following terminfo capabilities. The full variable name is followed by the capname in parenthesis.

auto_right_margin(am), clr_eos(ed), clr_eol(el), columns(cols), cursor_address(cup), cursor_down(cud1), cursor_left(cub1), cursor_right(cuf1), cursor_up(cuu1), eat_newline_glitch(xenl), key_backspace(kbs), key_dc(kdch1), key_down(kcud1), key_left(kcub1), key_right(kcuf1), key_up(kcuu1), key_insert(kich1), keypad_local(rmkx), keypad_xmit(smkx), lines(lines).

GT.M sends keypad_xmit before terminal reads for direct mode and READs (other than READ *) if EDITING is enabled. GT.M sends keypad_local after these terminal reads.

Return to top

Change History

Return to top

M-Database Access

  • GT.M journaling logic now recovers from additional runtime errors. If the control structures in the journal buffer (in database shared memory) get set to invalid values (such as unanticipated, out-of-design condition), GT.M journal buffer flushing logic detects this situation, turns OFF journaling right away and sends appropriate messages to the syslog (operator log in VMS). Subsequent updates to the database continue to work without any issues. Previous versions of GT.M used to hang for minutes trying to recover from this situation and terminate unlucky processes abnormally with GTMASSERT errors. In addition, processes could try writing to non-allocated portions of the journal file, which in turn caused a flood of JNLACCESS messages in the operator log. (S9D11-002394, S9I07-002690)

  • This release includes a field test grade implementation of the MM (Mapped Memory) database access method for UNIX/Linux. The OpenVMS editions of GT.M previously supported MM and continue to do so unchanged. The MM access method maps database files (with the mmap() system call) to the address space of all processes accessing the corresponding MM region, thereby using the operating system to manage traffic between memory and disk rather than using the global buffer pool as in the Buffered Global (BG) access method. Note that before image journaling and backward recovery require that before-image journal records be committed to disk before the corresponding database updates are committed. Since this is not possible with MM, before-image journaling, and consequently mupip backward recovery/rollback to recover a database without a restore are not available with MM. Attempts to use MM with before image journaling produce an error. The MM access method supports nobefore_image journaling and mupip forward recovery, as well as mupip journal rollback with the -resync or -fetchresync qualifiers to generate lost and broken transaction files. The implementation of MM on UNIX/Linux allows databases to extend dynamically, as they do with BG; as before, the implementation of MM on OpenVMS does not permit dynamic database file extension. The MM access method may provide a performance advantage in situations where its restrictions are acceptable. Although we do not yet recommend this feature in production (the next GT.M release will make MM fully Supported), we encourage you to try it in appropriate development, testing and benchmarking environments and to tell us how it works for you – especially about any issues you encounter and any performance gain you experience. Note that the field test designation refers only to the new MM access method for UNIX/Linux. V5.3-002, including MM for OpenVMS, is a fully tested and qualified, production grade GT.M release that is at least as robust as, if not more robust than, any previous GT.M release. [UNIX] (C9904-001024)

  • The Linux version of GT.M can now utilize O_DIRECT support for journal files. The O_DIRECT option is made available by using the sync_io option to the MUPIP SET -JOURNAL command just as for the other platforms that support direct I/O. [Linux] (C9D10-002409)

  • The 'VIEW "FLUSH"' (originally introduced in V5.0-000), now always flushes all dirty buffers from the global buffer pool. Previous versions might only do a partial flush. (C9E02-002525)

  • GT.M now correctly maintains the database file corresponding to $REFERENCE even in case of runtime errors during TCOMMIT or ZTCOMMIT where those transactions reference multiple regions. In previous versions, GT.M maintained $REFERENCE correctly but could leave it associated with an incorrect database file. This meant that if the next global reference inside of the error-trap routine is the same as $REFERENCE at the time of the runtime error, GT.M could return incorrect values and/or report false errors (for example, it could report GVUNDEF errors on a global node that existed). (C9F03-002709)

  • GT.M now performs database commits in two phases. Phase 1 consists primarily of transaction (TP or mini/non-TP) validation and journal management while the process holds the critical section on the database region. Phase2 performs the actual block updates under block locks after the release of the region critical section. By reducing the per-transaction time that a transaction holds the region critical section, this change improves database transaction throughput under conditions of contention. In prior versions GT.M did all transaction commit work while holding the critical section.

    GT.M now better maintains database integrity throughout a database update operation even when it encounters an error in the middle of committing the update. Prior versions used to complete the database commit operation under these unusual circumstances, but in cases such as where the error occurred in the middle of a TP transaction that did KILLs of globals, it could result in a variety of errors including database structural damage.

    GT.M now better protects against abnormal process termination. Previous versions of GT.M could in very rare cases issue GVxxxFAIL or TPFAIL errors if one or more other processes terminated abnormally or were stopped using a MUPIP STOP.

    GT.M now writes correct checksums in the journal file. Every journal record in the journal file has a checksum field. With before-image journaling, it was possible in very rare cases that GT.M would write a before-image journal record with an incorrect checksum value. This would cause MUPIP RECOVER/ROLLBACK to issue a "Checksum validation failed" error. Similar issues were fixed in GT.M V5.0-000D as part of C9F10-002762 and in GT.M V5.3-000 as part of C9B11-001813 but there were a few very rare cases that were not. These are now fixed.

    GT.M now works more correctly when VIEW "GDSCERT" is turned on. In previous versions, in rare cases it was possible to get GTMASSERT errors when VIEW "GDSCERT" was turned on with TP transactions and a high contention in the database (for example, with MUPIP REORG concurrently running).

    MUPIP INTEG -REGION works correctly when a MUPIP SET -VERSION or MUPIP REORG UPGRADE/DOWNGRADE runs at the same time. In previous V5 versions, in rare cases it could incorrectly issue a DBTNNEQ error.

    DSE MAPS -RESTORE now works correctly when the total blocks in the database file is a multiple of 512. Previously, it could cause either of two kinds of benign database structural damage: free blocks counter in file header incorrect, or DBMBPINCFL errors where Master bit map incorrectly marks this local map full. Similar issues existed for MUPIP JOURNAL RECOVER/ROLLBACK and were fixed in GT.M V5.3-001 as part of C9H10-002923.

    DSE DUMP -FILE now prints a new field in the file header "Commit Wait Spin Count". When a GT.M process must wait for another process to complete its update on a particular block, it does a sequence of CPU spins followed, if still unsuccessful, by a yield of the CPU. The spin reduces unnecessary time spent waiting. A process uses this spin/yield sequence as many times as needed until the wait time is approximately 1 minute, at which point it logs an operator message. The new file header field, which has a default value of 16, determines the number of times the waiting process spins before yielding the CPU. DSE CHANGE -FILE now supports a new qualifier -COMMITWAIT_SPIN_COUNT= for modifying the spin_count value. Setting the spin_count to 0 will cause the waiting process to do a sequence of small sleeps instead of the spins or yields. In Tru64 Unix (where the spin_count is displayed in DSE DUMP -FILE) and VMS (where it is not even displayed), the waiting process does unconditional sleeps and therefore the spin_count value is immaterial. The spin_count applies only to Unix databases that have an access method of BG. (C9F06-002736)

  • GT.M now handles a journal align size of 2GB correctly. In previous versions the size was interpreted incorrectly resulting in a request for a large, negative size; which could result in journal failures. While larger align sizes trade off crash recovery time in favor of increased journaling throughput, especially when before image journaling is in use, there is marginal value in using align sizes larger than a few MB. (C9I03-002972)

  • GT.M now properly handles certain cases of multiple updates within a TP transaction to a global having the NOISOLATION characteristic. A flaw in the optimization work for C9I01-002938 introduced the potential for a memory access violation (SIG-11) in V5.3-001. Although apparently rare, this case could be dangerous because prior to the failure it could damage shared memory used in managing the database. (C9I05-002989)

  • Non-TP SET operations on journaled globals now deal appropriately with boundary conditions that very rarely coincide with a journal file switch. In previous versions of GT.M, in these very rare cases it was possible for the process doing a SET operation to terminate abnormally with a GTMASSERT error. (C9I07-003007)

Return to top

M-Other Than Database Access

  • GT.M now warns of non-graphic characters in string literals (which are an M standard violation) at compile time, but produces no error at run-time. Such errors are completely ignored within XECUTE arguments and indirection. In previous versions, GT.M treated such constructs as errors in accordance with the standard. (S9D08-002359, S9I07-002688)

  • Turning off MPROF tracing to write the results to the array now functions correctly. GTM no longer intermittently fails with a signal-11/ACCVIO error in this situation. (S9F06-002552)

  • GT.M now accepts source lines up to 8192 bytes in length. While FIS does not recommend long lines as a wholesome programming practice, this adds flexibility for those who found the prior length of 2048 bytes too confining, especially for strings used in XECUTE. This change also increases the maximum length of a single line of ZSHOW output. (S9F01-002523)

  • For characters in Unicode, GT.M assigns patcodes based on the default classification of the Unicode character set by the ICU library with three adjustments:

    1. If $ZPATNUMERIC is not "UTF-8", non-ASCII decimal digits are classified as A.

    2. Non-decimal numerics (Nl and No) are classified as A.

    3. The remaining characters (those not classified by ICU functions: u_isalpha, u_isdigit, u_ispunct, u_iscntrl, 1), or 2) above) are classified into either patcode P or C. The ICU function u_isprint is used since is returns "TRUE" for non-control characters.

    This is the resulting Unicode general category to M patcode mapping:

    Unicode General Category

    GT.M patcode Class

    L* (all letters)

    A

    M* (all marks)

    P

    Nd (decimal numbers)

    N (if decimal digit is ASCII or $ZPATNUMERIC is "UTF-8", otherwise A

    Nl (letter numbers)

    A (examples of Nl are Roman numerals)

    No (other numbers) 

    A (examples of No are fractions)

    P* (all punctuation)

    P

    S* (all symbols)

    P

    Zs (spaces)

    P

    Zl (line separators)

    C

    Zp (paragraph separators)

    C

    C* (all control code points)

    C

    For a description of the Unicode general categories see http://unicode.org/versions/Unicode4.0.0/ch04.pdf (section 4.5)

    [Note]
    Even though non-ASCII decimal digits (with $ZPATNUMERIC set to "UTF-8") match patcode N, GT.M does not treat them as digits.

    For example:

    GTM> w $c($$FUNC^%HD("D67"))?.N ; This is the Malayalam decimal digit 1                            
    1
    GTM>w 1+$c($$FUNC^%HD("D67"))
    1
    GTM>w 1+$c($$FUNC^%HD("31")) ; This is the ASCII digit 1
    2
    

    Previously, non-ASCII code points from the following Unicode general categories only matched patcode E:

    • Nl (letter numbers)
    • No (other numbers)
    • M* (all marks)
    • S* (all symbols)
    • Zs (spaces). (S9I05-002686)
  • On AIX and Tru64 systems, certain SOCKET reads and replication communication operations no longer use excessive CPU time. [AIX, Tru64] (S9I06-002687)

  • GT.M now provides an environment variable (or VMS logical) gtm_zquit_anyway, which, if defined to 1 (or case insensitive TRUE or YES), causes the compiler to generate what might be described as paranoid object code for QUITs, turning them into the form of Q:$Q arg Q. In other words, QUIT with an argument if the virtual stack frame was invoked as an extrinsic and without an argument if it was invoked with a DO. If the original code has an argumentless QUIT, GT.M supplies an empty string return value. This has no effect on QUIT from FOR loops, or implicit QUITs, whether at the end of a block or at the end of a routine. At run-time, the value of this setting is available as $ZQUIT and may be SET. Nonetheless the setting is not a run-time setting, but rather a compile-time one, so $ZQUIT has no effect on the behavior existing object code - it only effects code generated by auto-ZLINK or the ZCOMPILE command. This setting has no effect on late bound code such as that in XECUTE arguments, $ETRAP, $ZTRAP device EXCEPTIONS. FIS recommends M standard coding practice of explicitly coding QUITs as they are intended to be used, which avoids the need for this feature and provides useful error checking. (S9I07-002689)

  • ZPRINT now issues an error if the object and source file names don't match. In prior versions the operation could fail with a memory violation (Signal 11/SEG-V/ACCVIO). (S9I07-002692)

  • On Solaris, GT.M now operates as a 64-bit application. Henceforth, there are no 32-bit GT.M processes on that platform. GT.M now uses the Solaris libumem package to provide memory allocation in place of the default libc malloc. libumem can provide more predictable memory allocation when using large address spaces.

    GT.M now generates somewhat more compact code on the Linux x86_64 platform. [Linux x86_64]

    GT.M error messages now include 64-bit contexts where appropriate including adapting between 32- and 64-bit addresses depending on the platform. Previously some context might have either excluded some information or included extra information. As part of this change, DBFHEADERR messages have become either DBFHEADERR4 or DBFHEADERR8 messages, which accept 4-byte and 8-byte context values respectively. (C9D10-002413)

  • GT.M now handles MEMORY (UNIX) or VMSMEMORY (VMS) out-of-storage events with the following attributes:

    • When GT.M encounters MEMORY or VMSMEMORY error conditions it now issues FATAL error messages and terminates the process performing whatever clean up is possible. Previous versions triggered $ZTRAP or $ETRAP handlers which frequently ran into recursive error problems when the error handling attempted to allocate yet more memory.
    • Given that these errors are now FATAL errors, GT.M creates GTM_FATAL_ERROR files (as do other FATAL errors). Opening this file and writing to it can take some memory, therefore while performing process initialization, GT.M allocates a (default) 64K chunk of storage, which it reserves until, and unless, it encounters one of these errors. At that time, the mumps process releases the reserved memory for the OS to use as it needs with the hope that it will suffice to properly generate the file and handle any other clean up needs.
    • While GT.M provides a default reservation of 64K, you can override that amount with the gtm_memory_cache environment variable (UNIX) or GTM_MEMORY_CACHE logical (VMS). The value is the number of K bytes to allocate and hold. Values from 1 and up are allowed. If do not get the GTM_FATAL_ERROR files you need to diagnose an out-of-memory error, increase this value. Given that these errors are now FATAL errors, they can create a UNIX core or VMS dump file. However, like the STACKOFLOW error, GT.M normally suppresses the core/dump for these memory errors, but unlike STACKOFLOW, the it does the suppression on both UNIX and VMS (STACKOFLOW is suppressed only on UNIX).
    • The MEMORY (UNIX) and VMSMEMORY (VMS) out-of-memory error messages replace the HTEXPFAIL out-of-memory during a hash table expansion message. This allows the out-of-memory mitigation processing also work in the case of hash table expansion. Not doing so previously allowed failed hash table expansions to cause further memory problems during error processing with unpredictable results. Note that HTEXPFAIL message can still occur in situations where processing can continue (example a hash table is being reduced in size but the process cannot get the space to allocate a new smaller one, so it continues to use the existing, larger hash table).

    Prior versions of GT.M were less graceful in handling these errors, with symptoms including recursive errors, missing or mangled messages and severely limited context for debugging. (C9D12-002471, C9I04-002977)

  • The SOCKET device now works on HP-UX IA64 11V3. In addition, GT.M now has better error handling for HP-UX SOCKET devices and replication receiver servers. It retries ENOBUFS errors from socket calls before reporting an error, since these may be transient on HP-UX. Previous versions reported ENOBUFS immediately as an error. [HP-UX] (C9I04-002974, C9I04-002975)

  • In the unusual case where there's no valid error handling in place for an error and the error handler that is ultimately found contains a BREAK command, GT.M now reports the original error and error location before entering direct mode. Previously in such a case, GT.M would report the error condition followed by the BREAK location while the correct error location is recorded in $ZTATUS. This mixed report on entering direct mode was deemed confusing.

    The RTSLOC error message now prints the correct M source location. Previously, in case of certain runtime errors (for example, a FMLLSTPRESENT error), the error location reported could be incorrect (one more than the actual location).

    While the first two paragraphs of this item (C9I04-002976) apply to all platforms, the next two only apply to the following platforms: Linux Itanium, HPUX Itanium, and HPUX HPPA.

    In case the OPEN, USE, READ or WRITE command on an IO device errors out and the current EXCEPTION deviceparameter contains a string that results in a compile error, the location reported in $ZSTATUS is now correct. Previously, it could be one line before the actual location where the IO command was invoked.

    GT.M now reports errors from DO, extrinsic functions ($$) and other transfers of control accurately. Previously in some unusual cases GT.M could report a location one line before the actual location. (C9I04-002976)

  • When run in UTF-8 mode, GT.M requires ICU 3.6 installed and available to GT.M, however, it no longer requires ICU 3.6 to be the current version. An operating system may have installed multiple versions of a library such as ICU, with one version being the current version. Prior releases running in UTF-8 mode required ICU 3.6 to be the current version, which could cause a conflict with other software using ICU. [UNIX] (C9I06-002998)

  • GT.M now handles any DAY picture in the format specification of $ZDATE() function correctly. GT.M V5.2-000 and later ignored the DAY picture and unconditionally used the three-character English abbreviations for days of the week. (C9I06-003002)

  • GT.M now guards against signals interrupting memory allocation requests. Previously limitations on reentrancy of Unix services could occasionally cause memory allocation requests to hang if a signal resulted in another memory allocation while one was already active. [UNIX] C9I07-003004

  • GT.M now correctly handles run-time errors encountered during indirection in accordance with the M standard. In previous versions of GT.M, if a run-time error occurred inside indirection (for example, SET REF="^GBL(UNDEF)" WRITE $ORDER(@REF), where UNDEF is an undefined variable and hence causes a GTM-E-UNDEF error) and if $ETRAP includes a NEW command (e.g. SET $ETRAP="NEW X SET X="ERROR ENCOUNTERED" WRITE X,! QUIT") followed by a QUIT without resetting $ECODE to "", the UNDEF error would not be re-thrown in the caller function, which did not conform to the M-standard. (C9I07-003006)

  • GT.M now clears $ECODE (assigns it the value of the empty string) after an error in the GT.M utility which implements the display of help text; if the utility encounters no errors, it leaves $ECODE at its value on entry. This can cause the loss of some error context. In prior versions of GT.M (subsequent to the introduction of $ECODE functionality) errors in the help utility could change $ECODE and cause unintended behavior in subsequent error handling. Note that both the prior and current behavior of errors in ZHELP can disturb debugging of error handling. [UNIX] (C9I07-003009)

Return to top

Utilities- MUPIP

  • GT.M now avoids a class of shared memory corruption that could be caused by reusing the same buffer more than once in a transaction. In versions prior to V5.3-001, when this was fixed as a consequence of other changes, such corruption could occasionally occur and cause process failure or even database damage. While in theory this could happen under other circumstances, this was discovered (and is by far most likely) during a MUPIP JOURNAL RECOVER of a KILL that clears multiple blocks. (S9H03-002644)

  • MUPIP JOURNAL -RECOVER -BACKWARD or MUPIP JOURNAL -ROLLBACK now honor the current database full-block-write setting (controlled by the "gtm_fullblockwrites" environment variable/logical) while playing before-image journal records into the database. While they honored the setting for other database writes, previous versions of GT.M would write only as much data as available in the before-image journal record even though gtm_fullblockwrites was set to 1. This could potentially result in GT.M writing partial blocks (as far as the underlying file system is concerned). Depending on the type of file system used, this could take longer than writing full blocks - in other words, than padding the before-image record enough to write data that is a multiple of the underlying file system page size. (S9I05-002681)

  • The Update Process on a secondary instance now issues an UPDREPLSTATEOFF error whenever it encounters a record in the replication pipe that is destined to a non-replicated database file. After issuing the message, the update process shuts down immediately. The UPDREPLSTATEOFF error message section in the Messages and Recovery manual describes how to restart replication in this situation. Previous versions used to allow updates to non-replicated databases, which caused various issues including (a) even when a secondary instance was shutdown with zero backlog, a restart would show it as having a huge backlog and (b) a switchover to this secondary instance could cause the databases to no longer be logically equivalent. (S9I05-002682)

  • GT.M now allows the OpenVMS XFC file cache to be bypassed for journal files.

    Depending on your configuration, this may improve journaling performance under certain workloads. Note that any concurrent journal file read operations, including the replication source server if it needs to refer to the journal file, also bypass the XFC file cache. However, if there are no writers that have a journal file open, the XFC file cache is used which may be useful when doing journal extracts or recoveries.

    Note that enabling this feature for journal files which are on volumes not enabled for the XFC file cache either has no effect or may cause errors. This includes early versions of XFC which just provided VIOC emulation. Please check with your OpenVMS system manager.

    MUPIP SET /FILE /JOURNAL= has a new option, NOCACHE, which sets the GT.M NOCACHE mode. The default if it is not specified is CACHE.

    This option is also available for MUPIP BACKUP /NEWJNLFILES= to change the mode after the backup.

    MUPIP DOWNGRADE and UPGRADE now have slightly different outputs when journaling is enabled. Previously, two fields which only have meaning on UNIX were output:

    %GTM-I-MUINFOSTR, Journal sync_io :  FALSE 
    %GTM-I-MUINFOUINT4, Journal yield limit : 0 [0x00000000]
    

    The above two lines are now replaced with the following line on OpenVMS:

    %GTM-I-MUINFOSTR, Journal NOCACHE :  FALSE
    

    DSE DUMP /FILE output now has an additional line to show whether the associated journal file is opened in NOCACHE mode. The following line comes before the "Journal File:" line:

    Journal NOCACHE IO                  FALSE
    

    DSE CHANGE /FILE now has an additional qualifier, /JNL_CACHE= which accepts the values TRUE or FALSE. TRUE sets the GT.M CACHE mode. FALSE sets the GT.M NOCACHE mode.

    The default CACHE mode causes the journal file to be opened in the caching mode specified by the OpenVMS caching attribute which defaults to write through. However, when the journal file is switched, whether by operator action or the auto-switch limit, the new journal file has the OpenVMS default caching attribute. If the directory in which the journal file(s) exists has its caching attribute set to NO_CACHING, that becomes the default for all files created in the directory. If the NO_CACHING file attribute is set, all operations on that file bypass the XFC file cache, not just writes, regardless of the GT.M journal caching mode. This behavior is unchanged from earlier versions of GT.M. (C9C06-002064) [VMS]

  • GT.M is now robust enough to recognize when it is dealing with partially initialized shared memory and handles it appropriately. Previously, it would try to dereference uninitialized fields, leading to access violations. (C9D07-002355)

  • Please refer to the M Database section for MUPIP information in the description for C9F06-002736.

  • The source server now moves on to the next region whenever it detects a sought after transaction that has no record in the journal files of its current region. In previous versions, the source server could possibly enter an indefinite loop when unusual circumstances combined with this condition. (C9I06-003000)

  • The GT.M replication source server now deals properly with journal files on Tru64 that are 2GB or larger. In V53001A, the source server could terminate with a GTM-E-REPLFILIOERR error when using journal files 2GB or larger. [Tru64] (C9I08-003012)

Return to top

Utilities-Other Than MUPIP

  • The LKE CLEAR command now recognizes the -[NO]EXACT qualifier which limits the CLEAR to the exact resource name specified with the -LOCK= qualifier. Without this qualifier, LKE treats the resource name specified by the -LOCK= qualifier as a leading prefix for an implicit wild card search of all locks that start with the specified name. With the -INTERACTIVE qualifier (the default) this allows the operator to select one or more LOCKs or to "quit" if the desired LOCK(s) have already been cleared, but with NOINTERACTIVE, the prior behavior (without -EXACT) is extremely awkward. (S9I03-002677)

  • Please refer to the M Database section for DSE information in the description for C9F06-002736.

  • When directed to a region with a file header that's marked corrupt, DSE now issues a DBFLCORRP as a warning message and continues. In previous versions DSE terminated when it encountered this error. You can now use the previously documented DSE CHANGE -FILE -CORRUPT_FILE=FALSE command to clear this flag. The CORRUPT_FILE flag is set during a MUPIP JOURNAL -RECOVER and cleared on completion of a successful recovery; you can also set this flag with DSE CHANGE -FILE. Changing this flag does not correct or create any database damage. FIS advises against modifying this flag except on specific instructions from FIS. (C9I01-002946)

  • DSE CHANGE -FILE now has a -INTERRUPTED_RECOV=TRUE|FALSE qualifier you can use to manipulate a MUPIP JOURNAL RECOVER related flag in the file header. FIS advises against modifying this safety-related flag except on specific instructions from FIS. (C9I01-002947)

  • DSE CHANGE -FILE now has a -FULLY_UPGRADED=TRUE|FALSE you can use to manipulate the setting of an upgrade-related flag in the file header. FIS strongly advises against modifying this safety-related flag except on specific instructions from FIS and certainly not without a full understanding of the implications. V5.3-000/1/2 versions have an ambiguity with respect to V4-to-V5 upgrade status, which they deal with conservatively by requesting a rerun of MUPIP REORG -UPGRADE. Setting FULL_UPGRADED to TRUE on a file definitively known to be fully upgraded is an alternative to running REORG -UPGRADE. Inappropriately setting this flag to TRUE can cause database structural damage. Setting this flag to FALSE causes some additional overhead and requests to run MUPIP REORG -UPGRADE. (C9I01-002953)

Return to top

Error Messages

Return to top

GTMSECSHRTMPPATH

GTMSECSHRTMPPATH: gtmsecshr path is pppp

Information Message: GT.M displays this message when different users of an instance of GT.M connect using a socket or a semaphore and when gtmsecshr is started and it detects an existing gtmsecshr. pppp indicates the gtm_tmp path set in the clients. Gtmsecshr inherits the path from the first GT.M process that uses its services.

Action: If different clients of the same instance of GT.M are using different gtmsecshr paths, then set a common value for the environment variable gtm_tmp for all users of an instance of GT.M, then stop and restart the processes that were using incorrect paths. If gtmsecshr itself has the incorrect path, all processes that are using that incorrect path must be stopped first - then stop gtmsecshr with a kill command.

Return to top

DBFHEADERR4

DBFHEADERR4: Database file ffff: control problem: aaaa was xxxx expecting yyyy

Run Time Error: This indicates that database cache recovery was triggered due to some abnormal event, and the recovery routine detected damage to the control structures in the database global buffer cache.

Action: The system automatically attempts to correct the problem. If this error continues to occur, attempt MUPIP RUNDOWN and if that fails too, restore database from backup and replay journal files. Report this error to GT.M Support if necessary.

Return to top

DBFHEADERR8

DBFHEADERR8: Database file ffff: control problem: aaaa was xxxx expecting yyyy

Run Time Error: This indicates that database cache recovery was triggered due to some abnormal event, and the recovery routine detected damage to the control structures in the database global buffer cache.

Action: The system automatically attempts to correct the problem. If this error continues to occur, attempt MUPIP RUNDOWN and if that fails too, restore database from backup and replay journal files. Report this error to GT.M Support if necessary.

Return to top

LITNONGRAPH

LITNONGRAPH M standard requires graphics in string literals.

Compile-time warning: flags a standard violation. The generated code will accept the string, even though it contains “invisible” characters.

Action: Consider revising the literal to use $CHAR() and possibly concatenation to make the code more maintainable.

Return to top

MMBEFOREJNL

MMBEFOREJNL: BEFORE image journaling cannot be set with MM access method in database file ffff

MUPIP error: MM access method is incompatible with BEFORE_IMAGE journaling.

Action:If you require BEFORE_IMAGE journaling, use the BG access method. If you wish to use MM, turn off BEFORE_IMAGE journaling before selection MM as the access method.

Return to top

UPDREPLSTATEOFF

UPDREPLSTATEOFF: Error replicating global gggg as it maps to database xxxx which has replication turned OFF.

MUPIP Error: This indicates that the update process encountered an update record in the replication pipe that is destined for a non-replicated database file. GT.M does not allow such updates because they make the journal sequence numbers go out of sync between the replication primary and secondary. After issuing the message, the update process shuts down immediately. No more updates are processed on the secondary until replication is turned ON in the mentioned database file.

Action: Shut down the secondary instance including the receiver server, passive source server and any other helper processes accessing this instance. Turn replication ON in the mentioned database. Restart the secondary instance. The update process should now be able to process the update successfully.

For more information, see the GT.M web site.