クライアントとサーバーのクラッシュは誰もが避けたいものですが、ひとたびそれが発生した場合は、再発を防止し、迅速な復旧を行うために必要なデータを入手することが最優先事項となります。 この記事では、IBM Lotus Notes/Domino 7に追加された新しい保守機能について解説します。この記事は、IBMサポートに送信するためにクラッシュ関連の適切なデータを取得したいDominoのシステム管理者、およびNotes Clientが突然停止したときに何が起きたのかを知りたいユーザーの方を対象に書かれています。
障害復旧はリリース 4からUNIXプラットフォーム向けのLotus Dominoに搭載されましたが、マニュアルに記載がなく、やや使いづらいものでした。 Lotus Notes/Domino 6から、障害復旧はLotus Notes/Dominoが実行されているすべてのプラットフォームで機能するようになり、サーバー文書で容易に設定できるようになりました。 障害復旧は、クライアントまたはサーバーに使用されているすべてのリソースを追跡し、クラッシュが発生したときは、これらをすべてクリーンアップします。 Domino Serverについては、診断情報を取得した後に、これを再起動するオプション機能があります。 ユーザーにとって、これはNotes Clientによって開始されたすべてのプロセスを停止しなくても、クラッシュ後にNotes Clientを再起動できることを意味します。
障害復旧により、Lotus Notes/Dominoはクラッシュごとに適切な診断情報を収集できます。しかし、クラッシュが発生した各マシンで、この情報にアクセスしなければならないため、 Notes Clientクラッシュの場合はこれが問題となることがあります。各マシンからデータを収集する必要性をなくすために、自動診断収集(ADC)機能がLotus Notes/Domino 6.0.1に追加されました。 ADCを使用してメール受信データベースを設定することにより、Notes ClientまたはDomino Serverのクラッシュから収集された診断情報を中央の1箇所のリポジトリーに集約することができます。
ADCは、サーバー設定文書(サーバー用)およびデスクトップポリシー設定文書(クライアント用)を通じて設定できます。データは、クライアントまたはサーバーが再起動するときに、メール受信データベースに送られます。 クライアント・クラッシュの場合、ポリシー文書によって、ユーザーに診断情報の送信の選択を許可するかどうか、クラッシュ前にユーザーが何をしていたかを示すコメントの入力を許可するかどうかを設定できます。
Lotus Notes/Domino 7の自動診断収集(ADC)に追加された新機能
Lotus Notes/Domino 7では、ADC機能が拡張されました。このセクションでは、新しい機能について紹介し、より適切な診断情報を収集し、機能停止に至るまでの傾向を把握する方法について解説します。 新しい機能は次のとおりです。
- クラッシュ発生時に収集するファイルの設定
- SametimeおよびQuickPlaceのクラッシュで収集される追加情報
- Dominoドメインモニター(DDM)へのサーバーの再起動の通知
- ログ用オプションの拡張
- 電子メール通知に含まれる情報の拡張
- 添付ファイルサイズの制限
- NSDの実行が設定されていない場合の警告
- Fault Analyzer
Lotus Notes/Domino 6.xでは、ADCはあらかじめ決められたファイルのリストに沿って収集していました。これには、NSD出力、コンソール・ログ、メモリー・ダンプが含まれます。 標準的なクラッシュのデバッグにはこれらの情報で十分ですが、固有のログ・ファイルを持つサード・パーティー製アプリケーションがクライアントまたはサーバーで実行されている場合はどうなるでしょうか。 あるいは、セマフォーで競合があり、それが停止の原因となったためにSEMDEBUG.TXTファイルを取得したい場合はどうすればよいでしょうか。
Lotus Notes/Domino 7では、デフォルトで取得されるファイルの数が増え、クラッシュ時に追加ファイルを収集するためのオプションも設けられています。デフォルトで収集されるファイルは次のとおりです。
- NSD出力:システム情報のダンプと、クラッシュ時にすべてのNotes/Dominoプロセスの各スレッドが何をしていたかを示す情報です。
- コンソール出力:Dominoコンソールに書き込まれたメッセージを含むテキスト・ファイルです。
- メモリー・ダンプ:特定の時刻にNotes/Dominoプロセスによって割り当てられていたメモリー・ブロックのスナップショットです。
- Notes_Child_PID出力:各プロセスの作成時のプロセス IDと、終了時のステータス情報です。
- Memcheckエラー:Notes/Dominoメモリー・プールをスキャンするときに、memcheckプログラムによって検出されたエラーです。
- セマフォー・デバッグ:競合するセマフォーを示すテキスト・ファイルです。
- HTTPセッション/スレッド・ログ:各HTTPセッションとスレッドが何をしていたのかを示す詳細情報です。これは、クラッシュがHTTPで発生し、セッション/スレッド・ロギングが有効になっている場合にのみ収集されます。
- NSD-sysinfo出力:クライアント/サーバーの起動時に記録されたシステム情報です。
- NSD-kill出力:クライアントまたはサーバーを終了するためにnsd -killを使用したときに収集される情報です。
これらのファイルに加え、サーバー設定文書またはデスクトップポリシー設定文書を設定することにより、クラッシュ時に存在する可能性がある任意のファイルを収集できます。 これらのいずれかの文書で[診断情報]タブをクリックすると、次の図1に示すようなセクションが表示されます。これは、Domino 7のDominoディレクトリの設計を使用します。
図1. [診断情報コレクションオプション]セクション

