GT.M V5.3-001A — 64-bits on x86_64 GNU/Linux and IBM pSeries AIX

Release Notes: GT.M 5.3-001A

Legal Notice

April 08, 2008

Revision History
Revision 1.0April 08, 2008



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
Global Directory Upgrade
Additional Installation Instructions
UNIX
OpenVMS
Database Upgrade Procedure
Pre V5.0-000 to V5.3*
V5.0*/V5.1*/V5.2* to V5.3*
Managing M mode and UTF-8 mode
Setting the environment variable TERM
Change History
V5.3-001A
V5.3-001
M-Database Access
M-Other Than Database Access
Utilities- MUPIP
Utilities-Other Than MUPIP
Error Messages
GTMSECSHRTMPPATH
OPCOMMISSED [V5.3-001A]

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

V5.3-001A is a minor release derived from V5.3-001, and provides timely fixes to defects, including an issue with NOUNDEF handling, an issue with TP transactions that include multiple global directories, as well as some other issues.

GT.M V5.3-001 introduced support for 64-bit GT.M processes to x86_64 GNU/Linux and IBM pSeries AIX.

For a brief description of 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

11V2(11.23)

Database performance may be unsatisfactory unless you apply patch PHKL_37279

[Warning]
V5.3-0001A does not properly support the SOCKET devices when used with 11V3 (11.31); this will be addressed in the next release. We are aware of no other issues with 11.31, but consider it not formally Supported for V5.3-001A.

IA64 GNU/Linux - Red Hat Enterprise Linux

5

Although Red Hat Enterprise Linux is the formally supported distribution, the software should run on any contemporary combination of Linux kernel, glibc (version 2.3.2 or later) and ncurses (version 5).

We have verified that GT.M passes comprehensive testing on RHEL 5 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, GT.M V5.3-001A may well 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

Current versions of AIX can be configured as either 32-bit or 64-bit; either version can support both 32- and 64-bit applications. 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-001A 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 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.1

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

Although RHEL 5.1 is the formally supported distribution, GT.M should run on any contemporary release of any major x86_64 Linux distribution.

x86 GNU/Linux

Red Hat Enterprise Linux 4, 5, and 5.1; SuSE Linux Enterprise Server 10

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.

Although RHEL and SLES are the formally supported distributions, the software should run on any contemporary combination of kernel with support for the msem facility (2.6 or suitably retrofitted 2.4), glibc (version 2.3.2 or later) and ncurses (version 5). 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. The GT.M team 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

Global Directory Upgrade

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.

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.

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-001A in /opt/lsb-gtm/V5.3-001A 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. Alternatively, since a journal file can grow to a maximum size of 4GB, you must set the journal auto switch limit to less than 2 GB for any journal file on a file system 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 Upgrade Procedure

Pre V5.0-000 to V5.3*

To upgrade from a GT.M version prior to V5.0-000, you need to perform a database upgrade. See Database Migration Technical Bulletin (Database Migration Technical Bulletin) for more information on the database upgrade procedure.

