前言

繼前期《HP NonStop系統之Pathway Shutdown模式研究(上)》中介紹過Pathway Shutdown的各種方式，接下來筆者將針對各種shutdown模式作業系統實際運作過程作說明，讓讀者能了解系統實際運作方式，避免因遇到系統處理限制，造成shutdown失敗，或引發其他問題。

Messenger Process Senduse說明

隨著客戶Pathway環境日趨龐大，shutdown時會有大量close/death訊息在系統間傳遞，此狀況可能會達到系統資源 - Messenger process的極限，以下先說明Messenger process功能以及使用達到極限後可能引發之問題。

所有process都有一個outstanding message的限制，此限制為1024；而每個CPU上的Messenger process (pin 2)，限制為4095，此稱為Senduse limit。在H版本和J版本作業系統，Senduse limit已放大為16383，但是仍建議以4095為限制。Messenger process會處理death message和close message，若一CPU上有一process停掉，death message會經由該CPU上的Messenger process負責傳遞；若一process呼叫close procedure或停止，其close訊息也是經由該process所在CPU上的Messenger process負責傳遞，每個close和death訊息會在Messenger process的Senduse佔一個slot(總共有4095個slot，也就是Senduse limit)，若要接收此close或death message的process沒有去讀取他自己的$RECEIVE，則Messenger process不會釋放該slot，最終Messenger process可能會到達Senduse limit；若要接收此close或death message的process已經停止了，則該process所在CPU的Monitor process (pin 0)會處理，會告知Messenger process將傳遞給此process的close或death message丟掉(discard)，釋放該slot。

當發生Senduse limit狀況，新產生的close或death message將會被Messenger process丟掉，也就是當某CPU的Messenger process達到Senduse limit時，若有close或death message要交給該Messenger process，這時Messenger process不會處理該message，且不會回應對方；更進一步說明send端不需要等待Messenger process給他ack，但是receive process需要等Messenger process送close/death message到其$RECEIVE，他去$RECEIVE讀取此close/death message後會通知Messenger process，這時Messenger process會release此close/death message佔用的Senduse slot。若Messenger process尚未將此close/death message送給receive process，receive process就停掉，當這個訊息送到該CPU時，找不到receive process，這時Messenger process會直接release此訊息佔用的Senduse slot。

當達到Senduse limit時可能會引發後續一些問題，尤其是Pathway環境，如果Pathway server沒有取得所有的close message，他不會把自己停掉，如果Pathmon沒有取得他底下process的death message，他會認為這些process仍在執行；若TACL沒有收到process的death message，他並不會知道要wake up，而是hang在那邊；例如：使用FUP interactive模式，當下exit後，FUP process會結束，並送death message給TACL，若TACL沒收到此death message，他並不知道要wake up，會一直hang住，直到user按break鍵。

在G06.23版本作業系統之前，並沒有任何警告訊息顯示系統有此問題發生，且Messenger process不會送出錯誤訊息。直到SPR T9050API版本開始，有一個warning message - GUARDLIB Message 110，當Messenger process有3000 outstanding message也就是Senduse slot被佔用3000個(73% of the max)，他會刷出警示訊息，此訊息會列出佔用Messenger Senduse slot最多的前10個process，會顯示這些process的System number、CPU、PIN和他佔用多少個slot(或是稱為Senduse share)。 此訊息每5分鐘會刷一次，直到Senduse使用低於73%，或是達到Senduse limit，無法再處理新的close和death message時也會刷出訊息。

Messenger (pin 2)除了負責處理close/death message外，也負責與message傳遞相關的工作，當一個process需要將一個message傳遞給其他process，這個訊息實際上是經由Messenger傳遞；它負責link的動作，並盡一切努力將此message傳給接收者(listener)，而發送端(linker)這時可以去繼續做他的工作。Messenger同時也負責將interrupt handlers產生的status message發送給要求此message的process，例如:CPU up/down、Disk up/down、網路狀態改變、SETTIME、power on，Messenger也負責將IOP的訊息傳送給$ZLOG process。

此處舉實際範例說明Message process處理close message的流程：

1.CPU 2的process A要發close message給在CPU 8的process B，process A會呼叫FILE_CLOSE_，close message會先經由CPU 2的Messenger process，而它會透過message system與CPU 8的Messenger溝通，再將此close message放進process B的 $RECEIVE。而在同一時間，process A會將其對process B的open從它的FCB拿掉，process A不需要接收process B或Messenger的reply。

2.若process B還沒去讀取它 $RECEIVE的close message就被停掉，則Messenger process會自動將此close message丟掉；同樣的若process B尚未收到Messenger送來的close message前就被stop，則Messenger process會自動將此close message丟掉。

使用MODE ORDERLY停止Pathway

