ToolTalk ユーザーズガイド

Q & A

次に示す頻繁に寄せられる質問は、ToolTalk サービスに関する追加情報の役割も果たしています。

ToolTalk サービスとは何ですか

ToolTalk サービスを使用すれば、個々のアプリケーションは直接相手を知らなくても、互いに通信できます。アプリケーションは ToolTalk メッセージを作成して送信することにより、互いに通信します。ToolTalk サービスはこのメッセージを受信すると、受信側を判別し、適切なアプリケーションに配信します。

ToolTalk サービスは、Common Object Request Broker Architecture (CORBA) の Sun 版ですか

違います。ToolTalk サービスは、CORBA に準拠した Sun オブジェクト要求仲介 (ORB) ではありません。ToolTalk サービスは、オブジェクト管理グループ (OMG) の CORBA 仕様が定義される以前の 1991 年に設計出荷されました。

CORBA に準拠した Sun ORB は、分散オブジェクト管理機能 (DOMF) であり、これは Sun のプロジェクト DOE 製品の一部です。Sun は、DOMF が Solaris の一部として一般利用できるようになった時点で、DOMF 上で動作する ToolTalk API をサポートすると公約しています。現在 ToolTalk メッセージサービスを使用しているアプリケーションは、将来は分散オブジェクト環境に移行します。

ToolTalk サービスに入っているファイルの種類を教えてください

ToolTalk ファイルは、/usr/openwin/bin、lib、include/desktop、および man ディレクトリの他に /usr/dt/bin、lib、および include/Tt ディレクトリにもあります。これには、過去のいきさつがあります。ToolTalk は、共通デスクトップ環境 (CDE) の前から存在していて、Solaris とともに /usr/openwin ディレクトリ構造で出荷されていました。CDE がリリースされると、ToolTalk は、シンボリックリンクを使って /usr/dt ディレクトリから見えるようになりましたが、実際には、依然として /usr/openwin にインストールされていました。CDE がインストールされた Solaris 2.6 オペレーティング環境およびその互換バージョンのシステムでは、ToolTalk の 2 つの完全版がインストールされています。1 つは /usr/dt に、もう 1 つは /usr/openwin にインストールされていますが、/usr/dt にインストールされているものだけが CDE で有効です。

表 D-1 にこれらのファイルを示します。

表 D-1 ToolTalk のファイル


ファイル名	説明
`ttsession`	ネットワーク上で通信してメッセージを配信する
`rpc.ttdbserverd`	ToolTalk オブジェクト仕様や、ToolTalk メッセージで参照するファイル情報を格納し管理する
`ttcp`, `ttmv`, `ttrm`, `ttrmdir`, `tttar`	標準オペレーティングシステムのシェルコマンド ToolTalk オブジェクトの入ったファイルや、ToolTalk メッセージのサブジェクトであるファイルがコピー、移動、または削除されると、これらのコマンドは ToolTalk サービスに連絡する
`tttrace`, `ttsnoop`	`tttrace` は、`truss` (1) に類似している。これにより、特定の `ttsession` で発生するメッセージパッシングとパターンマッチングをトレースできる。また、これを使用することにより、すべての呼び出しのプログラムごとのトレースを ToolTalk API に提供できる。`ttnsoop` は Motif をベースにしたプログラムで、`tttrace` のメッセージとパターントレース機能に、デバッグとチュータ機能として、メッセージを簡単に作成または送信したり、パターンを登録したりできる付加機能
`ttdbck`	ToolTalk データベースの検査と修復を行うツール
`tt_type_comp`	ptype と otype のファイルをコンパイルし、ToolTalk 型データベースに自動的にインストールする
`ttce2xdr`	ToolTalk 型データを、分類機構データベースフォーマットから XDR データベースフォーマットに変換する
`libtt.a`, `libtt.so`, `tt_c.h`, `tttk.h`	アプリケーションが使用してメッセージを送受信する ToolTalk 関数のアプリケーションプログラミングインタフェース (API) ライブラリとヘッダーファイル

X ベースの ttsession が最初に起動されるのはいつですか

ttsession が 1 つも動作していない場合は、tt_open を最初に呼び出した時点で ttsession が自動的に起動されます。ただし、/usr/dt/bin/Xsession ファイルには下記のようなエントリがあり、それによって usr/dt/bin/dtlogin を使用している際に、ログイン時に自動的に ttsession を起動します。

# Start ttsession here.
  dtstart_ttsession="$DT_BINPATH/ttsession"

rpc.ttdbserverd はどこで起動されますか

/etc/inet/inetd.conf ファイルに、次のようなエントリが入っています。

# Sun ToolTalk Database Server
100083/1  tli  rpc/tcp  wait  root  /usr/dt/bin/rpc.ttdbserverd 
 /usr/dt/binrpc.ttdbserverd

ToolTalk 型データベースはどこにありますか

ToolTalk 型データベースの場所は、環境変数 TTPATH で ToolTalk サービスに教えます。この環境変数のフォーマットを次に示します。

 userDB[:systemDB[:networkDB]]

注 -

型ファイルは、TTPATH に指定した順序と逆の順序で読み込まれます。

この環境変数は、データベースサーバーのリダイレクトファイルの場所も ToolTalk サービスに教えます。そのデフォルトの位置を表 D-2 に示します。

表 D-2 ToolTalk 型データベースのデフォルト位置


データベース	位置
ユーザー	`‾/.tt`
システム	`/etc/tt`
ネットワーク	`$OPENWINHOME/etc/tt` または `/usr/dt/appconfig/tttypes`

ToolTalk サービスを使用するには、X Window System が必要ですか

ToolTalk サービスは、メッセージの配信に X のメッセージやプロトコルを使用しません。ToolTalk サービスが X Window System と関連付けられるのは、X セッションを動作させた場合だけです。

X セッションを起動すると、そのセッション名が X サーバーのルートウィンドウ上にプロパティ (名称は TT_SESSION) として表示されます。この X サーバーをディスプレイとして指定するすべてのプロセスは、その X セッションをデフォルトセッションとして取得します。X セッションは個々の X ディスプレイ上で表示を行うプロセスのグループとして定義されているため、定義に従えば X Window System を起動する必要がありますが、ToolTalk サービスから要求があるまで X Window System を起動する必要はありません。

