Release Notes: GT.M 5.3-000
Copyright © 2007 Fidelity National Information Services, Inc.
October 30, 2007
| Revision History | |
|---|---|
| Revision 1.1 | October 30, 2007 |
|
|
|
Table of Contents
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 [ ].
GT.M V5.3-000 is a major new release, with support for HP-UX and GNU/Linux on Itanium based servers such as the HP Integrity family. Although there are no changes to M language support or to database functionality, GT.M has been internally re-engineered to support both 32- and 64-bit architectures. Even on 64-bit hardware, prior GT.M releases have always executed as 32-bit processes.
In GT.M V5.3-000, GT.M processes on HP-UX and GNU/Linux on Itanium are true 64-bit processes. On all other platforms, GT.M processes remain 32-bit processes. In releases to follow in the next few months, GT.M on IBM pSeries AIX and Sun SPARC Solaris will execute as 64-bit processes, and there will be no 32-bit versions of GT.M on those platforms.
Also coming in a release in the near future, 64-bit GT.M processes will be supported on GNU/Linux on x86_64. A 32-bit GT.M will continue to be available to run on GNU/Linux on both x86 as well as x86_64 hardware.
GT.M on OpenVMS and Tru64 UNIX on Alpha/AXP servers, as well as GT.M on HP-UX on PA-RISC will permanently retain a 32-bit architecture.
FIS would like to acknowledge the active participation of HP in the project to deliver GT.M on Itanium hardware.
As with any GT.M release, V5.3-000 includes fixes to bugs and misfeatures.
See section Change History for a brief description of the fixes and enhancements in this release.
![[Note]](images/note.png) | |
| 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 as soon as possible. |
As of the publication date, Fidelity supports this release on the following hardware and operating system versions. Contact Fidelity for a current list of supported platforms.
|
Platform |
Supported Versions |
Notes | |||
|
Hewlett-Packard Integrity IA64 HP-UX |
11.23 |
Database performance may be unsatisfactory unless you apply patch PHKL_37279 | |||
|
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). Please note that as of this date, RHEL 5 is not officially supported on IA64 hardware. Nevertheless, it ran stably on our hardware and the GT.M automated regression test suite passed. | |||
|
Hewlett-Packard HP-PA HP-UX |
11.11 |
GT.M supports UTF-8 mode and M mode on this platform.
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 a user's 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. Users who need to work with external calls written in C with Version 6.x of the Compaq C compiler on Alpha OpenVMS must carefully review all the provided kits for that product and apply them appropriately. | |||
|
IBM eServer pSeries AIX |
5.2/5.3 |
| |||
|
Sun SPARC Solaris |
9 and 10 |
GT.M supports deprecated DAL calls in M mode but not in UTF-8 mode. | |||
|
x86 GNU/Linux |
Red Hat Enterprise Linux 4 and 5; SuSE Linux Enterprise Server 10 |
Although RHEL and SLES are the formally supported distributions, the software should run on any contemporary combination of kernel, 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 Fidelity for support of older CPUs. |
![[Tip]](images/tip.png)
The same application code runs on both 32-bit and 64-bit platforms with the following preparations:
- Users must compile the application code separately for each platform.
- 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.
|
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 (32 bit) |
8-byte (64-bit) |
gtm_ulong_t is much the same as the C language unsigned long type. |
|
gtm_int_t |
4-byte (32 bit) |
4-byte (32 bit) |
gtm_int_t has 32 bit length on all platforms. |
|
gtm_uint_t |
4-byte (32 bit) |
4-byte (32 bit) |
gtm_uint_t has 32 bit length on all platforms |
![[Caution]](images/caution.png) | |
| 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 and potentially dangerous and hard to diagnose ways. In testing, GTMASSERT and SEGV (signal-11) errors were most common caused by storage chain (malloc) corruption failures. |
|
Parameter type |
32-Bit |
64-bit |
Remarks |
|
gtm_descriptor in gtm_descript.h |
4-byte (32 bit) |
8-byte (64-bit) |
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]](images/important.png) | |
| Any collation routines require only a recompile, assuming other aspects of their code are 64 bit capable. |
|
Parameter type |
32-Bit |
64-bit |
Remarks |
|
gtm_string_t type in gtmxc_types.h |
4-byte (32 bit) |
8-byte (64-bit) |
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. |
| |
| Any environment translation routines require only a recompile, assuming other aspects of their code are 64 bit capable. |
| |
| Although any existing M code must be compiled in the 64-bit environment, the source is identical to the 32-bit editions. |
Recompile all M and C source files.
![[Warning]](images/warning.png) | |
| On the Linux platform, 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) |
Relink all object files after recompiling all M and C source files.
Users who upgrade from GT.M V5.0-000 or later do not require a global directory upgrade.
Users on the Integrity IA64 platforms must create new global directories as the format on 64 bit editions differs from 32 bit editions.
Users who upgrade from a GT.M version prior to V5.0-000 require a global directory upgrade because the V5 global directory format is different from a V4 global directory format. When a user opens a V4 global directory with the V5 GDE utility program, even if they make no changes, an EXIT command automatically replaces the V4 format global directory file with a V5 format global directory file.
| |
| Fidelity strongly recommends users make a copy of any global directory before upgrading it. There is no way to downgrade a global directory from V5 format to V4 format. |
If a user inadvertently opens V4 global directory with a V5 GDE with no intention of upgrading it, then execute the QUIT command rather than the EXIT command.
If a user inadvertently upgrades a global directory, then perform the following steps:
- Open the global directory with V5 GDE.
- Execute the SHOW ALL command.
- Then, edit the output into a command file or manually enter the commands corresponding to the output into a V4 GDE invocation.
Users who upgrade from a GT.M version prior to V5.0-000 need to perform a database upgrade. See Database Migration Technical Bulletin (Database Migration Technical Bulletin) for more information on the database upgrade procedure. No database upgrade is necessary for users who upgrade from GT.M V5.0-000 or later.
| |
| The global directory in use at the time of database upgrade MUST have a mapping of globals to databases that exactly matches the globals that are actually resident in those databases. Some sites have more than one global directory with some having reduced or changed mappings such that, for example, a database may have more than one global in it but the global directory mapping has only a single global in it. This situation can potentially cause the database upgrade procedure to fail because database certification was not correctly processed. A sign that this could be an issue is if MUPIP REORG UPGRADE or a GT.M process fails with the DYNUPGRDFAIL message (block has insufficient room for expansion) after the V5 upgrade. |
See the "Installing GT.M" section in the GT.M Administration and Operations Guide.
Fidelity strongly recommends installing each version of GT.M in a separate (new) directory, rather than overwriting a previously installed version. Users who overwrite an existing GT.M installation with a new version must shut down all processes using the old version.
Use the MUPIP RUNDOWN command of the old GT.M version to bring down any open database files.
In UNIX editions, make sure gtmsecshr is not running. If found running, perform kill <pid of gtmsecshr>.
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). In UNIX editions, the GT.M configure script asks the following question:
Enter the RC node ID of the GT.CM server, if desired (42).
Respond by pressing ENTER.
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 like "aio0 has been created". This means that there is no further need of setup at this time. Note that some systems may have a "posixaio" option instead of "aio", so in the case that the above SMIT command fails. If this is the case then try posixaio instead. 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 rebooted next.
Users who expect their database files to grow larger than 2GB must configure its file system to permit files larger than 2GB. By default, a journal file can grow to a maximum size of 4GB, therefore users must set the journal auto switch limit to less than 2 GB for any journal file on a file system with a 2GB limit.
In OpenVMS, users who upgrade from a GT.M version prior to V4.3-001 must update any customized copy of GTM$DEFAULTS to include a definition for GTM$ZDATE_FORM.
User can ignore the following section if they choose standard GT.M configuration or if they answer yes to the following question:
Do you want to define GT.M commands to the system
Users who 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 must execute the same command after installing the new version of GT.M before using it. Users who define the GT.M commands to the system other than during the installation of GT.M need to 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 to match the proper GTMCOMMANDS.CLD with the version of GT.M being used.
When you complete the installation of V5.3-000, run the MUPIP REORG -UPDATE command.
If you have upgraded from a pre-V5 version to V5.3-000, then the MUPIP REORG -UPDATE command upgrades all the blocks.
If you have upgraded from another V5 version to V5.3-000, the MUPIP REORG -UPDATE command cleans those recycled database blocks that escaped prior upgrade activities. This command also adjusts the file header to stop log message like the following:
GTM[iiii]: %GTM-W-DBVERPERFWARN2, Peformance warning: Database /home/voet/EHR/g/mumps.dat is not fully upgraded. Run MUPIP REORG UPGRADE for best overall performance -- generated from 0xaaaaaaaa
where iiii is a process id and aaaaaaaa is a hexadecimal address that depends on your platform.
On a system that does not have ICU installed, GT.M assumes M mode operation and installs M mode components only.
On a system that has ICU installed, GT.M installs both M mode and UTF-8 mode components and an additional utf8 subdirectory. The technique that GT.M uses to separate M mode and UTF-8 mode object files is as follows:
From the same source file, the GT.M compiler generates an object file for M mode or UTF-8 mode depending on the value of the environment variable gtm_chset. 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 the object file was generated with a different setting of gtm_chset/$ZCHset than the current 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 M utility programs, their object files must conform to this rule. In order for the users to be able to use both M mode and UTF-8 mode, the GT.M installation ensures that both M and UTF-8 "flavors" of object modules exist and can be found in known locations. The technique of segregating the object modules by their compilation mode prevents both frequent recompiles and errors in installations where both modes are in use. Users 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:
Most GT.M (mumps, mupip, dse, lke, and so on) are in the parent directory, that is, the location specified by the environment variable gtm_dist.
Object files for programs written in M (GDE, utilities) have two versions-- one compiled for support of Unicode™ in the utf8 subdirectory, and one compiled without support of Unicode™ in the parent directory. Installing GT.M (V5.2-000 and above) generates both the versions of object files. Note that GT.M generates the object files for utf8 subdirectory only if ICU 3.6 is installed on the system.
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 the user sources the shell scripts gtmprofile or gtmcshrc, the behavior is as follows:
If gtm_chset is "m", "M" or undefined, there is no change to the environment from the previous versions.
If gtm_chset is "UTF-8",
$gtm_dist is set to the utf8 subdirectory (that is, if GT.M is installed in /usr/local/gtm_V5.2-001, then $gtm_dist is set to /usr/local/gtm_V5.2-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.
Users must set the environment variable TERM to 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.
| |
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. Users 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. |
Fixes and enhancements specific to V5.3-000 are:
GT.M now handles name-level $ORDER(gvn,-1) and $ZPREVIOUS(gvn) operations which move between database regions appropriately. In prior versions, if the region holding global name specified in the argument had a smaller maximum key size than the region holding the result, it could cause process memory corruption and possible shared memory corruption, which could, in turn, cause database corruption. (S9H05-002658)
Before-image journaling now writes a correct checksum on journal records in a few cases where it formerly did not, which would cause MUPIP RECOVER/ROLLBACK to issue a "Checksum validation failed" error. This issue was reported as fixed in GT.M V5.0-000D as part of C9F10-002762 but this item addresses a few rare cases that remained. (C9F10-002762)
GT.M now timestamps journal records such that the times never decrease in the record sequence. Prior versions of GT.M could, in rare cases, write journal records with out-of-order timestamps when recording transactions that used ZTSTART/ZTCOMMIT semantics, which could cause problems with backward journal recovery. Note that FIS strongly recommends TSTART/TCOMMIT transaction processing over ZTSTART/ZTCOMMIT. (C9E05-002604)
GT.M now appropriately handles the case where a process in the midst of updating a journaled database is terminated with prejudice (kill -9). In prior versions, another process attempting to update the same database might trigger a JNLMEMDSK error and close journaling for that database. Note that FIS strongly recommends against issuing kill -9 on processes that may actively be updating a GT.M database. While this change improves the odds of avoiding database damage, GT.M cannot ensure database integrity after a kill -9. [UNIX] (C9F09-002753)
GT.M error handling now appropriately preserves non-standard global collation after an error handled with adaptive $ZTRAP. In previous versions, an adaptive $ZTRAP could cause globals with non-M standard collation to inappropriately revert to standard collation, which could cause UNDEF errors and other problems. (C9H05-002863)
If a process encounters an error or termination signal in the midst of committing a TP transaction that updates at least 32 GDS blocks and it happens that an online backup is running at the same time, GT.M now completes the database commit operation and maintains database integrity. Prior versions could, in rare cases, corrupt database shared memory, which could potentially damage database integrity. (C9H07-002876)
V5.3-000 correctly upgrades the database file header to have the appropriate minor version (only major versions denote changes to the block format). Databases created by or upgraded to a release prior to V5.3 may not have their minor database version set correctly, which may interfere with tools as MUPIP ENDIANCVT. The workarounds for those versions was to manually set the database minor version number with DSE. (C9H08-002888)
A GT.CM GNP server updating a journaled database now creates properly formatted journal files. Prior versions could, in rare cases, create journal files with JNLBADRECFMT errors if another process concurrently switched journal files either because of reaching the autoswitchlimit or because of an explicit MUPIP SET JOURNAL. This is similar to the issue addressed C9H06-002865 as part of GT.M V5.2-001 [UNIX] (C9H08-002890)
GT.M now maintains database integrity while creating new global variables inside of TP transactions. In prior versions of GT.M, it was possible in very rare situations involving concurrent database activity that a GT.M process could cause database damage (for example, "Invalid mixing of global names" or "Keys out of order" integrity errors) or terminate abnormally with GVxxxFAIL or TPFAIL errors while trying to create a new global variable inside a TP transaction. This is now fixed. (C9H09-002901)
GT.M now correctly handles a pattern of local variable usage that could cause occasional SEGV (signal-11) errors. [UNIX] (S9H08-002667)
GT.M now reliably produces an appropriately sized object file when a recompile produces a smaller object. In prior versions, the file retained its original size and therefore caused an invalid object file error if you attempted to put it in a shared library. This eliminates the previous requirement to delete existing objects when recompiling modules intended for inclusion in a shared library. [UNIX] (C9C11-002165)
GT.M now avoids possible deadlocks that might result from nested calls to the system logging service. In previous versions, the typical, and fortunately rare, symptom was a process hung attempting to output an error report about a nested error encountered during reporting a prior error. [UNIX] (C9H07-002883)
MUPIP EXTRACT and MUPIP REORG now work correctly even if many global variables are specified in the SELECT qualifier. Prior versions could hang or terminate abnormally with SEGV (signal-11) errors due to an undetected internal buffer overflow. (S9H08-002668)
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 case the height of the global variable tree or the directory tree increased while REORG was running. (C9B11-001813)
The maximum allowed value for the journal buffer size (in number of 512-byte blocks) has been increased from 2016 to 32768. This increases the maximum possible journal buffer size from approximately 1Mb to 16Mb. (C9B11-001813A)
MUPIP JOURNAL ROLLBACK or RECOVER BACKWARD work works even in the case where they are interrupted and reissued. Prior versions could, in rare cases, terminate abnormally with a GTMASSERT error if more than one previous recovery was interrupted. (C9D07-002357)
MUPIP REORG UPGRADE now upgrades REUSABLE blocks in the database. Previously it used to upgrade only BUSY blocks. This change ensures that rolling back the database upgrade continues to preserve its integrity. In GT.M V5.2-001, C9H06-002867 addressed an issue where prior versions of GT.M could issue DYNUPGRDFAIL, GVxxxFAIL or TPFAIL errors in some cases when trying to allocate REUSABLE blocks. This fix was incomplete in that it was still possible for a MUPIP journal rollback or backward recovery to result in a broken database if the commands roll a database back to a state where the MUPIP REORG UPGRADE is incomplete. Previous V5 versions of GT.M could, in rare cases, terminate abnormally with SEGV (signal-11 or ACCVIO in VMS) if an upgraded database was downgraded followed by an upgrade. This issue existed in all GT.M versions prior to V5.3-000. With this change, any sequence of MUPIP REORG UPGRADE and MUPIP REORG DOWNGRADE (including multiple occurrences) works correctly irrespective of how many of each and the order in which they execute for a given database. (C9H07-002873)
The source server no longer logs every flush of the replication instance file header. In V5.1-000 and subsequent versions through V5.2-001, the source server logged every occurence of this event and this could potentially cause many essentially redundant messages to build up in a short time. [UNIX] (C9H09-002905)
KILLBYSIGSINFO1, iiii process xxxx has been killed by a signal yyyy at address aaaa (vaddr bbbb)
Run Time Error: This indicates that the process failed due to the yyyy signal, which occurred at the code address aaaa. bbbb is the virtual address attempting to be accessed from code address aaaa.
Action: Refer to the associated core file and contact GT.M Support (gtmsupport@fnis.com) for further guidance.
KILLBYSIGSINFO2, iiii process xxxx has been killed by a signal yyyy at address aaaa
Run Time Error: This indicates that the process iiii failed due to a signal, which occurred while attempting a memory access with an instruction at location aaaa.
Action: Refer to the associated core file and contact GT.M Support (gtmsupport@fnis.com) for further guidance.
KILLBYSIGSINFO3, iiii process xxxx has been killed by a signal yyyy accessing vaddress aaaa
Run Time Error: This indicates that the iiii (GTM, MUPIP, DSE, and so on) process failed due to the yyyy signal, which occurred while attempting to access virtual address aaaa.
Action: Refer to the associated core file and contact GT.M Support (gtmsupport@fnis.com) for further guidance.