[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 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 V5.3* format.

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

No database upgrade is necessary if you upgrade from a V5 version prior to V5.3-000. However, for getting better database performance on heavily loaded system and stop logging the DBVERPERFWARN2 message, you should execute the MUPIP REORG -UPGRADE command on ALL the database files after you complete the GT.M installation. On a less heavily loaded system, the MUPIP REORG -UPGRADE command may not noticeably improve the performance but you may still want to execute it to stop logging the DBVERPERFWARN2 message.

[Note]
The MUPIP REORG -UPGRADE command upgrades only those recycled database blocks that escaped a MUPIP REORG -UPGRADE operation previously.

Return to top

Managing M mode and UTF-8 mode

GT.M requires International Components for Unicode (www.icu-project.org) version 3.6 for Unicode support. On a system that does not have ICU 3.6 installed and visible to the installation script, 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. 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 a ICU 3.6 installation on the system is visible to the installation script.

  • 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

  • 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)

  • [V5.3-001A] GT.M now appropriately handles TP transactions that include multiple global directories (due to SET $ZGBLdir or extended references) having multiple regions that map to the same database file. Previous versions could, in rare cases, terminate the GT.M process abnormally with TPFAIL or SIG-11 errors (ACCVIO in VMS) and damage the database if TP transactions accessed global variables in such a database files via different global directories.

    [Note]
    If you use the VIEW "NOISOLATION" command to turn NOISOLATION characteristics ON for a global name in one global directory and turn it OFF for the same name in a different global directory and if the two global directories map the global name to the same database file, then GT.M leaves NOISOLATION OFF if any path specifies OFF, irrespective of the order of the specifying VIEW command. (C9E04-002596)
  • After changing $ZGBLDIR, $VIEW() now properly reflects the current value of $ZGBLDIR even with no intervening global variable access. Previously this sequence could give an incorrect answer, or a memory access violation with the workaround being to perform an intervening global variable access. (C9H09-002900)

  • The GT.M database critical section lock wakeup mechanism has been enhanced to use memory semaphores. Previous versions used a socket-based scheme for wakeup. In some cases this led to processes being blocked trying to wake other processes up. This is no longer an issue in the new scheme. Since memory semaphores were introduced in 2.6 kernels, running GT.M on 2.4 kernels now requires a kernel which has had memory semaphores back-ported from 2.6. Note that contemporary releases of major Linux distributions use 2.6 kernels. [Linux] (C9H10-002918).

  • GT.M now avoids restarting a TP transaction in some additional cases where the global variable it is planning on updating has NOISOLATION turned ON even though it has been concurrently updated thereby improving GT.M transaction throughput rates. (C9I01-002938)

  • TP transactions now do not sleep between TP restarts thereby improving GT.M transaction throughput rates. Previously they used to sleep for a short time between every restart potentially resulting in inefficient use of system resources. (C9I01-002939)

  • [V5.3-001A] Using TSTART with no prior global reference now works if you precede it with a SET $ZGBLDIR command and no intervening database references. In previous GT.M versions, such an unusual usage would terminate a GT.M process abnormally with SIG-11 (ACCVIO in VMS) errors. (C9I02-002963)

  • [V5.3-001A] GT.M now closes journaling and continues with database updates even if:

    • it encounters errors (for example, insufficient disk space errors ) while writing to the journal file, and
    • it is holding the critical section lock on the database file. If GT.M does not hold the critical section lock on the database file, then it waits in a sleep loop until it successfully writes to the journal file.

    This enhancement eliminates the need to retry writing to journal file and in doing so saves CPU time.

    In previous versions (starting with V5.1-000), if a process was holding the critical section lock on the database file:

    • GT.M did not close journaling, and
    • kept retrying indefinitely to write to the journal file anticipating that the errors that prevent writing to the journal file to go away (say for example, disk space becomes available again).

    If the process was not holding the critical section lock, these previous versions used to indefinitely retry writing to the journal file without any sleep loop and consume CPU time. This misfeature was introduced in V5.1-000 as part of C9D11-002447 and fixed in V5.2-001 as part of S9H02-002643 . (C9I03-002964)

Return to top