[診断情報ファイルのパターン]フィールドには、クラッシュ時に検索し、メール受信データベースに送る文書に情報を添付するファイル名またはパターンのリストを入力します。 ただし、添付されるのは、設定されたサイズの制限を超えない場合です(サイズの制限については、後述の「添付ファイルのサイズの制限」セクションを参照してください)。 パターンには、1つ以上の文字を示すアスタリスク(*)、または1文字を示す疑問符(?)を含めることができます。
ファイルが現在の診断ディレクトリー(通常は、<データ・ディレクトリー>/IBM_TECHNICAL_SUPPORT)にある場合は、ファイル名だけを指定します。 ファイルがこのディレクトリーの外部にある場合は、ファイルの絶対パスを指定する必要があります。
SametimeおよびQuickPlaceのクラッシュに関する追加情報
クラッシュがSametimeサーバーまたはQuickPlaceサーバーで発生した場合は、デフォルトで追加情報が収集され、メール受信データベースに送られる文書に添付されます。 具体的には、Sametimeでのクラッシュの場合は、stdiags_*ファイルがメール受信文書に追加されます。 QuickPlaceでのクラッシュの場合、Lotus Dominoは問題の診断に役立つqpconfig.xmlファイルとadmin.nsfファイルの添付を試みます。
Dominoドメインモニターにポストされたサーバーの再起動情報
Dominoドメインモニター(DDM)はLotus Domino 7の新機能で、ドメイン全体がどのように機能しているかを示す高レベルのビューをシステム管理者に提供します。 クラッシュ後にサーバーが再起動するとメッセージがDDMにポストされ、システム管理のコンソールでイベントを追跡できます。また、DDMによって、ドメイン全体にわたりこれらのイベントを追跡した履歴も得られます。
Lotus Notes/Domino 6.xでは、クライアントまたはサーバーでコンソール・ロギングが有効になっていないと、メール受信データベースにコンソール情報が収集されません。 しかし、特定のケースでは問題の原因を把握するためにこれらの情報が必要になるため、Lotus Notes/Domino 7では、情報を得るためにさまざまな工夫がされています。
ログが有効であるかどうかにかかわらず、サーバーがDominoコントローラー(Javaコントローラーとも呼ばれます)下で実行されている場合、ADCは最初にDominoコントローラーのログ(サーバー上)でコンソール情報を検索します。 サーバーがDominoコントローラー下で実行されている場合、ADCはそのログを使用します(サーバー設定でのサイズ制限に従います)。 このログはコンソールに出力された情報のスーパーセットであり、メッセージと各メッセージの重大度を示すコードを含んでいます。
ADCがクライアントで実行されている場合、またはサーバーがDominoコントローラー下で実行されていない場合、ADCはコンソール・ログが有効かどうかをチェックします。 有効な場合は、Lotus Domino 6.xのときと同様に、ADCはコンソール出力を使用します。
コンソール・ログが有効でない場合、ADCはlog.nsfに書き込まれた情報を使用します(これは、コンソール・ログに含まれる情報のサブセットです)。 情報を得る方法としては、log.nsfの[Miscellaneous Events]ビューでクラッシュの時刻までさかのぼってテキストを抽出し、疑似コンソール出力ファイルを作成します。 そして、コンソール・ログの場合と同様に、このファイルを文書に添付します。log.nsf全体を文書に添付しない理由は、ほとんどのケースで、設定されているサイズの制限値よりもlog.nsfが大きくなるためです。 また、log.nsfはバイナリー・ファイルなので、単純に切り捨てて最後の部分だけを送ることができないためです。
Lotus Domino 6.xには、サーバーが再起動するときにユーザーまたはグループに通知を送信する設定オプションがあります。 しかし、この通知には、サーバーがクラッシュした日時や現在は回復していることを示す基本的な情報しか含まれていません(図2参照)。
図2. Domino 6のサーバー再起動通知

