MQGMO のオプション (MQLONG)

MQGET 要求が使用禁止になっている場合や、待機中に MQGET 要求が使用禁止になる場合は、待機が取り消されます。 キューに適切なメッセージがあるかどうかに関係なく、呼び出しはMQCC_FAILEDおよび理由コードMQRC_GET_INHIBITEDで完了します。

MQGMO_WAIT は、 MQGMO_BROWSE_FIRST オプションまたは MQGMO_BROWSE_NEXT オプションとともに使用できます。

同じ共有キューでいくつかのアプリケーションが待機している場合は、以下の規則に従い、適切なメッセージが到着したときに活動化されるアプリケーションが選択されます。

1. 特定のメッセージによってのみ満たすことができる特定の get-wait 要求。例えば、特定のMsgIdまたはCorrelId (あるいはその両方) を持つ要求。
2. どのメッセージによっても満たすことができる一般的な get-wait 要求。

z/OS®では、以下の点が適用されます。

• メッセージの到着を待機している間に、アプリケーションが他の作業を続行するようにしたい場合は、代わりにシグナル・オプション (MQGMO_SET_SIGNAL) を使用することを検討してください。 ただし、シグナル・オプションは環境固有のものなので、異なる環境との間で移植するアプリケーションではこれを使用してはなりません。
• 複数の MQGET 呼び出しが同じメッセージを待機している場合、待機オプションとシグナル・オプションが混在していても、各待機呼び出しは同等に扱われます。 MQGMO_WAITでMQGMO_SET_SIGNALを指定するとエラーになります。 また、未解決のシグナルがあるキュー・ハンドルと共にこのオプションを指定した場合も、エラーになります。
• MQIT_MSG_TOKENのIndexTypeを持つキューに対してMQGMO_WAITまたはMQGMO_SET_SIGNALを指定した場合、選択基準は許可されません。 つまり、以下のようになります。
  • version-1 MQGMOを使用している場合は、 MQGET 呼び出しで指定した MQMD の MsgId および CorrelId フィールドを MQMI_NONE および MQCI_NONEに設定します。
  • version-2 以降MQGMOを使用している場合は、MatchOptionsフィールドをMQMO_NONEに設定します。
• 共有キューに対する MQGET 呼び出しにおいて、この呼び出しがブラウズ要求またはグループ・メッセージの破壊読み取りである場合、MsgId または CorrelId を使用した突き合わせがいずれも行われなければ、200 ミリ秒後にユーザーのシグナル ECB で MQEC_MSG_ARRIVED が通知されます。

  適切なメッセージがキューに到着していない場合でもこれが行われ、やがて待機インターバルが満了すると MQEC_WAIT_INTERVAL_EXPIRED がキューに通知されます。 MQEC_MSG_ARRIVED が通知される場合、2 番目の MQGET 呼び出しを再発行することでメッセージを取得する必要があります (入手可能な場合)。

  この手法を使うと、タイムリーな方法でメッセージ到着が通知されるようになりますが、非共有キューに対する同様の呼び出しシーケンスと比べて、予期されない処理オーバーヘッドと見なすこともできます。

MQGMO_WAITは、MQGMO_BROWSE_MSG_UNDER_CURSORまたはMQGMO_MSG_UNDER_CURSORと一緒に指定しても無視されます。エラーは発生しません。

メッセージ記述子に指定されている基準を満たすメッセージがどれも現在使用可能でない場合は、メッセージの到着を待たずに制御がアプリケーションに戻されます。 CompCodeおよびReasonパラメーターは、MQCC_WARNINGおよびMQRC_SIGNAL_REQUEST_ACCEPTEDに設定されます。 その他のメッセージ記述子内の出力フィールド、および MQGET 呼び出しの出力パラメーターは、設定されません。 その後、適切なメッセージが到着すると、ECB を通知することによってシグナルが送達されます。

この後、呼び出し元は MQGET 呼び出しを再発行して、メッセージを取得する必要があります。 アプリケーションは、オペレーティング・システムが提供する関数を使用して、このシグナルを待機することができます。