動作中の X サーバーが 1 つもない (たとえば、ダム端末上で動作する文字モードアプリケーションだけのセッションを実行する) 場合は、「プロセスツリーセッション」を使用してください。プロセスツリーセッションを実行すると、そのセッション名は環境変数 TT_SESSION に表示されます。プロセスツリーセッションは、プロセスツリー上で、自分より下のすべてのプロセスに対してデフォルトセッションになります。

MIT X で ToolTalk サービスを使用できますか

使用できます。ただし、libtt.so ファイル用に、LD_LIBRARY_PATH で /usr/dt/lib を指定しなければなりません。

X セッションのセッション ID はどこにありますか

この識別子を入手するには、次のコマンドを入力します。

 xprop -root | grep TT_SESSION

注 -

X セッションは、ルートウィンドウの TT_SESSION プロパティ上にそのセッション ID を表示します。

tt_open はどのように ttsession に接続しますか

内部的な初期設定を行なった後、tt_open は ttsession の検索を開始します。

tt_open は、環境変数 TT_SESSION が設定されているか検査します。

設定されている場合は、その値を ttsession の ID として使用します。

設定されていない場合は、環境変数 DISPLAY が設定されているか検査します。
- 設定されている場合は、その値を ttsession の ID として使用します。
- 設定されていない場合は、(そのディスプレイを実行しているマシンの) ルート X Window System 上の TT_SESSION プロパティが設定されているか検査します。
以上の結果、これらの環境変数が 1 つも設定されていない場合は、tt_open は自分で ttsession を起動します。
tt_open は、ttsession が動作中か確認します。
tt_open は環境変数 TT_TOKEN を検査し、そのクライアントが ptype の「Start」コマンドから起動されたかどうかを決定します。

ptype の「Start」コマンドから起動された場合、tt は procid を作成します。
tt_open は、ttsession が接続するクライアント側の TCP/IP ソケットを作成します。

ソケット上の動作は、関連付けられたファイル記述子で通知されます。ttsession はこのチャネルだけを使用して、着信メッセージをクライアントに通知します。

注 -
このファイル記述子には、tt_close を使用してください。close 関数をは使用しないでください。tt_fd が返すファイル記述子に close 関数を使用すると、後で tt_open や close を呼び出すたびに、ファイル記述子のカウント値が増えます。
tt_open は、データベースのホスト名リダイレクト用マップを読み取ります。

tt_open を呼び出した後、セッションが実際に始まるのはいつですか

デフォルトセッションが X セッションであり、動作中の ttsession がない場合は、libtt がセッションを 1 つ起動します。そうでない場合は、セッション名を入手するために、ttsession を最初に起動しなければなりません。

別のセッションが接続されると最初のセッションは終了しますか

終了しません。最初のセッションはまだ動作しています。

動作するマシンが異なるプロセス同士は、ToolTalk サービスをどのように使用すれば通信できますか

動作するマシンが異なるプロセス同士が ToolTalk サービスを使用して通信するには、次の 2 つの方法があります。

同一セッションに接続する。
それぞれのマシン上で NFS にファイルをマウントし、そのファイルを配信範囲とする。

同一セッションへの接続

複数のプロセスを同一セッションに接続するには、まずプロセス共通の処理対象 (セッション名など) を決定します。次に、それらの全プロセスにセッション名を伝達する方法を決定します。ToolTalk サービスには、セッションアドレスを配布する手段がありません (できるのは、X サーバールートウィンドウの TT_SESSION プロパティにセッション ID を表示することだけです)。

セッション名を入手するには、次のコマンドを使用できます。

 ttsession -p

これはセッションを新規に生成し、標準出力にそのセッション名を出力します。また、次のコマンドも使用できます。

 ttsession -c

これは環境変数 $TT_SESSION にセッション ID を設定します。

次に、他のプロセスが見つけられる場所に、セッション名を設定する必要があります。セッション名を設定する場所の例としては、次のものがあります。

共有ファイル
.plan ファイル
メールメッセージ
独自に設計した別の RPC 呼び出し
NIS

NFS^TM 公開ファイルシステムで、公共ファイルを使用する場合の例を次に示します。

次のコマンドで ttsession を起動します。
ttsession -p >/home/foo/sessionaddress
この /home/foo/sessionaddress ファイルに入っているセッションアドレスをクライアントで確実に使用するには、たとえば、次のようなシェルスクリプトでセッションアドレスを読み取り、_SUN_TT_SESSION を設定してからクライアントを起動します。
#!/bin/csh setenv TT_SESSION `cat /home/foo/sessionaddress` exec client-program

プロセスからこのセッションに接続するには、tt_default_session_set を呼び出す際にセッション名を指定します。

また、個々の X サーバーに関連付けられた ttsession からメッセージを送信すると、新規に作成した ttsession を表示できます。

NFS にマウントしたファイルを配信範囲とする

ファイルが配信範囲になるのは、ファイルを配信範囲とするパターンをプロセスが登録したときです。登録したプロセスのセッション名は、登録したファイルに関連付けられた rpc.ttdbserverd のセッションリスト上に格納されます。ファイルを配信範囲とするメッセージが送信されると、ToolTalk サービスは、この該当ファイルのセッションリストを検索し、そのリスト上の各セッションにメッセージを配布します。

注 -

NFS にマウントしたファイルを配信範囲とするには、すべてのシステム上で 1 つのファイルシステムを NFS にマウントし、rpc.ttdbserverd を NFS サーバー上で実行する必要があります。

tt_default_session_set の目的は何ですか

tt_default_session_set は、tt_open 呼び出しで接続する ttsession を指定します。

1 つのプロセスで 2 つ以上のセッションに接続するには、どうすればいいですか

ToolTalk サービスと通信する際に使用されるデフォルト変数を表 D-3 に示します。

表 D-3 デフォルト変数


変数	説明
procid	`tt_open` が設定する。この変数により `ttsession` はクライアントを識別する
ptype	`tt_ptype_declare` が設定する
file	ファイルを結合すると設定される。メッセージ中にファイルが 1 つも設定されていない場合は、デフォルトファイルが設定される

API 関数を使用して procid の取得と設定を行うと、アプリケーションから複数セッション間の切り替えができます。次に例を示します。

connect to session 1
store the default procid in filename
connect to session 2,
store the default procid filename
restore associated default procid
interact with particular_session

注 -

デフォルトのファイルと ptype は、現在のデフォルト procid の一部です。デフォルトの procid を変更すると、デフォルトのファイルと ptype も、その procid に関連付けられたものに変更されます。

あらかじめ決めたセッション ID で ttsession を起動できますか