Lotus Notes/Domino 7ではこの通知が拡張され、件名と本文により多くの情報が含められるようになりました。このため、通知リストによって、クラッシュに関する詳細な情報をより素早く得ることができます。 図3に示されるように、[件名]フィールドには、Dominoのバージョン、クラッシュしたプロセス、およびクラッシュの時刻が含まれています。 [本文]フィールドには、メール受信データベースに送信されたほとんどすべての情報が(添付ファイルを除く)、メール受信データベースへのデータベースリンクと共に含まれています(クラッシュしたサーバーと同じドメインにメール受信データベースがある場合)。
図3. Domino 7のサーバー再起動通知

[件名]行の拡張により、通知リストに登録されていてハンドヘルド・デバイスやページャーを使用しているユーザーも、メール受信データベースにアクセスせずに、必要な情報を得られます。 6.x形式を使いたい場合は、6.x形式でメッセージを送信させるすべてのサーバーのNotes.iniファイルで、Notes.iniパラメーター「ADC_USE_OLD_EMAIL_FORMAT=1」を設定します。
Notes.iniパラメーターFR_ATTACH_NSDは、Lotus Domino 7でも使用できます。FR_ATTACH_NSDは、サーバーの再起動時に送信される通知メッセージにNSD出力ファイルを添付するかどうかを指定します。 このパラメーターを 1に設定すると、NSD出力が通知メッセージに添付されます。1よりも大きな値を設定した場合、NSD出力のサイズが、設定値をキロバイト単位で示した値以下の場合にのみ、NSD出力が添付されます (たとえば、「FR_ATTACH_NSD=5」と設定すると、NSD出力のサイズが5KB以下のときにのみ添付されます)。 この設定は、NSD出力を通知メッセージに添付するかどうかだけに適用され、メール受信データベースに送信されるメッセージに何を添付するかについては影響しません。
ADCがメール受信データベースに送るメッセージに添付ファイルを追加するときの問題の1つとして、メッセージのサイズが大幅に増加する点が挙げられます。メッセージを転送するための十分なディスク・スペースがない場合や、社内でルーター・コントローラーを使用して環境内で送信されるメッセージのサイズを制限している場合は、サイズの増加が問題となります。
Lotus Notes/Domino 7では、メール受信データベースに送信されるメッセージの合計サイズを制限できるだけでなく、どれだけの量のNSD出力を[診断情報コレクションオプション]セクションに添付するのかを指定できます(これは、前のセクションで説明したINIパラメーターとは無関係です)。図4をご覧ください。
図4. [診断情報コレクションオプション]セクションの最大サイズ・フィールド

図4に示されるように、デフォルトでは、メッセージ・サイズの合計は5MBで、NSD出力は2MBです。これはファイルの先頭からの値で、最初の2MB分が使用されます。
ADCがメッセージを構築するとき、次の順序でファイルを添付します。
- NSD出力(設定されたサイズまで)
- コンソール出力(設定されたサイズまで)
- Diagindex.nbfファイル。このファイルには、サーバーの前回の再起動以降に生成されたすべての診断情報ファイルのリストが含まれています。
- それ以外のすべてのファイル。他のデフォルトのファイルや収集するよう設定したファイルなどが含まれます。
NSDファイルを切り捨てる必要がある場合、または制限を超えるためにファイルをメッセージに添付できない場合、これらのファイルはメール受信データベースに格納されるので、手動で取り出すことができます。サーバー・クラッシュの例を図5に示します。
図5. サーバー・クラッシュのADCメッセージの例

クライアント・クラッシュの場合は、どのデスクトップポリシー設定が有効になっているかを示す追加情報が得られます(図6参照)。
図6. クライアント・クラッシュのADCメッセージの例