オペレーティング・システムが複数待機のメカニズムを提供している場合、そのメカニズムを利用して複数のキューのいずれかにメッセージが到着するのを待機できます。

ゼロ以外のWaitIntervalが指定された場合、待機間隔が満了した後にシグナルが送信されます。 キュー・マネージャーは待機をキャンセルすることもでき、その場合、シグナルが送達されます。

複数の MQGET 呼び出しが同じメッセージ用のシグナルを設定する場合があります。 アプリケーションが活動化される順序は、MQGMO_WAITで説明されている順序と同じです。

複数の MQGET 呼び出しが同じメッセージを待機している場合、各待機呼び出しは同等に扱われます。 複数の呼び出しで、待機オプションとシグナル・オプションが混在していても構いません。

特定の条件下では、MQGET 呼び出しがメッセージを取得し、そのメッセージが到着した結果として生成されたシグナルが送達される場合があります。 シグナルが送達される場合、アプリケーションは、使用可能なメッセージがない状態に対する準備ができていなければなりません。

1 つのキュー・ハンドルに、複数の未解決のシグナル要求があってはなりません。

共有キューに対する MQGET 呼び出しにおいて、この呼び出しが browse 要求またはグループ・メッセージの破壊読み取りである場合、MsgId または CorrelId を使用した突き合わせがいずれも行われなければ、200 ミリ秒後にユーザーのシグナル ECB で MQEC_MSG_ARRIVED が通知されます。

これは、適切なメッセージがキューに到着していない場合でも、待機間隔が満了するまで、キューが MQEC_WAIT_INTERVAL_EXPIREDで通知されるまで発生します。 MQEC_MSG_ARRIVED が通知される場合、2 番目の MQGET 呼び出しを再発行することでメッセージを取得する必要があります (入手可能な場合)。

この手法を使うと、タイムリーな方法でメッセージ到着が通知されるようになりますが、非共有キューに対する同様の呼び出しシーケンスと比べて、予期されない処理オーバーヘッドと見なすこともできます。

メッセージの追加頻度が低い場合には、これは効率的なメッセージ取得方法ではありません。 ブラウズの場合のこのオーバーヘッドを回避するには、 MQGET 呼び出しで MsgId (索引が付いていないか、 MsgIdによって索引が付けられている場合) または CorrelId ( CorrelIdによって索引が付けられている場合) を指定します。

このオプションは、 z/OS でのみサポートされます。

z/OSでは、このオプションは、接続 ( CICS® または IMS アプリケーションの場合) が静止状態の場合にも、 MQGET 呼び出しを強制的に失敗させます。

このような違いがあるため、移植するアプリケーションでは、このオプションをデフォルトにすることはできません。MQGMO_SYNCPOINTまたはMQGMO_NO_SYNCPOINTを明示的に指定してください。

• メッセージが持続メッセージの場合、キュー・マネージャーは、アプリケーションがMQGMO_SYNCPOINTを指定したかのように呼び出しを処理します。
• メッセージが持続メッセージでない場合、キュー・マネージャーは、アプリケーションがMQGMO_NO_SYNCPOINTを指定したかのように呼び出しを処理します。

このオプションは、MQGMO_BROWSE_FIRSTまたはMQGMO_BROWSE_NEXTを指定した場合に想定されます。

このような違いがあるため、移植するアプリケーションでは、このオプションをデフォルトにすることはできません。MQGMO_SYNCPOINTまたはMQGMO_NO_SYNCPOINTのいずれかを明示的に指定してください。

MQGMO_BROWSE_FIRST を指定した MQGET 呼び出しは、ブラウズ・カーソルの直前の位置を無視します。 メッセージ記述子に指定された条件を満たすキュー上の最初のメッセージが検索されます。 メッセージはキューに残り、ブラウズ・カーソルはこのメッセージの上に置かれます。