起動できません。ttsession のセッション ID は、ToolTalk サービスから入手しなければなりません。

セッション ID には、どのような情報が入っていますか

セッション ID はたくさんのフィールドから構成されていますが、その中には次のものがあります。

アドレスフォーマットのバージョン
プロセスの UNIX pid
RPC 非常駐プログラム番号
未使用バージョン (互換性のために使用)
認証レベル
ユーザー ID
ホストの IP アドレス
RPC のバージョン

注意 -

セッション ID のフォーマットは、公開されていないインタフェースです。セッション ID のフォーマットに依存するような ToolTalk クライアントを作成しないでください。

プログラムが新しくセッションに参加したことを通知する標準的な方法はありますか

プロセスが新しくセッションに参加する際は、通知メッセージを送って、処理対象のプロセスに通知してください。また、プロセスが新しくセッションに参加した際に通知をもらいたいプロセスは、その通知メッセージを監視するためのパターンを登録しておく必要があります。

注 -

デスクトップサービスの「Started」メッセージは、このために開発されました。

メッセージの行き先を教えてください

送信した各メッセージを ttsession がどのように処理するかを監視するには、起動時に -t (トレースモード) を指定します。次のように USR1 シグナルを ttsession に送信すると、トレースモードのオンとオフを切り替えることができます。

 kill -USR1 <ttsession_pid>

また、ttsnoop ユーティリティ (または tttrace ユーティリティ) を使用すると、削除メッセージを監視できます。

メッセージの基本的なフローを教えてください

メッセージフローには、次の 2 種類があります。

セッションを配信範囲とするもの

ファイルを配信範囲とするもの

セッションを配信範囲とするメッセージフロー

セッションを配信範囲とするメッセージの基本的なフローは、次のとおりです。

クライアントが要求メッセージを作成し、tt_message_send を呼び出します。
ttsession がハンドラを見つけます。

ttsession はハンドラを起動する際に、環境変数 TT_TOKEN を設定します。
ハンドラが動作を開始し、tt_open と tt_fd を呼び出して、ttsession への通信を確立します。
ハンドラは自分の ptype を ttsession に宣言します。
ttsession は ptype の静的パターンをすべて動的パターンに変更します。

この時点では、ハンドラがまだセッションに参加していないため、そのパターンは無効です。
ハンドラがセッションに参加して、パターンが有効になります。
ttsession は、メッセージが待ち行列に入っていることをハンドラに通知します。
ハンドラはファイル記述子で通知を受け、tt_message_receive を呼び出してそのメッセージを検索します。

tt_message_receive が返したメッセージ状態が TT_WRN_START_MESSAGE の場合、ToolTalk サービスはすでにそのプロセスを起動してメッセージを配信済みです。この場合 ptype 用のメッセージは、プロセスがメッセージ (通知の場合でも) に対して応答、拒否、異常終了のいずれかの処理を行うか、tt_message_accept を呼び出すまでブロックされます。
ハンドラは要求された操作を実行します。
ハンドラは要求に対する応答を返します。
ttsession は、(応答) メッセージが待ち行列に入っていることをクライアントに通知します。

クライアントのファイル記述子が有効になります。

注 -
実際には、要求メッセージの状態が変化するたびに、クライアントはメッセージを受信します。
クライアントは tt_message_receive を呼び出し、結果を検索します。

ファイルを配信範囲とするメッセージフロー

ファイルを配信範囲とするメッセージの基本的なフローは、次のとおりです。

ファイルを配信範囲とするパターンが登録されます。

ファイルと、パターンを登録しようとしているセッションを、libtt がデータベースサーバーに通知します。
libtt はデータベースサーバーに照会して、指定されたファイルを処理対象として登録しているクライアントのセッションをすべて検索します。
- 通知の場合、libtt はこれらのセッションすべてと直接通信します。
- 要求の場合、libtt はメッセージと、関連する他のセッションリストをそのセッションに通知します。
これらのセッションは互いに通信し合い、ハンドラを探します。

アプリケーションにメッセージが到着するとどうなりますか

アプリケーションにメッセージが到着すると、次のようになります。

ファイル記述子が有効になります。
Xt メインループが select から抜け出し、XtAppAddInput 呼び出しで登録してある関数を呼び出します。
この登録関数は、tt_message_receive を呼び出します。

メッセージが読み込まれ、メッセージに関連付けられているコールバックがすべて起動されます。
メッセージのコールバックから戻ります。
- メッセージコールバックの戻り値が TT_CALLBACK_PROCESSED の場合、tt_message_receive は値として NULL を入力コールバックに返します。
- メッセージコールバックの戻り値が TT_CALLBACK_CONTINUE の場合、メッセージの Tt_message ハンドルが返されます。
入力コールバックは他の処理を継続します。

たとえば、次のような入力コールバックに対して、

input_callback(...)
{
     Tt_message m;
     printf ("input callback entered¥n");
     m = tt_message_receive();
     printf ("input callback exiting, message handle is %d¥n",
             (int)m);
}

メッセージコールバックが次のようになっている場合、

message_callback(...)
{
     printf("message callback entered¥n");
     return TT_CALLBACK_PROCESSED;
}

次のように出力されます。

input callback entered
message callback entered
input callback exiting, message handle is 0

メッセージを区別する方法を教えてください

メッセージの区別は、次のように行います。

動作中のすべての ttsession では、メッセージを一意に識別する識別子がメッセージごとに 1 つあります。

tt_message_user 呼び出しを使用すれば、ユーザーセルに関する情報を読み込み、メッセージをアプリケーションの内部状態に関連付けることができます。

メッセージハンドルは同じです。たとえば、例 D-1 では、受信メッセージと送信メッセージが同じかどうかを調べています。

例 D-1 メッセージの区別

    Tt_message m, n;
    m = tt_message_create();
    ...
    tt_message_send(m);

   ... wait around for tt_fd to become active

   n = tt_message_receive();
    if (m == n) {
 // this is a reply to the message we sent
        if (TT_HANDLED == tt_message_state(m)) {
             // the receiver has handled the message, so we can go on
             ....
         }
    } else {
         // this is some new message coming in
    }

プロセスは自分自身に要求を送信できますか

送信できます。プロセスは、自分で処理する要求を送信できます。このような要求は通常、次のように処理します。

{	...
	tt_message_arg_val_set(m, 1, "answer");
 tt_message_reply(m);
	tt_message_destroy(m);
 return TT_CALLBACK_PROCESSED;
}