ADCは、その多くの情報をNSD出力に依存しているので、クラッシュ時にNSDが実行されるよう設定されていないと、有効な情報がADCレポートにほとんど収集されません。特に、IBMサポートがお客様の問題を解決するために使用する情報は得られません。これをシステム管理者に警告するために、クラッシュ時にNSD出力が検出されない場合は、次の警告がメール受信データベースに表示されます。
WARNING: Crash information not extracted! Make sure NSD is configured to run on the
Server document.
Lotus Domino 7でのADCの最大の新機能はFault Analyzerです。Fault Analyzerは、メール受信データベース内のクラッシュ・レポートと、情報を送信するADCを比較できるDomino Serverの新しいアドイン・タスクです。
Fault Analyzerは多くのメール受信データベースを処理できますが(たとえば、クライアント・クラッシュとサーバー・クラッシュ用に異なるデータベースを使用している場合など)、現在処理中のデータベースでのみ一致を検索し、複数のデータベースにわたって一致を検索することはありません。
Fault Analyzerが新しいクラッシュについて一致を検出できない場合、そのクラッシュは親クラッシュとして指定されます(このクラッシュが初めて検出されたことを意味します)。Fault Analyzerが一致を検出すると、そのクラッシュは子クラッシュとして指定され、同じクラッシュの最初の出現例がその親となります。この親子関係については後述しますので、ここでは、2つのクラッシュが一致するかどうかを判断するプロセスについて説明しましょう。
2つのNotes/Dominoクラッシュが根本的に同じ問題から発生したのかどうかを判断することは、常に簡単であるとは限りません。Lotus Notes/Dominoは階層型アーキテクチャーであるため、エラー・メッセージだけに基づいて原因を識別することはできません。異なるコード・パスが同じエラー・メッセージを生成する可能性があるからです。
Fault Analyzerは、クラッシュしたスレッドに呼び出された関数のシーケンスを使用して、クラッシュの固有のシグニチャーを作成します。この関数呼び出しのシーケンスは、クラッシュへのパスを示します。
さまざまなNotes/DominoプラットフォームでのNSD出力ファイルを調べると、オペレーティング・システムによってコール・スタック情報を表示する方法が大きく異なることがわかります。ADCは、レポートをメール受信データベースに送信する前に、これらの違いを正規化します。この正規化には、関数を日時的に逆順でリストアップしたり、C++関数をデマングルする(<クラス>::<関数>という形式にする)処理が含まれます。
Fault Analyzerは、スタックの先頭から下方に順番に読み込むことによってその一致プロセスを開始し、2つのスタック間で一致しない関数名に遭遇するまで、読み込みを続けます。スタックの先頭はPanic関数によって決められます。Panic関数は、Windows 32プラットフォームではアクセス違反となったスタックの最初の関数で、UNIXではfatal_error後の最初の関数です。
Fault Analyzerはstack1内の各関数を順番に読み取り、stack2の同じ位置に一致する関数があるか調べます。このプロセスは、関数が一致しなくなるまで繰り返されます。一致しなくなった時点で、2つのスタック間の一致率(パーセント)が決められます。一致率は、2つのスタック間で共通する関数の数を、各スタックの関数の数の平均で割ることによって算出します。
たとえば、stack1に10個の関数、stack2に15個の関数があり、スタック間で最初の5個の関数が一致するとき、一致率は 5 / ((10+15) / 2) = 41パーセントとなります。
もし、2つのスタック間ですべての関数が共通する場合、一致率は100パーセントとなり、これは完全一致と呼ばれます。この場合、2つのクラッシュは同じ根本原因を持つと判断してもよいでしょう。しかし、2つのスタックが同じ根本原因を持っていても、コール・スタックが一致するとは限りません。これは、Lotus Dominoが、サブシステムを相互に積み上げて構築するレイヤー型モデルとして成り立っているためです。もし、データベース(NSF)にアクセスするレイヤーで問題が発生すると、多くの他のサブシステム(たとえば、ルーター、レプリケーターなど)が同じ根本的問題に遭遇しますが、その問題につながるコール・スタックの内容は、それぞれ異なるものになります。
2つのスタックが部分的に一致するかどうかを決めるために、2つのコール・スタックの平均スタック長に基づいてパーセントで分類する方法が用いられています。平均スタック長は、stack1とstack2の関数の数を加え、これを2で割って求めます。平均コール・スタック長に基づいて判断するときのカットオフ・パーセントを下表に示します。
| コール・スタック長 | カットオフ・パーセント |
|---|---|
| < 4 | 完全一致であること。スタックに存在する関数の数が少なすぎるため、一部の関数が同じであっても、部分一致と認めるのは危険です。 |
| 4 | 一致率が75パーセント以上であること。 |
| 5 〜 7 | 一致率が60パーセント以上であること。 |
| 8 以上 | 一致率が40パーセント以上であること。 |
平均スタック長が増加すると、部分一致と認めるためのパーセンテージが低下しています。これは、より長いスタックでは、スタックの最上位で共通する関数が多いほど、問題が同じであることの信頼性が高まるからです。
このアルゴリズムは、Fault Analyzerを実行するサーバー上のNotes.iniファイルでパラメーター「FAULT_ANALYZER_MATCH_PERCENTAGE」を設定することにより、手動で変更できます。パラメーターの設定範囲は1〜99です。この設定を用いると、平均スタック長にかかわらず、すべてに同じ一致率が適用されます。
Fault Analyzerは、デフォルトでオフになっています。メール受信データベースでFault Analyzerを機能させるには、そのデータベースがDomino 7サーバーでホストされている必要があります。また、Dominoディレクトリをリリース 7の設計にアップグレードしなければなりません。これによって、Fault Analyzerを設定するための新しいフィールドがサーバー文書の[診断情報]タブに追加されます(図7 参照)。
図7. サーバー設定文書のFault Analyzerに関するフィールド