この呼び出しの後、ブラウズ・カーソルは、戻されたメッセージ上に置かれます。 このメッセージは、 MQGMO_BROWSE_NEXT を指定した次の MQGET 呼び出しが発行される前に、キューから除去される可能性があります。 その場合は、そのキューの中で削除されたメッセージが入っていた位置に (現在そこが空であっても) ブラウズ・カーソルが残ります。

この MQGMO_MSG_UNDER_CURSOR オプションを非ブラウズの MQGET 呼び出しで使用すると、キューからメッセージを削除することになります。

ブラウズ・カーソルは、同じ Hobj ハンドルを使用する場合でも、非ブラウズ MQGET 呼び出しによって移動されません。 また、ブラウズの MQGET 呼び出しで完了コード MQCC_FAILED または理由コード MQRC_TRUNCATED_MSG_FAILED が戻された場合も移動されません。

ブラウズされるメッセージをロックするには、このオプションとともにMQGMO_LOCKオプションを指定します。

MQGMO_BROWSE_FIRSTは、MQGMO_*オプションとMQMO_*オプションの任意の有効な組み合わせで指定できます。これらのオプションは、グループ内のメッセージおよび論理メッセージのセグメントの処理を制御します。

MQGMO_LOGICAL_ORDERを指定すると、メッセージは論理順序でブラウズされます。 このオプションを省略すると、メッセージは物理順序でブラウズされます。 MQGMO_BROWSE_FIRSTを指定すると、論理順序と物理順序を切り替えることができます。 後続の MQGET 呼び出しで MQGMO_BROWSE_NEXT を使用すると、キュー・ハンドル用に MQGMO_BROWSE_FIRST を指定した最後の呼び出しと同じ順序でキューをブラウズします。

キュー・マネージャーは、MQGET 呼び出し用にグループおよびセグメント情報を 2 セット保持します。 ブラウズ呼び出し用のグループおよびセグメント情報は、キューからメッセージを削除する呼び出しの情報とは別個に保持されています。 MQGMO_BROWSE_FIRSTを指定すると、キュー・マネージャーはブラウズ用のグループおよびセグメント情報を無視します。 キュー・マネージャーは、現行のグループも現行の論理メッセージも存在していない場合と同じようにキューをスキャンします。 MQGET 呼び出しが成功すると、完了コード MQCC_OK または MQCC_WARNING が戻され、ブラウズ用のグループおよびセグメント情報は、戻されたメッセージの情報に設定されます。 呼び出しが失敗した場合、ブラウズ用のグループおよびセグメント情報は、呼び出しが行われる前の状態から変更されません。

ブラウズ・カーソルによって示されるメッセージは、MQGMO_BROWSE_FIRSTオプションまたはMQGMO_BROWSE_NEXTオプションのいずれかを使用して最後に取得されたメッセージです。

MQGMO_COMPLETE_MSGがMQGMO_MSG_UNDER_CURSORとともに指定されている場合、ブラウズ・カーソルは、MQMD 内のOffsetフィールドがゼロであるメッセージを識別する必要があります。 この条件が満たされない場合、呼び出しは失敗し、理由コードMQRC_INVALID_MSG_UNDER_CURSORが戻ります。

メッセージはキューから削除されません。

協働レベル・マークは、既に設定されている可能性のある任意のハンドル・レベル・マークに追加して付けられます。

メッセージはキューから削除されません。

メッセージが既にマークされており、オプションMQGMO_UNMARKED_BROWSE_MSGが指定されていない場合、呼び出しはMQCC_FAILEDおよび理由コードMQRC_MSG_MARKED_BROWSE_CO_OPで失敗します。

MQGMO_UNMARK_BROWSE_CO_OP の使用は、オプション MQOO_CO_OPを指定した MQOPEN の正常な呼び出しによって戻されるハンドルでのみ有効です。 MQGET は、協働ハンドル・セットからメッセージがマーク付けされているとみなされていなくても成功します。

呼び出しは、このハンドルに対してメッセージがマークされていなくても成功します。

• MQGMO_BROWSE_FIRST
• MQGMO_BROWSE_NEXT
• MQGMO_BROWSE_MSG_UNDER_CURSOR

