GTM V5.5-000 リリースノート

リリースノート:GT.M 5.5-000

注意事項

Copyright © 2012 Fidelity Information Services, Inc. All Rights Reserved

Free Software Foundationによって公開されているGNU Free Documentation License, Version1.3 またはそれ以降のバージョンで同意されたものとして、本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件のもとに配布される場合にのみ許可します。但し、「変更不可能部分」「おもて表紙テキスト」「うら表紙テキスト」など変更不可部分は含みません。

GT.M™ は、Fidelity Information Services, Inc. のトレードマークです。その他商標は、それぞれの所有者の所有物です。

このドキュメントでGT.Mの説明および操作方法は、システムを構成するさまざまな機能に関するものが含まれます。このドキュメントには、FISのコミットメントは何も含まれていません。FISは、この文書の情報は発表日現在において正確であると考えていますが、情報は予告なしに変更される場合があります。FISのすべてのエラーまたは欠陥について責任は負いません。

2012年2月22日

改訂履歴
Revision 1.02012年2月22日最初の公開バージョン

連絡先情報

GT.Mグループ 
Fidelity Information Services, Inc. 
2 West Liberty Boulevard, Suite 300 
Malvern, PA  19355, 
United States of America


GT.M Support for customers: +1 (610) 578-4226  
gtmsupport@fisglobal.com 
Switchboard: +1 (610) 296-8877
Website: http://fis-gtm.com 


目次

表記法
リリースの概要
プラットフォーム
64bitプラットフォームへの移行
再コンパイル
共有ライブラリまたはイメージを再構築
インストール手順の追加
GT.M V5.5-000へアップグレード
MモードとUTF-8モードのマネージメント
環境変数TERMの設定
圧縮ライブラリのインストール
変更履歴
V5.5-000
Mデータベースアクセス
M本体(データベースアクセス以外)
MUPIP ユーティリティ
ユーティリティ(MUPIP以外)
エラーメッセージ
ACTLSTEXP
BADREGION
COREINPROGRESS
DBCDBNOCERTIFY
DBFLCORRP
DBROLLEDBACK
DSEWCREINIT
FMLLSTPRESENT
GTMASSERT2
IGNBMPMRKFREE
INSNOTJOINED
INSROLECHANGE
INSUNKNOWN
INVTRCGRP
JIUNHNDINT
JOBEXAMFAIL
JNLALLOCGROW
JNLNOREPL
JRTNULLFAIL
JNLRECINCMPL
LOCKSPACEFULL
LOCKSPACEINFO
LOCKSPACEUSE
MAXSEMGETRETRY
MUINFOUINT6
MUTRUNC1ATIME
MUTRUNCBACKINPROG
MUTRUNCERROR
MUTRUNCFAIL
MUTRUNCNOSPACE
MUTRUNCNOTBG
MUTRUNCNOV4
MUTRUNCPERCENT
MUTRUNCSSINPROG
MUTRUNCSUCCESS
NOLOCKMATCH
NONASCII
NOREPLCTDREG
NORESYNCSUPPLONLY
NORESYNCUPDATERONLY
NOSUPPLSUPPL
ORLBKCMPLT
ORLBKFRZOVER
ORLBKFRZPROG
ORLBKNOSTP
ORLBKNOV4BLK
ORLBKSTART
ORLBKTERMNTD
PERMGENDIAG
PERMGENFAIL
PRIMARYISROOT
RCVR2MANY
RCVRMANYSTRMS
REPL2OLD
REPLINSTDBSTRM
REPLINSTMISMTCH
REPLUPGRADEPRI
REPLUPGRADESEC
RESOLVESEQNO
RESOLVESEQSTRM
RESUMESTRMNUM
REUSEINSTNAME
RLBKCONFIGBNDRY
RLBKSTRMSEQ
RNDWNSKIPCNT
RSYNCSTRMSUPPLONLY
RSYNCSTRMVAL
SECNOTSUPPLEMENTARY
SEMWT2LONG
SHMREMOVED
STRMNUMMISMTCH1
STRMNUMMISMTCH2
STRMSEQMISMTCH
SUPRCVRNEEDSSUPSRC
SRVLCKWT2LNG
STRMNUMIS
TRIGMODREGNOTRW
UPDSYNC2MTINS
UPDSYNCINSTFILE
ZDATEBADDATE
ZDATEBADTIME
ZTRIGNOTRW
ドキュメント付録
ジャーナル抽出フォーマット
共有リソースの承認権限
オンライン ロールバックにより影響を受けるエリア

表記法

コマンドシンタックス : UNIXのシンタックス(フラグや修飾子の小文字テキストと"-")はこの文章全体を通して使われます。OpenVMSは小文字と大文字の両方のテキストを認めます;OpenVMS上でのフラグ/修飾子は、"-"よりはむしろ"/" を前にする必要があります。

プログラム名:GT.Mプログラムまたは関数を参照する時、例えば " MUPIP BACKUP " のように、リファレンスは大文字です。詳しい例が提供されている時、例えば" mupip backup -database ACN,HIST /backup "のように、UNIXコマンド名は小文字を使います。

リファレンス番号 : 括弧()で表示されるリファレンス番号は、ソフトウェア強化を突き止めたり、カスタマーサポートの要求するために使用します 。

プラットフォーム識別子 : もし新しい機能やソフトウェアの拡張はすべてのプラットフォームで適用されない場合は、関連のあるプラットフォームはカッコ[ ]で表示されます。

GT.Mのマニュアルでは、以前に"プライマリ インスタンス" または "オリジナル プライマリ インスタンス" として使っていたものを " オリジナル インスタンス " と表現し、そして、以前に "セカンダリインスタンス" と " オリジナルのセカンダリ インスタンス" として使っていた用語を "レプリケーション インスタンス"として用語を表現することを採用します。 そのソフトウェアを変更することよりも、ドキュメントを変更する方が簡単であるし、そして、とりわけ既存プログラムやスクリプトの互換性維持の伝統継承は我々に与えられた課題なので、たとえそれらがコードの中の新しい用語で補足されたとしても、ここまで来るのに長い時間を要したソフトウェアをそのままにし、以前の用語をドキュメントで置き換えることとしました。

GT.Mは、OpenVMSだけでなく、さまざまなUNIX/Linux実装上で動作します。現在サポートされているバージョンはF.I.Sに問い合わせてください。各GT.Mリリースは、FISにより、特定のハードウェアアーキテクチャ上で、特定のオペレーティングシステムのバージョンの設定で、広範囲にテストされます。( オペレーティングシステムとハードウェアアーキテクチャの組合せは、プラットフォームとも呼ばれます)特定のバージョンのこのセットでは、サポートが考慮されています。あるGT.Mのリリースでテストされていない場合は、同じオペレーティングシステムの他のバージョンとなるでしょう、しかし、FISのGT.Mサポートチームは、なぜGT.Mが動かないないのかの、見当が付かないことを知っています。バージョンのこの大規模なセットは、サポート可能と見なされます。GT.Mも十分に実行できる大規模なプラットフォームのセットになりますが、しかし、FISのGT.Mチームが、そのGT.Mがサポート可能であるかどうかを判断するための知識は不足しています 。これらは、アン サポートと見なされます。ご希望のプラットフォームについてのお問い合わせは、FISのGT.Mサポートにコンタクトしてください。

リリースの概要

V5.5-000では、サプリメンタリ インスタンス テクニカルニュースでより詳細に説明し、レプリケーションの新しいタイプを提供します。サプリメンタリ インスタンス(SI) レプリケーションで、GT.Mは、独自のビジネスロジックを実行しながらデータベース更新をコミットすることができ、例えば、レポート、意思決定支援、データウェアハウス、監査などを提供する、サプリメンタリ インスタンスにレプリケートするメカニズムを提供します。その作業の過程で、レプリケーションの他の側面を改善しました。

MUPIP REORG では、新しくホストファイルシステムへデータベース ファイルの最後に未使用スペースを返すために、-TRUNCATE オプションが追加されました。

DOコマンドの機能強化としては、実要素リスト(actuallist) の無いコールで、もはや括弧を必要としない DOを使ってのラベル呼び出しが可能になります。この変更で、ルーチンの呼び出しのパフォーマンスが向上します。

MUPIP ROLLBACKは、現在、- ONLINE オプションの機能の実装におけるフィールドテスト評価 の段階です。これは、将来のGT.M強化を見込んでおり、現在実装されてプロダクションに使用することを意図したものではありません。

暗号化リファレンスプラグインは、無関係なプロセス間、または、1つのシステムから別システムへ、不明瞭化なパスワードを渡したい場合に採用が可能なメソッドをサポートします。

いつものように、リリースでは、多くの小さな改善と修正が含まれています。わかりやすいリストについては、変更履歴 を参照してください。

プラットフォーム

時間が経つにつれて、コンピューティング·プラットフォームは進化しています。陳腐化したハードウェアアーキテクチャも提供されています。オペレーティングシステムの新しいバージョンは古いものを置き換えます。 FISは継続的にGT.Mでサポートされるプラットフォームとプラットフォームのバージョンを評価しています。以下の表では、このリリースで現在サポートされているものだけでなく、コンピューティング プラットフォームの評価によっては将来の計画に対して警告をも発してます。 もしFIS顧客であり、これらの計画で困難を起こすような場合、ニーズに対して議論するために速やかにFISアカウントエグゼクティブに連絡してください。

発行日の時点で、FISは、次のハードウェアおよびオペレーティングシステムのバージョンで、このリリースをサポートしています。サポートされているプラットフォームの現在のリストについては、FISにお問い合わせください。

プラットフォーム

サポート バージョン

注意点

Hewlett-Packard Integrity IA64 HP-UX

11V3 (11.31)

-

IA64 GNU/Linux - Red Hat Enterprise Linux

Red Hat Enterprise Linux 5.6

GT.Mは、Linuxカーネル2.6と同時期の, glibc (version 2.5-24以降), ncurses(version 5.5-24以降)など他の主要なLinuxディストリビューションの最新リリースで実行する必要があります。GT.Mがシングルセル(8個以上のCPU)を持つマシン上で、RHEL 5.x の包括的なテストをパスしたことを、FISは確認しました。それらが認定されるまで、複数セルのマシンは、本番環境での使用に適したとは見なされません。

このプラットフォームは完全にサポートされている今では残っていますが、それが Red Hat Enterprise Linux 6 でサポートされないと言うアナウンスは、将来のGT.Mリリースがこのプラットフォームでサポートされないことはあるかもしれません。

このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

Hewlett-Packard PA-RISC HP-UX

11.11

GT.Mは次のようなこのプラットフォームを対象にUTF-8モードとMモードをサポートします:

  • Problems with HP-UX 11.11 prevent FIS from testing 4 byte UTF-8 characters. FIS understands that the issue is resolved in HP-UX 11.31. At this time, GT.M is still untested and not formally supported on HP-UX 11.31; however, we are not aware of anything that would prevent this GT.M release 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 (executed as root) can be used to determine if this patch has been applied. Since recent "BATCH" and "GOLDEN" patches may contain this patch, your system may already have this patch applied but may not list it separately. [注意]HP-UXに関する翻訳はしません。Contact your HP support channel for more information.

[注意]HP-UXに関する翻訳はしません。GT.M does not support database encryption on this platform.

GT.M does not support the Memory Mapped (MM) Access Method on this platform.

OpenVMSに関する翻訳はしません。Although this platform remains at present fully supported with respect to bug fixes, owing to its looming sunset by the vendor, new functionality is supported on this platform only for FIS' convenience. It is likely that future GT.M releases will not be supported on this platform.

このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

Hewlett-Packard Alpha/AXP Tru64 UNIX

5.1B

GT.M supports M mode but not UTF-8 mode on this platform. [注意]HP-UXに関する翻訳はしません。GT.M does not support database encryption on this platform.

OpenVMSに関する翻訳はしません。Although this platform remains at present fully supported with respect to bug fixes, owing to its looming sunset by the vendor, new functionality is supported on this platform only for FIS' convenience. It is likely that future GT.M releases will not be supported on this platform.

このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

Hewlett-Packard Alpha/AXP OpenVMS

7.3-1 / 7.3-2 / 8.2 / 8.3

GT.M supports M mode but not UTF-8 mode on this platform. GT.M does not support several recent enhancements on this platform, including but not limited to database encryption, on-line backup, multi-site replication, PIPE devices and triggers.

[注意]OpenVMSに関する翻訳はしません。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.

OpenVMSに関する翻訳はしません。Although this platform remains at present fully supported with respect to bug fixes, owing to its looming sunset by the vendor, new functionality is supported on this platform only for FIS' convenience. Future GT.M releases may not be supported on this platform. Regardless of ongoing plans for support of the OpenVMS platform itself, the next GT.M release will likely no longer support OpenVMS 7.x. このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

IBM System p AIX

6.1, 7.1

[注意]AIXに関する翻訳はしません。Since GT.M processes are 64-bit, FIS expects 64-bit AIX configurations to be preferable.

[注意]AIXに関する翻訳はしません。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.

Running GT.M on AIX 7.1 requires APAR IZ87564, a fix for the POW() function, to be applied. To verify that this fix has been installed, execute instfix -ik IZ87564.

GNU/Linux on IBM System z

SuSE Linux Enterprise Server 10.3 and 11 or later

GT.M support starts at SuSE Linux Enterprise Server 10 Service Pack 3. On SuSE Linux Enterprise Server 11 or later, we require the installation of the SuSE provided libelf0-0.8.10-37.10, or later, package. Future GT.M releases are likely to no longer support SLES 10 and to support only SLES 11.

このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

IBM System z z/OS

V1R11

このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。

Sun SPARC Solaris

Ver 9 (Update 3以上) と、Ver 10 (Update 6以上)

The deprecated DAL calls operate in M mode but not in UTF-8 mode. Please refer to the Integrating External Routines chapter in the Programmer's Guide for appropriate alternatives.

x86_64 GNU/Linux

Red Hat Enterprise Linux 5.6; Ubuntu 8.04 LTS through 10.10; SuSE Linux Enterprise Server 11

64ビットのGT.Mプロセスを実行するには、64ビットカーネルだけでなく64ビットのハードウェアの両方が必要です。

GT.Mは、Linuxカーネル2.6と同時期の, glibc (version 2.5-24以降), ncurses(version 5.5-24以降)など他の主要なLinuxディストリビューションの最新リリースで実行する必要があります。

RHEL5.4でサポートするUnicode(UTF-8)を使用してGT.Mをインストールするには、次のようなインストールの質問に応答してください。<s0>Should an ICU version other than the default be used?(y or n)</s0> のインストールの質問に対して <s1>y</s1> と答えてください。そして、引き続き Enter ICU version (at least ICU version 3.6 is required. Enter as <minor-ver>.<major-ver>):のプロンプトで、ICUのバージョンを指定してください(例えば、<s2>3.6 </s2>と入力 )。

将来のGT.Mのリリースでは、もはや Red Hat Enterprise Linux 5.xをサポートされない可能性があります。このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。将来のRHEL 6のサポートを楽しみに期待してください。

x86 GNU/Linux

Red Hat Enterprise Linux 5.5

このGT.Mの32ビットバージョンは32ビットまたは64ビットのいずれかのx86プラットフォームで動作しますが、我々は64ビットハードウェア上でより好ましくすべきことはGT.MのX86_64 GNU/Linux バージョンを期待します。

GT.Mは、Linuxカーネル2.6と同時期の, glibc (version 2.5-49以降), ncurses(version 5.5-24以降)など他の主要なLinuxディストリビューションの最新リリースで実行する必要があります。CPUは最低限 686(Pentium Pro)または同等のインストラクションセットが必要です。

将来のGT.Mのリリースでは、もはや Red Hat Enterprise Linux 5.xをサポートされない可能性があります。このプラットフォームでGT.Mを必要とする場合には、FISアカウントマネージャにお問い合わせください。将来のRHEL 6のサポートを楽しみに期待してください。

プラットフォーム サポートのライフサイクル

FISは、通常、安定したリリースが利用可能になってから半年後に新しいオペレーティングシステムのバージョンをサポートし、その後2年間の窓口で各バージョンを通常サポートします。GT.Mのリリースは、また、通常はリリース後2年のサポートとなります。 FISは、任意のGT.Mのリリースとオペレーティングシステムのバージョンについて、当社の能力のために優良顧客にサポートを提供しようとした。提供されるサポートが2年間の窓口の後に減少していることから。

GT.Mは、パッチはありません、バグは、ソフトウェアの新しいリリースで修正されています。

64bitプラットフォームへの移行

同じアプリケーションコードで32ビットおよび64ビットの両方のプラットフォーム上で実行します。注意点:

  • プラットフォームごとに別々のアプリケーションコードをコンパイルする必要があります。Mのソースコードがまったく同じであっても、生成されるオブジェクトモジュールは、同じハードウェアアーキテクチャ上でさえも異なります - オブジェクト コードは、x86とx86_64 で異なります。

  • Cの呼び出し規則を使って非MコードとGT.Mとのインタフェースのパラメータ タイプは、それらターゲットプラットフォーム上のデータタイプと一致しなければなりません。たいていは、これらのパラメータは、以下の表にリストされているような、コールイン、外部コール、国際化(照合)、環境翻訳するためのものです。64ビットプラットフォーム上のほとんどのアドレスは、8バイト長であり、構造体は8バイトアライメントを必要しますが、これに反して、32ビットプラットフォーム上のすべてのアドレスは、4バイト長で、構造体は4バイトのアライメントを必要とすることに、注意してください。

内部コール(Call-ins)と外部コール

パラメータ タイプ

32ビット

64ビット

備考

gtm_long_t

4バイト(32ビット)

8バイト(64ビット)

gtm_long_t はC言語のlong型としてほぼ同じ、Tru64 UNIX を除き、GT.Mは 32ビットアプリケーションのままです。

gtm_ulong_t

4バイト

8バイト

gtm_ulong_t は、C言語のunsigned long型 とほぼ同じです。

gtm_int_t

4バイト

4バイト

gtm_int_t は、すべてのプラットフォーム上で32ビット長を持ちます。

gtm_uint_t

4バイト

4バイト

gtm_uint_t は、すべてのプラットフォーム上で32ビット長を持ちます。

注意

もし、あなたのインターフェイスが、gtm_long_t または gtm_ulong_t 型を使用し、しかし、インターフェイスコードが int または signed int 型を使用するならば、64ビットプラットフォーム上でのそれらのマッチは、診断方法によって、不愉快で潜在的な危険性をもち難しい中で失敗するコードが発生するほどの、型変換の障害があります。

国際化(照合)

パラメータ タイプ

32ビット

64ビット

備考

gtm_descriptor in gtm_descript.h

4バイト

8バイト

これらのタイプの内での変更するアドレスのみがあるにもかかわらず、構造体は、プラットフォームのアライメントの要件を満たすために、コンパイラのパディングの結果として最大8バイトまで拡張する可能性があります。

[重要]

それらのコードの他のアスペクトが64ビット対応と仮定すると、照合ルーチンは再コンパイルのみを必要とすべきです。

変換の環境

パラメータ タイプ

32ビット

64ビット

備考

gtm_string_t type in gtmxc_types.h

4バイト

8バイト

これらのタイプの内での変更するアドレスのみがあるにもかかわらず、構造体は、プラットフォームのアライメントの要件を満たすために、コンパイラのパディングの結果として最大8バイトまで拡張する可能性があります。