當執行"SHUTDONW2, MODE OR"時，Pathmon會依序停止該Pathway所控管的TERM、TCP、SERVER，且會通知TCP，請其close對該Pathway server process的open。

◎當TCP(包含local、external TCP)收到Pathway要shutdown訊息後，便不會再傳送新的request給server，但是未完成的還是會繼續做完。

◎等到所有request都完成後，Pathmon就會stop其控管的TERM。

◎TERM都被stop後，Pathmon會依序開始停local TCP，順序是由Pathmon決定，停local TCP時是一個接著一個，不是全部一起停；此時TCP會先呼叫FILE_CLOSE_將server的open給close，每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_，如果TCP有open 1000個server process，他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉，所有open都close後，TCP就會stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply，所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_，是連續呼叫FILE_CLOSE_ 執行的。

舉例說明：若TCP A在CPU 2，所open的server B在CPU 8，這時候A會呼叫FILE_CLOSE_去close這個open，此時會有一close message經由CPU 2的Messenger process(Pin 2)與CPU 8的Messenger process(Pin 2)，再傳送給位於CPU 8的B，而此close message會佔用CPU 2的Messenger process的Senduse的一個slot，當B去其$RECEIVE讀取此close message後，Messenger process便會釋放佔用的Senduse slot。當TCP A所有的open都close後，也就是當A針對所有的open都呼叫完成FILE_CLOSE_，不會管B有沒有收到此close message，就會被停掉，而此時TCP A的death message經由CPU 2的Messenger process與Pathmon所在CPU的Messenger process，再傳送給Pathmon，同樣的此death message也會佔用CPU 2 Messenger process的Senduse的一個slot，當Pathmon去讀取其$RECEIVE的death message後，Messenger process便會釋放佔用的Senduse slot。

◎external TCP的行為如下：external TCP會呼叫FILE_CLOSE_ 將server的open給close，每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_，如果external TCP有open 1000個server process，他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉，所有open都close後，針對此shutdown動作便告完成，external TCP不會被stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply，所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_，是連續呼叫FILE_CLOSE_ 執行的。

舉例說明：若external TCP C在CPU 2，所open的server B在CPU 8，這時候C會呼叫FILE_CLOSE_ close這個open，此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2)，再傳送給位於CPU 8的B，而此close message會佔用CPU 2的Messenger process的Senduse的一個slot，'B'去其$RECEIVE讀取此close message後，Messenger process便會釋放佔用的Senduse slot。

與local TCP依序停止不同的是，若有100個external TCP，則此100個external TCP會同時執行上述動作。

◎Server process會等待所有的open(包含local、external TCP、LINKMON的open)都被close後，便會stop，而此時Server的death message經由該server process所在CPU的Messenger process與Pathmon所在CPU的Messenger process，再傳送給其Pathmon，同樣的此death message也會佔用該CPU的Messenger process的Senduse的一個slot，Pathmon去其$RECEIVE讀取此death message後，Messenger process便會釋放佔用的Senduse slot。

◎當Pathway下的TERM、TCP、server都停止後，Pathmon便會把自己停掉，完成shutdown作業。

◎此方式shutdown Pathway時，因為是依序停止TERM、TCP、SERVER，所以並不會造成該Pathway環境所在CPUs非常busy，尤其是Pathmon process所在CPU。當然，Primary Pathmon process所在CPU仍有可能會因為沒有其他request，造成Pathmon搶走CPU time而100% Busy，但這屬正常行為，不會影響整個shutdown進行。

◎因為委託TCPs會同時去close所open的server process，但是因為server process所在CPU不會像MODE IM那麼busy，有較多的資源可以去讀取close message，釋放委託TCP所在CPU的Messenger process的Senduse slot，所以不易達到Senduse limit。

使用MODE ABORT停止Pathway

執行"SHUTDONW2, MODE AB"時，Pathmon會依序停止該Pathway所控管的TERM、TCP、SERVER，且會通知TCP，請其close對該Pathway server process的open。

此方式與MODE ORDERLY大致相同，唯一差異是當local TCP收到Pathway要shutdown訊息後，就會直接stop其控管的TERM，其於與MODE ORDERLY相同，此處不再重複。

使用MODE IM停止Pathway

當執行"SHUTDONW2, MODE IM"時，Pathmon會呼叫PROCESS_STOP_停止他所管理的TCP再停止server，且會通知external TCP，請external TCP close對該Pathway server process的open。

◎Pathmon直接呼叫PROCESS_STOP_停止所有的local TCP，而PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_ procedure去停止該TCP所有的open，實際上FS_FILE_CLOSEALL_會針對每個open呼叫FILE_CLOSE_去停止該open。如果TCP有open 1000個server processes，FS_FILE_CLOSEALL就會連續呼叫1000次FILE_CLOSE_將這1000個open給close掉。