ロックされたメッセージは常にブラウズ・カーソルの下にあります。 MQGMO_MSG_UNDER_CURSOR オプションを指定した後の MQGET 呼び出しによって、メッセージをキューから除去することができます。 キュー・ハンドルを使用する他の MQGET 呼び出し (例えば、ロックされたメッセージのメッセージ ID を指定した呼び出し) でも、メッセージを削除できます。

呼び出しが完了コードMQCC_FAILEDまたはMQCC_WARNINGと理由コードMQRC_TRUNCATED_MSG_FAILEDを戻した場合、メッセージはロックされません。

MQGMO_UNLOCKを指定した場合、MsgDesc、BufferLength、Buffer、およびDataLengthパラメーターは検査も変更もされません。 Bufferにメッセージは返されません。

MQGMO_UNLOCKを指定するために特別なオープン・オプションは必要ありません (ただし、最初にロック要求を発行するにはMQOO_BROWSEが必要です)。

• メッセージをブラウズすると、ブラウズ・カーソルが、戻されたメッセージに進みます。
• メッセージを削除すると、戻されたメッセージがキューから削除されます。
• 他にエラーが発生していなければ、理由コード MQRC_TRUNCATED_MSG_ACCEPTED が戻ります。

• メッセージをブラウズしても、ブラウズ・カーソルは進みません。
• メッセージを削除しても、メッセージはキューから削除されません。
• 他のエラーが発生しない場合は、理由コードMQRC_TRUNCATED_MSG_FAILEDが返されます。

キュー・マネージャーが変換を実行する形式名のリストについては、 MQMD-メッセージ記述子 で説明されている Format フィールドを参照してください。

セグメント化された論理メッセージは、同じ非ヌル・グループ ID (MQMD のGroupIdフィールド) を持つ複数の物理メッセージで構成されます。 これらは同じメッセージ・シーケンス番号 (MQMD のMsgSeqNumberフィールド) を持っています。 セグメントは、セグメント・オフセット (MQMD のOffsetフィールド) の値が異なることによって区別されます。 セグメント・オフセットは、論理メッセージ内のデータの先頭から始まる、物理メッセージ内のデータのオフセットです。 各セグメントは 1 つの物理メッセージなので、論理メッセージ内のセグメントには通常、それぞれ固有のメッセージ ID があります。

セグメント化されていない論理メッセージにも、送信側のアプリケーションでセグメント化が許可されている場合は、ヌル以外のグループ ID があります。 この場合、論理メッセージがメッセージ・グループに属していなければ、そのグループ ID を持つ物理メッセージは 1 つだけになります。 送信側アプリケーションによってセグメント化が禁止されている論理メッセージは、論理メッセージがメッセージ・グループに属していない限り、ヌルのグループ ID MQGI_NONEを持ちます。

同じキュー・ハンドルに対する連続した MQGET 呼び出しに対して MQGMO_LOGICAL_ORDER を指定すると、グループ内のメッセージは、メッセージ・シーケンス番号の順序で戻されます。 論理メッセージのセグメントはそのセグメント・オフセットで指定された順序で戻されます。 この順序は、これらのメッセージやセグメントのキューでの出現順序とは異なる場合があります。

必要な順序でメッセージを戻すように、キュー・マネージャーは、連続した MQGET 呼び出し間でグループおよびセグメント情報を保持します。 グループおよびセグメント情報により、キュー・ハンドルに対する現行のメッセージ・グループと現行の論理メッセージが特定されます。 また、グループおよび論理メッセージ内の現行の位置、およびメッセージが 1 つの作業単位内で取得されているかどうかも特定します。 キュー・マネージャーがこの情報を保持するので、アプリケーションでは、それぞれの MQGET 呼び出しの前にグループおよびセグメント情報を設定する必要はありません。 具体的には、アプリケーションが MQMD にGroupId、MsgSeqNumber、およびOffsetの各フィールドを設定する必要がないことを意味します。 ただし、アプリケーションは、各呼び出しでMQGMO_SYNCPOINTオプションまたはMQGMO_NO_SYNCPOINTオプションを正しく設定する必要があります。