しかし、ハンドラと送信者が同じプロセスの場合、(同じプロセスに) 応答が返って来た時点では、メッセージは既に削除されています。送信側がメッセージに添付したメッセージ (コールバックやユーザーデータなど) もすべて削除されています。これを防ぐには、メッセージを削除しないでください。次に例を示します。

{	...
	if (0!=strcmp(tt_message_sender(m),tt_default_procid())) {
		tt_message_destroy(m);
}

tt_message_callback_add で登録した関数に、自分自身のデータを渡せますか

tt_message_callback_add で登録した関数に自分自身のデータを渡すには、メッセージのユーザーデータセルを使用します。次に例を示します。

       x = tt_message_create();
       tt_message_callback_add(x,my_callback);
       tt_message_user_set(x, 1, (void *)my_data);

....

Tt_callback_action
Tt_message_callback(Tt_message m, Tt_pattern p)
{
	struct my_data_t *my_data;
 my data = (struct my_data_t *)tt_message_user(m, 1);

        ...

}

注 -

ユーザーデータは、送信先クライアントでしか見ることができません。

任意のデータをメッセージで送信する方法を教えてください

ToolTalk サービスには構造体を送信する方法が組み込まれていないため、送信できるのは文字列、整数、バイト配列だけです。構造体を送信するには、XDR ルーチンを使用して構造体をバイト配列に変換した後、メッセージに設定します。このシリアル化を解除するにも、同じ XDR ルーチンを使用します。

ToolTalk サービスでファイルを転送できますか

直接は転送できません。ただし、次のことは可能です。

ファイルデータをメッセージの引数に設定する。

ToolTalk サービスはメッセージデータを、アプリケーションからライブラリに、ライブラリから ttsession に、ttsession から受信側のライブラリへとコピーし、受信側が引数値を取得する際に、この受信側のライブラリから取り出します。データが大きいと、この方法では非常に遅くなり、使用するメモリーも膨大になります。
ファイル名をメッセージの引数に設定する。

この方法では、すべての受信側がファイルを同じ場所にマウントすることが前提です。
ファイル名を tt_message_file 属性に設定する。

この方法でもすべての受信側がファイルをマウントすることが前提ですが、マウント場所が異なる場合は、ToolTalk サービスがすべて解決します。

ToolTalk サービスは、メモリー (バイト) の順序の問題をどのように処理しますか

ToolTalk サービスでは、整数、文字列、バイト配列をメッセージに格納できます。XDR ルーチンにより、これらのデータ型はどのクライアントでも保証されています。これら 3 つの型以外のデータの場合は、メッセージに設定する前にシリアル化して、バイト配列にしなければなりません。

メッセージは再使用できますか

再使用できません。引数を変えて同じメッセージを複数回は送信できません。メッセージはそれぞれ、作成、送信、破棄のサイクルを繰り返さなければなりません。

メッセージを破棄するとどうなりますか

メッセージを破棄する際、そのハンドルは破棄できますが、メッセージ本体は破棄できません。メッセージ本体は、ToolTalk がそのメッセージの処理を完了し、外部のハンドルがすべて破棄されたときにだけ破棄されます。たとえば、メッセージを送信した直後にそのハンドルを破棄しても、応答が返って来た時点で新しいハンドルが渡されます。

メッセージをいったん破棄してしまうと、二度とそのメッセージを見ることはできません。たとえば、自分が送信する要求を監視するパターンを登録し、パターンが一致した時点でそのメッセージを破棄すると、そのメッセージの状態が「handled」(応答) になってもそのメッセージを見ることはできません。

1 つのメッセージを 2 つ以上のハンドラで処理できますか

現在は処理できません。1 つのメッセージを複数のプロセスで処理したい場合は、通知を使用できます。また、メッセージの拒否を利用して ToolTalk サービスに、使用可能なハンドラすべてに要求を配信させることもできます。ただし、これらのハンドラはそれぞれ、実際には何らかの操作を処理する必要があります。

1 つの ptype のハンドラを 2 つ以上実行できますか

実行できます。ただし、ToolTalk サービスには負荷分散の概念がないため、ToolTalk はいくつかのハンドラから 1 つだけ選択し、一致するものであれば、その他のメッセージもそのハンドラだけに配信します。メッセージをその他のハンドラにも配信させるには、次のような方法があります。

tt_message_reject を使用する。

メッセージを受信してもビジーなのでそのメッセージを処理したくないプロセスは、メッセージを拒否できます。この場合、ToolTalk サービスは使用可能な次のハンドラを探します。(登録されているハンドラがすべて拒否した場合は、処置オプションが適用されます。)

この方法では、tt_fd が有効になったら tt_message_receive を呼び出すというイベントループを、プロセスが実行中でなければなりません。ただし、プロセスが複雑な計算ループを実行していると、この方法ではうまくいきません。
ビジーになるようなメッセージの場合は、そのパターンを登録解除する。次に例を示します。
m = tt_message_receive(); if (m is the message that causes us to go busy) { tt_pattern_unregister(p); }
ToolTalk サービスは、パターンが登録されていないと、一致するメッセージをプロセスに渡しません。プロセスでもう一度メッセージを受信したい場合は、パターンを再登録してください。

注 -
この方法を使用すると、競争条件が生じます。たとえば、tt_message_receive と tt_pattern_unregister 呼び出しの間に次のメッセージが送信され、このプロセスに渡される可能性があります。

方法 1 と方法 2 を組み合わせる。

方法 1 と方法 2 を組み合わせて、次のようにすることもできます。

get the message
   unregister the pattern
   loop, calling tt_message_receive until it returns 0; reject
   all the returned messages
   handle the message
   re-register the pattern
   repeat

注 -

この方法では、プロセスで登録するパターンは 1 つであることが前提です。

メッセージの処置の値とは何ですか

メッセージの処置を指定すると、静的型定義に指定された処置の値を上書きできます。ハンドラに ptype を指定したメッセージが静的シグニチャに一致しないと、メッセージで指定した処置に従って処理されます。たとえば、メッセージの処置に TT_START、ptype に開始文字列を指定すると、インスタンスが 1 つ起動されます。

メッセージ状態要素とは何ですか

ToolTalk サービスでは、message_status_string を使用しません。このメッセージ要素は、アプリケーションが使用するためのものです。ToolTalk サービスがこのメッセージ状態を設定するのは、メッセージの配信に問題が発生したときだけです。その他の場合、このメッセージ要素はアプリケーション独自の方法で設定または読み取りを行います。

tt_free はいつ使用しますか

アプリケーションがデータバッファとして受け取る内部記憶領域のスタックは、libtt が管理します。アプリケーションが ToolTalk API ルーチンから返される char * や void * はすべて、そのコピー領域を指していて、これらの領域はアプリケーションで解放する必要があります。

割り当てられたバッファは、マーク関数と解放関数を使用して、一連の操作で解放してください。ただし、解放関数を呼び出すと、対応するマーク関数を呼び出した以降に割り当てられたすべての領域が解放されます。ToolTalk サービスが返したデータを一部残しておきたい場合は、解放操作を実行する前にデータのコピーを取っておいてください。

ptype とは何ですか

ptype はツールの種類を指定する文字列で、プログラマが定義します。(「プロセス型」と呼ぶこともあります。) 各 ptype は一連のパターンに関連付けることができます。そのパターンには、ptype が処理対象とするメッセージと、その ptype のインスタンスを起動する際に ToolTalk サービスが使用する文字列を指定します。

ptype の主な目的は、ツールのインスタンスがメッセージの配信範囲で 1 つも動作していないときも、メッセージをツールの処理対象にできるようにすることです。メッセージが要求する操作を実行できる場合や、メッセージが送信された際に通知を受けたい場合は、ツールの ptype でその旨を指示しておくと、ToolTalk は必要に応じてそのツールを起動します。ptype データベースはシステム管理者やユーザーが変更できるため、現場やユーザーの好みに応じて、個々のメッセージを処理するツールを指定できます。

新しく作成した型が認識されない理由を教えてください

ttsession がデータベースタイプを読み込むのは、起動時、USR1 信号受信時、またはデータベースタイプが変更されたときに特別の ToolTalk メッセージによってその旨を通知されたときです。通常、手作業で ttsession を更新してファイルタイプをもう一度読み込む必要はありません。ただし、強制的に実行中の ttsession にデータベースタイプを再読み込みさせたいときは、下記のような USR2 信号を送信することによって実行できます。たとえば、次のように送信します。

 kill -USR2 <ttsession pid>

ptype のプロセスが既に存在する場合、ptype 情報は使用されますか

ToolTalk サービスは、すべてのメッセージに対して常に 1 つのハンドラと任意の数のオブザーバを探します。この場合、ToolTalk サービスは動作中のハンドラを 1 つ見つけても、メッセージに一致する任意の監視パターンを ptype の中から探します。一致する監視パターンの ptype が 1 つ存在するが、その ptype のプロセスが動作していない場合、ToolTalk サービスは (ptype パターンまたはメッセージの指定に従って) プロセスを新しく起動するか、メッセージを待ち行列に入れます。

(インスタンスが既に動作中かどうかにかかわらず) インスタンスを常に起動するよう ptype の定義を変更できますか

変更できません。起動時の ptype へのメッセージは、ptype がそのメッセージに応答するか、tt_message_accept 呼び出しを発行するまでブロックされます。しかし ptype は、TT_WRN_START_MESSAGE 状態以外のすべての要求に対して、tt_message_reject を実行できます。したがって、その ptype を持つ動作中のすべてのインスタンスにすべての要求が配信され (そして拒否され) てから、インスタンスが新しく起動されます。この方法は、同時に動作している ptype が多い場合や、メッセージに大量のデータが入っている場合は遅くなります。また、tt_message_accept を使用することもできます。これは、ptype へのメッセージを基本的にはブロックしません。

tt_ptype_declare は何を行いますか

ptype を宣言した時点では、静的パターンは ttsession のメモリーに存在します。アプリケーションが ptype を登録すると、ToolTalk サービスはその ptype を指定している otype をチェックし、otype の中のパターンも登録します。静的パターンを有効にするには、アプリケーションから適切な join 関数を呼び出す必要があります。

注 -

1 つのアプリケーションで同じ ptype を複数回宣言しても無視されます。

TT_TOKEN とは何ですか

アプリケーションの起動を要求するメッセージを処理する際、ToolTalk サービスは、その子プロセスの _SUN_TT_TOKEN 環境変数を設定します。アプリケーションが動作を開始して tt_open を実行すると、この情報は ToolTalk サービスに戻され、メッセージを処理するのに起動、つまり任命されたのはそのアプリケーションであることを ToolTalk に知らせます。

パターンはいつ有効になりますか

パターンは、そのパターンを有効にしたいセッションに登録しなければなりません。パターンは (1 つの procid で) 2 つ以上のファイルに対して有効にできるため、パターンのファイル部はリストされたすべてのファイルに一致します。

注 -

コンテキストは配信範囲ではありません。コンテキストに結合してもファイルやセッションに結合していないパターンは、どのメッセージにも一致できません。

応答を入手するにはパターンの登録が必要ですか

必要ありません。ただし、応答に一致するパターンを登録すると、その応答はイベントループに 2 度表われます。1 度目はパターンに一致したためで、2 度目はそれが応答であるためです。

要求を監視するにはどうすればいいですか

パターンに一致し、しかもポイントツーポイント (つまり TT_HANDLER) ではない要求メッセージは監視できます。監視パターンがどの要求にも一致しない場合は、ttsession をトレースモードで動作させれば原因が分かります。

静的パターンの属性値と照合させる方法を教えてください

ToolTalk の静的パターン (つまり、型データベース) 機構では、属性値でパターンと照合させることはできません。ファイルの配信範囲や引数の vtype で照合させることはできますが、ファイル名や引数値で照合させることはできません。

注 -

この制限は、静的パターンのコンテキストの照合にも当てはまります。

TT_HANDLER に対してワイルドカードでパターンを指定できない理由を教えてください

TT_HANDLER にアドレス指定されたメッセージは、パターンと照合されないため、ワイルドカードでパターンを指定できません。

ファイルを配信範囲とする任意のメッセージを監視するようなパターンを設定できますか

設定できません。ファイルを配信範囲とする際にファイル名を指定しないのは、すべてのファイルについてファイルを配信範囲とするメッセージと照合するよう指定するのと実質的には同じです。

注 -

ファイルを配信範囲とするパターンにセッション属性を設定して、セッション中のファイルを配信範囲とするようエミュレートしてもかまいません。ただし、配信範囲が TT_FILE になっているパターンのセッション属性は、tt_session_join を呼び出しても更新されません。

静的パターンのファイル配信範囲は file_in_session と同じですか

違います。これらの配信範囲は使用目的が違います。

たとえば、すべてのセッションが同じ静的パターンを持ち、(アプリケーションが送信しようとしている) メッセージ M に一致するパターン P を少なくとも 1 つ持つとします。そして、ファイル foo.bar を処理対象とするクライアントのセッションが 1 つもないとします。

アプリケーションはセッション A に接続しており、ファイル foo.bar を配信範囲とするメッセージ M を発行します。このファイルを処理対象とするクライアントのセッションは 1 つもないため、このメッセージを受け取るファイルはセッション A だけです。(このメッセージは、セッション A の静的パターン P と一致します。) ptype が動作を開始すると、そのパターンは実際には (そのセッション中の) ファイルを配信範囲とするようになり、セッション A がすべて処理します。

セッションの静的パターンがすべて同じとは限らない場合は、結果は異なります。たとえばセッション B が、ファイル配信範囲指定でメッセージ M に一致する P' というパターンを持つことも考えられます。メッセージ M がセッション A に送信されると、ファイル foo.bar を処理対象にしたクライアントがセッション B に 1 つもない場合、dbserver はそのメッセージをセッション B に送信しません。しかし、セッション B のクライアントの 1 つがファイル foo.bar を処理対象としていれば、セッション B の少なくとも 1 つのクライアントがファイル foo.bar を処理対象としていることを知り、dbserver はセッション B にもそのメッセージを送信します。

arg_add、barg_add、iarg_add の違いを教えてください

barg_add と iarg_add の呼び出しも、基本的には一組の値が後ろに付いた arg_add 呼び出しです。

メッセージ引数の type や vtype とは何ですか

メッセージ引数の type や vtype (value type の短縮形) は、その引数値が意味を持つ領域を示し、アプリケーションが指定します。

vtype は C の typedef に似ています。すべての vtype は通常、その引数に設定できる 3 種類のデータ型のどれか 1 つに対応します。

vtype 機構を使用すれば、2 つの値を同じ型として宣言できます。たとえば、messageID と bufferID という 2 つの vtype を C の文字列と同様に、それぞれ異なる意味を持つように定義し、操作によって messageID にだけ有効、bufferID にだけ有効、または両方の vtype に有効とすることもできます。このパターン照合機構を使用すれば、bufferID 文字列を指定した要求は、messageID 文字列にだけ有効な操作のパターンには一致しません。

コンテキストの使用方法を教えてください

コンテキストは、照合を制限するのに使用できます。照合を制限するには、照合する確率を大きくするために、メッセージは同じコンテキスト、つまりコンテキストのスーパーセットを持たなければなりません。また、コンテキストスロット名がドル記号 ($) で始まり (たとえば $ISV)、そのメッセージによってアプリケーションが起動される場合、コンテキストスロットにどのような値が設定されていても、その値がアプリケーションの環境変数に設定されます。

ttsession はどのように照合をチェックしますか

ttsession が照合を検査するさまざまな方法を表 D-4 に示します。

表 D-4 ttsession の照合の検査方法


方法	説明	一致するか
`TT_HANDLER`	このようなアドレス指定は「ポイントツーポイント」配信であり、メッセージは受信側に直接渡される。登録されたパターンは検査されないため、ポイントツーポイントのメッセージは監視できない	照合は不要
`TT_PROCEDURE`	操作 (op) の同じ静的シグニチャ (sig) のリストを検索し、オブザーバと見込みのあるハンドラのリストを収集する。 sig が引数もコンテキストも持たない場合 sig プロトタイプ (引数の個数、型、モード) の値が異なる場合 sig コンテキストがメッセージのコンテキストのサブセットである場合待ち行列に入れる必要のあるすべての静的オブザーバ用情報を保存する。動的パターンを検索し、オブザーバと使用可能なハンドラのリストに追加する。このリストを作成するのに、`ttsession` はまず操作付きのパターンを使用し、次に操作なしのパターンを使用する。信頼性、状態、クラス、アドレス、ハンドラ、ハンドラの ptype、配信範囲、オブジェクト、otype、送信側、送信側の ptype、引数、コンテキストを検査する。まずオブザーバに配信する (ハンドラは状態が変わる可能性があるため)。最もよく一致したハンドラに配信する。2 つ以上のハンドラが等しく「最適」な場合は、任意に選択する。	=> 一致する => 一致しない => 一致する
`TT_OBJECT & TT_OTYPE`	type 引数が設定されているかどうかを検査する。 sig が異なる otype を持つ場合 sig が otype を 1 つも持たず、配信範囲が異なる場合その他の場合は、`TT_PROCEDURE`	=> 一致しない => 一致しない

ToolTalk サービスには、配信範囲が何種類ありますか

現在は、セッションとファイルの 2 種類だけです。

注 -

X セッションも 1 つの配信範囲と言われることがありますが、実際にはセッション配信範囲です。

TT_DB ディレクトリとは何ですか、また、型データベースと TT_DB ディレクトリは何が違いますか

ToolTalk 型データベースには、静的な ptype と otype の定義が入っています。これらの定義は、アプリケーションやオブジェクトが応答するメッセージを宣言しています。静的型定義を追加または変更すると、ToolTalk 型コンパイラがその型データベースを更新します。ttsession は起動時、これらの型ファイルを読み込みます。

TT_DB データベースは、rpc.ttdbserverd が作成します。tt_db ディレクトリには、このパーティション内のファイルと、そのファイルを処理対象とするパターンのセッションの関連付けが入っています。また、このパーティション内のファイルのオブジェクト仕様情報もすべて入っています。

tt_db データベースには何を入れればいいですか

tt_db データベースには現在、次の 10 個のファイルが入っています。

access_table.ind
access_table.rec
file_object_map.ind
file_object_map.rec
file_table.ind
file_table.rec
file_table.var
property_table.ind
property_table.rec
property_table.var

これらのファイルのアクセス権は、-rw-r--r-- に設定されています。

rpc.ttdbserverd は何を実行しますか

ToolTalk データベースサーバーのデーモンは、次の主な機能を実行します。

tt_file_join 呼び出しでファイルを結合したクライアントのセッション ID を格納する。
メッセージの処置が TT_QUEUED で、しかもそのメッセージを処理できるハンドラがまだ起動されていないために待ち行列に入っているファイル配信範囲のメッセージを格納する。
ToolTalk のオブジェクト仕様を格納する。
ToolTalk ファイル名フレームマッピング API への要求に応答する。

ttsession と rpc.ttdbserverd は通信しますか

通信しません。

どのような帯域幅のメッセージをサポートできますか

小さなメッセージなら 1 秒あたり約 100 個です。性能は主に、各メッセージの受信側の数で決まります。つまり、どのパターンにも一致しない通知が最も安く、多くのオブザーバに一致するメッセージが最も高くなります。

メッセージサイズや引数の個数に制限はありますか

制限はありません。ToolTalk メッセージのサイズや引数の個数に設計上の制限はありませんが、ToolTalk はメッセージデータを (クライアントのアドレス空間内の領域間、および RPC 接続を経由したサーバーとの間で) 何回かコピーします。たとえば、ToolTalk メッセージで 1M バイトのデータを送信すると、次のように少なくとも 4 回コピーされます。

アプリケーション領域から ToolTalk ライブラリ領域へ
ToolTalk ライブラリ領域から ToolTalk サーバーへ
ToolTalk サーバーから受信側のライブラリへ
受信側のライブラリから最終目的地へ

このメッセージを監視しているプロセスがあると、さらにコピー回数が増えます。また、ttsession プロセスはシングルスレッドであるため、コピー期間中は、このセッションに他のメッセージは配信されません。このため、非常に大きなデータを頻繁に送信する場合は、ToolTalk 以外の方法でデータを渡すよう検討する必要があります。

メッセージを送信する際、最も時間効率のよい方法は何ですか

手続き的なメッセージで 1 つの受信者だけに一致させるより、直接処理する (つまり、TT_HANDLER を使用してメッセージをアドレス指定する) 方が高速です。

ネットワークのオーバヘッドの種類を教えてください

ToolTalk サービスでは、ハードウェアによるブロードキャストやマルチキャストを使用しません。メッセージは、(ネットワークを経由するかどうかに関係なく) 該当セッションの ttsession プロセスに直接送信されます。パターンを登録すると、そのパターンも ttsession プロセスに直接送信されます。ttsession プロセスは、すべてのパターンに対してメッセージを照合し、メッセージに一致するパターンを登録してあるプロセスにだけメッセージを直接送信します。メッセージを処理対象とするプロセスがマシン上にない場合、そのマシンは起動されません。

ToolTalk サービスは、要求を処理するのに負荷分散を使用しますか

使用しません。ToolTalk サービスは、負荷分散機構ではありません。同じパターンを持つプロセスを 2 つ登録してある場合、ToolTalk サービスはどちらか 1 つのプロセスを任意に選択して、一致するメッセージをすべてそのプロセスに配信します。プロセスがビジーの間はパターンを登録解除して、同時にパターンを登録解除する前に受信していた可能性のあるメッセージをすべて拒否すると、負荷を分散できます。

ToolTalk アプリケーションに必要なリソースには何がありますか

メッセージを処理するには、送信側クライアント、ttsession、受信側クライアントで約数百キロバイトのワーキングセットが必要です。クライアントがメッセージをタイムリに処理している限り、ToolTalk のメモリー条件は、時間が経過しても変わりません。

ttsession が異常終了するとどうなりますか

ttsession に障害が発生すると tt_fd が有効になり、ToolTalk API 呼び出しのほとんどが次のような TT_ERR_NOMP エラーメッセージを返します。

 No Message Passer

このメッセージが返されると、ほとんどのアプリケーションは ttsession に何か問題が発生したものとして、ToolTalk メッセージの送受信を停止します。この状況から回復する方法を次に示します。

TT_ERR_NOMP という状況を認識する。
tt_close を呼び出し、相手との接続を切断する。
ToolTalk サービスを再度初期設定する。
次の順序で呼び出す。

   tt_open, tt_default_session_join, tt_fd

パターンをすべて再登録し、ptype を再度宣言する。

注 -

障害の発生した ttsession を再起動して障害発生箇所から継続する際、環境変数 TT_SESSION の設定と、ルートの X Window System がある場合は TT_SESSION プロパティ値を操作する必要がある場合があります。また、障害の発生したセッションの他の参加者も回復できるように、再起動したセッションと新しいセッションの ID を連絡する必要があります。

ttsession に障害が発生すると、次の項目は回復できません。

障害が発生したセッションの procid で登録したパターン
障害が発生したセッションの procid から出した要求で保留されているもの
障害が発生したセッションの procid で tt_message_send_on_exit 呼び出しに渡したメッセージ
セッションのプロパティ
セッションの待ち行列に入っているメッセージ

rpc.ttdbserverd が異常終了するとどうなりますか

rpc.ttdbserverd が不意に終了すると、inetd は代わりに新しい rpc.ttdbserverd を起動します。データは一時的に使用できなくなりますが消失しません。ただし、API 呼び出しが TT_ERR_DBAVAIL を返すことがあります。API 呼び出しが TT_OK を返すと、dbserver は即座に、または障害回復記録を新しい dbserver が読んだ時点で、ToolTalk データベースを更新します。

ホストやリンクが停止するとどうなりますか

ホストやリンクが停止したことを TCP が検知すると、TCP 接続は破棄されます。プロセスと ttsession の接続が破壊されると、ttsession はそのプロセスが終了したときと同じように動作します。パターンがすべて消去されるため、メッセージを送受信しようとすると、プロセスは TT_ERR_NOMP というエラーメッセージを受信します。

tt_close は何をしますか

tt_close を呼び出すと、ttsession は現在の procid だけを閉じます。現在の procid が最後の procid の場合は、tt_open 呼び出し以降に作成された ToolTalk の構造体をすべて消去します。tt_close は tt_fd が返したファイル記述子を使って呼び出さなければなりません。そうしないと、後で tt_open や close を呼び出すたびにファイル記述子のカウンタ値が増えます。

メッセージの配信は、ネットワーク上でも保証されますか

保証されます。メッセージは TCP/IP の RPC を使用して送信するため、配信の信頼性があります。

メッセージの配信には、時間的な順序がありますか

送信側と受信側の間では、メッセージの順序は決まっています。まず、プロセス A がメッセージ M1 を送り、その後でメッセージ M2 を送信し、これらのメッセージをプロセス B が受信する場合、プロセス B はメッセージ M2 を受信する前にメッセージ M1 を受信します。ただし、次の 2 つの例外があります。

プロセス B がメッセージ M1 を受信して拒否すると、メッセージ M1 は再度ディスパッチされてプロセス C に行きます。この間 (プロセス B がメッセージ M1 に対して応答するか拒否するかを決定している間)、ToolTalk サービスはメッセージの配信を継続します。このような場合は、後のメッセージが最初のメッセージを「追い越した」ように見えることがあります。
プロセス B へのメッセージが待ち行列に入っている場合、待ち行列に入る原因となったパターンの ptype をプロセス B が宣言した時点で、プロセス B 待ち行列に入っていたメッセージを受信します。しかし、プロセス B は実際は、プロセス A から次のメッセージをすべて受信するまで、待ち行列に入ったメッセージ (この場合はメッセージ M1 ) を受信しない場合があります。

unix、xauth、des とは何ですか

これらは認証方法の種類です。

unix は、RPC 呼び出しでアプリケーションを呼び出しているエンティティの uid を教えます。dbserver は各 RPC 呼び出しに機密保護を実施し、デフォルト時はこの認証方法を使用します。
xauth はホームディレクトリ中の読み出し保護ファイルを使用して、X ディスプレイへのアクセスを制御します (これにより、ttsession へのアクセスも制御されます)。
des はデータ暗号化規格 (DES) を使用して、ttsession にアクセスするプロセスの身元をチェックします。

アプリケーションが互いにメッセージを隠すことはできますか

できません。あるアプリケーションへのメッセージを他のアプリケーションが隠す機構を、ToolTalk サービスでは意図的に提供していません。

横取りや模造に対して保護機構はありますか

ありません。ToolTalk サービスの「プラグアンドプレイ」概念によれば、アプリケーションは個々のタスクに最適なツールを選択して、インストールしたりインストールを解除したりできます。プロトコル X に対して、アプリケーション A よりアプリケーション B の方が応答が良い場合、アプリケーション A のインストールを解除して、アプリケーション B をインストールできるようにプロトコル X を設計してください。

待ち行列に入ったメッセージはどこに格納されていますか、また、その記憶領域はどのくらい安全ですか

ファイルを配信範囲とするメッセージで待ち行列に入ったものは、配信範囲となるファイルと同じファイルシステム上のデータベースに格納されます。このデータベースを読むことができるのはスーパーユーザーだけであり、(ルートとして動作中の) ToolTalk データベースサーバーは、そのファイルの読み取り権を持つユーザーのプロセスだけにそのメッセージを渡します。

セッションを配信範囲とするメッセージで待ち行列に入ったものは、そのセッションを管理する ttsession のアドレス空間に格納されます。ttsession は、自分が動作している認証モードを満たすプロセスだけにそのメッセージを渡します。

ToolTalk サービスは C2 保証されていますか

保証されていません。

メッセージの行方を追跡するには、どうすればいいですか

メッセージの行方を追跡するには、使用する ttsession のトレース出力をオンにしてください。これを行う最も簡単な方法は、関連する ttsession のトレース出力をオンにすることですが、次のコマンドを使って SIGUSR1 信号を ttsession の実行プロセスに送信する方法もあります。

 kill -USR1 <unix_pid_of_the_ttsession_process>

ToolTalk サービスを使用して、他のすべてのツールから自分のデバッグツールを隔離するには、どうすればいいですか

デバッグツールを隔離するには、「プロセスツリーセッション」モードを使用してください。このモードはセッション名を環境変数に設定して、該当する ttsession プロセスを見つけます。このモードを使用するには、次のように実行してください。

トレースモードをオンにして、プロセスツリーセッションを新しく起動します。
% ttsession -t -c $SHELL * * ttsession (version 1.3, library 1.3) * ttsession: starting %
ttsession が動作を開始して該当する環境変数を設定し、指定されたコマンド ($SHELL) を生成します。この段階では、サブシェルを実行しています。このサブシェルから起動したコマンドはすべて、上記ので起動した ttsession を使用します。この新しい ttsession のセッション ID は、環境変数 TT_SESSION に入っています。

サブシェルの中で次のテストプログラムを実行します。

% ./my_receiver &
[1] 4532
% ./my_sender &

.. and look at the output of the ttsession trace.

テストが完了したら、サブシェルを終了します。

サブシェルの中で ToolTalk サービスを使用するツールを起動すると、X セッションの ttsession ではなく、プロセスツリーの ttsession が使用されるため未定義となります。

C++ で ToolTalk サービスを使用できますか

使用できます。ToolTalk API ヘッダーファイルは、C++ を扱えるようになっています。C++ を使用する際、tt_c.h はすべての API 呼び出しを extern C として宣言します。

ファイル名を修飾する必要はありますか

ありません。ToolTalk サービスでは、パス名の明示的なホスト名修飾を許可していません。ファイル名の中にコロン (:) を使用すると、ToolTalk サービスはコロンの入ったファイル名を検索します。tt_message_file や tt_default_file を呼び出すと、使用中のマシンの画面に表示されるのと同じような形式で、指定したファイルの「実パス」が返されます。ToolTalk サービスでは、次のことを保証しています。

2 つのクライアントが、異なるマシン上にある同じ名前のファイルを配信範囲に指定した場合、各マシン上にファイルが実際にマウントされているかどうかにかかわらず、これらのクライアントは互いに交信できる。
ローカルで有効な、標準的なパス名が返される。

ToolTalk オブジェクトとは何ですか

ToolTalk オブジェクトは、通常のオブジェクト指向言語によく出てくるオブジェクトとは少し異なっています。

otype と継承は実行専用です。2 つの仕様が同じ otype を持つことはできますが、プロパティが異なります。これらが共有するのは、otype の宣言のシグニチャで定義した操作だけです。otype の宣言の各シグニチャに対して、ptype を 1 つ指定しなければなりません。指定した ptype (プロセス型) は、この otype を持つオブジェクトに対する操作の「実行エンジン」です。仕様のファイル部は要求されたプロパティと同様、すべての仕様がファイル名を持たなければなりません。ただし、そのファイルが存在する必要はありません。仕様のファイル名部分にはいくつかの機能がありますが、その中には次のようなものがあります。

仕様を格納するホストやパーティションを指定する。
オブジェクトに対してグループ化機構を提供する。
ToolTalk で拡張した標準オペレーティングコマンド (ttmv など) で、データベース内外の整合性をとる。

ToolTalk ニュースグループはありますか

あります。ToolTalk news グループは、alt.soft-sys.tooltalk です。共通デスクトップ環境 (CDE) は、新規のアプリケーションの統合やアプリケーションプログラムの起動時に ToolTalk を利用しているため、comp.unix.cde グループも役立つでしょう。