Release Notes: GT.M 5.3-001
Copyright © 2008 Fidelity National Information Services, Inc.
January 30, 2008
| Revision History | |
|---|---|
| Revision 1.0 | January 30, 2008 |
|
|
|
- Typographical Conventions
- Bulletin Overview
- V5.3-001 Change History
- M-Database Access
- M-Other Than Database Access
- Utilities- MUPIP
- Utilities-Other Than MUPIP
- Error Messages
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-001 extends support for 64-bit GT.M processes to x86_64 GNU/Linux and IBM pSeries AIX. Whereas 32-bit version of GT.M continues to be available for x86 as well as x86_64 GNU/Linux, on pSeries AIX, the 32-bit GT.M is replaced by this 64-bit GT.M. Also, GT.M for x86_64 GNU/Linux has the ability to create shared libraries containing object modules created by GT.M using the standard system ld utility.
As with any GT.M release, V5.3-001 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 (gtmsupport@fnis.com) as soon as possible. |
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 |
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). | |||
|
Hewlett-Packard HP-PA HP-UX |
11.11 |
GT.M supports UTF-8 mode and M mode on this platform subject to the following:
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. 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 |
Boot AIX using the 64-bit kernel to run GT.M processes on the 64-bit AIX platform. GT.M does not support 32-bit applications on AIX. Although AIX 5.2 and 5.3 are the officially supported releases, we are not aware of any reason why GT.M V5.3-001 will not run on AIX 6.x.
| |||
|
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 |
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 FIS for support of older CPUs. |
![[Tip]](images/tip.png)
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.
|
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]](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, potentially dangerous and hard to diagnose ways. |
|
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]](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 |
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. |
| |
| 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 for the 64-bit environment, the source the same as the 32-bit editions. |
Recompile all M and C source files.
![[Warning]](images/warning.png) | |
| On all the 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) |
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.
| |
| 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:
- Open the global directory with GDE from the current version.
- Execute the SHOW ALL command.
- Create a command file, or manually enter the commands corresponding to the output, into GDE from the prior GT.M version.
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. If you must overwrite an existing GT.M installation with a new version you must first shut down all processes using the old version.
Use the MUPIP RUNDOWN command of the old GT.M version to ensure all database files are cleanly closed.
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 >.
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 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. Furthermore, 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.
You must boot a 64-bit AIX kernel on 64-bit hardware to run 64-bit GT.M for IBM pSeries AIX.
Execute the following command to determine your current kernel:
getconf -a | grep KERN
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.
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.
| |
| 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.3* format.
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.
| |
| The MUPIP REORG -UPGRADE command upgrades only those recycled database blocks that escaped a MUPIP REORG -UPGRADE operation previously. |
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 resulting 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, 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 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 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 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 /usr/local/gtm_V5.3-001, then $gtm_dist is set to /usr/local/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
Ensure that system environment variable PATH includes the location of all the compilers mentioned above.
Download the source code of ICU version 3.6 for C from http://icu.sourceforge.net/download/3.6.html#ICU4C
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
- 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.
| |
By default, ICU is installed in /usr/local. If you install ICU in a different directory, type:
|
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.
| |
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. |
Fixes and enhancements specific to V5.3-001 are:
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. [UNIX/Linux] (C9D10-002409)
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. [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 in 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)
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 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. All users of an instance of GT.M should 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 either of these situations are encountered, please see the action section of the GTMSECSHRPATH message.
If performance is severely degraded, 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.
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.
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.[UNIX] (C9B03-001664)
V5.3-001 now supports 64-bit GT.M processes on IBM pSeries AIX. It replaces the previous 32-bit GT.M for IBM pSeries AIX. 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)
V5.3-001 now supports 64-bit GT.M processes on the x86_64 GNU/Linux platform. V5.3-001 for running 32-bit GT.M processes on x86 Linux is also available as a separate build. V5.3-001 for x86_64 GNU/Linux now has the ability to create shared libraries containing GT.M object modules 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)
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)
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) [UNIX] (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. This is now fixed. (C9H11-002926)
The "execstack" 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 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)
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)'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)
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.