キュー上に複数のメッセージ・グループが存在し、戻してよいものである場合、それらのグループが戻される順序は、各グループ内の最初の論理メッセージの最初のセグメントがキュー上のどの位置にあるかによって決定されます。 つまり、メッセージ順序番号が 1、オフセットが 0 の物理メッセージにより、該当するグループが戻される順序が決定されます。

MQGMO_LOGICAL_ORDER を指定する場合、 MQGET 呼び出しで提供される MQGMO は MQGMO_VERSION_2以上でなければならず、 MQMD は MQMD_VERSION_2以上でなければなりません。 この条件が満たされない場合、呼び出しは失敗し、該当する理由コードMQRC_WRONG_GMO_VERSIONまたはMQRC_WRONG_MD_VERSIONが戻ります。

キュー・ハンドルに対する連続した MQGET 呼び出しに対して MQGMO_LOGICAL_ORDER が指定されていない場合は、メッセージがメッセージ・グループに属しているかどうか、またはメッセージが論理メッセージのセグメントであるかどうかに関係なく、メッセージが返されます。 これにより、あるグループ内のメッセージや論理メッセージのセグメントが正しくない順序で戻されたり、他のグループ内のメッセージ、他の論理メッセージのセグメント、またはグループにも属さずセグメントでもないメッセージとが混在したりする場合があります。 この場合、連続する MQGET 呼び出しによって戻される特定のメッセージは、それらの呼び出しで指定される MQMO_* オプションによって制御されます (これらのオプションの詳細については、 MQGMO-メッセージ取得オプション で説明されている MatchOptions フィールドを参照してください)。

この手法を用いると、システム障害が発生した後に、メッセージ・グループまたは論理メッセージを途中から再開することができます。 システムの再始動時に、アプリケーションは GroupId、 MsgSeqNumber、 Offset、および MatchOptions フィールドを適切な値に設定し、 MQGMO_LOGICAL_ORDERを指定せずに MQGMO_SYNCPOINT または MQGMO_NO_SYNCPOINT を設定して MQGET 呼び出しを発行することができます。 この呼び出しが成功した場合、キュー・マネージャーはグループおよびセグメント情報を保持し、キュー・ハンドルを使用する後続の MQGET 呼び出しで通常どおり MQGMO_LOGICAL_ORDER を指定できます。

メッセージおよびセグメントを論理順序でリトリーブしたいアプリケーションは、MQGMO_LOGICAL_ORDERを指定することをお勧めします。これは、使用する最も簡単なオプションであるためです。 このオプションを指定すると、キュー・マネージャーがグループおよびセグメント情報を管理するので、アプリケーションでこの情報を管理する必要はなくなります。 ただし、特殊アプリケーションは、MQGMO_LOGICAL_ORDERオプションによって提供される制御よりも多くの制御を必要とする場合があります。これは、そのオプションを指定しないことによって行うことができます。 その後、アプリケーションは、各 MQGET 呼び出しの前に、 MQMDの MsgId、 CorrelId、 GroupId、 MsgSeqNumber、および Offset フィールド、および MQGMOの MatchOptions の MQMO_* オプションが正しく設定されていることを確認する必要があります。

例えば、受信する物理メッセージがグループ内にあるか、論理メッセージのセグメント内にあるかに関係なく、それらのメッセージを転送するアプリケーションでは、MQGMO_LOGICAL_ORDERを指定してはなりません。 送信側のキュー・マネージャーと受信側のキュー・マネージャーの間にパスが複数あるような複雑なネットワークの場合には、物理メッセージが正しくない順序で到達することがあります。 MQGMO_LOGICAL_ORDERも、MQPUT 呼び出しで対応するMQPMO_LOGICAL_ORDERも指定しないことによって、転送アプリケーションは、論理順序で次の物理メッセージが到着するのを待たずに、到着するとすぐに各物理メッセージを検索して転送することができます。

このオプションを使用するには、アプリケーションが完全なメッセージを収容するのに十分な大きさのバッファーを提供するか、MQGMO_ACCEPT_TRUNCATED_MSGオプションを指定する必要があります。