デフォルトでは、Fault Analyzerを有効にすると、Fault Analyzerはサーバー上のすべてのメール受信データベースに対して有効になり、サーバーの開始時に起動されます(Notes.iniファイルのServerTasks行に追加する必要はありません)。Fault Analyzerは、メール受信データベースが定義されているサーバー設定文書またはデスクトップポリシー設定文書をローカルDominoディレクトリで検索し、サーバー上のどのデータベースがADCメール受信データベースであるのかを識別します。該当するデータベースがローカル・サーバーにあるときは、それをモニターします。該当するデータベースがローカル・サーバーで見つからない場合は、Fault Analyzerはシャットダウンします。
Fault Analyzerは、起動時にメール受信データベースで新規クラッシュをすべて処理し、次のクラッシュが発生するまでアイドル状態となります。クラッシュが発生するとFault Analyzerはすぐに実行を開始し、新しいクラッシュを処理します。
選択したデータベースに対してFault Analyzerを実行するよう設定することもできます(図8 参照)。サーバー上の一部のデータベースだけにFault Analyzerを実行したい場合、または複数の場所でFault Analyzerを実行する代わりに、すべてのメール受信データベースを1つのサーバーに複製し、その1箇所で処理する場合に、このオプションを選択します。
図8. 選択されたデータベースで実行するように設定されたFault Analyzer

また、コンソール・コマンド「load faultanalyzer」を発行することで、Fault Analyzerを手動で実行できます。引数を渡さないと、Fault Analyzerは前述の方法を用いて、現在のサーバー上ですべてのADCメール受信データベースを検索します。データベース、ディレクトリー、またはインダイレクト・ファイル(データベースのリストを含む *.IND)を示す引数を渡すことにより、Fault Analyzerが処理する対象を指定できます。Fault Analyzerを手動でロードした場合、Fault Analyzerはデータベース内の新規クラッシュを処理して終了します。次のクラッシュが発生するまでアイドル状態で待機することはありません。
メール受信データベースのスペースを節約するために、子クラッシュ(完全一致と部分一致の両方)から添付ファイルを削除するオプションを使用できますこれは、同じクラッシュであると判断された場合は診断情報を2つ保存する必要はないという考えに基づいています。メール受信データベースから削除するよう選択した場合でも、データはクライアントまたはサーバーに残っています。
メモ:Lotus Domino 6.xでADCを実行していて、Lotus Domino 7にアップグレードし、Fault Analyzerを有効にすると、Fault Analyzerの最初の実行時に、メール受信データベース内の現在のすべてのエントリーが処理されます。
Notes/Domino Fault Reportsデータベースの変更点
Notes/Domino Fault Reports (lndfr.ntf)テンプレートがDomino 7サーバー用にアップグレードされ、ADCメール受信データベース内にあるすべての新規情報が見られるようになりました。サーバーをリリース 7にアップグレードし、designタスクを実行すると、現在のメール受信データベースが新しい設計にアップグレードされます。
データベースの新しいアウトラインを図9に示します。[By Date]、[Clients]、[Servers]の各ビューに [Standard]ビューと[Fault Analyzed]ビューが追加されたので、現在の日付による分類に加えて、親子関係を表示できます。
図9. Domino 7 Fault Reportsデータベースのアウトライン