M-Other Than Database Access

  • ZWRITE now preserves the representation of global variable numeric subscripts in exponential ("E") form. Previously large subscript values (>1E46) in exponential format [represented as strings] triggered a NUMOFLOW error. (S9E08-002478)

  • A new message, GTMSECSHRTMPPATH, has been added to help detect the situation where not all of the users of a GT.M instance have the same value for gtm_tmp. This message is issued in conjunction with the GTMSECSHRSRVF message when a client is unable to communicate with gtmsecshr, and with the GTMSECSHRSTART message when a new gtmsecshr is started and detects an existing gtmsecshr. In both cases the GTMSECSHRTMPPATH message displays the directory used for socket files that GT.M uses to communicate with gtmsecshr.

    The directory for socket files used to communicate with gtmsecshr, either defaulting to /tmp or taken from the environment variable gtm_tmp, ensures all processes using the same GT.M instance can properly communicate with gtmsecshr. For proper operation, all users of an instance of GT.M must have the same value for gtm_tmp, including the case of it not being defined (defaults to /tmp).

    The gtmsecshr process is started by the first client that needs its services and client is unable to communicate with the gtmsecshr process (normally, this means that the gtmsecshr process does not exist). The gtmsecshr process inherits the directory for socket files from the client that started it (via the gtm_tmp environment variable).

    gtmsecshr is a long running process. Once it has been initiated, it waits an hour from the last time it has received a service request before it automatically shuts down. Consequently, it is unusual to see multiple instances of a client being unable to communicate with gtmsecshr within a short period of time. It is also unusual to see the gtmsecshr process shutting down because another one exists already. If you encounter either of these situations, please see the action section of the GTMSECSHRPATH message.

    If you have poor performance, this may be the cause. Examine the syslog for these messages.

    Below is an example of syslog messages showing this situation. Notice the multiple failed attempts to communicate with gtmsecshr (a few seconds apart by the same client process) and corresponding failed start attempts (because gtmsecshr was already running).

    This enhancement helps you troubleshoot improperly configured GT.M installations. (S9H11-002670)

    Jan 23 17:17:34 host1 GTM[18950]: %GTM-E-GTMSECSHRSRVF, Client - 18950 : Attempt to service request failed, %GTM-I-TEXT, sendto to gtmsecshr failed, %SYSTEM-E-ENO2, No such file or directory -- generated from 0x00282B3E.
    Jan 23 17:17:34 host1 GTM[18950]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x00282BAD.
    Jan 23 17:17:34 host1 GTM[18960]: %GTM-F-GTMSECSHRSTART, Server - 18960 : gtmsecshr failed to startup, %GTM-I-TEXT, server already running, %SYSTEM-E-ENO11, Resource temporarily unavailable -- generated from 0x0804D275.
    Jan 23 17:17:34 host1 GTM[18960]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x0804D2E4.
    Jan 23 17:17:37 host1 GTM[18950]: %GTM-E-GTMSECSHRSRVF, Client - 18950 : Attempt to service request failed, %GTM-I-TEXT, sendto to gtmsecshr failed, %SYSTEM-E-ENO2, No such file or directory -- generated from 0x00282B3E.
    Jan 23 17:17:37 host1 GTM[18950]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x00282BAD.
    Jan 23 17:17:37 host1 GTM[18962]: %GTM-F-GTMSECSHRSTART, Server - 18962 : gtmsecshr failed to startup, %GTM-I-TEXT, server already running, %SYSTEM-E-ENO11, Resource temporarily unavailable -- generated from 0x0804D275.
    Jan 23 17:17:37 host1 GTM[18962]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x0804D2E4.
    Jan 23 17:17:40 host1 GTM[18950]: %GTM-E-GTMSECSHRSRVF, Client - 18950 : Attempt to service request failed, %GTM-I-TEXT, sendto to gtmsecshr failed, %SYSTEM-E-ENO2, No such file or directory -- generated from 0x00282B3E.
    Jan 23 17:17:40 host1 GTM[18950]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x00282BAD.
    Jan 23 17:17:40 host1 GTM[18964]: %GTM-F-GTMSECSHRSTART, Server - 18964 : gtmsecshr failed to startup, %GTM-I-TEXT, server already running, %SYSTEM-E-ENO11, Resource temporarily unavailable -- generated from 0x0804D275.
    Jan 23 17:17:40 host1 GTM[18964]: %GTM-I-GTMSECSHRTMPPATH, gtmsecshr path is /secshrpath/two, %GTM-I-TEXT, (from $gtm_tmp) -- generated from 0x0804D2E4.
    
    
  • [V5.3-001A] GT.M now handles name indirection and call-ins in an a wholesome way. In V5.3-001, an inconsistency in handling these operations in NOUNDEF mode could cause various misfortunes including out of memory conditions and segmentation faults (SIG-11/ACCVIO). (S9I03-002674)

  • [V5.3-001A] GT.M now suppresses STACKCRIT errors in the current frame at the time of the error. Previously, GT.M suppressed STACKCRIT errors in stack levels invoked because of an error, but this did not cover the GOTO implicit in $ETRAP processing or any explicit GOTO or ZGOTO in a $ZTRAP that placed control at the original stack level of the error. (S9I03-002676)

    GT.M now signals the STACKCRIT error when a process has 16K stack space left available. This gives processes more opportunity to recover and trim the stack using QUIT, ZGOTO, or HALT. Previous versions used to display the STACKCRIT message when there was 1K stack space left. [UNIX] (S9I03-002676)

  • GT.M introduces a new environment variable gtm_noundef. If it is defined, and evaluates to a non-zero integer, the string "TRUE", or the string "YES" (or any case independent leading substrings thereof), then GT.M, at process startup, treats undefined variables as having an implicit value of an empty string. Otherwise, GT.M triggers an error on an attempt to use the value of an undefined variable. Previously the only way to alter this behavior of undefined variables was to use the UNDEF or NOUNDEF arguments of the VIEW command.

    [Note]
    To establish the behavior of undefined variables on OpenVMS, set "GTM$UNDEF_INHIBIT == 1" in GTM$DEFAULTS.M64 to treat undefined variables as having a null value or set "GTM$UNDEF_INHIBIT == 0" to trigger an error on an attempt to use the value of an undefined variable.

    Running with VIEW "NOUNDEF" no longer has the disconcerting result of a test of a value implicitly creating (with a null value) previous undefined local unsubscripted variables. Now, while the variables still appear to have a null value in NOUNDEF mode, they remain undefined and will not show up in the output of ZWRITE, and functions such as $DATA() and $ORDER().

    When running in VIEW "UNDEF" mode, $STACK(X,Y) where the variable Y is undefined now causes an UNDEF error to be issued by GT.M at runtime. Previous versions used to incorrectly issue a INVSTACODE error.

    When running in VIEW "UNDEF" mode, JOB @LABEL+OFFSET^@ROUTINE where any of the variables LABEL, OFFSET or ROUTINE are undefined now causes an UNDEF error to be issued by GT.M at runtime. Previous versions used to incorrectly issue a JOBFAIL error. (C9B03-001664)

  • [V5.3-001A] GT.M now handles an error while $ZTRAP is active (a recursive error) in a similar fashion to an error while $ETRAP is active -- $ZTRAP now returns to the previous stack level and does not enter the direct mode. $ZTRAP creates an implicit additional frame, and therefore GT.M clears the current $ZTRAP to avoid indefinite recursion. GT.M invokes any $ETRAP or $ZTRAP handler that it encounters during unwinding the stack. If GT.M cannot locate any valid handler, it eventually terminates the process or, if invoked from direct mode, returns to direct mode. This behavior means that production environments should always start with a mumps -run. In prior versions, if GT.M could not locate a valid handler during $ZTRAP error processing, it would enter direct mode as a last resort. Although this behavior may be appropriate for some development environments, it did not match many production requirements.

    GT.M now handles an error in an EXCEPTION or ZBREAK action by triggering the current $ETRAP/$ZTRAP handler. In prior versions, GT.M would enter direct mode in those circumstances.

    GT.M now handles a compilation error in the SET of a $ZSTEP action by triggering the current $ETRAP/$ZTRAP handler. In prior versions, GT.M ignored such errors. Note -- Unlike ZBREAK actions, $ETRAP, $ZTRAP, and EXCEPTION strings, $ZSTEP is compiled when it's SET rather than when it's first used. This means that the prior $ZTEP action value (which defaults to "B" - BREAK) is not changed on a defective SET. We don't expect or recommend production code use ZSTEP commands. Nonetheless, if it should happen to, we recommend ensuring $ZSTEP is successfully assigned a value other than the default; for example, $ZSTEP="" causes a ZSTEP to have no effect (other than to slow execution if ZSTEP is used). (C9C11-002181)

  • [V5.3-001A] GT.M now reports the correct error location if it encounters errors during $ZTRAP error handling. In prior versions, in some cases, certain errors could cause GT.M to misreport the current location particularly in $ZSTATUS, but potentially in other location reports, such as $ZPOSITION. (C9D01-002232, S9I03-002676)

  • [V5.3-001A] GT.M no longer triggers a GTMASSERT error (causing a process termination) while trying to determine the error location under certain conditions. Previous versions occasionally issued the spurious GTMASSERT error. (C9D01-002234, C9E08-002617)

  • GT.M processes on IBM pSeries AIX are now 64-bit. See "Migrating to 64-bit platform" and "Additional Information on AIX" for more information on installing GT.M on IBM pSeries AIX. [AIX] (C9G04-002788)

  • GT.M processes on the x86_64 GNU/Linux platform are now 64-bit. GT.M for x86 Linux (32-bit) remains available as a separate build and continues to run on both x86 and x86_64 platforms. On x86_64 GNU/Linux, GT.M now has the ability to generate object modules that can be included in shared libraries using the standard system ld utility. See "Migrating to 64-bit platform" and "Additional Information on Linux" for more information on installing GT.M on x86_64 GNU/Linux. [Linux] (C9H07-002880)

  • The v5cbsu V4 to V5 upgrade utility component now operates with TRANSACTIONID="BATCH" which reduces its run-time by not waiting for journal hardening. It is safe to do this because the v5cbsu can be safely rerun or restarted should the original run stop before it is complete. (C9H09-002899)

  • If an application fails to detect and act on the loss of a SOCKET $PRINCIPAL device (using $DEVICE, $ZEOF, or EXCEPTION) and attempts additional READs or WRITEs, GT.M handles this condition by sending a NOPRINCIO message to the system log and terminating the process (as if performing a HALT). (C9H10-002916)

  • GT.M now prevents a module on the execution stack from being ZLINK'd in a pathological case. A pattern where an attempted ZLINK of a program on the stack (which would fail, as it should), followed by a ZLINK of a program with the same name when it was not on the stack (which would succeed), was followed by a ZLINK of the same module name when it was again on the stack would not fail with an error (whereas it should). Subsequent behavior could include memory access violations. (C9H11-002926)

  • The "execstack" command is no longer needed to permit GT.M processes to execute dynamically generated code. [Linux] (C9H11-002927)

  • GT.M is now able to explicitly ZLink object modules in shared libraries. In prior versions, doing an explicit ZLink on an object module in a shared library produced a ZLink error. The new behavior is now consistent between explicit and implicit ZLinks. If you have $ZROUTINES search lists that assume that explicit ZLINK would bypass your shared libraries, you should revise those in light of what you were trying to accomplish. (C9H11-002932)

  • [V5.3-001A] GT.M no longer generates unaligned access errors in the system log files. Previously, due to an incorrect size of a structure in 64-bit UNIX versions of GT.M, running the gtcm_gnp server could generate unaligned access messages. (C9I02-002959)

  • [V5.3-001A] An auto-ZLINKing process now holds control of a newly generated object file until it completes loading the fresh code from it. Previous versions used to close the newly created object file at the end of the compile and then reopen it to load the code - this left a small window where another process could delete that file and cause a somewhat mystifying file-not-found error. (C9I02-002960)

  • [V5.3-001A] GT.M now guards against signals interrupting time requests other than those for internal use. Previously limitations on reentrancy of UNIX services could occasionally cause time requests to hang if a signal resulted in another time request while one was already active. [UNIX] (C9I03-002967)

  • [V5.3-001A]GT.M now reports if it encounters errors or a full OPCOM mailbox while trying to send operator messages; it sends this report at the first non-failing attempt. It also retries sending an operator message for the mail box full condition. [OpenVMS] (C9I03-002969)

  • [V5.3-001A] GT.M now manages object files on some 64-bit platforms in a way that avoids a small memory leak that existed in prior versions. [Linux/IA64, Linux/x86_64, HPUX/IA64] (C9I03-002971)