[重要]

それらのコードの他のアスペクトが64ビット対応と仮定すると、環境翻訳ルーチンは再コンパイルのみ必要です。

再コンパイル

  • MとCのソースファイルすべてを再コンパイルしてください。

共有ライブラリまたはイメージを再構築

  • すべてのMとCのソースファイルをコンパイルした後、共有ライブラリ(UNIX)または共有可能な実行可能なファイルのイメージ(OpenVMS)を再構築します。

インストール手順の追加

GT.Mをインストールしるには、『GT.M管理とオペレーションガイド』の"GT.Mインストール"のセクションを参照してください。最小限のダウンタイムのために、少なくともそれがカレントになるまでは、現在のレプリケーション インスタンスをアップグレードし、レプリケーションをリスタートし、一旦そのレプリケーションインスタンスがカレントにして、オリジナルインスタンスへそれを切り替えて、そして、レプリケーション インスタンスになるように、以前のオリジナル インスタンスをアップグレードします。

UNIX

  • FISは、以前にインストールしたバージョンを上書きではなく、別の(新しい)ディレクトリにGT.Mの各バージョンをインストールすることを、強く推奨します。もし新しいバージョンで既存のGT.Mインストールを上書きするための正当なニーズがある場合、最初に古いバージョンを使用してすべてのプロセスをシャットダウンする必要があります。FISは、 /usr/lib/fis-gtm/V5.5-000_arch (例えば32-bit Linuxシステムでは /usr/lib/fis-gtm/V5.5-000_x86) などのように、ファイルシステム階層標準に準拠した場所に、GT.M V5.5-000をインストールすることを、提案します。/opt/fis-gtm/V5.5-000_arch のような場所も適切でしょう。もし同じシステム上で同じGT.Mのリリースの32ビット版および64ビット版バージョンをインストールするには、 arch 接尾語は特に重要なことに、注意してください。

  • すべてのデータベースファイルを確保するために古いGT.MバージョンのMUPIP RUNDOWNコマンドの使用は、正常にクローズされます。

  • UNIXエディションには、gtmsecshr は実行しないでください。もしgtmsecshr が実行されると、最初にDSE, LKE, MUPIPユーティリティを含むすべてのGT.Mプロセスを停止しさせ、そして、MUPIP STOP pid_of_gtmsecshr を実行してください。

注意

アクティブなプロセスによって使用中の任意の実行可能ファイルのディスク上に、バイナリイメージに置き換ることを決してしてはいけません。これは予期しない結果を招くことがあります。オペレーティングシステムに応じて、これらの結果が含まれますが、サービスの拒否に限定されません(つまり、システムのロックアップ)、さらに、これらのプロセスをオープンになっているファイルへ損傷を与えます(つまり、データベース構造の損傷)。

AIXの情報は翻訳しません。Additional Information for JFS1 on AIX

AIXの情報は翻訳しません。If you expect a database file or journal file to exceed 2GB with older versions of the JFS file system, then you must configure its file system to permit files larger than 2GB. AIXの情報は翻訳しません。Furthermore, should you choose to place journal files on file systems with a 2GB limit, since GT.M journal files can grow to a maximum size of 4GB, you must then set the journal auto switch limit to less than 2 GB.

OpenVMS

[参考] [注意]OpenVMS用の追加情報は翻訳しません。To upgrade from a GT.M version prior to V4.3-001, you must update any customized copy of <s0><i1><s2>GTM$DEFAULTS</s2> </i1></s0>to include a definition for <s3>GTM$ZDATE_FORM</s3><s4>.</s4>

[参考] [注意]OpenVMS用の追加情報は翻訳しません。You can ignore the following section if you choose the standard GT.M configuration or answer <s0><i1>yes </i1></s0>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, all GT.M processes must match the proper GTMCOMMANDS.CLD with the version of GT.M they run.

GT.M V5.5-000へアップグレード

GT.Mデータベースは、データベースファイル、ジャーナルファイル、グローバルディレクトリの、レプリケーションインスタンスファイルの4種類のコンポーネントで構成されます。いくつかのデータベースコンポーネントの形式は、x86 GNU / Linuxプラットフォーム用の32ビットおよび64ビットのGT.Mリリース間のこのGT.Mバージョンごとに異なります。

V5.5-000 GT.Mのアップグレード手順は4段階で構成されています。

各ステージのアップグレードの説明を注意深く読んでください。GT.M V5.5-000のアップグレード手順は、あなたのGT.Mアップグレードの歴史と現在のバージョンに依存します。

ステージ1:グローバル ディレクトリをアップグレード

グローバルディレクトリをアップグレードする前に、グローバルディレクトリのコピーを作ることを、FISは強く推奨します。グローバルディレクトリを以前の形式にダウングレードするシングルステップの方法はありません。

以前のGT.Mバージョンからアップグレードするには:

  • GT.M V5.5-000からGDEユーティリティプログラムを使用してグローバル ディレクトリを開きます。

  • EXIT コマンドを実行してください。他に介在するコマンドなしで、このコマンドは自動的にグローバルディレクトリをアップグレードします。

x86 GNU / Linux プラットフォーム上で、32ビットと64ビットのグローバルディレクトリ- を切り替えるには:

  • 32ビットプラットフォーム上で、GDEユーティリティプログラムを使用してグローバルディレクトリを開きます。

  • それをサポートするGT.Mバージョン上で、SHOW -COMMAND -FILE=<file-name> 実行してください。コマンドファイルfile-name は、現在、グローバルディレクトリの設定を保持しています。

  • GDE SHOW -COMMAND をサポートしていないGT.Mバージョン上では、SHOW -ALL と、適切なコマンドファイルを生じた結果を編集するか、あるいは、手動でGDEに情報を再入力することを導くためにそれらを使用するか、どちらかを使用します。

  • 64ビットプラットフォームでGDEを開きます。もし 上記 2. または 3. からコマンドファイルを使用している場合。 @<file-name> を実行し、次にEXITコマンドを実行してください。これらのコマンドは自動的にグローバルディレクトリを再作成します。そうでない場合は、新しい環境での構成をレプリケートする古いグローバルディレクトリからGDEの出力を使用してください。

同じ手順を逆方向に適用してください。

もし、それをアップグレードするつもりが無く、不注意で以前の形式でグローバルディレクトリを開いたならば、 EXIT コマンドではなく、QUIT コマンドを実行してください。

もし不注意によりグローバルディレクトリのアップグレードをしてしまったならば、次の手順を実行してください:

  • V5.5-000からGDEを使用してグローバルディレクトリを開きます。

  • 古いバージョンのグローバルディレクトリを再作成するために使用するコマンドファイルを作成するには、SHOW -COMMAND -FILE=<file-name> コマンドを実行します。もし古いバージョンが著しく旧式ならば、より最近のバージョンに唯一適用されるテキストを削除するコマンドファイルを編集する必要があります。代替手段として、手動で古いバージョンのグローバルディレクトリを再確立するためのガイドとして、SHOW -ALL または SHOW -COMMAND からの出力を使用することができます。

ステージ2:データベースファイルのアップグレード

ブロック形式のアップグレード(V4からV5など)がある時のみ、データベースファイルをアップグレードする必要があります。しかし、いくつかのバージョンでは、例えば、V4として作成され(その後V5形式へアップグレード)初期化されたデータベースが、以前のアップグレードツールで仕損じている可能性があるフリーブロックでは無く以前に使用されていたものをアップグレードするために MUPIP REORG –UPGRADE 操作がさらに必要となるでしょう。

V5.000より前のGT.Mバージョンからアップグレードするには:

  • 所定の場所で使用するデータベースファイルをアップグレードしてください、または、伝統的なデータベースは、状況に応じた手順でアップグレードします。所定の場所の/伝統的なデータベースアップグレードの詳細については、データベースの移行技術情報 を参照してください。

  • MUPIP REORG –UPGRADE コマンドを実行してください。このコマンドは、すべてのV4のブロックをV5フォーマットへアップグレードします。

[注意]

V5.0-000より以前のGT.Mリリースで作成され、そして、V5フォーマットへアップグレードされたデータベースは、64M(67,108,864)ブロックの最大サイズ制限を保持します。

GT.M V5.0*/V5.1*/V5.2*/V5.3*/V5.5* からアップグレードするには:

もしGT.M V5.0-000以降からV5.3-000またはそれ以降にアップグレードするならば、データベースファイルのアップグレードの手順は決して必要ではありません。以前に使用されていて、そして、以前のアップグレードサイクル中に失われている可能性があるフリーブロックをアップグレードするには、MUPIP REORG -UPGRADE コマンドを実行する必要があるかもしれません。以下のいずれかの状況で MUPIP REORG -UPGRADE を実行する必要はありません。

  • データベースが、V5の MUPIP CREATE によって作成された。

  • データベースが、V5.3-003またはそれ以降から MUPIP REORG –UPGRADE によって、以前に完全に処理されていた。

もしV5.3- 003より前のバージョンで MUPIP REORG –UPGRADE コマンドを既に実行しているならば、それ以降のバージョンでは、MUPIP REORG -UPGRADE が実行するために、正しく行われ、そして、オペレータログに警告を記録されたかどうかを判断することはできません。したがって、どれかが必要です:

  • 再度、MUPIP REORG –UPGRADE コマンドを実行してください。

  • 警告を停止するために、DSE CHANGE –FULLY_UPGRADED=1 コマンドを実行してください。

注意

あなたが絶対に、V5.3-003以降の MUPIP REORG –UPGRADE を完了させるために以前の正常な実行を確かめない限りは、DSE CHANGE -FILEHEADER –FULLY_UPGRADED=1 コマンドを実行しないでください。不適切にこのコマンドを使用すると、データベースの整合性の問題につながる可能性があります。

アップグレードの考慮する追加事項については、"データベースの互換性ノート"を、参照してください。

[注意]

もしV5.4-001からV5.5-000へのアップグレード時に、アプリケーションコードがトリガーを使用している場合、トリガーは、データベースから抽出され、以前のGT.Mバージョンを使用してそれらの中に削除され、新しいGT.Mバージョンでロードする必要があります。

データベースの互換性に関する注意
  • データベースファイル ヘッダーへの変更は、任意のリリースで発生する可能性があります。必要に応じてGT.Mは自動的にデータベースファイル ヘッダーをアップグレードします。データベースファイルのヘッダーへのいくつかの変更は、データベースのメジャーリリース番号で、上位へも下位へも互換性があります。すなわち、1つだけのGT.Mリリースからのプロセスが、任意の時点でデータベースファイルにアクセスすることができますが、同じメジャーリリース番号で異なるGT.Mリリースで実行しているプロセスは、異なるタイミングでデータベースファイルにアクセスできます。

  • V5.3-004以降で作成されたデータベースは、224M(234,881,024)ブロックの最大サイズに増やすことができます。この意味は、たとえば、8KBブロックサイズで、最大のデータベースファイルサイズは、1,792ギガバイトですが、これは自身の領域が持てる単一のグローバル変数の実質的なサイズで、1つのデータベースは、グローバル変数の任意の数で構成します。GT.MバージョンV5.0-000からV5.3-003で作成されたデータベースは、128M から 224M ブロックへデータベースファイル サイズに制限を増やすためには、MUPIP UPGRADE でアップグレードできます。

  • GT.MバージョンV5.0-000からV5.3-003で作成されたデータベースは、128M(134,217,728)ブロックの最大サイズを持てます。GT.MバージョンV5.0-000からV5.3-003は、128Mブロック制限内にとどまる限りは、V5.3-004以降で作成されたデータベースにアクセスができます。

ステージ3:レプリケーションのインスタンスファイルのアップグレード

V5.5-000 は、新しいレプリケーション インスタンス ファイルを必要とします。それらを作成するための手順は、サプリメンタリ インスタンス レプリケーションテクニカルニュースにあります。このインスタンスから更新のために見ている(通信している)他のインスタンス上のすべてのレシーバ サーバをシャットダウンし、このインスタンスをシャットダウンし、インスタンスファイルを再作成し、次に -UPDATERESYNC 修飾子を用いてこのインスタンスでレシーバサーバを再起動してください。

[注意]

UPDATERESYNC 修飾子なしで、レプリケーションインスタンスは、レプリケーションインスタンス上でインスタンスと潜在的なロールバック情報の両方からのステータス情報を使用して、オリジナルのインスタンスを同期します。UPDATERESYNC修飾子は、オリジナルインスタンスのいくつかの以前の(または現在の)状態に一致する健全な状態にあるべきレプリケーションインスタンスを宣言します; それは、オリジナルインスタンスのレプリケーションインスタンスファイルに情報を更新するMUPIPを引き起こし、そして、レプリケーションインスタンス上のデータベースにある現在の情報を変更しません。このコマンドの後、レプリケーションインスタンスは、独自に現在の状態から開始するオリジナルインスタンスに追いつきます。レプリケーションインスタンスデータベースが、エラーなしで 、または、エラーなしで別のインスタンスから適切なコピーを持って、正常にシャットダウンされたことが絶対に確実である時のみ、UPDATERESYNC を使用してください。

[重要]

論理デュアルサイト(LDS)の設定からLMSの設定へ移行する時は、たとえGT.Mリリースを変更されなくても、あなたはいつも、マルチサイトレプリケーション技術情報の手順をフォローする必要があります。

ステージ4:ジャーナルファイルのアップグレード

すべての GT.M アップグレードの場合:

  • 新鮮なデータベースのバックアップを作成してください。

  • バックリンク(back-links)のない新しいジャーナルファイルを生成してください。

[重要]

MUPIP JOURNAL が、RECOVER 、ROLLBACK、EXTRACT のために、それ自身以外のリリースからジャーナルファイルを使用できないということが必要です。

ステージ5:トリガーの定義をアップグレードする

もしV5.4-002A/V5.4-002BからV5.5-000にアップグレードする場合、トリガーを抽出しリロードする必要はありません。

もしV5.4-000/V5.4-000A/V5.4-001からV5.5-000にアップグレードする場合にのみ、トリガ定義を抽出しリロードする必要があります。マルチラインは、トリガ用の内部記憶域の変更を必要とされたトリガを実行するので、V5.4-000/V5.4-000A/V5.4-001で作成されたトリガのレンダリングは、V5.4-002/V5.4-002A/V5.4-002B/V5.5-000 と互換性はありません。

MUPIPトリガを使用してV5.5-000 上でトリガ定義を抽出し再適用するには:

  1. mupip trigger -select="*" trigger_defs.trg のようなコマンドを実行してください。今出力したファイル trigger_defs.trg は、すべてのトリガ定義を保存します。

  2. それらを再適用する前に、古いトリガ定義を削除するために、trigger_defs.trgファイルの先頭に、-* を付けてください。

  3. トリガ定義を再適用するために、mupip trigger -triggerfile=trigger_defs.trg を実行してください。

$ZTRIGGER()関数を使用してV5.5-000 レプリケーションインスタンス上のトリガ定義を抽出し再適用するには:

  1. GT.M.の古いバージョンを使用してインスタンスをシャットダウンしてください。

  2. mumps -run %XCMD 'i $ztrigger("select")' > trigger_defs.trg のようなコマンドを実行してください。今出力したファイル trigger_defs.trg は、すべてのトリガ定義を保存します。

  3. すべての領域でのレプリケーションをオフにします。

  4. 古いトリガ定義を削除するために、mumps -run %XCMD 'i $ztrigger("item","-*") を実行してください。

  5. V5.5-000の適応可能なアップグレード手順を実行します。

  6. トリガ定義を適用するために、mumps -run %XCMD 'if $ztrigger("file","trigger_defs.trg")' を実行してください。

  7. レプリケーションをオンに戻します。

  8. オリジナルインスタンスに接続します。

MモードとUTF-8モードのマネージメント

選択されたプラットフォームでは、Unicode 国際化コンポーネント International Components for Unicode(ICU)バージョン3.6以降がインストールされ、GT.MのUTF-8モードで、Unicode(ISO/IEC-10646)文字列のサポートを提供しています。他のプラットフォーム上で、または、ICU 3.6以降がインストールされていないシステム上では、GT.MはMモードだけサポートしています。

ICUがインストールされているシステムで、GT.Mは、GT.MがインストールされているディレクトリのUTF8サブディレクトリを含めて、MモードとUTF-8モードの両方のサポートを必要に応じてインストールします。同じソースファイルから、環境変数 $gtm_chset の値に応じて、GT.Mコンパイラは、MモードまたはUTF-8モードのどちらか一方のオブジェクトファイルを生成します。それがソースとオブジェクトファイルの両方を検出した時に、GT.Mは、新しいオブジェクトファイルを生成し、そのオブジェクトは、ソースファイルを先行し、同じ $gtm_chset / $ZCHsetのセットで生成されました。もしそれがそのプロセスの現在の値よりも$gtm_chset / $ZCHset の異なるセットで生成されたオブジェクトファイルを検出した場合、GT.Mプロセスはエラーとなります。

そのモジュールが持っている実行中のプロセスの値に一致している $gtm_chset / $ZCHset の値で、Mのオブジェクトモジュールを常に生成します。GT.Mインストール自体は、Mで書かれたユーティリティプログラムを含んでいるので、それらオブジェクトファイルも、このルールに準拠します。MモードとUTF-8モードの両方でユーティリティプログラムを使用するために、GT.Mインストールは、MとUTF-8のオブジェクトモジュールの両方のバージョン存在することを保証しますが、utf8のサブディレクトリでは後者です。それらコンパイル モードでオブジェクト モジュールを分離するこの手法は、両方のモードで使用されているインストールで、両方で頻繁に再コンパイルしエラーがでることを防ぐことができます。もしインストールが両方のモードを使用する場合は、アプリケーションのオブジェクトコードリポジトリを構築するために、同様のパターンを考慮してください。

GT.Mは、次のように、親ディレクトリとutf8 サブディレクトリにインストールされています:

  • GT.M実行可能プログラム(mumps, mupip</s1>,dse, lke, など)の実際のファイルは親ディレクトリにあります、すなわち、インストールで指定された場所です。

  • Mで書かれたプログラムのオブジェクトファイル(GDE、ユーティリティなど)は、2つのバージョンがあります - 1つはutf8 サブディレクトリ内でUnicodeのサポート付きでコンパイルされたもので、もう1つは親ディレクトリでUnicodeのサポートなしでコンパイルされたものです 。GT.Mインストールは、両方のオブジェクトファイルのバージョンを生成し、GT.Mがインストールされた後にICU 3.6以降がインストールされGT.Mに見えるようになっている場合において、Unicodeのサポートのインストールのオプションを選択します。

  • utf8 サブディレクトリは、mumps, mupip, dse, lke, などをコールされるファイルを持ち、それらは、親ディレクトリで実行可能な相対シンボリックがあります(例えば、mumpsは、シンボリックリンク ../mumps があります )。

  • シェルプロセスが gtmprofile をソース実行する時は、動作は次のようになります:

    • もし $gtm_chset が "m" , "M" または未定義ならば、以前のGT.Mのバージョンから環境変数 $gtmroutines の値へ変更はできません 。

    • もし $gtm_chset が "UTF-8" ならば (大文字と小文字を区別のチェックはしない)、

      • $gtm_dist は utf8 サブディレクトリにセットされます(つまり、GT.Mが /usr/lib/fis-gtm/gtm_V5.5-000_i686 にインストールされているならば、gtmprofile とgtmcshrc は $gtm_dist を /usr/lib/fis-gtm/gtm_V5.5-000_i686/utf8 に設定します )。

      • オブジェクトファイルが libgtmutil.so 共有ライブラリに配置されていないプラットフォームでは、ユーティリティプログラム用の親ディレクトリ内のソースファイルが、utf8 サブディレクトリ内のオブジェクトファイルと一致されるように、$gtmroutines の最後の要素は $gtm_dist( $gtm_dist / .. )です。オブジェクトファイルが libgtmutil.so であるプラットフォーム上では、その共有ライブラリが、プロセスのモードでコンパイルされたオブジェクト ファイルを備えたものです。

