CICS 如何確保事件發出

您可以利用具有同步發出模式的 EP 配接器和適當的交易模式,來確保事件發出。利用同步發出,事件格式化及發出處理會在擷取交易的工作單元內同步完成。 只有在事件發出後,工作單元才會順利完成。 從應用程式作業鏈結 EP 配接器;亦即,事件不會排入佇列,以供 EP 分派器執行緒或個別的 EP 配接器作業進行非同步處理。

系統擷取點不支援同步事件發出,因此無法確保系統事件的發出。

同步事件可以是交易式或非交易式,但每一種情況都必須正確設定傳輸的可回復性。

同步非交易式事件:
EP 配接器必須以無法復原的方式,將事件發出至其傳輸中,以便如果工作單元失敗,不會取消事件。
同步交易式事件:
EP 配接器必須以可復原的方式,將事件發出至其傳輸中,以便如果取消工作單元,也會取消交易式事件。

並非所有 EP 配接器都可以與所有的 TRANSMODE 組合支援同步發出。如需相關資訊,請參閱事件處理配接器

當事件無法發出時,EP 配接器會提供事件及為什麼未發出事件的相關資訊,也會增加相關事件統計資料,進而導致擷取交易的工作單元遭到取消。

規劃考量

瞭解同步事件發出的運作方式,可以協助您瞭解如何善用此功能。當您使用同步事件發出時,需要考量的一些事項包括:安全、效能、傳輸,以及對應用程式的影響。

事件擷取交易必須對事件發出傳輸(例如,WebSphere® MQ EP 配接器的 WebSphere MQ 佇列)具有寫入權限,才能進行同步發出;發出事件的 EP 分派器或配接器作業需要寫入權限,才能進行非同步發出。

同步的交易式事件是可回復的。 當您使用 CICS WebSphere MQ EP 配接器時,事件會放在 WebSphere MQ 事件佇列的同步點下; 因此,您可能必須檢閱 WebSphere MQ 日誌資料集空間配置。當您使用 CICS TSQ EP 配接器時,這個配接器會增加使用可回復 TS 佇列的次數,所以您可能必須檢閱 CICS 日誌串流大小及屬性。搭配長時間執行的作業來使用同步交易式事件時,如果未採用同步點,可能會導致日誌溢位。

使用同步發出時,自訂 EP 配接器必須在 DFHEP.ADAPTPARM 儲存器中允許使用 EPAP_RECOVER 旗標。如需相關資訊,請參閱自訂 EP 配接器

確保事件發出可提供機會來建置商業重要事件型應用程式,並以可靠的方式來延伸現有的應用程式。犧牲的代價為確保發出事件所需的同步處理可能對應用程式回應時間有所影響。 審慎使用同步事件發出可將對應用程式的影響降至最低。請參閱事件處理效能,以取得在確保事件發出時,關於效能考量的相關資訊。

單一工作單元可能導致許多事件發出,其中部分事件是交易式,而部分事件是非交易式。如果擷取交易無法發出同步事件,則會取消工作單元以及其擷取的任何交易式事件。不過,仍然可能會發出非交易式事件。

EP 配接器、其資源(例如 WebSphere MQ 佇列)以及事件消費者必須配置有足夠的容量,才能處理預期發出事件的尖峰數量,以免擷取交易失敗。

為了協助您決定在何處使用同步發出,以下是比較同步和非同步發出的一些考量:

當您使用非同步事件發出時,請考量下列性質:
  • 從 CICS® 程式發出事件的順序,可以與擷取事件的順序不同。
  • 發出事件的順序,可以與對另一個事件啟用的 CICS 程式所執行的順序不同。
  • 不會確保事件發出。如果 CICS 異常結束時,有事件在進行中,事件可能會遺失。雖然 CICS 系統不太可能在擷取事件之後失敗,但是在發出之前,事件可能根本未發出(不管事件連結中的 EP 配接器是否指定事件為交易式)。
  • 格式化並發出事件的成本,會移轉到事件處理執行緒或個別的交易。
  • 對擷取交易的影響很小。
  • 不需要變更應用程式碼。
當您使用同步事件發出時,請考量下列性質:
  • 事件會以其擷取的順序,從 CICS 程式發出。
  • 當擷取交易順利完成時,會確保事件發出。
  • 可以將事件視為針對商業重要資料的應用程式延伸。
  • 當同步發出搭配 WebSphere MQ EP 配接器使用時,可以確保事件遞送。
  • 格式化並發出事件的成本,會加到應用程式執行緒。
  • 對擷取交易的影響較大;如果在應用程式執行緒發出事件,事件發出失敗會造成取消應用程式。請考量擷取交易配置,以及對整體系統資源使用的影響。