Return to top

Utilities- MUPIP

  • [V5.3-001A] The source server now replicates data correctly whether it reads from journal files or the journal pool. In GT.M V5.3-001, if the source server needed to read from journal files and if the journal files had sync_io turned on and were using alignsize values greater than 64Kb, it read more data than its internal buffers could hold leading to memory corruption and mysterious abnormal termination. [UNIX] (S9I03-002675)

  • The GT.M utilities except GDE (DSE, LKE, MUPIP) now require arguments and values entered directly from the shell and containing single-quote (') or double-quotes (") to have the quotes "protected" by an escape mechanism. Each one must be preceded by a back-slash (\) or the entire string must be enclosed in a set of quotes (single or double) that do not also appear in the string. Previously GT.M attempted to implicitly escape quotes within some strings when it added quotes in preprocessing strings, but that prior approach led to inconsistent behavior in certain cases. The following are examples of appropriate usage:

      lke show -lock='^global("embed=and""nospace")'
      lke show -lock="^global(\"embedded\"\" quote\")"
      lke show -lock='^a("two words",5)'
      
    [Caution]
    This change may cause some existing scripts to fail.

    The following is an example from our test system where the old usage required revision:

    $MUPIP backup -o -i -t=1 DEFAULT "| gzip -c > online5pipe.inc.gz"

    Now must be:

    $MUPIP backup -o -i -t=1 DEFAULT "\"| gzip -c > online5pipe.inc.gz"\"

    Behavior at the utility prompt is unchanged. [UNIX] (D9G12-002633)

  • Backward journal recovery (MUPIP JOURNAL ROLLBACK or MUPIP JOURNAL RECOVER BACKWARD) now maintains the integrity of the master bitmap when the total blocks in the database is a multiple of 512. In previous versions, these operations could, in that case coupled with other unusual conditions, result in a database with a DBMBPINCFL integrity error (Master bitmap incorrectly marks this local map full). Please note that although no database integrity error is desirable, DBMBINCFL is a "benign" error whose only effect is wasted space in the database. (C9H10-002923)

  • MUPIP REORG now preserves application data integrity even in case of concurrent GT.M updates. In previous versions, running MUPIP REORG concurrently with GT.M could result in data loss in certain extremely rare cases. In GT.M V5.3-000 one particular case of this issue was addressed by C9B11-001813. Additional cases are addressed by this change. (C9H12-002934)

  • [V5.3-001A] MUPIP INTEG now correctly reports a DBINVGBL integrity error when it finds records with one global name in the Global Variable Tree (GVT) belonging to a different global name. Previous GT.M versions used to miss reporting an integrity error in case the incorrectly placed records were in the rightmost leaf block of the target GVT and the global name corresponding to the incorrectly placed records lexically sorted AFTER the global name corresponding to the target GVT. For example, if MUPIP INTEG encountered records of ^AA in the rightmost leaf block of the GVT of ^BB, it issued (and continues to issue) an integrity error but if there were records of ^CC incorrectly placed in the rightmost leaf block of the GVT of ^BB, then INTEG previously issued no error. (C9I02-002956)

Return to top

Utilities-Other Than MUPIP

  • None.

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

OPCOMMISSED [V5.3-001A]

OPCOMMISSED n errors and m MBFULLs sending prior operator messages

Informational Message: GT.M issues this message to the operator log if any operator messages prior to the immediately preceding one had not been sent due to errors from $SNDOPR. m is the number of time a persistent MBFULL error prevented a messages from being sent and n is the number of other errors whose reports were bypassed.

Action: None.

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