gtmprofile とgtmcshrc の詳細については、 UNIX管理および操作ガイドの 基本操作の章を参照してください。

ICUのコンパイル

V5.3-004より以前のGT.Mバージョンは 、厳密にはICU 3.6が必要ですが、しかし、V5.3-004(またはそれ以降)はICU 3.6以降を受け入れます。ICUをダウンロードし、マルチスレッドを使用しないように設定し、さまざまなプラットフォーム用にコンパイルするサンプルの説明は、UNIX管理および操作ガイドの付録C:GT.Mをサポートしているプラットフォーム上でICUをコンパイル を参照してください。

GT.Mは ICUを使用できますが、ICUはFISのソフトウェアではありませんし、FISは、ICU自体のサポートはしていません。ICUのインストールおよび設定のためのサンプルの手順は、単にユーザーの便宜として提供されています。

また、ダウンロードサイト、コンパイラのバージョン、ICUのメジャー番号(ミリやマイクロ)のリリースでは、これらの命令がそれら旧式でMake テストをされた時の埋め込まれた日付以降に、ICUが変更されている可能性があることに注意してください。したがって、これらの命令は、手引書(クックブック)ではなく、参考例として考慮する必要があります。

環境変数TERMの設定

環境変数 $TERMは、正確にターミナル(またはターミナルエミュレータ)の設定と一致する terminfo エントリを指定する必要があります。GT.Mを実行する必要があるプラットフォームの端末の設定の詳細については、terminfoのmanページを参照してください。

  • いくつかのterminfoエントリが正しく動作するように思えるかもしれませんが、GT.M.からエスケープシーケンス応答で、ファンクションキーシーケンスの認識 、または、カーソル位置にの認識に失敗します。GT.M自体は、特定の端末制御の特性について、すべての知識を持っていません。したがって、正しくは、GT.Mとターミナルとが通信できるように、正しいterminfoエントリを指定することが重要です。特定のプラットフォームや実装に応じて、新しい terminfoエントリを追加する必要があります。ターミナル(エミュレータ)ベンダも、ヘルプできる場合があります。

  • GT.Mは、次のterminfoの機能を使用します。完全な変数名は、丸括弧内のcapnameに続きます。

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

編集が有効な場合、ダイレクトモードでの読み取りと、READs(読み取り以上*)として、GT.Mは、keypad_xmit 端末に送信します。GT.Mは、後にこれらのターミナルを読み取りを、keypad_localへ送信します。

圧縮ライブラリのインストール

もしレプリケーション用のオプションの圧縮機能を使用する予定であれば、圧縮ライブラリを提供する必要があります。圧縮ライブラリ用のGT.Mインタフェースは、適応作業を必要とせずに、zlib圧縮ライブラリを受け入れます。これらのライブラリは、多くのUNIXディストリビューションに含まれており、zlibのホームページからダウンロードできます。もし他の圧縮ライブラリを使用する場合、zlibが提供する同じAPIを提供するためにそれらを設定したり、適応させる必要があります。多くのプラットフォームでは zlibをコンパイルするための簡単な手順は以下のとおりです。GT.Mは zlib を使用できますが、zlib はFISのソフトウェアではありませんし、FISは、zlib 自体のサポートはしていません。これらの命令は、単にユーザーの便宜として提供されています。

もしzlibのためのパッケージがあなたのオペレーティングシステムで利用可能ならば、構築よりはむしろその利用について、FISは提案します。

Sun StudioからSolaris/cc コンパイラ:

./configure --sharedmake CFLAGS="-KPIC -m64"

HP-UX(IA64)/HP Cコンパイラ:

./configure --sharedmake CFLAGS="+DD64"

AIX/XL コンパイラ:

./configure --sharedAdd -q64 to the LDFLAGS line of the Makefilemake CFLAGS="-q64"

Linux/gcc:

./configure --sharedmake CFLAGS="-m64"

z/OS:

[参考] z/OS はちょっと?Refer to the steps we used to install zlib on z/OS in the GT.M for z/OS technical bulletin.

デフォルトでは、GT.M検索libz.so共有ライブラリ(HPUX PA-RISC上でlibz.sl)の標準システム·ライブラリ·ディレクトリ(たとえば、/ usr / libには、/ usr / local / lib、/ usr / localに/ lib64に)。共有ライブラリは、レプリケーションを開始する前に、非標準の場所にインストールされている場合は、環境変数$ LIBPATH(AIXおよびz / OS)または$ LD_LIBRARY_PATH(その他のUNIXプラットフォームでは)ライブラリをcontainungディレクトリが含まれていること。を確認する必要があります ソースおよびレシーバServerは実行時に共有ライブラリをリンクします。これは何らかの理由(例えば、ファイルが見つからない、または不十分な承認など)で失敗した場合、複製ロジックがDLLNOOPENエラーをログに記録し、圧縮なしで続行されます。

変更履歴

V5.5-000

V5.5 - 000固有の修正と拡張機能:

ID

以前の ID

カテゴリ

サマリ

GTM-2296

C9905-001114

ユーティリティ

DSE FIND -SIBLING 機能を改善

GTM-3873

C9B09-001740

MUPIP

新しい機能 - UNIX上でMUPIP REORG のための TRUNCATE 修飾子

GTM-4033

C9B12-001841

MUMPS

TROLLBACK to a $TLEVEL other than zero (0) leaves $REFERENCE empty which is the same behavior as a full TROLLBACK to 0=$TEVEL.

GTM-4202

C9C03-001934

MUPIP

Correction to NOREPLCTDREG error message context in UNIX.

GTM-4337

C9C05-002005

DB

UNIX gtm_db_startup_max_wait environment variable to control waiting on resource conflicts.

GTM-5797

S9F12-002581

MUPIP

New -REGION qualifier for MUPIP REORG operations.

GTM-5996

C9H04-002848

MUMPS

Interrupted GT.M HANG commands account for the time spent handling the interrupt when the hang resumes.

GTM-5997

C9H04-002849

MUMPS

Interrupted timed GT.M LOCK commands account for the time spent waiting before the interrupt when the LOCK resumes its wait.

GTM-6185

S9I05-002991

MUMPS

GT.M evaluates command postconditionals for invalid commands at runtime before generating an INVCMD error.

GTM-6224

S9I08-002697

ユーティリティ

Improved the setting of Journaling attributes with GDE.

GTM-6228

C9I08-003014

MUMPS

GT.M properly manages stack frames when fielding CTRAP interrupts from the console.

GTM-6306

C9I12-003062

DB

UNIX MUPIP JOURNAL -ROLLBACK -ONLINE capability and associated primarily operational changes.

GTM-6340

C9J02-003091

MUPIP

Supplementary Instances and operational changes primarily to replication.

GTM-6736

S9L01-002801, C9J03-003101

MUPIP

New JNLNOREPL error for the Source Server and PREVJNLLINKSET message to the operator log.

GTM-6449

S9J08-002739

MUMPS

<CTRL-D> at the GT.M Direct Mode prompt on an empty line terminates GT.M and returns control to the shell in UNIX.

GTM-6569

C9K03-003250

MUMPS

In UNIX, GT.M defers MUPIP STOP for a time window during which a process should not be terminated.

GTM-6614

C9K05-003274

MUMPS

In UNIX, GT.M ignores SIGINT (control-C) if $PRINCIPAL is not a terminal.

GTM-6622

S9K06-002778

MUMPS

GT.M better handles some error processing cases.

GTM-6650

C9K07-003295

MUPIP

A Receiver Server started with the -UPDATERESYNC qualifier starts every connection handshake (with a Source Server) during its own lifetime with that characteristic.

GTM-6664

C9K08-003307

ユーティリティ

Enhancements for configure, gtmprofile, and gtminstall scripts in UNIX.

GTM-6711

C9K10-003334

MUMPS

When returning from code invoked by MUPIP INTRPT (clearing $ZININTERRPT), GT.M implicitly clears any error(s) detected while 1=$ZININTERRUPT and sends a JIUNHNDINT error notification to the operator log.

GTM-6719

C9K11-003340

MUMPS

Improved management of internal timers in UNIX.

GTM-6725

C9K12-003344

MUPIP

Improved handling of database migration from V4 format.

GTM-6738

C9L01-003352

MUMPS

New %RANDSTR string generator utility function.

GTM-6759

S9L03-002806

MUMPS

Improved handing of TPTIMEOUT interrupts.

GTM-6771

C9L03-003376

MUMPS

In UNIX, ZMESSAGE treats any non-GT.M error as a trappable or fatal event.

GTM-6811

C9L05-003414

DB

Improved ftok algorithm for shared resources on UNIX.

GTM-6813

C9L05-003416

MUMPS

Change to actuallist-formallist handling mostly affecting DO

GTM-6819

S9L06-002815

MUMPS

New gtm_trace_gbl_name environment variable and M-profiling enhancements.

GTM-6826

S9L06-002819

MUPIP

GT.M no longer requires that an external filter treat its output as a transaction in UNIX.

GTM-6834

C9L06-003421

MUPIP

MUPIP RECOVER -BACKWARD restricts processing that identifies broken transactions to the most recent journal file(s).

GTM-6836

C9L06-003423

MUMPS

Improved SOCKET device handling of WRITE /LISTEN and WRITE /WAIT.

GTM-6841

C9L06-003428

MUPIP

The Source Server no longer hangs while waiting for a REPL_CMP_SOLVE message in UNIX.

GTM-6845

C9L06-003432

MUMPS

The GT.M parser now appropriately recognizes the end of the last source line in a routine.

GTM-6849

S9L07-002821

ユーティリティ

Corrected typographical errors in three messages.

GTM-6851

S9L07-002822

MUMPS

Improved error handling for $ZDATE().

GTM-6854

S9L07-002823

MUMPS

With VIEW "FULL_BOOLEAN", GT.M now evaluates functions with side effects - extrinsic functions ($$), external functions ($&) and $INCREMENT() in left-to-right order.

GTM-6856

S9L07-002824

MUMPS

GT.M correctly compiles expressions like if a<$$x(b-c) when specifying FULL_BOOLEAN.

GTM-6860

C9L07-003439

ユーティリティ

DSE DUMP -FILE -ALL output prints journal record types in hexadecimal.

GTM-6896

--

MUPIP

Fixes to UNIX cross-endian replication.

GTM-6898

--

MUPIP

Improved replication of duplicate KILLs.

GTM-6935

--

MUMPS

MERGE no longer gives an error when the source and destination variables are identical.

GTM-6939

--

ユーティリティ

%RO no longer strips trailing spaces or program text starting with a quoted semi-colon

GTM-6953

--

DB

Database encryption reference plug-in improvements in UNIX.

GTM-6957

--

MUMPS

$ZTRNLNM() recognizes all the documented keywords including all the OpenVMS keywords.

GTM-6958

--

MUPIP

MUPIP INTEG and MUPIP JOURNAL -ROLLBACK (or -RECOVER) now operate successfully on database files larger than 1TB.

GTM-6994

--

MUMPS

64-bit GT.M (all except HP Alpha (OpenVMS and Tru64), HP PA-RISC (HP-UX), and 32-bit x86 (Linux)) now passes 64-bit long and ulong values between C and M though the call-out and call-in interfaces.

GTM-6996

--

MUMPS

ZSHOW "D" that includes one or more SOCKET devices no longer causes memory leak.

GTM-7002

--

MUMPS

Fixes for INDEPENDENT and RENAME device parameters for the PIPE device in UNIX.

GTM-7004

--

MUPIP

Closed tiny hole in MUPIP FREEZE.

GTM-7005

--

ユーティリティ

More meaningful GDE error messages for encryption and MM access method set.

GTM-7007

--

MUMPS

Corrected handling of subscripted FOR control variables in XECUTE strings.

GTM-7008

--

MUMPS

Fix for XECUTE "DO @x" where x doesn't specify an actuallist.

GTM-7016

--

MUPIP

New -STDIN qualifier for MUPIP LOAD in UNIX.

GTM-7018

--

MUMPS

Duplicate SET optimization now the default.

GTM-7020

--

DB

UNIX trigger updates don't get spurious TRIGDEFBAD errors.

GTM-7021

--

ユーティリティ

Cleaner operation and organization of the UNIX installation kit.

GTM-7027

--

ユーティリティ

LKE now issues NOLOCKMATCH when a non-existing lock is searched with SHOW or attempted to be released with CLEAR.

GTM-7029

--

ユーティリティ

GT.M build successful on Ubuntu 11.10 with GCC 4.6.

GTM-7034

--

MUPIP

MUPIP JOURNAL RECOVER (or ROLLBACK) -BACKWARD now processes multi-region broken TP transactions appropriately.

GTM-7073

--

ユーティリティ

Improved LKE message when no matching LOCK found.

GTM-7077

--

MUPIP

MUPIP EXTRACT -FORMAT=BIN now handles database blocks of maximum size.

GTM-7078

--

MUMPS

New GTMASSERT2 message to produce more information about a failing condition.

GTM-7079

--

MUPIP

MUPIP JOURNAL -SHOW=ALL output now shows counts of all Record Types correctly up to 1 billion.

GTM-7082

--

MUPIP

In UNIX, -EXTRACT - writes to stdout instead of writing to a file named "-".

GTM-7110

--

ユーティリティ

In UNIX, GT.M utilities now give a CLIERR error when an equal-sign (=) follows a qualifier without an immediately following value.

GTM-7122

--

DB

GT.M handles journal file switches for some complex permissions patterns.

GTM-7123

--

MUMPS

DEVOPENFAIL for a deficient PIPE device specification

GTM-7158

--

DB

MUPIP TRIGGER, $ZTRIGGER() and ZTRIGGER now operate correctly on a read-only database in UNIX.

GTM-7176

--

MUMPS

Improved error handling for ZBREAK and ZPRINT().

GTM-7179

--

MUMPS

Report global gets from MERGE in database counters displayed with ZSHOW "G".

GTM-7185

--

MUMPS

FOR evaluates a termination value specified with a subscripted local variable at loop initiation.

GTM-7188

--

MUMPS

Error messages report the address of an event in hexadecimal in UNIX.

GTM-7196

--

MUMPS

M-profiling corrections.

GTM-7206

--

MUMPS

Resolved an interaction between ZGOTO 0:entryref and triggers in UNIX.

GTM-7210

--

MUMPS

Better context for OpenVMS UNDEF error messages.

GTM-7214

--

MUMPS

LOCK management avoids a possible problem.

GTM-7215

--

MUMPS

Change to ZQUIT_ANYWAY behavior

GTM-7224

--

ユーティリティ

The GT.M distribution kit now includes a README.txt file.

GTM-7228

--

MUMPS

The LOCK (and ZALLOCATE and ZDEALLOCATE) commands manage LOCK resource names more efficiently in LOCK_SPACE.

GTM-7230

--

MUPIP

Update Process and journal recover/rollback correctly handle NULL journal record type.

GTM-7234

--

MUMPS

Improved parameter passing with nested JOB'd processes in UNIX.