キューにセグメント化されたメッセージがあり、いくつかのセグメントが欠落している場合 (ネットワーク内で遅延し、まだ到着していないことが原因である可能性があります)、MQGMO_COMPLETE_MSGを指定すると、不完全な論理メッセージに属するセグメントを取得できなくなります。 ただし、これらのメッセージ・セグメントは引き続きCurrentQDepthキュー属性の値に寄与します。これは、CurrentQDepthがゼロより大きい場合でも、検索可能な論理メッセージが存在しない可能性があることを意味します。

非持続メッセージの場合、キュー・マネージャーが再組み立てを実行するのに、作業単位が使用可能になっている必要はありません。

1 つのセグメントであるそれぞれの物理メッセージには、固有のメッセージ記述子があります。 単一の論理メッセージを構成するセグメントの場合、メッセージ記述子内のほとんどのフィールドは、論理メッセージ内のすべてのセグメントで同じです。通常、論理メッセージ内のセグメント間で異なるのは、MsgId、Offset、およびMsgFlagsフィールドのみです。 ただし、セグメントが中間キュー・マネージャーの送達不能キューに置かれている場合、DLQ ハンドラーはMQGMO_CONVERTオプションを指定してメッセージを取得します。これにより、セグメントの文字セットまたはエンコードが変更される可能性があります。 それで、この途中で DLQ ハンドラーがセグメントの送信に成功した場合、そのセグメントが宛先キュー・マネージャーに到着した時点で、そのセグメントの文字セットまたはエンコードは論理メッセージ内の他のセグメントと異なっていることがあります。

CodedCharSetIdフィールドとEncodingフィールドが異なるセグメントで構成される論理メッセージを、キュー・マネージャーが単一の論理メッセージに再組み立てすることはできません。 その代わりに、キュー・マネージャーは、論理メッセージの先頭にあり、同じ文字セット ID とエンコードを持つ連続したセグメントをいくつか再組み立てして戻します。このとき、MQGET 呼び出しは完了し、完了コード MQCC_WARNING と、理由コード MQRC_INCONSISTENT_CCSIDS または MQRC_INCONSISTENT_ENCODINGS の該当する方が戻ります。 これは、MQGMO_CONVERTが指定されているかどうかに関係なく発生します。 残りのセグメントをリトリーブするには、アプリケーションは MQGMO_COMPLETE_MSG オプションを指定せずに MQGET 呼び出しを再発行し、セグメントを 1 つずつリトリーブする必要があります。 MQGMO_LOGICAL_ORDERを使用して、残りのセグメントを順番に取り出すことができます。

セグメントの書き込みを行うアプリケーションでは、メッセージ記述子内の他のフィールドに、セグメント間で異なる値を設定できます。 ただし、受信側アプリケーションがMQGMO_COMPLETE_MSGを使用して論理メッセージを検索する場合は、これを行う利点はありません。 キュー・マネージャーは、論理メッセージの再組み立て時に、最初のセグメントのメッセージ記述子からの値をメッセージ記述子に戻します。唯一の例外はMsgFlagsフィールドで、再組み立てされたメッセージが唯一のセグメントであることを示すためにキュー・マネージャーが設定します。

レポート・メッセージにMQGMO_COMPLETE_MSGが指定されている場合、キュー・マネージャーは特殊な処理を実行します。 キュー・マネージャーは、キューをチェックして、論理メッセージ内のさまざまなセグメントに関連するそのレポート・タイプのすべてのレポート・メッセージがキュー上に存在しているかどうかを確認します。 正しい場合は、MQGMO_COMPLETE_MSGを指定することにより、単一メッセージとして取り出すことができます。 これを可能にするには、セグメント化をサポートするキュー・マネージャーまたは MCA によってレポート・メッセージを生成するか、発信元アプリケーションが少なくとも 100 バイトのメッセージ・データを要求する必要があります (つまり、適切なMQRO_*_WITH_DATAまたはMQRO_*_WITH_FULL_DATAオプションを指定する必要があります)。 1 つのセグメントに入るアプリケーション・データの一部に欠落があると、戻されるレポート・メッセージでは、足りないバイト分はヌルで置き換えられます。