跟MODE OR不同的，TCP並不會處理這些close動作，是由file system負責處理，因為Pathmon呼叫PROCESS_STOP_ procedure去停止local TCP，這時PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_，而FS_FILE_CLOSEALL_ 再針對每一個open呼叫FILE_CLOSE_，差別在於MODE OR是TCP主動呼叫，MODE IM則不是由TCP處理，由PROCESS_STOP_處理；感覺像是MODE OR是TCP負責打掃環境完成後離開，MODE IM則是PROCESS_STOP_幫TCP打掃環境，TCP可以先走，也就是TCP可能在close動作尚未完成前就被stop。

舉例說明：若TCP A在CPU 2，所open的server B在CPU 8，這時候Pathmon會呼叫PROCESS_STOP_ procedure去停止A，這時候PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_ close A所有的open，針對每個open，FS_FILE_CLOSEALL_都會呼叫一個FILE_CLOSE_去停止該open，此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2)，再傳送給位於CPU 8的B，而此close message會佔用CPU 2的Messenger process的Senduse的一個slot，B去其$RECEIVE讀取此close message後，Messenger process便會釋放佔用的Senduse slot。若A有open 1000個server process，FS_FILE_CLOSEALL_就會連續呼叫1000次FILE_CLOSE_去停止這1000個open。

因為A的close動作是由file system所處理，所以他可能會在close動作處理完成前就被stop。同樣的，當A被停掉時，會有一death message經由CPU 2的Messenger process與Pathmon所在CPU的Messenger process，再傳送給其Pathmon，同樣的此death message也會佔用CPU 2的Messenger process的Senduse的一個slot，Pathmon去其$RECEIVE讀取此death message後，Messenger process便會釋放佔用的Senduse slot。

◎因為Pathmon是直接停TCP，所以，所有的TERM都會直接ABORT，所有當時的transaction狀態都不確定。

◎當所有local TCP都被停止後，Pathmon會呼叫PRCOESS_STOP_ procedure去停止所有的server，此時，與MODE OR不同的，即使external TCP仍然open該server，該server還是會被停掉。此時會有一death message經由該server process所在CPU的Messenger process與Pathmon所在CPU的Messenger process，再傳送給其Pathmon，同樣的此death message也會佔用該CPU的Messenger process的Senduse的一個slot，Pathmon去其$RECEIVE讀取此death message後，Messenger process便會釋放佔用的Senduse slot。

◎而external TCP的行為如下：external TCP會呼叫FILE_CLOSE_ 將server的open給close，每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_，如果external TCP有open 1000個server process，他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉，所有open都close後，針對此shutdown動作便告完成，external TCP不會被stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply，所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_，是連續呼叫FILE_CLOSE_ 執行的。

舉例說明：若external TCP C在CPU 2，所open的server B在CPU 8，這時候C會呼叫FILE_CLOSE_ close這個open，此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2)，再傳送給位於CPU 8的B，而此close message會佔用CPU 2的Messenger process的Senduse的一個slot，B去其$RECEIVE讀取此close message後，Messenger process便會釋放佔用的Senduse slot。若此時B已經被停掉了，這時候CPU 8的Monitor process(Pin 0)會負責告知CPU 2的Messenger process，此server已經停掉了，Messenger process便會釋放佔用的Senduse slot。若有100個external TCP，則此100個external TCP會同時執行上述動作。

◎此方式shutdown Pathmon時，因為是Pathmon直接呼叫PROCESS_STOP_去停止TCP、SERVER，所以會造成Pathway環境所在CPU非常busy，尤其是Pathmon process所在CPUs非常busy，因為這時候要處理很多close和stop作業。

◎因為Pathmon直接呼叫PROCESS_STOP_ 停止server process，所以server process不會理會是否有TCP仍然open他，就會被stop，在這種情況下，可能會發生沒有足夠資源去回應TCP的close message的問題，很容易造成TCP所在CPU的Messenger process的Senduse slot被佔滿，很容易達到Senduse limt。

結語

本文主要是透過File system和Message system的實際運作來說明Pathway shutdown過程中，系統如何停止整個Pathway環境，以及會使用哪些系統資源以及Pathway各object間彼此關聯，有哪些訊息會在系統內傳遞，希望藉由這些經驗的分享，讓系統管理人員、Pathway維護人員與應用程式開發人員更清楚了解Pathway shutdown時系統核心的運作。

資料來源

一、原廠使用手冊：

Pathway/iTS SCREEN COBOL Reference Manual
Pathway/iTS System Management Manual
TS/MP System Management Manual
NonStop S-series Server Description Manual
Pathway System Management
NonStop Kernel Principle
NonStop Kernel Architecture

二、HP Knowledge Database：

GUARDLIB Message 110
Halt %004106 in Messenger MAUX^LINK^SUBPROC
Question about Pathway shutdown behaviour
Question about Messenger process