Mデータベースアクセス

  • GT.M components use the $gtm_db_startup_max_wait environment variable to determine how long to wait for a resolution of any resource conflict when they first access a database file. GT.M uses semaphores maintained using UNIX Inter-Process Communication (IPC) services to ensure orderly initialization and shutdown of database files and associated shared memory. Normally the IPC resources are held in an exclusive state only for minuscule intervals. However, under unusual circumstances that might include extreme large numbers of simultaneous database initializations, a long-running MUPIP operation involving standalone access (like INTEG -FILE or RESTORE), an OS overload or an unpredicted process failure the resources might remain unavailable for an unanticipated length of time. $gtm_db_startup_max_wait specifies how long to wait for the resources to become available:

    • -1 - Indefinite wait until the resource becomes available; the waiting process invokes the gtm_procstuckexec mechanism, if configured, at 48 and 96 seconds.

    • 0 - No wait - if the resource is not immediately available, give a DBFILERR error with an associated SEMWT2LONG

    • > 0 - Seconds to wait - rounded to the nearest multiple of eight (8); if the specification is 96 or more seconds, the waiting process invokes the gtm_procstuckexec mechanism, if configured, at one half the wait and at the end of the wait; if the resource remains unavailable, the process issues DBFILERR error with an associated SEMWT2LONG

    The default value for the wait if $gtm_db_startup_max_wait is not defined is 96 seconds. Previously, a process waited 60 seconds for one semaphore and immediately tried to acquire the other semaphore. If either of these attempts failed, it variously gave CRITSEMFAIL or REQRUNDOWN in addition to the above mentioned errors. [UNIX](GTM-4337)

  • MUPIP JOURNAL -ROLLBACK recognizes the -ONLINE qualifier which specifies that ROLLBACK run without requiring standalone access to the database and the replication instance file. GT.M provides the $ZONLNRLBK intrinsic special variable which it increments every time the process detects a concurrent MUPIP JOURNAL -ONLINE -ROLLBACK. If the logical state of the database after the completion of MUPIP JOURNAL -ONLINE -ROLLBACK matches the logical state of the database at the start of MUPIP JOURNAL -ONLINE .ROLLBACK, that is: only removes or commits an uncommitted TP transaction or non-TP mini-transaction, any transaction (TP or Non-TP) incurs a restart and nothing more. If the MUPIP JOURNAL -ONLINE -ROLLBACK changes the logical state of the database GT.M affects concurrent processing by incrementing $ZONLNRLBK and, In a TP transaction including trigger code within a transaction: restarts the transaction, or in a Non-TP mini-transaction, including within an implicit transaction caused by a trigger: issues a DBROLLEDBACK error, which, in turn, invokes the error trap if $ETRAP or $ZTRAP are in effect. Any utility/command attempted while MUPIP JOURNAL -ONLINE -ROLLBACK operates waits for ROLLBACK to complete; the $gtm_db_startup_max_wait environment variable (see GTM-4337) configures the wait. The default behavior of MUPIP JOURNAL -ROLLBACK is -NOONLINE, which requires standalone access on the database and replication instance file. Previously, ROLLBACK always required standalone access. At this time, FIS considers MUPIP JOURNAL -ROLLBACK -ONLINE to be of field test grade quality; please do not use this in production without doing comprehensive evaluation and testing. We would especially appreciate any feedback on this feature. In its current form, we expect its main usefulness would be to automatically rollback a replicating instance in response to a rollback on the originating instance.

    If ROLLBACK (either- NOONLINE or -ONLINE) terminates abnormally (say because of a kill -9), it leaves the database in a potentially inconsistent state indicated by the FILE corrupt field in the database file header. When a ROLLBACK terminates leaving this field set, all other processes receive DBFLCORRP errors any time they attempt to interact with the database. You can clear this condition as following in descending order of risk:

    • Rerun ROLLBACK to completion

    • MUPIP SET -FILE -PARTIAL_RECOV_BYPASS

    • DSE CHANGE -FILEHEADER -CORRUPT=FALSE -NOCRIT

    However, the MUPIP and DSE actions do not ensure that the database has consistent state; check for database integrity with MUPIP INTEG.

    The project to introduce this feature also addressed the following changes:

    GT.M manages database and replication locks more carefully. Previously, in some rare cases, a conflict between internally managed locks for a region and the replication [journal] pool could result in a deadlock.

    MUPIP now correctly manages control structures if it doesn't succeed in allocating shared memory. Previously such an unusual failure leaked a small amount of memory.

    MUPIP RESTORE now ensures that until the last of the incremental BACKUP files are restored, the process continues to operate in a standalone mode. Previously, it was possible for a concurrent process to sneak in while restore was switching input files and start accessing the database causing inconsistency.

    MUPIP now appropriately interprets MUPIP INTEG -ONLINE as equivalent to MUPIP INTEG -ONLINE -REGION and treats the response at the "File or Region:" prompt as a region. Previously, MUPIP treated MUPIP INTEG -ONLINE as MUPIP INTEG -FILE and assumed any input provided for "File or Region:" to be a file rather than a region.

    If the target database is frozen when MUPIP JOURNAL -RECOVER and -NOONLINE -ROLLBACK start, they issue a DBFRZRESETFL informational message and unfreeze the database. Previously, RECOVER did not issue any such informational message when it performed the unfreeze.

    MUPIP REPLIC -START -LISTENPORT -RECEIV now supports a new optional qualifier -AUTOROLLBACK[=VERBOSE] which allows the Receiver Server to run ONLINE FETCHRESYNC ROLLBACK on receiving a REPL_ROLLBACK_FIRST message from the Source Server. The optional value keyword VERBOSE allows the ONLINE FETCHRESYNC ROLLBACK to provide more diagnostic information. Previously, on receiving REPL_ROLLBACK_FIRST message, the Receiver Server halted and required FETCHRESYNC ROLLBACK to be run before restarting the Receiver Server.

    DSE ALL -WCREINIT and DSE WCREINIT now sends an operator log - DSEWCREINIT - to record this unusual event. Previously, no such message was sent to the operator log.

    For more information on the areas affected by ONLINE ROLLBACK, refer to Documentation Addendum. [UNIX] (GTM-6306)

  • GT.M now uses a revised filename-to-key (ftok) algorithm to locate shared resources on all UNIX platforms. The algorithm takes into account the identity of the file (inode number, generation number) and the identity of the file system containing it (major device, minor device). The previous algorithm had a higher probability of collisions between databases on different devices, with a consequent higher probability of synchronization problems.

    [注意]

    A prior GT.M release using the old algorithm may conflict with the current release if they concurrently attempt to initialize shared resources. Take care to avoid using prior and current GT.M versions at the same time on the same database. As with any hash algorithm,there is a very small probability of collisions with the new algorithm too; this can be detected using the "ftok" utility included with GT.M. In the event more than one database file produces the same ftok hash, copy the database file to a new location and use the copy, which will have a different key, instead of the original.

    In addition, MUPIP RUNDOWN on Unix now outputs a VERMISMATCH error after two shared memory size messages when an older GT.M is using the database. Previously, MUPIP would have only output the shared memory size messages, or in some cases (AIX or Solaris with a 32-bit prior version) succeeded, leading to database corruption.

    [注意]

    It is still possible to corrupt a database by running an older version of MUPIP RUNDOWN while a current GT.M has the database open. Be certain to shut down all GT.M processes before switching GT.M versions. [UNIX] (GTM-6811)

  • The encryption reference plug-in supports a method you can employ if you want to pass an obfuscated password between unrelated processes (e.g., a child process with a different userid invoked via a sudo mechanism), or even from one system to another (e.g., over an ssh connection). When the environment variable gtm_obfuscation_key names a file readable by the process, the plug-in uses an SHA-512 hash of the file's contents as the XOR mask for the obfuscated password in the environment variable gtm_passwd. When gtm_obfuscation_key does not point to a readable file, the plug-in creates an XOR mask based on the userid and inode of the mumps executable, as it did in previous versions, and then computes an SHA-512 hash of the XOR mask to use as a mask. In addition, the maskpass program handles passphrases containing blanks. Previous versions did not support blanks in the password, did not hash the mask before performing the XOR obfuscation and used a mask that was unique to the process and so could not be used to pass the password except to another process with the same user on the same GT.M installation. [UNIX] (GTM-6953)

  • If the duplicate SET optimization is enabled, and if a SET causes no change in the value of a preexisting node, that update now invokes any associated triggers. Previously it did not invoke the triggers in this case. It is now up to the trigger code to check if the value of the node did or did not change due to this update and take an appropriate course of action. This also makes trigger invocation behavior consistent between an originating and its replicating instances. Previously each GT.M process on the originating primary used to be able to control whether triggers were invoked or not for duplicate sets whereas the Update Process on the replicating instance (which performs updates on behalf of all the GT.M processes on the originating primary) inherited only one setting for trigger invocation (in case of duplicate sets) and hence did not always mirror the GT.M process in terms of trigger invocations. This could lead to potential out-of-sync situations between the originating instance and its replicating instance due to different trigger code being executed on the two instances and in addition caused a huge journal file on the replicating instance compared to the journal file on the replicating instance.

    The environment variable gtm_gvdupsetnoop is no longer honored. By default, the duplicate set optimization is now enabled (i.e. equivalent to gtm_gvdupsetnoop previously being set to 1). The only way to control this feature is with a VIEW command (View "GVDUPSETNOOP":0 disables the optimization, View "GVDUPSETNOOP":1 enables it). (GTM-7018)

  • Trigger updates from MUPIP TRIGGER and $ZTRIGGER() now handle concurrency conflicts with appropriate transaction restarts. Previously concurrency conflicts with these update could cause misleading TRIGDEFBAD errors [UNIX] (GTM-7020)

  • GT.M now correctly allows all processes with read-write access to a database file to switch journal files as long as they have read-write access to the journal file directory. Previously, in an edge case, GT.M did not permit a process with read-write access to a database file to perform a needed journal file switch. As part of this change, we have generated documentation to enumerate the various cases for ownership and permissions of shared resources. This documentation is reproduced in the Shared Resource Authorization Permissions section. (GTM-7122)

  • MUPIP TRIGGER, $ZTRIGGER(), and the ZTRIGGER command now operate correctly on a read-only database or in an environment where some databases are read-only and others are not. Previously, these functions ignored the read-only setting of the database updating shared memory anyway. If other processes had the database open read-write, the changes could be flushed to the database. The ZTRIGGER command assumed it had read-write access which could cause flushing issues. [UNIX] (GTM-7158)

M本体(データベースアクセス以外)

  • TROLLBACK to a $TLEVEL other than zero (0) now leaves $REFERENCE empty which is the same behavior as a full TROLLBACK to $TEVEL=0. Previously such a TROLLBACK left $REFERENCE with a value that was a function of the last rolled back action. (GTM-4033)

  • Interrupted GT.M HANG commands now account for the time spent handling the interrupt. Previously, the HANG command resumed using the full specified wait time thus potentially hanging indefinitely if hit with a stream of interrupts. (GTM-5996)

  • Interrupted timed GT.M LOCK commands now account for the time spent waiting before the interrupt when the LOCK resumes its wait. The time spent handling the interrupt is ignored thus the locks specified in the command may be waited on during several intervals which add up to the wait time specified in the LOCK command. Note that while handling the interrupt, the lock requests (and any partial reservations) are released. Previously, the LOCK command restarted the full wait time thus never completing if additional interrupts arrived. (GTM-5997)

  • GT.M now evaluates command postconditionals for invalid commands at runtime before generating a GTM-E-INVCMD error. If GT.M exaluates the postconditional to false, GT.M does not raise an error and continues execution. GT.M generates compile time GTM-E-INVCMD messages as before, though if the command includes a postconditional the compilation continues. Previously, GT.M considered the invalid command a run time error regardless of the command postconditional. (GTM-6185)

  • GT.M properly manages stack frames when fielding CTRAP interrupts from the console. Previously, if a $ETRAP did not handle a CTRAP error, GT.M mishandled the re-throw of the error in frames associated with an indirection, for example DO @X, subsequently causing a GTMASSERT or address exception (UNIX SIG-11 or OpenVMS ACCVIO). (GTM-6228)

  • <CTRL-D> at the GT.M Direct Mode prompt on an empty line terminates GT.M and returns control to the shell. FIS thanks Sam Habiel for this enhancement. Previously GT.M ignored <CTRL-D> in this circumstance. As in prior versions, if there is a character at the cursor when you enter <CTRL-D> in direct mode, GT.M erases it; if there are characters on the line but the character position is at the end of the line, GT.M ignores <CTRL-D>. Note: to delete the prior character on the line, use the key defined in your TERMINFO as key_backspace. [UNIX] (GTM-6449)

  • There are a few very small and infrequent windows in GT.M code (expected to be under a microsecond on contemporary hardware) during which a process should not be terminated (hence the recommendation to use kill -9 on GT.M processes only as a last resort). When a MUPIP STOP is received within such a window, GT.M now defers process termination until it is outside the window. If, for some reason, the process is stuck within such a window of protected code, and receives three MUPIP STOP signals, it stops immediately. Previously, GT.M processes responded to MUPIP STOP signals immediately, and if one received a MUPIP STOP within such a window, it might generate a GTMASSERT or other failure while attempting to terminate. This change should require no operational changes in GT.M because of the tiny windows within which MUPIP STOP is deferred---the three STOP technique being required only to recover from unanticipated out-of-design conditions. [UNIX] (GTM-6569)

  • GT.M ignores SIGINT (control-C) if $PRINCIPAL is not a terminal. Previously receipt of this signal blocked subsequent out-of-band events such as MUPIP INTRPT or TPTIMEOUT. [UNIX] (GTM-6614)

  • GT.M better handles some error processing cases. Previously, GT.M used to fail with addressing exceptions (UNIX SIG-11 or OpenVMS ACCVIO) while capturing error context information for $STACK(). Other changes have addressed the known errors in that category but this improves the robustness of GTM by giving it a better chance to continue operating even in adverse circumstances. (GTM-6622)

  • When returning from code invoked by MUPIP INTRPT (clearing $ZININTERRPT), GT.M implicitly clears any error(s) detected while 1=$ZININTERRUPT and sends a JIUNHNDINT error notification to the operator log, for example:

    Sep 26 11:41:09 flyingv GTM[15119]: %%GTM-E-JIUNHNDINT, An error during $ZINTERRUPT 
    processing was not handled: 150379874,jobintr2+4^jobintr,
    %%GTM-E-ERRWZINTR, Error while processing $ZINTERRUPT
    -GTM-E-LABELMISSING, Label referenced but not defined: 
    nonexistantrtn -- generated from 0x00007FEFD25B831A.

    Prior versions followed the basic error handling pattern of re-throwing the most recent unhandled error at each level as long as $ECODE is not equal to the empty string. [UNIX] (GTM-6711)

  • GT.M now provides better management of timed events by deferring their processing during certain brief sections of code. Previously, GT.M could not keep timers alive while preventing various timer-driven events from interfering with the executing code; this limitation resulted in a number of very rare failures, caused by either a lost timer or a timed event delivered at an inappropriate moment, resulting in symptoms such as hung processes and GTMASSERTs. In addition, GT.M now raises the COREINPROGRESS error if an attempt to generate a core fails and triggers an attempt to generate another core. Previously, under certain very rare conditions, GT.M could get into a core generation loop potentially eating up disk space and process slots. [UNIX] (GTM-6719)

  • The installation kit now includes a random string generator utility function called %RANDSTR (strlen,charranges,patcodes,charset). This generates a random string of length strlen from an alphabet defined by charset or by charranges and patcodes. If charset specifies a string of non-zero length, %RANDSTR generates the random string using the characters in charset, otherwise it takes its alphabet as specified by charranges and patcodes. charranges uses the same syntax used for FOR loop ranges, for example, 48:2:57 to select the even decimal digits or 48:1:57,65:1:70 to select hexadecimal digits. patcodes specifies pattern codes used to restrict the characters to those that match the selected codes. If charset is of zero length, and is passed by reference, %RANDSTR() initializes it to the alphabet of characters defined by charranges and patcodes. If not specified, strlen defaults to 8, charranges defaults to 1:1:127 and patcodes to "AN". (GTM-6738)

  • GT.M now defers TPTIMEOUT interrupts as follows:

    • $ETRAP has been SET since the last SET of $ZTRAP, and $ECODE'="" and $TLEVEL=0, GT.M defers TPTIMEOUT until one of those conditions changes; once $TLEVEL=0 GT.M cancels rather than delivers any deferred TPTIMEOUT.

    • If $ETRAP is in control and $ECODE'="", GT.M defers TPTIMEOUT until one of those conditions changes.

    • If $ZININTERRUPT=1, GT.M defers TPTIMEOUT until that condition changes.

    GT.M delivers interrupts including TPTIMEOUTs at the beginning of the next line, the beginning of the next FOR iteration or while waiting in a command with a timeout. Previously GT.M delivered TPTIMEOUT as described in the prior sentence without regard to the error, interrupt or transaction state. In addition, GT.M does not adjust state information related to transaction retry on any error, including on the error used to signal a TPTIMEOUT. This reduces the possibility of indefinite transaction restarts. This also means that the Principal device of a process in a transaction entering direct mode now displays a TPNOTACID error. Note that GT.M does not support transaction activity in Direct Mode. FIS recommends restricting Direct Mode interaction with transactions to investigating state for debugging purposes. Previously, GT.M released the database critical section on an error or interrupt. [UNIX] (GTM-6759)

  • ZMESSAGE now treats any non-GT.M error as a trappable or fatal event. In prior releases, a ZMESSAGE argument with low order bits indicating success or information in the GT.M error designation scheme, for example ZMESSAGE 1, went to $PRINCIPAL without activating an error trap. [UNIX] (GTM-6771)

  • Label invocations using DO no longer require parentheses for calls with no actuallist. If DO or a $$ that does not specify an actuallist invokes a label with a formallist, the missing parameters are undefined in the called routine. As a result, a GT.M process no longer issues ACTLSTEXP and FMLLSTPRESENT errors, regardless of the arguments passed and parameters expected. WARNING: If DO or $$ specifies a routine but no label using an actuallist, then whether that routine's top label has a formallist or not, the actuallist applies to it directly, whereas before the actuallist would "fall through" to the first label with executable code. Previously, excluding parentheses from a DO invocation of an entryref with a formallist resulted in FMLLSTPRESENT error for local labels, and ACTLSTEXP error for labels in external routines and indirect expressions. (GTM-6813)

  • The gtm_trace_gbl_name environment variable enables GT.M tracing at process startup. Setting gtm_trace_gbl_name to a valid global variable name instructs GT.M to report the data in the specified global when a VIEW command disables the tracing, or implicitly at process termination. This setting behaves as if the process issued a VIEW "TRACE" command at process startup. However, gtm_trace_gbl_name has a capability not available with the VIEW command, such that if the environment variable is defined but evaluates to zero (0) or, only on UNIX, to the empty string, GT.M collects the M-profiling data in memory and discards it when the process terminates (this feature is mainly used for in-house testing). Note that having this feature activated for process that otherwise don't open a database file (such as GDE) can cause them to encounter an error. Previously, the only way to start tracing was with a VIEW command. As with the VIEW command, tracing initiated with gtm_trace_gbl_name can be redirected or turned off by a subsequent VIEW command.

    In addition, if a process issues a malformed VIEW command that attempts to turn tracing off, GT.M issues an error but retains all accumulated profiling data and continues tracing. If the tracing is still enabled at the process shutdown and the trace start specified a reporting location, GT.M attempts to place the trace data there. Note that if there is a problem updating the specified trace-reporting global variable, GT.M issues an error at process termination. Previously, any VIEW command that unsuccessfully attempted to transfer tracing data to a global variable turned tracing off and discarded all collected data. On UNIX, for each line executed, GT.M tracing now reports the elapsed time in addition to CPU times (user, system, and combined).

    It also reports two aggregate entries for UNIX and one on OpenVMS, "*RUN" for the current process and, on UNIX, "*CHILDREN" for all of child processes spawned by the current process, each containing user, system, and combined CPU times. Previously, the trace facility did not report these details of the child processes for the ZSYSTEM command and PIPE devices that are closed before the trace data is reported. The "CHILD" category data excludes processes that result from the JOB command, PIPE devices OPENed with the INDEPENDENT device parameter and processes from PIPE devices that are still active. Note that M-profiling is currently disabled for DAL calls on OpenVMS. (GTM-6819)

  • GTM now correctly processes WRITE mnemonics for GTM socket devices. Previously,a WRITE mnemonic usage such as WRITE /LISTEN or WRITE /WAIT without the depth value (for /LISTEN) or without a timeout (for /WAIT) could cause either a INVCTLMNE error or an addressing exception (signal-11 (UNIX) or ACCVIO (VMS)). (GTM-6836)

  • The GT.M parser now appropriately recognizes the end of a source line. Previously it preprocessed the next character, which resulted in an inappropriate SPOREOL error if the two last lines in a routine had certain odd characteristics. The workaround was to add another line to the routine - either empty or comment lines work if a QUIT is not appropriate (GTM-6845)

  • $ZDATE() generates a ZDATEBADDATE for input date values greater than 31-Dec-999999 (364570088) or less than 01-JAN-1840 (-365), a ZDATEBADTIME for time values greater than a second before midnight (86399) or less than 0 (zero). Previously if the input was too large (either positive or negative), the process might produce meaningless output or terminate with a segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO). Because invalid conditions that used to be ignored are now treated as errors, this change might require revisions to existing application code. (GTM-6851)

  • GT.M now evaluates functions with side effects - extrinsic functions ($$), external functions ($&) and $INCREMENT() in left-to-right order when in full_boolean mode. In V5.4-002 it evaluated those functions early to ensure they were not skipped by the default GT.M short-circuit optimization, however this could cause their side-effects to occur out of order. (GTM-6854)

  • GT.M correctly compiles expressions like if a<$$x(b-c) when specifying FULL_BOOLEAN. Previously this combination caused a GTMASSERT. (GTM-6856)

  • MERGE now gives no error when the source variable and the destination variable are identical. Previously it would give a MERGEDESC error message. (GTM-6935)

  • $ZTRNLNM() now recognizes all the documented keywords including all the OpenVMS keywords. FULL and VALUE (the default) return the translation and LENGTH returns the length. Other keywords select default values. Many of the keywords return the empty string if the item to translate has no value. Previously it only recognized "FULL". Note that on UNIX $ZTRNLNM() does not do iterative translation. [UNIX] (GTM-6957)

  • 64-bit GT.M editions - currently those except HP Alpha (OpenVMS and Tru64), HP PA-RISC (HP-UX), and 32-bit x86 (Linux) - now pass 64-bit long and ulong values between C and M though the call-out and call-in interfaces. GT.M represents values that fit in 18 digits as numeric values, and values that require more than 18 digits as strings. M code may use these strings in a numeric context, but the numeric result has less precision than the original value. Note that this change may expose latent problems if a call-in definition file contains incorrectly typed values. Prior versions truncated long and ulong values passed between C and M through the these interfaces to 32-bit int values even on 64-bit platforms. (GTM-6994)

  • A ZSHOW "D" that includes one or more SOCKET devices manages memory in a stable fashion. In prior versions, each such ZSHOW leaked a small amount of memory. (GTM-6996)

  • The INDEPENDENT device parameter now has the correct behavior for all shells. Previously, the subprocess started by the PIPE device would not continue to run after the PIPE device was closed for some shells, such as the Bourne shell. The RENAME device parameter now correctly renames a sequential file if it is followed by another device parameter. Previously, the new file name of the sequential file could contain information from the following parameter. [UNIX] (GTM-7002)

  • GT.M now handles nesting of XECUTE strings that contain subscripted FOR control variables. In V5.4-002x such constructs could result in a memory segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO). (GTM-7007)

  • GTM correctly handles an indirect DO without arguments (e.g. DO @x) inside an XECUTE argument. In prior versions, this construct caused a GTMASSERT or an addressing exception. (GTM-7008)

  • GT.M now issues a DEVOPENFAIL error for a PIPE device if either the SHELL or STDERR device parameters are set to the null string. Previously, the open error was ignored and any subsequent ZSHOW "D" caused a SIG-11. In addition, the DEVOPENFAIL error message for a PIPE device now outputs the device name. Previously, it output the device type. [UNIX] (GTM-7123)

  • GT.M uses an additional form of GTMASSERT error - GTMASSERT2, which adds information about the failing condition. This additional information may only be useful to FIS or others familiar with GT.M internals. 次に例を示します。

    %GTM-F-GTMASSERT2, GT.M V5.5-000 Linux x86 - Assert failed /usr/library/V994/src/mdb_condition_handler.c 
    line 490 for expression (TPRESTART_STATE_NORMAL == tprestart_state)
    %GTM-F-GTMASSERT2, GT.M V5.5-000 Linux x86 - Assert failed /usr/library/V994/src/gds_rundown.c 
    line 543 for expression (NULL != csa->wbuf_dqd)

    GTMASSERT and GTMASSERT2 indicate GT.M has detected a condition that seems to violate a design assumption and should be reported to your GT.M support channel. Prior versions did not provide the additional diagnostic information reported by GTMASSERT2. (GTM-7078)

  • ZBREAK and ZPRINT() now issue errors when invoked with an indirect routine name that evaluates to the empty string other than a string literal, for example, the return from a $GET(). Previously this construction caused a memory segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO). (GTM-7176)

  • The MERGE command now counts global gets as well as updates in the database counters displayed with ZSHOW "G" and DSE. Previously MERGE only counted the update portion of its work. (GTM-7179)

  • FOR now evaluates a termination value specified with a subscripted local variable at loop initiation. Previously it incorrectly reevaluated the termination value at each iteration. (GTM-7185)

  • On platforms where the information is unavailable error messages that report the address of an event now report a hexadecimal -1 (all F's). This information in a message is typically of use only to FIS or others who work with the GT.M implementation code. Previously GT.M reported a zero (all 0's) address in such cases, which called into question whether the error message was properly constructed. [UNIX] (GTM-7188)

  • M-profiling no longer leaks memory. Previously, processes using M-profiling experienced a memory leak and could run out of memory when running code with repetitive function invocations. Also, M-profiling no longer receives a SIGSEGV signal during process termination. Previously, a tracing-enabled GT.M process interrupted at an inopportune time could die with a SIGSEGV condition. In addition, M-profiling correctly reports each label count entry. Previously, such it did not report entries for labels invoked with a DO command inside a FOR construct that used a variable rather than a literal for the termination value. (GTM-7196)

  • GT.M completely removes all trigger artifacts during an unlink using the form ZGOTO 0:entryref. Previously, GT.M removed the code but left some trigger-related structures behind, which could cause memory segmentation violations (SIG-11) or other bad behavior. [UNIX] (GTM-7206)

  • In OpenVMS, GT.M more reliably reports the name of an undefined unsubscripted local variable. Previously, depending on circumstances, the UNDEF error message sometimes failed to report the variable name. [OpenVMS] (GTM-7210)

  • The GT.M LOCK manager now guards against unlikely, but possible, mismanagement of LOCK resources. This is not an issue that we are aware of anyone ever encountering, but is analogous to a relatively uncommon issue we saw with local variables on certain x86 Linux releases. Previously GT.M could, at least in theory, fail to properly maintain resource names. (GTM-7214)

  • At runtime, gtm_zquit_anyway environment variable causes code of the form QUIT <expr> execute as if it were SET <tmp>=<expr> QUIT:$QUIT tmp QUIT, where <tmp> is a temporary local variable in the GT.M runtime system that is not visible to application code. This mode no longer relies on the GT.M compiler. Previously, the gtm_zquit_anyway environment was used when compiling code, and caused code of the form QUIT <expr> to be compiled as QUIT:$QUIT <expr> QUIT. While FIS normally avoids changing GT.M behavior in any way that is not upward compatible, in this instance FIS has worked with users of gtm_zquit_anyway to determine that this changed behavior is more appropriate to existing applications. (GTM-7215)

  • The LOCK (and ZALLOCATE and ZDEALLOCATE) commands now manage LOCK resource names more efficiently in LOCK_SPACE. Previously they used more space than they really needed and could lose efficiency or generate an error when it was unnecessary. (GTM-7228)

  • A JOB command with no parameters created by a JOB'd process with one or more parameters receives no parameters. Previously the JOB command with no parameters inappropriately received the first parameter of the JOB'd parent process. [UNIX] (GTM-7234)