MQGMO_COMPLETE_MSGがMQGMO_MSG_UNDER_CURSORまたはMQGMO_BROWSE_MSG_UNDER_CURSORとともに指定されている場合、MQMD 内のOffsetフィールドの値が 0 であるメッセージにブラウズ・カーソルを配置する必要があります。 この条件が満たされない場合、呼び出しは失敗し、理由コードMQRC_INVALID_MSG_UNDER_CURSORが戻ります。

MQGMO_COMPLETE_MSGはMQGMO_ALL_SEGMENTS_AVAILABLEを暗黙指定するため、指定する必要はありません。

MQGMO_ALL_MSGS_AVAILABLE を指定した MQGET 呼び出しが正常終了したということは、 MQGET 呼び出しが発行された時点で、グループ内のすべてのメッセージがキューにあったことを意味します。 しかし、それでも他のアプリケーションが、グループからメッセージを削除できることに注意してください (グループは、グループ内の最初のメッセージを取得するアプリケーションに対してロックされていません)。

このオプションを省略すると、不完全なグループに属しているメッセージが取得されることがあります。

MQGMO_ALL_MSGS_AVAILABLEはMQGMO_ALL_SEGMENTS_AVAILABLEを暗黙指定するため、指定する必要はありません。

このオプションを指定しないと、論理メッセージが不完全な場合でも、メッセージ・セグメントが取得されることがあります。

MQGMO_COMPLETE_MSGとMQGMO_ALL_SEGMENTS_AVAILABLEの両方とも、いずれかのセグメントを取得する前にすべてのセグメントが使用可能になっている必要がありますが、前者は完全なメッセージを返し、後者はセグメントを 1 つずつ取得することを許可します。

レポート・メッセージにMQGMO_ALL_SEGMENTS_AVAILABLEが指定されている場合、キュー・マネージャーはキューを検査して、完全な論理メッセージを構成するセグメントごとに少なくとも 1 つのレポート・メッセージがあるかどうかを確認します。 存在する場合は、MQGMO_ALL_SEGMENTS_AVAILABLE条件が満たされます。 しかし、キュー・マネージャーは、キューに入っているレポート・メッセージのタイプ はチェックしないので、論理メッセージのセグメントに対応したレポート・メッセージにはさまざまなタイプのレポートが混在している可能性があります。 結果として、MQGMO_ALL_SEGMENTS_AVAILABLEが成功しても、MQGMO_COMPLETE_MSGが成功することを意味するわけではありません。 ある論理メッセージのセグメントについてさまざまなレポート・タイプが混在している場合には、これらのレポート・メッセージは 1 つずつ取得する必要があります。

メッセージ記述子 (または拡張) に含まれるプロパティーを除き、メッセージのプロパティーは、PropertyControlキュー属性の定義に従って表す必要があります。 MsgHandleが指定されている場合、PropertyControlキュー属性の値がMQPROP_FORCE_MQRFH2でない限り、このオプションは無視され、メッセージのプロパティーはMsgHandleを介して使用可能になります。

これは、プロパティー・オプションが指定されていないときのデフォルト・アクションです。

メッセージのプロパティーは、MsgHandleを介して使用可能にする必要があります。 メッセージ・ハンドルが提供されない場合、呼び出しは理由MQRC_HMSG_ERRORで失敗します。

メッセージ記述子 (または拡張) に含まれるものを除き、メッセージのプロパティーは取得されません。 MsgHandleが指定されている場合は、無視されます。

メッセージ記述子 (または拡張) に含まれるプロパティーを除き、メッセージのプロパティーはMQRFH2ヘッダーを使用して表す必要があります。 これにより、プロパティーを取得することが予期されるものの、メッセージ・ハンドルを使用するように変更できない、アプリケーションの以前のバージョンとの互換性が提供されます。 MsgHandleが指定されている場合は無視されます。