新しい[Fault Analyzed]ビューでは、子クラッシュは、それに対応する親クラッシュのもとへカテゴリー化されます。親クラッシュ文書を開くと、それに関連するすべての子クラッシュが、文書の一番上にある埋め込みビューに表示されます。文書をダブルクリックすることで、埋め込みビューから子クラッシュ文書を直接開くことができます。完全一致または部分一致の場合は親クラッシュまでの文書リンクが含まれているので、文書リンクを使って親クラッシュに移動できます。また、部分一致の場合は一致率も示されるので、2つのスタックがどれぐらい一致しているかを確認できます。
それぞれの親クラッシュの出現数は、現在のメール受信データベースでそのクラッシュが検出された回数の合計を示します。この数は、親クラッシュ文書の[Administrative]セクション(図10 参照)と、メール受信データベースのすべてのビューに表示されます。
図10. 親クラッシュ文書内の[Administrative]セクションの[Occurrences]フィールド

Fault Analyzerは、合計出現数に加え、特定のクラッシュによって影響を受けた固有のクライアントまたはサーバーの数も追跡しています。これは、問題の重みを決定するときに役立ちます。たとえば、20人の異なるユーザーが20回のクラッシュを経験した場合、同じユーザーが20回のクラッシュを経験した場合よりも、より重大であると判断されます。固有IDは、親クラッシュ文書の管理セクションに、問題を経験した回数の降順でリスト表示されます。また、この数はメール受信データベースのビューでも見ることができます。
クラッシュの根本原因を特定し、その修正を含むリリースにアップグレードするか、修正用のホット・フィックスを適用した後は、同じスタックによる以降のクラッシュを子クラッシュとして扱わず、別の親クラッシュとして扱いたいと考えます(クラッシュはすでに解決されているため)。
以降の一致するスタック・コールを新しい親として扱うには、既存の親クラッシュ文書の管理セクションでクラッシュを解決済みとしてマークします。解決されたクラッシュは、ビュー内でその横に緑色のチェックマークが表示されます。
クラッシュを解決済みとしてマークするとき、すべてのクライアント/サーバーに修正を適用済みとして指定するか、修正を含むNotes/Dominoバージョンおよびホット・フィックスのリストを入力できます(図11 参照)。Fault Analyzerは、あるリリースで問題が解決されているならば、それ以降のリリースでも問題は解決済みであるとみなします(これは、Notes/Dominoリリースとホット・フィックス、つまりコンボ・ホット・フィックスにも適用されます)。また、Fault Analyzerはリリース 6.x と 6.5xとの関係も考慮するため、6.0.4で修正済みの件は6.5.2でも修正済みとして扱います。
図11. 親クラッシュを修正済みとして編集する

この記事では、Lotus Notes/Domino 7で強化された保守機能について説明しました。これらの機能を使用すると、クライアント・クラッシュとサーバー・クラッシュをより効率よく扱うことができます。これを機に、Lotus Notes/Domino 7にアップグレードして、コード・ネームHannoverと呼ばれるIBM Lotus Notesの次期リリースを楽しみに待ちましょう。
学ぶために
- developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
- developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
- developerWorksのLotus記事『Lotus Dominoのハングとクラッシュのトラブルシューティング』
- developerWorksのLotus記事『Lotus Domino 7.0 の新機能』
- developerWorksのLotus記事『Lotus Notes と Domino Designer 7.0 の新機能』
製品や技術を入手するために
- developerWorksからLotus Domino 7 試用版 (US)をダウンロードする。
- developerWorksからLotus Notes 7 試用版 (US)をダウンロードする。
議論するために
- フォーラムにご参加ください。 (US)
- developerWorks ブログ (US)を通じてdeveloperWorksコミュニティーに参加できます。