MUPIP ユーティリティ

  • MUPIP REORG -TRUNCATE[=percentage] specifies that REORG, after it has rearranged some or all of a region's contents, should attempt to reduce the size of the database file and return free space to the file system. The optional percentage (0-100) provides a minimum amount for the reclamation; in other words, REORG won't bother performing a file truncate unless it can give back at least this percentage of the file; the default (0) has it give back anything it can. TRUNCATE always returns space aligned with bit map boundaries, which fall at 512 database block intervals. TRUNCATE analyses the bit maps, and if appropriate, produces before image journal records as needed for recycled (formerly used) blocks; The journal extract of a truncated database file may contain INCTN records having the inctn opcode value 9 indicating that the specific block was marked from recycled to free by truncate. TURNCATE only works on V5 databases - it does not work on database files that contain unconverted V4 format blocks. TRUNCATE does not complete if there is a concurrent online BACKUP or use of the snapshot mechanism, for example by INTEG. [UNIX] (GTM-3873)

  • The NOREPLCTDREG error message now correctly identifies the reported context as the instance file. Previously since the introduction of multi-site replication on UNIX that error mislabeled the file as a global directory. The label has not changed on OpenVMS, where it is correct. [UNIX] (GTM-4202)

  • MUPIP REORG now takes an optional -REGION qualifier. MUPIP REORG -REGION <region-list> reorganizes each global in the specified regions. Note that a global must be in the global directory in order for MUPIP REORG to process it. Previously, REORG would reorganize every global in the global directory unless specific globals were selected with -SELECT or EXCLUDE. Note that MUPIP REORG previously supported a -REGION qualifier, but only in conjunction with the -UPGRADE and -DOWNGRADE qualifiers. (GTM-5797)

  • GT.M replication supports Supplementary Instances - instances which both receive updates from some other originating instance and local updates. Please refer to the Supplementary Instance Technical Bulletin for detailed information.

    The project to introduce this feature also addressed the following changes most, but not all, of which apply only to UNIX editions:

    • The -updateresync qualifier now requires a value, the name of an instance file. If you are following the previous procedure, you need to modify your scripts. As we bring you new Supplementary Instance replication, we regret our inability to maintain strict upward compatibility with prior GT.M releases with respect to this occasionally-used qualifier. [UNIX]

    • The journal extract file format has changed- please see Documentation Addendum

    • The argumentless MUPIP RUNDOWN command has been significantly reworked to work in various situations that it did not previously. [UNIX]

      • It now correctly cleans up orphaned journal pool shared memory and reports its actions. Previously it used to report a successful rundown when it actually did not do the rundown.

      • It now gives more details in case it is not able to rundown: for example:

        • If rundown encounters a journal pool with a different format, it now indicates the format and the GT.M version that created the journal pool in addition to indicating the format that the current MUPIP can handle. Previous versions did not indicate any of this.

        • If rundown encounters a database shared memory created by a different version of GT.M, it now indicates the database shared memory ID. Previous versions did not indicate this.

      • It now preserves shared memory IDs whose corresponding database or replication instance file cannot be opened (e.g. due to permissions). In GT.M V54002B, it silently deleted such shared memory segments.

      • It now cleans up as many GT.M created orphaned ipcs (shared memory segments and semaphores) as possible. Previously, if it encountered an error while cleaning up one ipc it terminated with an error instead of proceeding to the next available ipc.

      • The SHMREMOVED error message that RUNDOWN prints now indicates the database file or instance file name corresponding to the shared memory ID which it removed. Previously it did not provide this information.

    • In a replicated environment, GT.M now maintains a non-decreasing timestamp sequence in the journal file in all cases. Previously in some rare cases of concurrent processes doing multi-region TP transactions, it was possible to write an out-of-order timestamp sequence, which in turn could cause a MUPIP JOURNAL ROLLBACK to treat transactions that could be replayed as lost.

    • When a Source Server and Receiver Server connect with each other, they now correctly ensure their two instances are in sync before proceeding with replication. Previously the instance file histories did not contain sufficient detail to detect a number of mismatched conditions. [UNIX]

    • MUPIP SET JOURNAL now issues a FILEEXISTS error in various situations when it is unsafe to create a new journal file by renaming the existing file because it is not a valid current generation journal file pointing to the specified database file. Examples of such unsafe situations are, (i) if one unintentionally specifies the new journal file name to be an existing actively used database file name, (ii) a backup database points to the same journal files as the source database and a journal switch is attempted on the backup database. Previous versions used to incorrectly allow such switches with potentially serious operational consequences. [UNIX]

    • The PREVJNLLINKCUT message issued by a MUPIP SET JOURNAL command, now contains the correct new journal file name. Previously it displayed the journal file name stored in the database file header before the journal switch which might not always be the same as the new journal file name.

    • MUPIP REPLIC -EDITINST command, which allows edits to a replication instance file, now supports the -NAME=<new-name> qualifier where the new-name value is required. This changes the instance name in the replication instance file header to the newly specified name. It is now possible for new instances to be created without requiring a new instance file, loss of instance history, and use of the -updateresync qualifier when starting the Receiver Server for the first time.  The previous procedure to create a new instance was to ship a backup of another instance's database and recreate the instance file on the target instance. Although you can still use the older procedure with a modification to add an instance file name argument to the -updateresync qualifier, FIS recommends the following procedure as more robust way to create a new instance:

      • Use the MUPIP BACKUP command with the -REPLINSTANCE qualifier to backup the instance to be copied.

      • Ship the backed up databases and instance file to the target system.

      • Run the MUPIP REPLIC -EDITINST command on the backed up instance file to change the instance name to reflect the target instance. This makes the source replication instance file usable on the target instance while preserving the history records in the instance file.

      • Create new journal files, start a passive Source Server and a Receiver Server (without an -updateresync qualifier).

      • Allow a Source Server to connect.

    • The MUPIP replication commands recognize the -UPDOK qualifier as a preferred synonym for the -ROOTPRIMARY qualifier; they also recognize the -UPDNOTOK qualifier as the negation of -UPDOK and the preferred synonym for -PROPAGETPRIMARY.

    • The Receiver Server log now indicates the current journal sequence number of the replication instance at shutdown. Previously, it only printed the receive pool journal sequence number. [UNIX]

    • The Update Process logs now indicate the current journal sequence of the replication instance at the time the Update Process is shutdown. Previously, it only logged how many sequence numbers it had processed.

    • The Source Server and Receiver Server logs now indicate whether the other side is the same or opposite endianness relative to their side of the replication stream.

    • Because it controlled a field in the file header that was relevant only for releases prior to V5.1-000, starting with V5.5-000, DSE ignores CHANGE -FILE -DUALSITE_RESYNC_SEQNO; V5.5-000 and later versions do not support replication with versions prior to V5.1-000.

    • GT.M utilities like MUPIP, DSE, LKE etc. now produce time-ordered, and hence more easily understood, output in case the output and error streams (stdout and stderr) are redirected to the same logfile. Previously, in some cases, the logfile might have messages from the two streams mixed in the same file without maintaining the relative time order of when the process issued those messages. This meant a later message came ahead of an earlier message and resulted in confusing log files but only if both stdout and stderr were redirected to the same logfile. Since the replication server logfiles (Source Server, Receiver Server, Update Process) have this redirection inherently built in, they were also affected by this issue.

    • Copying and pasting a sequence of shell commands, that include MUPIP commands, into a terminal session now works appropriately. In previous versions, a MUPIP command stopped execution of such a sequence of commands. [UNIX] (GTM-6340)

  • The Source Server exits with error JNLNOREPL if it opens a journal file and finds that replication was not on for that journal. Also it retries any journal file read in the current journal file that returns an incomplete record; in UNIX, if it reads an incomplete record from a previous generation journal file, it exits with a JNLRECINCMPL error. Previously, these two conditions caused a GTMASSERT. Also, in UNIX, a Source Server does not switch to a new journal if it fails to open the currently active journal file. Additionally, MUPIP SET JOURNAL reports the PREVJNLLINKSET message in the operator log in addition to the operator terminal. Previously, those were only reported to the terminal. (GTM-6736)

  • A Receiver Server started with the -UPDATERESYNC qualifier starts every Source Server connection handshake during its own lifetime with that characteristic. Previously, a Receiver Server based only the initial handshake for its first connection on the -UPDATERESYNC qualifier, which meant any errors that closed the connection caused it to reconnect in a way that likely caused a REPLINSTNOHIST error. (GTM-6650)

  • A MUPIP action (RECOVER or ROLLBACK) that restores V4 format blocks to a database that had completed a transition from V4 to V5 format (using MUPIP REORG -UPGRADE) sets the indicator that the database still contains blocks in V4 format. Previously, such a sequence caused the database logic to incorrectly stop checking for V4 format blocks, which could, in rare cases, cause database corruption. The workaround was to take a BACKUP with fresh journal files immediately after completing the MUPIP REORG -UPGRADE. (GTM-6725)

  • A replication filter no longer needs to package a simple update as a transaction. This change enables the use of filters such as the UNIX tee utility. GT.M also no longer requires the external filter pipe buffer be large enough to accommodate the entire largest transaction. If an external filter returns a bad record, GT.M issues a FILTERBADCONV error. Previously, GT.M required the external filter to return all transactions wrapped as TP transactions, even if they were originally non-TP single updates (mini-transactions), would hang if a transaction exceeded the buffer size for the pipe, and would loop indefinitely if the filter returned a defective record. Note that GT.M still requires that a filter maintain a one-to-one relationship between input and output transactions, as documented. [UNIX] (GTM-6826)

  • MUPIP JOURNAL -ROLLBACK -FETCHRESYNC (or -RESYNC) now correctly recovers the database and creates a correct unreplicated (lost) transaction file in cases where a second command specifies a later point in time than the prior interrupted command. In prior versions, such a change sequence might create an incorrect recovery. In addition, MUPIP RECOVER -BACKWARD restricts processing that identifies broken transactions to the most recent journal file(s). Previously, backward recovery extended transaction validity checking all the way to the turnaround point at which it starts forward processing, which unnecessarily required more memory and potentially failed if that memory was not available. Also, now the -RESYNC ROLLBACK is more memory efficient and uses approximately same amount of memory as -FETCHRESYNC ROLLBACK uses. Previously -RESYNC required more memory than -FETCHRESYNC to accomplish the same thing. Note that -RESYNC is intended for use when advised by your GT.M support channel and is not recommended for routine normal use. (GTM-6834)

  • The Source Server no longer hangs while waiting for a the message used in the initial handshake between a Source and Receiver Server to determine if compression can be turned on to send journal records across. In previous versions of GT.M, if a Receiver Server sent a flow control messages just before sending the REPL_CMP_SOLVE message (which appears in the Receiver Server log), the Source Server hung. [UNIX] (GTM-6841)

  • Cross-endian replication now works correctly in various scenarios. Previously, any abnormal events on the receiver side (e.g. draining the replication pipe in case of Update Process crash or a bad transaction etc.) could result in a hang on the Receiver Server. Note that cross-endian replication is handled robustly by GT.M V5.5-000 only if both the source and receiver sides run that version. If not, only a few combinations are supported. Below is the list.

    1. If GT.M V5.5-000 is on one side of a replication connection, the minimum version supported on the other side is GT.M V5.1-000 when both sides have the same endianness

    2. In case of a cross-endian connection involving GT.M V5.5-000 on the source side, the minimum version supported on the receiver side is GT.M V5.4-002. Even though versions prior to V5.4-002 work in most usual situations, they do not robustly handle abnormal events and might hang

    3. In case of a cross-endian connection involving GT.M V5.5-000 on the receiver side, the minimum version supported on the source side is V5.3-003 (the earliest version for which cross-endian replication is supported). [UNIX](GTM-6896)

  • KILLs of non-existent global nodes (henceforth referred to as duplicate KILLs), which are possible for example if the global mapping is changed in the gld file on the replicating instance, are now handled robustly on the Update Process side by maintaining the journal sequence numbers of the originating instance and its replicating instances in sync. Previously, in this scenario, the Update Process printed a "Number of transactions from Primary which did NOT update JNLSEQNO on Secondary" message in its log indicating the sequence number at which the duplicate KILL occurred but continued processing even though the two instance sequence numbers were no longer in sync. This gave a false impression the two instances were in sync when they actually were not. Additionally, if an update that is played on the Update Process side does not increment the journal sequence number of the replicating instance, the Update Process prints the "Number of transactions from Primary which did NOT update JNLSEQNO on Secondary" message in its logfile and terminates. Previously, it used to continue processing thereby making it very difficult to get the two instances back in sync. (GTM-6898)

  • MUPIP INTEG and MUPIP JOURNAL -ROLLBACK or -RECOVER handle database files larger than one terabyte. Previously GT.M gave a DBFILOPERR error with a secondary error of invalid argument (ENO22 on UNIX) when they attempted to access data higher than 1TB (GTM-6958).

  • GT.M ensures not even a single update can occur during a MUPIP FREEZE. This issue was primarily addressed by C9J01-003076 in V5.3-004, however, we discovered one subtle case where under high update contention, a single update from MUPIP REORG might squeeze in right after a FREEZE. (GTM-7004)

  • MUPIP LOAD can now read from the standard input by specifying the -STDIN qualifier instead of a file-name. [UNIX] (GTM-7016)

  • MUPIP JOURNAL RECOVER or ROLLBACK -BACKWARD now processes multi-region TP transactions appropriately even if they are broken. Also, the Source Server avoids writes to the database and/or journal as much as possible. In versions starting with V5.4-000, RECOVER or ROLLBACK terminated with a GTMASSERT error if they encountered a complete transaction after a broken transaction. Previously the Source Server could write an INCTN journal record in cases where the database cache integrity was suspect. Both of these issues arose after processes were terminated abnormally, typically with a kill -9 - FIS strongly recommends against using kill -9 on GT.M processes, as it can cause database damage when used to terminate a process that is actively updating a database. (GTM-7034)

  • MUPIP EXTRACT -FORMAT=BIN now handles database blocks of maximum size. Previously it failed with a "%SYSTEM-E-ENO14, Bad address" error in UNIX or a "%RMS-F-RSZ, invalid record size" error in OpenVMS" (GTM-7077)

  • MUPIP JOURNAL -SHOW=ALL output now shows counts of all Record Types correctly up to 1 billion. Previously, a Record Type count more than 1 million showed as '*******'. (GTM-7079)

  • With a "-stdout" (case ignored) as the argument of its -EXTRACT qualifier, the MUPIP JOURNAL command now writes its output to standard output instead of creating a file with the name "-stdout". Although this alters existing GT.M behavior, FIS believes that using "-stdout" to direct output to stdout is more useful than creating a file with a name that makes it awkward to read and process. In addition, MUPIP JOURNAL -EXTRACT now ends with the last extracted journal record. Previously it placed a blank line at the end of the file. [UNIX] (GTM-7082)

  • The Update Process and journal recover/rollback now correctly handle a NULL type journal record. Previously, they skipped a check on the maximum available space in the current journal file (based on the journal file autoswitchlimit) while writing the NULL journal record. This resulted in the journal file space getting filled up so eventually there is no room left in it for writing even one journal record. At that point, a journal file switch is unavoidable because there is no space but is also impossible because the switching routine needs to write one journal record to the current journal file. This caused them to go into an indefinite recursion eventually running out of C-stack space and terminating abnormally as well as leaving the journal file in an out-of-design state. Any other process that next does a global reference in this database ended up with the same situation leading to a cascade of process terminations and an unusable journal file. (GTM-7230)

ユーティリティ(MUPIP以外)

  • DSE FIND -SIBLING now shows the current block in addition to any left and right siblings - all designated in hexadecimal. Previously the command only reported the two siblings when they were in the same branch of the tree, and while the representation was also in hexadecimal notation, it could be ambiguous. In addition, DSE FIND now correctly represents blocks in the global directory tree when they are selected. Previously FIND did not show block one and could represent other directory tree blocks as if they had been in a global tree. (GTM-2296)

  • GDE and MUPIP now allow the user to set the journal extension size to a maximum of 1073741823 blocks on Unix; the VMS maximum remains at 65535 blocks. This feature required a change to the Global Directory (GLD) file format; the file must be upgraded using GDE. (Refer to the section on Upgrading Your Global Directory.) Note that older versions of GT.M cannot read the upgraded GLD files. Previously, GDE and MUPIP limited the journal extension size to 65535 blocks on all platforms.

    GDE now supports AUTOSWITCHLIMIT as an option for the -JOURNAL region qualifier. GDE stores the value in the global directory, and MUPIP now uses the value from the global directory when initializing a region in place of the old default. However, the default AUTOSWITCHLIMIT value for GDE is the same as the old default for MUPIP CREATE, so the default result is unchanged. [UNIX]

    When you specify values for ALLOCATION, EXTENSION, and AUTOSWITCHLIMIT for a region such that (ALLOCATION+EXTENSION>AUTOSWITCHLIMIT), either using GDE or MUPIP SET -JOURNAL, the utility sets ALLOCATION to match the AUTOSWITCHLIMIT, and outputs a GDE-I-JNLALLOCGROW or GTM-I-JNLALLOCGROW message, respectively. [UNIX]

    At journal extension time, including journal autoswitch time, if (ALLOCATION+EXTENSION>AUTOSWITCHLIMIT) for a region, GT.M now uses the larger of EXTENSION and AUTOSWITCHLIMIT as the increment to warn of low available journal disk space. Otherwise, it uses the EXTENSION, as before. [UNIX]

    The GDE CHANGE -REGION -JOURNAL command no longer forces the EXTENSION to be the same as the specified ALLOCATION if the EXTENSION is not also specified. The previous behavior was documented for OpenVMS, but not for UNIX. (GTM-6224)

  • Corrected typos in the DBCDBNOCERTIFY and JOBEXAMFAIL error messages, a message from MUPIP RESTORE and, on OpenVMS, to the gtmkitinstal.com. (GTM-6849)

  • On platforms where GT.M supports object code in shared libraries, the configure script which installs GT.M now automatically creates a shared library libgtmutil.so containing the object modules of the routines distributed with GT.M that are written in M (GDE and utility programs). The "configure" installation script asks a question as to whether to delete the .o files as part of the installation. They can safely be deleted as long as the $gtmroutines environment variable ($ZROUTINES intrinsic special variable) specifies the libgtmutil.so file rather than the installation directory ($gtm_dist). The "gtminstall" installation script includes a --keep-obj command line switch and associated gtm_keep_obj environment variable (supporting "Y" and "N" values) that instructs the configure script not to delete object files. Note that some platforms use a .sl or .dll extension for shared libraries, rather than .so. The gtmprofile script that you can source to set up a default GT.M environment automatically uses libgtmutil.so if it exists. In addition, if there are any shared libraries in the $gtmdir/$gtmver/o directory ($gtmdir/$gtmver/o/utf8 for processes in UTF-8 mode), the gtmprofile script automatically includes them in the gtmroutines environment variable. Previously gtminstall, gtmprofile and configure scripts did not deal with shared object libraries. Furthermore, the gtmprofile script now provides a framework to extend GT.M with plug-ins. Place the M code in $gtm_dist/plugin/r, the M mode object code in the $gtm_dist/plugin/o directory and UTF-8 mode object modules in the $gtm_dist/plugin/o/utf8 directory. On platforms where GT.M supports object code in shared libraries, you can create shared libraries instead of .o files. The gtmprofile script now automatically includes these in the gtmroutines environment variable. [UNIX] (GTM-6664)

  • DSE DUMP -FILE -ALL output prints journal record types in hexadecimal. Since V4.4-002 these numbers have been printed in decimal which, if the numbers exceeded seven characters, overflowed the format and filled the output field with asterisks (*). (GTM-6860)

  • %RO now leaves trailing spaces intact and strips comments correctly. Previously it would strip trailing spaces from the end of each line in selected files, and it would mistake semicolons within quotes for comments. (GTM-6939)

  • GDE now generates a FILENOTFND message when it fails to open a command file, and a CRYPTNOMM message when it attempts to save a global directory with both encryption and MM access method set. Previously it would generate the undocumented FNF and ENCNOMM messages, respectively. (GTM-7005)

  • The size of the installation kit has been reduced by removing the file GTMDefinedTypesInit.o and creating a new GTMDefinedTypesInit for the distribution. This new kit contains the file GTMDefinedTypesInit.m from which GTMDefinedTypesInit.o can be created as needed. Previously, these were included in the installation kit. As the GTMDefinedTypesInit module is not needed for normal GT.M operation and is intended for use in diagnostic purposes under the guidance of FIS GT.M support, you do not need to download and install it except when so directed by FIS GT.M support. In addition, certain shell scripts have been removed from $gtm_dist. These scripts are not documented in GT.M user documentation but were inadvertently included in GT.M distributions. Also, when lowercase utility programs are requested during a UTF-8 mode GT.M installation, the configure script now supplies the programs in $gtm_dist/utf8 using symbolic links to the files in $gtm_dist, as it does for the upper case names. Previously, the lowercase .m files were copied from $gtm_dist. [UNIX] (GTM-7021)

  • LKE now issues NOLOCKMATCH when a non-existing lock is searched with "show l[ock]=<resource>" or attempted to be released using "clear l[ock]=<resource>". Previously, it issued the following text: "No locks were found in <region>" (GTM-7027)

  • GCC 4.6, which is part of the toolchain on Ubuntu 11.10, passes additional flags to the linker which prevent linking of libraries without direct dependencies. Previously, if a library was specified on the command line without direct dependencies, but that library's dependencies resolved a program dependency, the library would still be included. GT.M links libgtmshr against librt to get semaphore support, but semaphores are actually provided by libpthread, which is a dependency of librt. This caused builds to fail on Ubuntu 11.10 with a message that "sem_post" is not found. This change is of interest only for users who build GT.M from source. [UNIX] (GTM-7029)

  • LOCK commands which find no available lock space send a LOCKSPACEFULL message to the operator log. To prevent flooding the operator log, GT.M suppresses further such messages until the lock space usage drops below 75% full. In addition, LKE SHOW displays lock space usage with a message in the form of: "%GTM-I-LOCKSPACEUSE, Estimated free lock space: xxx% of pppp pages." If the lock space is full, it also displays a LOCKSPACEFULL error. Previously, GT.M did not issue such messages. (GTM-7073)

  • GT.M utilities now give a CLIERR error when an equal-sign (=) follows a qualifier without an immediately following value. Previously GT.M handled this case either with a different error or by ignoring the command without reporting any error. [UNIX] (GTM-7110)

  • All GT.M distribution kits now include a README.txt file which clarifies license related text in the header of each source file and its relationship to the COPYING file. Previously, this information was not provided. Output from the configure script has been changed to omit the word "National" and to refer appropriately to UTF-8. [UNIX] (GTM-7224)

エラーメッセージ

We are introducing the term "Group" to mean a set of one or more instances that replicate from or to one another and all represent the same logical state of an application. Operators can reconfigure the Group members to change which is the Originating Instance, how many Replicating Instances participate and how (the paths by which) the Replicating Instances receive their updates. Members cannot move from one Group to another although the resources they use can be moved by replacing all their state, using a backup that moves both database files and an instance file to create a new instance with a current or past state of the new Group. GT.M implicitly forms a Group by propagating the identification of the Originating Instance to each Replicating Instance. Supplementary Instances form groups that are different than non-Supplementary Instances; the originating member of a Supplementary group, started with -UPDOK, can replicate from other Groups and also perform local updates.

The new and revised error message(s) for V5.5-000 are as follows:

ACTLSTEXP

ACTLSTEXP, Actuallist expected

Obsolete Error: No longer issued by GT.M

BADREGION

BADREGION, Region is not BG, MM, or CM

LKE Error: The current global directory attempted to map a region with an access method other than those listed.

Action: Use LKE only with database mapped to one of the listed database access methods.

COREINPROGRESS

COREINPROGRESS, Previous core attempt failed; core generation bypassed.

Run Time Error: This indicates that the process, which failed, was unable to create a memory dump file and tried to create another one.

Action: Report the entire incident context to your GT.M support channel for further analysis.

DBCDBNOCERTIFY

DBCDBNOCERTIFY, Database xxxx HAS NOT been certified due to the preceding errors - rerun DBCERTIFY SCAN

Mupip Error: MUPIP UPGRADE for V5 triggers this error if it finds the DBCERTIFY CERTIFY command has not run to completion on database xxx.

Action: Complete the scan phase of DBCERTIFY by executing the DBCERTIFY SCAN command.

DBFLCORRP

DBFLCORRP, xxxx Header indicates database file is corrupt

Run Time/MUPIP Error: This indicates that a database operation tried to activate database file xxxx, which was previously marked as damaged.

Action: If ROLLBACK (either -NOONLINE or -ONLINE) terminates abnormally (say because of a kill -9), it leaves the database in a potentially inconsistent state indicated by the FILE corrupt field in the database file header. When an ROLLBACK terminates leaving this field set, all other processes receive DBFLCORRP errors any time they attempt to interact with the database. The best way to clear DBFLCORRP is by running another ROLLBACK. MUPIP SET -FILE -PARTIAL_RECOV_BYPASS and DSE CHANGE -FILE -CORRUPT=FALSE -NOCRIT can also clear this condition but these commands do not ensure that the database has consistent state so you should always run MUPIP INTEG after executing these commands.

DBROLLEDBACK

DBROLLEDBACK. Concurrent ONLINE ROLLBACK detected on one or more regions. The current operation is no longer valid>/error

Run Time Error: This indicates a non-TP mini-transaction attempted to interact with the database and found that a concurrent online rollback had taken the database to a state earlier than the one at the end of the last mini-transaction by this process unless there has been an intervening TP transaction.

Action: Application dependent - this error indicates a discontinuity in the database state that may cause inconsistent application data.

DSEWCREINIT

DSEWCREINIT, Database cache reinitialized by DSE for region rrrr

DSE Information: This indicates a DSE operator action to rebuild the database cache for region rrrr.

Action: None required.

FMLLSTPRESENT

FMLLSTPRESENT, The actual list is absent from a call to a label with a formal list: xxx

Obsolete Error: No longer issued by GT.M

GTMASSERT2

GTMASSERT2, GT.M eeee - Assert failed LLLL for expression (eeee)

Compile/Run Time Fatal Error: This indicates a design assumption failed at the location LLLL because the expression eeee was FALSE.

Action: Preserve the core (dump) files and report the entire incident context to your GT.M support channel for further analysis. If appropriate, verify database integrity by using the -FAST qualifier.

IGNBMPMRKFREE

IGNBMPMRKFREE, Ignoring bitmap free-up operation for region rrrr (dddd) due to concurrent ONLINE ROLLBACK

Run Time Information: A multi-node KILL bit map cleanup operation detected a concurrent online rollback in region rrrr mapped to database file dddd, and abandoned the cleanup, possibly leaving incorrectly marked busy errors.

Action: If there are incorrectly marked busy errors, match them with this cause and clean them up using DSE.

INSNOTJOINED

INSNOTJOINED, Replicating Instance RRRR is not a member of the same Group as Instance IIII

MUPIP Error: Issued by a Receiver Server or a MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on instance RRRR attempted to connect with Instance IIII, and found they are members of different Groups. Only Supplementary Instances started with -UPDOK can accept updates from a different Group.

Action: Analyze the move and if appropriate, reinitialize the instance that is moving from one Group to another.

INSROLECHANGE

INSROLECHANGE, Supplementary Instance SSSS and non-Supplementary Instance IIII belong to the same Group

MUPIP Error: Issued by a Receiver Server or a MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on Supplementary Instance SSSS attempted to connect to non-Supplementary Instance IIII, but found they have the same Group identification. Because supplementary and non-Supplementary Instances cannot belong to the same Group, one of these instances must have changed roles without appropriate re-initialization.

Action: Either reinitialize the instance that is changing roles or revert the inappropriate role change.

INSUNKNOWN

INSUNKNOWN, Supplementary Instance SSSS has no instance definition for non-Supplementary Instance IIII

MUPIP Error: Issued by a Receiver Server or a MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on Supplementary Instance SSSS, started with -UPDOK, attempted to connect to non-Supplementary Instance IIII, but found it has no matching instance information.

Action: Take a backup of the database and replication instance file from a current instance on the non-Supplementary Group, load the backup data on the Supplementary Instance and start the Receiver Server on the supplementary instance using -UPDATERESYNC=<instbak.repl> where instbak.repl is the backup of the replication instance file taken along with the database backup.

INVTRCGRP

INVTRCGRP, Invalid trace group specified in $gtm_trace_groups: gggg

Run Time Error: The process startup environment attempted to activate a diagnostic tracing facility but specified a group name of gggg and there is currently no such group.

Action: Check with your GT.M support channel for the currently available group names.

JIUNHNDINT

JIUNHNDINT, An error during $ZINTERRUPT processing was not handled: eeee;

Run-time Error: When returning from code invoked by MUPIP INTRPT (clearing $ZININTERRPT), GT.M implicitly clears any error(s) detected while 1=$ZININTERRUPT, sends this error notification to the operator log and continues processing; eeee is the mnemonic for the unhandled error.

Action: Fix $ZINTERRUPT handler to either not generate the error or to correctly handle it before returning to interrupted code

JOBEXAMFAIL

JOBEXAMFAIL, GT.M process aaaa executing $ZJOBEXAM function failed with the preceding error message

Run Time Error: This is a secondary message that accompanies a $ZJOBEXAM function error. This error message is sent to the operator log.

Action: Review the accompanying message(s) and take appropriate action.

JNLALLOCGROW

JNLALLOCGROW, Increased Journal ALLOCATION from [ssss blocks] to [aaaa blocks] to match AUTOSWITCHLIMIT for ffff nnnn

GDE or MUPIP Information: The utility increased the journal allocation value from ssss to aaaa for the journal files associated with ffff nnnn, which is either "database file" followed by a database file name or "region" followed by a region name. This indicates that the specified journal allocation and journal extension values combined exceed the specified journal autoswitchlimit and the utility has adjusted the journal allocation value accordingly.

Action: None required.

JNLNOREPL

JNLNOREPL, Replication not enabled for journal file jjjj (database file dddd)

MUPIP Error: Replication Source Server startup encountered a database dddd with journal file jjjj for which replication was turned off because of a journaling issue and has not since been re-enabled.

Action: Use MUPIP SET to re-enable replication. Take steps to ensure that there is sufficient management of journal file space to prevent a reoccurrence of this issue.

JRTNULLFAIL

JRTNULLFAIL, Applying NULL journal record failed. Failure code: xxxx.

MUPIP Error: Issued by an Update Process, MUPIP JOURNAL -ROLLBACK or MUPIP JOURNAL -RECOVER indicating it encountered a database problem when it attempted to play a NULL journal record into the database. xxxx contains the failure codes for the four attempts. It is very likely that the database may have integrity errors or that the process-private data structures are corrupted.

Action: Report the entire incident context to your GT.M support channel for further analysis.

JNLRECINCMPL

JNLRECINCMPL, Incomplete journal record at disk address aaaa for file jjjj while attempting to read seqno ssss

MUPIP Error: The replication Source Server had a problem with journal file jjjj at disk offset aaaa attempting to read the record with sequence number ssss.

Action: Report the entire incident context to your GT.M support channel for further analysis. Use MUPIP SET JOURNAL -EXTRACT to investigate the issue.

LOCKSPACEFULL

LOCKSPACEFULL, No more room for LOCK slots on database file ffff

Runtime Error: This indicates that the environment attempted more concurrent M LOCKs than the configured LOCK_SPACE for file ffff can support.

Action: Analyze the LOCK protocol for efficiency. Use mupip set -file -lock_space=size ffff to increase the lock space for region xxx. To avoid the same problem the next time you recreate the database, use GDE to make the analogous change to lock_space for the segment mapped to the ffff file in the global directory used to MUPIP CREATE this region

LOCKSPACEINFO

LOCKSPACEINFO, Region: rrrr: processes on queue: pppp/qqqq; LOCK slots in use: llll/kkkk; name space not full

Runtime Error: This indicates that the environment attempted more concurrent M LOCKs than the configured LOCK_SPACE for region rrrr can support. pppp processes are waiting on a lock. llll locks are in use. qqqq and kkkk indicate maximum number of process queue entries, and maximum number of locks respectively.

Action: Analyze the LOCK protocol for efficiency. Use mupip set -region -lock_space=size "rrrr" to increase the lock space for region rrrr. To avoid the same problem the next time you recreate the database, use GDE to make the analogous change to lock_space for the segment mapped to the ffff file in the global directory used to MUPIP CREATE this region.

LOCKSPACEUSE

LOCKSPACEUSE, Estimated free lock space: xxx% of pppp pages.

LKE Information: SHOW command displays the amount of free space along with the number of pages configured for lock space.

Action: If the free lock space report does not show a comfortable amount of free space, use MUPIP SET -LOCK_SPACE to increase the space; remember to also use GDE to revise the LOCK_SPACE in the global directory used to create the region in question so the change remains when the database is recreated.

MAXSEMGETRETRY

MAXSEMGETRETRY, Failed to get ftok semaphore after tttt tries because it is being continually deleted

Run Time Error: A process was unable to open a database file because on every one of tttt tries it found something kept deleting the IPC semaphore that gates access to the file.

Action: Check for one or more rogue processes disrupting IPC semaphore, or for damage to the Operating System semaphore services.

MUINFOUINT6

MUINFOUINT6 <tttt : vvvv [0x!hhhh] ; $H=dddddd,tttttt

MUPIP Information: This is secondary information message that provides additional context for some other MUPIP message; tttt is explanatory text, vvvv is a numeric value, hhhh is the hexadecimal equivalent of vvvv, dddddd and tttttt are a date and time in $HOROLOG format.

Action: Refer to the preceding message.

MUTRUNC1ATIME

MUTRUNC1ATIME, Process with PID iiii already performing truncate in region rrrr

MUPIP Information: Issued when a REORG -TRUNCATE on a region rrrr detects some other active REORG process concurrently processing a truncation.

Action: No action required. The other process will complete the truncate.

MUTRUNCBACKINPROG

MUTRUNCBACKINPROG, Truncate detected concurrent backup in progress for region rrrr

MUPIP Information: REORG truncate process detected concurrent backup. Database file not truncated.

Action: Ensure the backup has completed and rerun MUPIP REORG -TRUNCATE command.

MUTRUNCERROR

MUTRUNCERROR, Truncate of region rrrr encountered service error eeee

MUPIP Error: This indicates that a system call failed during REORG truncate.

Action: Use the OS documentation to investigate the failure.

MUTRUNCFAIL

MUTRUNCFAIL, Truncate failed after reorg

MUPIP Error: This indicates that REORG encountered an unexpected error. Truncate may be partially complete.

Action: Review accompanying message(s) for more information.

MUTRUNCNOSPACE

MUTRUNCNOSPACE, Region rrrr has insufficient space to meet truncate target percentage of yyyy

MUPIP Information: Issued when REORG truncate determines that there is not enough free space at the end of the file; database file not truncated.

Action: If appropriate specify a larger threshold.

MUTRUNCNOTBG

MUTRUNCNOTBG, Region rrrr does not have access method BG

MUPIP Error: The truncate feature is only supported with the BG access method.

Action: Use the BG access method for files you wish to truncate.

MUTRUNCNOV4

MUTRUNCNOV4, Region rrrr is not fully upgraded from V4 format.

MUPIP Error: The truncate feature is only available for fully upgraded database files.

Action: In order to use truncate, first upgrade the database file to the current major version.

MUTRUNCPERCENT

MUTRUNCPERCENT, Truncate threshold percentage should be from 0 to 99

MUPIP Error: This indicates the the value entered for MUPIP REORG -TRUNCATE is invalid.

Action: Specify a valid threshold percentage.

MUTRUNCSSINPROG

MUTRUNCSSINPROG, Truncate detected concurrent snapshot in progress for region rrrr

MUPIP Information: REORG truncate process detected concurrent snapshot; database file not truncated.

Action: Ensure snapshot, for example a MUPIP INTEG, has completed and rerun the MUPIP REORG -TRUNCATE command.

MUTRUNCSUCCESS

MUTRUNCSUCCESS, Database file dddd truncated from oooo blocks to nnnn at transaction tttt

MUPIP Information: This operator log message indicates that the specified database file was truncated by MUPIP REORG as described by the message.

NOLOCKMATCH

NOLOCKMATCH, No matching locks were found in rrrr

LKE Information: SHOW or CLEAR, found that no LOCKs match the specified criteria in region rrrr; note that specifying no search criteria acts like a wildcard, checking all LOCKs in the region.

Action: If this is not the expected result, check the search criteria and / or research the LOCK protocol to validate its correct operation.

NONASCII

NONASCII, ssss is illegal for a oooo as it contains non-ASCII characters

GDE Error: The specification ssss contains non-ASCII characters which are required for an object of type oooo.

Action: Chose an object name or value containing only ASCII characters.

NOREPLCTDREG

NOREPLCTDREG, Replication subsystem found no region replicated for dddd ffff

MUPIP Warning: This indicates that the replication system is present, but no globals are configured for replication in ffff where dddd is "instance file" for UNIX and "global directory" for OpenVMS.

Action: Use MUPIP SET to specify which database regions to replicate.

NORESYNCSUPPLONLY

NORESYNCSUPPLONLY, NORESYNC only supported for Supplementary Instances

MUPIP Error: Issued by a Receiver Server on a non-Supplementary Instance when it is started with a -NORESYNC; -NORESYNC only applies to Supplementary Instances started with -UPDOK, not to non-Supplementary Instances.

Action: Use this qualifier only in a valid context.

NORESYNCUPDATERONLY

NORESYNCUPDATERONLY, NORESYNC qualifier only allowed on a Supplementary Instance which allows local updates

MUPIP Error: Issued by a Receiver Server when started with -NORESYNC on a Supplementary Instance but started without -UPDOK; -NORESYNC applies only to Supplementary Instances started with -UPDOK.

Action: Use this qualifier only in a valid context.

NOSUPPLSUPPL

NOSUPPLSUPPL, Instance ssss is configured to perform local updates, so it cannot receive from Supplementary Instance iiii

MUPIP Error: Issued by a Receiver Server or a MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on a Supplementary Instance ssss started with -UPDOK attempted to connect to instance iiii, but found IIII is also a Supplementary Instance. A Supplementary Instance that permits local updates can only replicate updates that originate on a non-Supplementary Instance.

Action: Reconfigure the instances to a supported configuration.

ORLBKCMPLT

ORLBKCMPLT, ONLINE ROLLBACK completed successfully on instance iiii corresponding to dddd

MUPIP Information: Issued by MUPIP ROLLBACK -ONLINE when it successfully completes work on database file dddd on instance iiii.

Action: None required.

ORLBKFRZOVER

ORLBKFRZOVER, tttt : FREEZE on region rrrr (ddd) cleared

MUPIP Information: Issued by MUPIP ROLLBACK -ONLINE when it clears a FREEZE on region rrrr mapped to database file dddd; tttt is the time it cleared the FREEZE.

Action: None required.

ORLBKFRZPROG

ORLBKFRZPROG, tttt : waiting for FREEZE on region rrrr (dddd) to clear

MUPIP Information: Issued by MUPIP ROLLBACK -ONLINE when it encounters a region rrrr mapped to dabase file dddd which is frozen; tttt is the time it encountered the condition.

Action: ROLLBACK waits for a period determined the the gtm_db_startup_max_wait environment variable, after which it clears the FREEZE and proceeds. The ROLLBACK is inappropriate due to the conditions that lead to the FREEZE, cancel the ROLLBACK, otherwise cancel the FREEZE or wait for ROLLBACK to clear it automatically.

ORLBKNOSTP

ORLBKNOSTP, ONLINE ROLLBACK proceeding with database updates. MUPIP STOP will no longer be allowed

MUPIP Information: Issued by MUPIP ROLLBACK -ONLINE when it starts processing that cannot be interrupted without jeopardizing database integrity.

Action: Wait for the ROLLBACK to complete.

ORLBKNOV4BLK

ORLBKNOV4BLK, Region rrrr (dddd) has V4 format blocks. Database upgrade required. ONLINE ROLLBACK cannot continue

MUPIP Error: Issued by MUPIP ROLLBACK -ONLINE when it finds the region rrrr mapped to database file dddd contains V4 format blocks - online rollback does not support old format blocks.

Action: Upgrade the database to the current major version before attempting to use online rollback.

ORLBKSTART

ORLBKSTART, ONLINE ROLLBACK started on instance iiii corresponding to dddd

MUPIP Information: Issued by MUPIP ROLLBACK -ONLINE when it starts work on database file dddd on instance iiii.

Action: None required.

ORLBKTERMNTD

ORLBKTERMNTD, ONLINE ROLLBACK terminated on instance iiii corresponding to dddd with the above errors

MUPIP Error: Issued by MUPIP ROLLBACK -ONLINE when it encounters issues that prevent it from operating on database file dddd on instance iiii.

Action: Analyze and address the errors in the output preceding this message.

PERMGENDIAG

PERMGENDIAG, Permissions: Proc(uid:uuuu,gid:gggg), DB File(uid:vvvv,gid:hhhh,perm:pppp), Lib File(gid:iiii,perm:qqqq), Group Mem(opener:jjjj,owner:kkkk)

Run Time Information: This shows the permissions involved in a resource creation for the process, the associated database file, the libgtmshr and the process group membership.

Action: Typically none, but if you have a permission issue use this key information for diagnosis.

PERMGENFAIL

PERMGENFAIL, Failed to determine access permissions to use for creation of xxxx for file yyyy

MUPIP/Run Time Error: This message indicates that GT.M was unable to determine the permissions to use when creating a file or resource associated with database file yyyy. xxxx may be "ipc resources", "journal file", "backup file", or "snapshot file".

Action: Note the user and group ownership of the database file and $gtm_exe/libgtmshr.*, and the user and group permissions of the GT.M process, and report them to your GT.M support channel.

PRIMARYISROOT

PRIMARYISROOT, Attempted operation not valid on root primary instance xxxx

MUPIP Error: If a replication instance has local updates enabled, that is: the Source Server that created the journal pool was started with -UPDOK, issuing any Source Server command with the start, activate or deactivate qualifiers where the command explicitly specifies the propagateprimary qualifier or that qualifier is implicitly assumed by default, or, if this is a not a supplementary instance, attempting to start a Receiver Server causes MUPIP to issue this error.

Action: Do not start a Receiver Server on a root primary non-supplementary instance. Use rootprimary qualifier instead of propagateprimary in the source server command.

RCVR2MANY

RCVR2MANY, The instance already has the maximum supportable number of receiver servers nnnn active

MUPIP Error: Issued by a Receiver Server on a Supplementary Instance (started with -UPDOK) which found it exceeds nnnn, the currently permitted number of Receiver Servers.

Action: Reconfigure the instances to a supported configuration.

RCVRMANYSTRMS

RCVRMANYSTRMS, Receiver server now connecting to source stream NNNN but had previously connected to a different stream nnnnMUPIP Error: Issued by a Receiver Server on a Supplementary Instance (started with -UPDOK) which had formerly connected to a source server corresponding to non-Supplementary stream nnnn, later disconnected and on reconnection found the Source Server corresponds to a different non-Supplementary stream NNNN.

Action: Mixing of non-Supplementary streams are not allowed in the same Receiver Server process. Restart the Receiver Server.

REPL2OLD

REPL2OLD, Instance IIII uses a GT.M version that does not support connection with the current version on iiii.

MUPIP Error: Issued by a Source Server, Receiver Server or MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on Instance iiii attempted to connect to instance IIII, but found IIII is running an earlier version that does not support the current replication protocol. This can indicate either that the older version is just too old for any connection with the newer version (in case the older version is less than V5.1-000) or that the older version doesn’t have the logic required to support a Supplementary Instance (in case the older version is less than V5.5-000). Note that IIII may not be available if the older instance uses a version of GT.M less than V5.1-000.

Action: Upgrade the GT.M version on IIII to a version that can support communication with the current version or, if this is a Supplementary Instance, that can deal with a Supplementary Instance or choose another appropriate instance for the connection.

REPLINSTDBSTRM

REPLINSTDBSTRM, Replication instance file rrrr has seqno xxxx for Stream nnnn while database has a different seqno XXXX

MUPIP Error: Issued by the first source server started on a supplementary instance if the journal stream sequence numbers (for any non-supplementary stream from 0 through 15) stored in the instance file do not match those stored in the database file headers. This is possible if a database was recreated or refreshed from a backup on another instance without correspondingly recreating the instance file.

Action: If the database file is known to be accurate, recreate the instance file. If not, reinitialize this instance from a backup of some other instance in the same LMS Group (see Action section of REPLINSTDBMATCH error for more details on this).

REPLINSTMISMTCH

REPLINSTMISMTCH, Process has replication instance file ffff (jnlpool shmid = ssss) open but database dddd is bound to instance file gggg (jnlpool shmid =tttt)

Run Time Error: An update is being attempted on the replicated database dddd which is associated with the replication instance file ffff and journal pool shared memory id ssss but the currently updating process has a different replication instance file gggg or journal pool shmid tttt open.

Action: A replicated database can only be updated by processes that have the same replication instance file (defined by the environment variable gtm_repl_instance) open. Ensure the environment variable gtm_repl_instance is defined to be the same for all processes that update the same replicated database file. This error is also possible if the replication instance file was recreated (while processes were still accessing the replication instance). In this case, the name ffff and gggg would be the same but the corresponding journal pool shared memory ids would be different. To recover from this situation, shut down all processes accessing the instance from before and after the instance file recreate. Run an argumentless mupip rundown to clean up the older journal pool tttt and restart the instance. One more case of this error is when gggg is the empty string and tttt is 4294967295 (i.e. 2**32 - 1). In this case, the Source Server was started with a global directory that (a) did not have this database file listed and hence this database was not associated with the journal pool that the Source Server created OR (b) had this database file listed but later the source server and this particular database file was shut down while other database files in this global directory were still active. To recover from (a), add this database file to the global directory used by the Source Server and restart the instance. The Source Server (which is the first process to start on a replicated instance) only binds replicated databases from its global directory to the journal pool that it creates. No other replicated database file can be bound with this journal pool. To recover from (b), restart the Source Server.

REPLUPGRADEPRI

REPLUPGRADEPRI, Attempted operation requires primary instance xxxx to support multi-site replication

Obsolete Error: No longer issued by GT.M

REPLUPGRADESEC

REPLUPGRADEPRI, Attempted operation requires primary instance xxxx to support multi-site replication

Obsolete Error: No longer issued by GT.M

RESOLVESEQNO

RESOLVESEQNO, Resolving until sequence number dddd [0xxxxx]

MUPIP Information: This indicates MUPIP JOURNAL ROLLBACK expects to do backward processing until it reaches sequence number with hexadecimal value xxxx (decimal value dddd). This is usually the common sequence number agreed upon between the primary and secondary by a -FETCHRESYNC rollback or the sequence number specified in a -RESYNC rollback.

Action: No action required.

RESOLVESEQSTRM

RESOLVESEQSTRM, Resolving until stream sequence number Stream nnnn : Seqno dddd xxxx

MUPIP Information: This indicates MUPIP JOURNAL ROLLBACK expects to do backward processing until it reaches the stream sequence number whose hexadecimal value is xxxx (decimal value dddd). This is usually the common stream sequence number agreed upon between the primary and secondary by a -FETCHRESYNC rollback or the stream sequence number specified in a -RESYNC rollback where -RSYNC_STRM is also specified.

Action: No action required.

RESUMESTRMNUM

RESUMESTRMNUM, Error with stream number specified in RESUME qualifier

MUPIP Error: Issued by a Receiver Server as an accompanying message to a UPDSYNCINSTFILE error. The stream number nnnn can be any integer value from -1 through 15.

Action: No action required for this message. Action is required for the preceding UPDSYNCINSTFILE error.

REUSEINSTNAME

REUSEINSTNAME, Error with instance name specified in REUSE qualifier

MUPIP Error: Issued by a Receiver Server when started with the -REUSE qualifier in case of either inappropriate use of this qualifier or an inappropriate instance name specified as a value to this qualifier.

Action: An accompanying GTM-I-TEXT message describes the particular error situation. Take appropriate corrective action based on that.

RLBKCONFIGBNDRY

RLBKCONFIGBNDRY, Rollback encountered journal records indicating current source iiii replaced old source oooo; cannot rollback past sequence number ssss

MUPIP Error: Issued by MUPIP JOURNAL -ROLLBACK indicating it found a change in the source configuration from instance oooo to iiii for stream ssss within the range of its attempt to process. Since it cannot dynamically reconfigure the source connections to deal with this, it stops.

Action: Investigate whether a shorter rollback that won't encounter this configuration change would be useful. If not, refresh this instance from a backup or use the -RSYNC_STRM qualifier if appropriate.

RLBKSTRMSEQ

RLBKSTRMSEQ, Stream journal seqno of the instance after rollback is Stream nnnn : Seqno dddd xxxx

MUPIP Information: On a Supplementary Instance, MUPIP JOURNAL -ROLLBACK issues this message for each stream (from 0 through 15) that has at least one update. This message indicates how many updates in each stream this Supplementary Instance has processed.

Action: No action required.

RNDWNSKIPCNT

RNDWNSKIPCNT, A total of nnnn process(es) skipped database rundown due to a concurrent ONLINE ROLLBACK

Run Time Information: nnnn processes disconnected from a one or more databases while online rollback was running and therefore relied on online rollback or other remaining processes to complete any database shutdown.

Action: None required typically. If there's cleanup required, use MUPIP RUNDOWN.

RSYNCSTRMSUPPLONLY

RSYNCSTRMSUPPLONLY, RSYNC_STRM qualifier only supported for Supplementary Instances

MUPIP Error: Issued by MUPIP JOURNAL -ROLLBACK indicating the -RSYNC_STRM qualifier only applies to Supplementary Instances - Business Continuity instances require comprehensive synchronization.

Action: Reissue the command without the -RSYNC_STRM qualifier.

RSYNCSTRMVAL

RSYNCSTRMVAL, RSYNC_STRM qualifier can only take on a value from 0 to 15

MUPIP Error: Issued by a MUPIP JOURNAL -ROLLBACK -RESYNC command which also specifies -RSYNC_STRM with a stream number outside of the range of 0 through 15.

Action: Specify a stream number within the allowed range.

SECNOTSUPPLEMENTARY

SECNOTSUPPLEMENTARY, ssss is a Supplementary Instance and so cannot act as a source to non-Supplementary Instance iiii

MUPIP Error: Issued by a Source Server on a Supplementary Instance ssss attempted to connect to a Replicating Instance iiii, but found iiii is not configured as a Supplementary Instance.

Action: Reconfigure the instances to a supported configuration.

SEMWT2LONG

SEMWT2LONG, Process wwww waited ssss second(s) for the llll lock for region rrrr, lock held by pid pppp

Run Time Error: This indicates that the process pppp appears to be holding the llll control semaphore for region rrrr for longer than GT.M expects.

Action: Analyze the behavior of process pppp, and terminate it if appropriate. This error may indicate that the system is under-configured for the workload.

SHMREMOVED

SHMREMOVED, Removed Shared Memory id mmmm corresponding to file ffff

MUPIP Information: MUPIP RUNDOWN removed shared memory segment mmmm, corresponding to the file ffff, which could be a database file or a replication instance file with a GT.M signature because the resource was not actively in use.

Action: No action required.

STRMNUMMISMTCH1

STRMNUMMISMTCH1, Stream nnnn exists on the receiver instance file but is unknown on the source instance

MUPIP Error: Issued by a Source Server on a Supplementary Instance when it detects a non-Supplementary stream number nnnn (which can be any value from 1 through 15) exists on the receiving instance but not on the source instance. This indicates the two instances are not in sync at least with respect to stream nnnn, so replication cannot proceed.

Action: Reinitialize the receiving instance from a backup of the source instance and restart replication between the two instances.

STRMNUMMISMTCH2

STRMNUMMISMTCH2, Stream nnnn exists on the source instance file but is unknown on the receiver instance

MUPIP Error: Issued by a Source Server on a supplementary instance when it detects a non-Supplementary stream number nnnn (which can be any value from 1 through 15) exists on the source instance but not on the receiving instance. This indicates the two instances are not in sync at least with respect to stream nnnn and so replication cannot proceed.

Action: Reinitialize the receiving instance from a backup of the source instance and restart replication between the two instances.

STRMSEQMISMTCH

STRMSEQMISMTCH, Unable to play update on Stream nnnn with seqno xxxx as receiving instance has a different stream seqno XXXX

MUPIP Error: Issued by the Update Process on a supplementary instance started with -UPDNOTOK (that is, local updates are disabled) when it finds the source and receiving instances have different values of stream sequence number for the non-Supplementary stream nnnn (can be any value from 1 through 15). This indicates the two instances are not in sync at least with respect to stream nnnn and so replication cannot proceed.

Action: Reinitialize the receiving instance from a backup of the source instance and restart replication between the two instances.

SUPRCVRNEEDSSUPSRC

SUPRCVRNEEDSSUPSRC, Instance iiii is not configured to perform local updates, so it cannot act as a receiver for non-Supplementary Instance ssss

MUPIP Error: Issued by a Receiver Server or a MUPIP JOURNAL -ROLLBACK -FETCHRESYNC on a Supplementary Instance ssss started with -UPDNOTOK attempted to connect to non-Supplementary Instance iiii. A Supplementary Instance that does not permit local updates can only replicate from another Supplementary Instance.

Action: Reconfigure the instances to a supported configuration.

SRVLCKWT2LNG

SRVLCKWT2LNG, PID pppp is holding the source server lock. Waited for mmmm minute(s). Now exiting

MUPIP Error: Issued by MUPIP ROLLBACK -ONLINE when it finds process pppp has not released the journal pool resource for mmmm minutes.

Action: Investigate the state of process pppp and whether it should be stopped by operator action.

STRMNUMIS

STRMNUMIS, Stream # is ssss

MUPIP Information: Issued by a Receiver Server to designate a stream associated with the the immediately preceding message.

Action: Refer to the associated prior message.

TRIGMODREGNOTRW

TRIGMODREGNOTRW, Trigger(s) cannot be added/changed/deleted because region rrrr is read-only

Runtime Error: This error occurs when $ZTRIGGER() or MUPIP TRIGGER attempts to write to read-only region rrrr.

Action: Check for appropriate global directory mapping and appropriate permissions on the database file mapped to region rrrr.

UPDSYNC2MTINS

UPDSYNC2MTINS, Can only UPDATERESYNC with an empty instance file

MUPIP Error: Issued by a Receiver Server started with the -UPDATERESYNC qualifier on a non-supplementary instance or on a Supplementary Instance started specifying the -UPDNOTOK qualifier, when the replication instance file on the Receiver side contains at least one history record. The purpose of -UPDATERESYNC is to unconditionally declare the instance state as a valid state in the set of current and prior states of the originating instance disregarding any history. Note that the receiver server on a Supplementary Instance started with -UPDOK does not issue this error.

Action: Verify that -UPDATERESYNC is appropriate and if so, recreate the instance file to discard the history then reissue the command. If the replication state is not a valid match to some available current or prior state of the originating instance, either do a normal resync or refresh the replicating instance to an appropriate state.

UPDSYNCINSTFILE

UPDSYNCINSTFILE, Error with instance file name specified in UPDATERESYNC qualifier

MUPIP Error: Issued by a Receiver Server when started with the -UPDATERESYNC qualifier in case of any error while processing the instance file specified as a value to this qualifier.

Action: An accompanying message, usually a GTM-I-TEXT message, describes the particular error situation. Take appropriate corrective action based on that.

ZDATEBADDATE

ZDATEBADDATE, $ZDATE() date argument dddd is less than -365 (the $HOROLOG value for 01-JAN-1840) or greater than 364570088 (the $HOROLOG value for 31-DEC-999999)

Run Time Error: The value of the date portion of the argument dddd to $ZDATE() is outside the range of values the function handles.

Action: Examine the code that created the value of dddd for errors or revise the design to create dates within the range supported by $ZDATE().

ZDATEBADTIME

ZDATEBADTIME, $ZDATE() time argument tttt is less than 0 or greater than 86399 (the $HOROLOG value for a second before midnight)

Run Time Error: The value of the time portion of the argument tttt to $ZDATE() is outside the range of values the function handles.

Action: Examine the code that created the value of tttt for errors or revise the design to create times within the range supported by $ZDATE().

ZTRIGNOTRW

ZTRIGNOTRW, ZTRIGGER cannot operate on read-only region rrrr

Runtime Error: This error occurs when ZTRIGGER attempts to write to read-only region rrrr.

Action: Check for appropriate global directory mapping and appropriate permissions on the database file mapped to region rrrr.

ドキュメント付録

ドキュメント付録

ジャーナル抽出フォーマット

To support supplementary instance replication, V5.5-000 added new fields and changed the record format of journal extracts. You may need to modify application code and shell scripts which read and process journal extracts. Here is the summary of the journal extract format changes in V5.5-000. New fields are in bold and changes are in italics.

V5.4-002B

V5.5-000

Journal extract format (Plain)

Header Label

GDSJEX05

GDSJEX06

NULL

00\time\tnum\pid\clntpid\jsnum

00\time\tnum\pid\clntpid\jsnum\strm_num\strm_seq

KILL

04\time\tnum\pid\clntpid\token_seq\updnum\nodeflags\node

04\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

SET

05\time\tnum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

05\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

TSTART

08\time\tnum\pid\clntpid\token_seq

08\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq

TCOM

09\time\tnum\pid\clntpid\token_seq\partners\tid

09\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\partners\tid

ZKILL

10\time\tnum\pid\clntpid\token_seq\updnum\nodeflags\node

10\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

ZTWORM

11\time\tnum\pid\clntpid\token_seq\updnum\ztwormhole

11\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\ztwormhole

ZTRIG

12\time\tnum\pid\clntpid\token_seq\updnum\nodeflags\node

12\time\tnum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

Journal extract format (Detail)

Header Label

GDSJDX05

GDSJDX06

KILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

SET

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

TKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

UKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

TSET

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

USET

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

FSET

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

GSET

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node=sarg

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node=sarg

FKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

GKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

TSTART

time\tnum\chksum\pid\clntpid\token_seq

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq

TCOM

time\tnum\chksum\pid\clntpid\token_seq\partners\tid

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\partners\tid

ZKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

TZKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

UZKILL

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

EPOC

time\tnum\chksum\pid\clntpid\jsnum\blks_to_upgrd\free_blocks\total_blks

time\tnum\chksum\pid\clntpid\jsnum\blks_to_upgrd\free_blocks\total_blks\fully_upgraded[\strm_num\strm_seq]...

ZTWORM

time\tnum\chksum\pid\clntpid\token_seq\updnum\ztwormhole

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\ztwormhole

NULL

time\tnum\pid\clntpid\jsnum

time\tnum\pid\clntpid\jsnum\strm_num\strm_seq

ZTRIG

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

TZTWORM

time\tnum\chksum\pid\clntpid\token_seq\updnum\ztwormhole

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\ztwormhole

UZTWORM

time\tnum\chksum\pid\clntpid\token_seq\updnum\ztwormhole

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\ztwormhole

TZTRIG

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

UZTRIG

time\tnum\chksum\pid\clntpid\token_seq\updnum\nodeflags\node

time\tnum\chksum\pid\clntpid\token_seq\strm_num\strm_seq\updnum\nodeflags\node

Legend (additions in bold and changes in italics):

strm_num

If replication is true and this update originated in a non-supplementary instance but was replicated to and updated a supplementary instance, this number is a non-zero value anywhere from 1 to 15 (both inclusive) indicating the non-supplementary stream number. In all other cases, this stream # value is 0. In case of an EPOCH record, anywhere from 0 to 16 such "strm_num" numbers might be displayed depending on how many sources of supplementary instance replication have replicated to the instance in its lifetime.

strm_seq

If replication is true and this update originated in a non-supplementary instance but was replicated to and updated a supplementary instance, this is the journal sequence number of the update on the originating non-supplementary instance. If replication is true and this update originated in a supplementary instance, this is the journal sequence number of the update on the originating supplementary instance. In all other cases, this stream sequence number is 0. Note that the journal seqno is actually 1 more than the most recent update originating on that stream number. In case of an EPOCH record, anywhere from 0 to 16 such "strm_seq" numbers might be displayed depending on how many sources of supplementary instance replication have replicated to the instance in its lifetime.

nodeflags

Decimal number interpreted as a binary mask.. Currently only 5 bits are used.

  • 00001 (1) => update journaled but NOT replicated (For example, update inside a trigger)

  • 00010 (2) => update to a global that had at least one trigger defined, even if no trigger matched this update

  • 00100 (4) => $ZTWORMHOLE holds the empty string ("") at the time of this update or was not referenced during this update

  • 01000 (8) => update did not invoke any triggers even if they existed (For example, MUPIP LOAD)

  • 10000 (16) => whether the update (set or kill) is a duplicate. In case of a KILL, it is a kill of some non-existing node aka duplicate kill. Note that the dupkill occurs only in case of the Update Process. In case of GT.M, the KILL is entirely skipped. In both cases (duplicate set or kill), only a jnl record is written, the db is untouched.

Combinations of the above bits would mean each of the individual bit characteristics. For example, 00011 => update within a trigger context, and to a global with at least one trigger defined. For example, 00011 => update inside a trigger and to a global with at least one trigger defined. Certain bit combinations are impossible. For example, 01001 since GT.M replicates any update that does not invoke triggers.

fully_upgraded

1 if the db was fully upgraded (indicated by a dse dump -file -all) at the time of writing the EPOCH

共有リソースの承認権限

GT.M uses several types of shared resources to implement concurrent access to databases. The first GT.M process to open a database file creates IPC resources (semaphores and shared memory) required for concurrent use by other GT.M processes, and in the course of operations GT.M processes create files (journal, backup, snapshot) which are required by other GT.M processes. In order to provide access to database files required by M language commands and administration operations consistent with file permissions based on the user, group and world classes, the shared resources created by GT.M may have different ownership, groups and permissions from their associated database files as described below. As an example of the complexity involved, consider a first process opening a database based on its group access permissions. In other words, the database file is owned by a different userid from the semaphores and shared memory created by that first process. Now, if the userid owning the database file is not a member of the database file's group, a process of the userid owning the database file can only have access to the shared resources if the shared resources have world access permissions or if they have a group that is guaranteed to be shared by all processes accessing the database file, even if that group is different from the database file's own group. Again, although FIS strongly recommends against running GT.M processes as root, a root first process opening the database file must still be able to open it although it may not be the owner of the database file or even in its group - but it must ensure access to other, non-root processes. Some things to keep in mind:

  • Even a process with read-only access to the database file requires read-write access to the shared memory control structures and semaphores.

  • Creating and renaming files (for example, journal files) requires write access to both the files and the directories in which they reside.

  • If you use additional layered security (such as Access Control Lists or SELinux), you must ensure that you analyze these cases in the context of configuring that layered security.

GT.M takes a number of factors into account to determine the resulting permissions:

  • The owner/group/other permissions of the database file

  • The owner of the database file

  • The group of the database file

  • The group memberships of the database file's owner

  • The owner/group/other permissions of the libgtmshr file

  • The group of the libgtmshr file

  • The effective user id of the creating process

  • The effective group id of the creating process

  • The group memberships of the creating process' user

The following table describes how these factors are combined to determine the permissions to use:

Database File PermissionsOpening process is owner of database file?Owner is member of group of database file?Opening process is a member of database file group?Opening process is not owner but a member of database file group?Execution of GT.M restricted to members of a group?
Group of Resource IPC Permissions File Permissions
-r*-r*-r*---Y--
Group of database file -rw-rw-rw -r*-r*-r*
-rw-rw-r*--N--
Current group of process -rw-rw-rw -rw-rw-rw
-rw-rw-rw--N--
Current group of process -rw-rw-rw -rw-rw-rw
-rw-rw-rwYY---
Group of database file -rw-rw-rw -r*-r*----
-r*-r*----YN--N
Current group of process -rw-rw-rw- -rw-rw-rw-
-r*-r*----YN--Y
Group to which GT.M is restricted -rw-rw---- -rw-rw----
-r*-r*-----Y-Y-
Group of database file -rw-rw---- -r*-r*----
-r*-r*-----N-YN
Group of database file -rw-rw-rw- -rw-rw-rw-
-r*-r*-----N-YY
Group to which GT.M is restricted -rw-rw---- -rw-rw----
----r*-----N-Y-
Group of database file -rw-rw---- ----r*----
-r*-------Y----
Current group of process -rw------- -rw-------
  • The resulting group ownership and permissions are found by matching the database file permissions, then determining which question columns produce the correct "Y" or "N" answer; "-" answers are "don't care".

  • An asterisk ("*") in the Database File Permissions matches writable or not writable. An asterisk in the Resulting File Permissions means that GT.M uses the write permissions from the database file.

  • GT.M determines group restrictions by examining the permissions of the libgtmshr file. If it is not executable to others, GT.M treats it as restricted to members of the group of the libgtmshr file.

  • Group membership can either be established by the operating system's group configuration or by the effective group id of the process.

  • A GT.M process requires read access in order to perform write access to database file - a file permission of write access without read access is an error.

  • GT.M treats the "root" user the same as other users, except that when it is not the file owner and not a member of the group, it is treated as if it were a member of the group.

オンライン ロールバックにより影響を受けるエリア

Area Impacted by MUPIP JOURNAL -ONLINE -ROLLBACK

Effect of MUPIP JOURNAL -ONLINE -ROLLBACK

$ZONLNRLBK

Incremented by any online rollback that takes the database back to a prior state

M run-time actions that do not interact with the target database

None

M run-time database interactions

Suspended during the online rollback. Restart if the online rollback does not take the database back to a prior state or if within an explicit TP transaction. Otherwise, DBROLLEDBACK error if the interaction is a non-TP mini-transaction. Note that triggers act like an extension of their originating event: they get the same treatment as the trigger event would get - if they are within an implicit transaction triggered outside a TP transaction, the process gets a DBROLLEDBACK error.

M run-time larger KILLs

Because of the way GT.M manages multi-node KILLs, it possible for online rollback to remove bit-map cleanup while leaving the original KILL. This creates incorrectly marked busy errors, which represent unused, but protected space - they are benign, but should be cleaned up in a timely manner.

GT.CM GNP Server

Like the M run-time, except it sends any DBROLLEDBACK error to the client processes.

Starting most GT.M actions from the shell, including operator Utilities - see below for exceptions

Deferred until the ONLINE ROLLBACK is complete. The environment variable gtm_db_startup_max_wait determines the deferred time. For more information, refer to GTM-4337.

MUMPS

None unless, and until, the process tries to interact with the target database

ソース サーバ

If the online rollback takes the database back to a prior state, disconnect from the receiving instance and restart the connection with a message that a rollback occurred.

Update Process

If the online rollback takes the database back to a prior state, suspend processing and notify the Receiver Server that there was a rollback on this receiving instance.

レシーバー サーバ

When notified by the Update Process, disconnect from the source instance and reconnect with a message to restart transmission from the new current sequence number. When it receives a message the source instance has rolled back and it was started with -AUTOROLLBACK, initiate an online rollback on the receiving instance, otherwise shutdown in anticipation of an operator action.

LKE

None if already running before online rollback starts

Running GT.M utility commands that are mutually exclusive with MUPIP JOURNAL -ONLINE -ROLLBACK and require standalone access. 次に例を示します。

  • MUPIP UPGRADE

  • MUPIP DOWNGRADE

  • MUPIP JOURNAL -ROLLBACK or MUPIP JOURNAL -RECOVER

  • MUPIP ENDIANCVT

  • MUPIP RUNDOWN

  • MUPIP RESTORE

  • MUPIP INTEG -FILE

MUPIP JOURNAL -ONLINE -ROLLBACK does not run when these commands are running. Analogously, these commands cannot run during a MUPIP JOURNAL -ONLINE -ROLLACK.

Multi-action state dependent utility commands. 次に例を示します。

  • MUPIP INTEG -REGION [-ONLINE|-NOONLINE]

  • MUPIP BACKUP (MUPIP バックアップ)

  • MUPIP LOAD

Produces a DBROLLEDBACK error.

Subsequent MUPIP BACKUP -BYTESTREAM -SINCE=<event> commands may start at transaction 1 if the rollback takes the database state back prior to the event (DATABASE, BYTESTREAM or RECORD).

DSE

DSE cannot start while online rollback is running. If it has already started, its commands work as described in other rows of this table.

Utility commands that do not interact with database files. 次に例を示します。

  • DSE CLOSE

  • DSE EVALUATE

  • DSE EXIT

  • DSE HELP

  • DSE OPEN

  • DSE PAGE

  • DSE QUIT

  • DSE SPAWN

  • DSE VERSION

  • グローバルディレクトリエディタ(GDE)

  • LKE CLEAR

  • LKE SHOW

  • MUPIP CREATE

  • MUPIP EXIT

  • MUPIP FTOK

  • MUPIP INTRPT

  • MUPIP QUIT

  • MUPIP STOP

DSE and LKE cannot start while online rollback is active, but if active they can continue to operate; MUPIP commands always start from the shell so each command may have different behavior.

MUPIP CREATE does create database files but only if they do not already exist and if they do not exist, they can be rolled back.

MUPIP INTRPT does not interact with a database, but the target process may and that could prevent it from recognizing the interrupt in a timely fashion.

Utility commands that update a database and interlock with online rollback. 次に例を示します。

  • DSE ADD

  • DSE ALL -WCINIT

  • DSE ALL -BUFFER_FLUSH

  • DSE ALL -SEIZE

  • DSE ALL -RELEASE

  • DSE ALL -FREEZE -OVERRIDE

  • DSE BUFFER_FLUSH

  • DSE CACHE except -SHOW

  • DSE CHANGE except -FILEHEADER –NOCRIT

  • DSE CRITICAL -SEIZE

  • DSE CRITICAL -RELEASE

  • DSE CRITICAL -CYCLE

  • DSE MAPS

  • DSE OVERWRITE

  • DSE REMOVE -RECORD

  • DSE RESTORE

  • DSE SAVE

  • DSE SHIFT

  • DSE WCINIT

These commands wait for online rollback to complete.

Utility commands that only read database files and display current state information. For example: ·

  • DSE ALL -DUMP

  • DSE ALL -NOFREEZE

  • DSE CACHE -SHOW

  • DSE CRITICAL -ALL

  • DSE CRITICAL -CRASH

  • DSE DUMP -BLOCK

  • DSE DUMP -RECORD

  • DSE DUMP -FILE

  • DSE FIND

  • DSE INTEG

  • DSE REMOVE -BLOCK

  • DSE RANGE

These commands show the state as of the time they are issued and if issued while there are any concurrent updates, including online rollback may show a transient and out-of-date state.

Utility commands that interact with a database and are not blocked by online rollback:

  • DSE ALL -REFERENCE

  • DSE CRITICAL -INIT

  • DSE CRITICAL -REMOVE

  • DSE CHANGE -FILEHEADER -NOCRIT

These commands may disrupt the -online rollback and may cause database damage - they are available only for very unusual situations and should only be used under instructions from your GT.M support channel.

inserted by FC2 system