主機(jī)系統(tǒng)CICS健康檢查手冊(cè).docx

主機(jī)系統(tǒng)CICS和CPSM健康檢查手冊(cè) 目 錄第 1 章CICS和CPSM檢查方法概述31.1檢查內(nèi)容31.2數(shù)據(jù)收集3第 2 章CICS和CPSM系統(tǒng)配置檢查42.1系統(tǒng)配置檢查內(nèi)容42.2CICS和CPSM配置描述42.3CICS與其他子系統(tǒng)連接描述42.4數(shù)據(jù)案例5第 3 章CICS和CPSM運(yùn)行性能檢查73.1CICS運(yùn)行性能檢查概述73.2交易完成速率和響應(yīng)時(shí)間73.3交易量執(zhí)行情況83.4達(dá)到MXT和TCLASS情況103.5DSA/EDSA使用情況123.6TDQ和TSQ使用情況133.7CICS CONNECTION使用情況153.8DB2 Attachment153.9DBCTL Attachment173.10TCB POOL使用情況193.11VSAM文件檢查193.12LOGSTREAM檢查21第 4 章CICS和CICSPLEX 錯(cuò)誤信息檢查234.1CICS LOG信息檢查234.2聯(lián)機(jī)STORAGE VIOLATION檢查234.3聯(lián)機(jī)交易DUMP檢查24第 1 章 CICS和CPSM檢查方法概述1.1 檢查內(nèi)容本CICS和CPSM健康檢查主要檢查CICS運(yùn)行的整體性能，資源使用瓶頸、系統(tǒng)錯(cuò)誤等；而對(duì)于與應(yīng)用程序相關(guān)的交易的性能，則不在本檢查范圍內(nèi)。概括講，主要包括以下內(nèi)容： CICS和CPSM的配置檢查對(duì)CICS和CPSM的整體配置進(jìn)行評(píng)估。 CICS系統(tǒng)運(yùn)行性能檢查檢查CICS運(yùn)行的資源使用情況，發(fā)現(xiàn)資源使用瓶頸。 CICS系統(tǒng)錯(cuò)誤信息檢查檢查影響CICS系統(tǒng)穩(wěn)定運(yùn)行的出錯(cuò)情況。1.2 數(shù)據(jù)收集CICS和CPSM檢查基于如下系統(tǒng)數(shù)據(jù)： CICS和CPSM系統(tǒng)參數(shù)，包括: CICS啟動(dòng)JCL， CICS SYSIN參數(shù)， CSD資源定義， CPSM DREP資源定義 CICS LOGSTREAM定義 CICS End-of-day統(tǒng)計(jì)報(bào)告數(shù)據(jù)（SMF 110） LOGSTREAM統(tǒng)計(jì)數(shù)據(jù)（SMF 88） CMAS EYULOG和CICS JOB LOG第 2 章 CICS和CPSM系統(tǒng)配置檢查2.1 系統(tǒng)配置檢查內(nèi)容對(duì)檢查環(huán)境的CICS和CPSM配置進(jìn)行描述，并對(duì)配置情況進(jìn)行檢查和評(píng)估。2.2 CICS和CPSM配置描述數(shù)據(jù)來源CICS啟動(dòng)JCL，CICS啟動(dòng)參數(shù)SYSIN，CICS資源定義CSD，CPSM資源定義DREP。配置描述包括： CPSM的拓?fù)浣Y(jié)構(gòu) CAS的LPAR分布，連接狀況 CMAS的LPAR分布，功能（MP或Non MP），連接狀況 MAS的LPAR分布，功能（TOR，AOR，F(xiàn)OR等），連接狀況 MAS GROUP分類情況 CPSM WLM描述 WLM SPEC，GROUP，DEF定義描述 WLM 交易路由控制（DYNAMIC或STATIC） WLM 交易 AFFINITY情況 CPSM RTA描述 RTA SPEC，DEF定義描述檢查要點(diǎn) 應(yīng)當(dāng)充分利用CPSM 交易動(dòng)態(tài)路由的功能，減少交易的AFFINITY。 對(duì)于CPSM，建議實(shí)施CICSDB2 CONNECT的監(jiān)控功能。2.3 CICS與其他子系統(tǒng)連接描述數(shù)據(jù)來源CICS啟動(dòng)JCL，CICS啟動(dòng)參數(shù)SYSIN，CICS資源定義CSD。配置描述包括： CICSDB2 INTERFACE CICSMQ INTERFACE CICS RLS使用情況 CICS CF STRUCTURE使用情況，如NAMING COUNTER，TS SERVER，和CFDT2.4 數(shù)據(jù)案例第 3 章 CICS和CPSM運(yùn)行性能檢查3.1 CICS運(yùn)行性能檢查概述CICS運(yùn)行性能檢查主要是通過CICS EOD的STATISTICS和WLM RMF報(bào)告檢查CICS各部分運(yùn)行的狀況，目的在于消除CICS運(yùn)行的性能瓶頸。CICS運(yùn)行性能檢查部分包括： 交易完成速率和響應(yīng)時(shí)間 交易量執(zhí)行情況 達(dá)到MXT和TCLASS情況 DSA/EDSA使用情況 TDQ和TSQ使用情況 CICS CONNECTION使用情況 DB2 Attachment TCB POOL使用情況 VSAM文件檢查 LOGSTREAM檢查3.2 交易完成速率和響應(yīng)時(shí)間數(shù)據(jù)來源來自RMF WLM報(bào)表中，交易完成速率和交易響應(yīng)時(shí)間數(shù)據(jù),每隔15分鐘為一個(gè)數(shù)據(jù)采集點(diǎn)。 TRANSACTIONS TRANS.-TIME HHH.MM.SS.TTT AVG 0.00 ACTUAL 107 MPL 0.00 EXECUTION 106 ENDED 129734 QUEUED 0 END/S 144.15 R/S AFFINITY 0檢查要點(diǎn)根據(jù)WLM定義的GOAL檢查交易的平均響應(yīng)時(shí)間和完成速率。交易的完成速率（END/S）反映CICS的壓力，交易的平均響應(yīng)時(shí)間（ACTUAL）反映了交易運(yùn)行的性能。如果交易的平均響應(yīng)時(shí)間出現(xiàn)異常，則需要對(duì)異常情況進(jìn)行分析。造成平均響應(yīng)時(shí)間異常的原因主要有資源的瓶頸（如STORAGE SHORT），資源的鎖（如文件，DB2的LOCK），交易錯(cuò)誤（如大量的ABEND）等。數(shù)據(jù)案例從上圖分析, 核心系統(tǒng)的交易峰值在384筆/秒左右,平均交易響應(yīng)時(shí)間在0.12秒以內(nèi); 基本達(dá)到響應(yīng)時(shí)間要求在0.3秒以內(nèi)的目標(biāo).3.3 交易量執(zhí)行情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表:TRANSACTION MANAGER STATISTICSTotal number of active user transactions 檢查要點(diǎn)Total number of active user transactions ：反映CICS總體的交易量。通過交易量的檢查，其一可以了解CICS交易總量，其二可以了解各CICS和各LPAR交易負(fù)載均衡情況。負(fù)載均衡情況反映了各個(gè)CICS或LPAR承受的壓力大小，理想情況是各CICS或LPAR的負(fù)載能夠大致相同，避免個(gè)別CICS或LPAR壓力過大，CPU等資源承受不了。從CICS看，各TOR和各AOR的交易量應(yīng)當(dāng)大體均衡；從LPAR看，各LPAR上的交易量也應(yīng)當(dāng)大體均衡。如果交易量出現(xiàn)較大的不均衡，應(yīng)當(dāng)調(diào)查不均衡的原因，并進(jìn)行改進(jìn)。數(shù)據(jù)案例數(shù)據(jù)分析核心系統(tǒng)除PB21交易量相對(duì)較外, 其他AOR上的交易分布相對(duì)均衡。每個(gè)AOR的一天內(nèi)處理交易數(shù), 在160萬筆左右。數(shù)據(jù)表明核心兩個(gè)LPAR上處理的交易量, 還是比較均勻的。3.4 達(dá)到MXT和TCLASS情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表:MXT達(dá)到情況檢查：TRANSACTION MANAGER STATISTICSCurrent MAXTASKS limit ：Peak number of active user transactions ：Times the MAXTASKS limit reached ：Peak number of MAXTASK queued user transactions ：Total number of MAXTASK delayed user transactions ：TCLASS達(dá)到情況檢查：TRANSACTION CLASS STATISTICSPeak Act，Peak Queued，Times MaxAct檢查要點(diǎn)Peak number of active user transactions 反映交易的最大活動(dòng)數(shù)，值應(yīng)當(dāng)小于最大的定義值Current MAXTASKS limit，即Times the MAXTASKS limit reached應(yīng)當(dāng)為0。如果Times the MAXTASKS limit reached不為0，則Peak number of MAXTASK queued user transactions和Total number of MAXTASK delayed user transactions可以反映出達(dá)到MXT的嚴(yán)重性。Peak Act，Peak Queued，Times MaxAct反映了TCLASS的使用情況，Times MaxAct值應(yīng)當(dāng)為0。如果出現(xiàn)MXT或者TCLASS達(dá)到的情況，可以考慮適當(dāng)增加MXT或TCLASS的最大設(shè)定值。因?yàn)閃LM用CICS最大任務(wù)數(shù)這個(gè)參數(shù)來確定PB（Performance Block）的數(shù)量以進(jìn)行數(shù)據(jù)收集。如果最大任務(wù)數(shù)設(shè)定較高，則會(huì)導(dǎo)致嚴(yán)重的開銷問題；同時(shí)活動(dòng)交易增多，同樣會(huì)造成其他的資源瓶頸，如DSA/EDSA等。檢查案例核心AOR的MXT為200, 沒有到達(dá)MXT的情況發(fā)生, 目前PEAK MAX TASK是123以下.核心TOR的MXT為200, 各TOR有最多175次到達(dá)MXT的情況貸記卡AOR的MXT為100, 沒有到達(dá)MXT的情況發(fā)生.貸記卡TOR的MXT為100, 沒有到達(dá)MXT的情況發(fā)生核心系統(tǒng)上的其他CICS分區(qū), 沒有到達(dá)MXT的情況發(fā)生核心系統(tǒng)AOR有TCALSS TCLCBB10最6次到達(dá)TCLASS purge threshold, 最多24個(gè)交易被QUEUE的情況, 此TCLASS定義了AIPS和TLUA交易, 定義Max Act為10, Purge Thresh為5, 如果不是有意對(duì)這兩個(gè)交易做這種限制, 建議加大Max Act數(shù)據(jù)分析總體正常, 但仍有調(diào)整的余地。建議如果CPU資源如果不特別緊張, 可以加大核心TOR的MXT到250。3.5 DSA/EDSA使用情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表，包括DSA和EDSA。STORAGE MANAGER STATISTICSCurrent DSA size :Peak DSA Size :Times went short on storage ：檢查要點(diǎn)DSA/EDSA反映CICS STORAGE使用情況，當(dāng)DSA/EDSA使用達(dá)到定義值時(shí)，CICS會(huì)進(jìn)入SHORT ON STORAGE狀態(tài)，CICS交易如果無法得到內(nèi)存而無法執(zhí)行，CICS性能將會(huì)受到嚴(yán)重影響。正常情況下，DSA應(yīng)該有1M以上的空余空間，EDSA應(yīng)該有50M以上的空余空間；并且在一段時(shí)間內(nèi)，DSA/EDSA的使用量沒有明顯的變化趨勢(shì)。如果出現(xiàn)DSA的SHORT ON STORAGE，除了考慮擴(kuò)大DSA空間外，還應(yīng)該減少/消除程序?qū)?6M線下STORAGE的使用；如果出現(xiàn)EDSA的SHORT ON STORAGE，可以考慮增加CICS EDSA的大小。數(shù)據(jù)案例核心CICS DSA/EDSA使用情況數(shù)據(jù)分析核心環(huán)境和貸記卡環(huán)境AOR的DSA/EDSA的PEAK使用率都不高, DSA/EDSA有相當(dāng)富余空間。3.6 TDQ和TSQ使用情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表。TDQ使用情況TRANSIENT DATA Control intervals : Peak control intervals used : Intrapartition buffers : Intrapartition buffer waits : Peak intrapartition buffer waits : Number of strings : Intrapartition string waits : Peak string waits : TSQ使用情況TEMPORARY STORAGENumber of control intervals available : Peak control intervals in use : Temporary storage buffers : Buffer waits : Peak users waiting on buffer : Temporary storage strings : Peak number of strings in use : Times string wait occurred : Peak number of users waiting on string : 檢查要點(diǎn)對(duì)于TDQ和TSQ，主要關(guān)心三個(gè)方面：Buffer Waits：應(yīng)該避免出現(xiàn)Buffer Wait。如果出現(xiàn)Buffer Waits在CICS Storage富裕的情況下，可以適當(dāng)增加Buffer值。String Waits：應(yīng)該避免出現(xiàn)String Wait。如果出現(xiàn)String Waits在CICS Storage富裕的情況下，可以適當(dāng)增加String值。Peak Control Intervals In Used： 應(yīng)當(dāng)與Number of control intervals available有較大距離。如果達(dá)到或接近Number of control intervals available ，則需要增加TSQ或TDQ Dataset的大小，或者對(duì)TDQ或TSQ進(jìn)行清理。數(shù)據(jù)案例數(shù)據(jù)顯示核心環(huán)境AOR和MOR的TSQ的TS buffer需要增加。AOR的TS=(,100,50)增加為TS=(,110,50); MOR的TS=(,3,3) 增加為TS=(,6,3)3.7 CICS CONNECTION使用情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表。ISC/IRC SYSTEM AND MODE ENTRIESPeak outstanding allocatesFailed link allocates Failed allocates due to sessions in use 檢查要點(diǎn)CICS連接是由一組SESSION構(gòu)成。如果SESSION數(shù)目不足，會(huì)影響CICS間交易的路由及通信。主要關(guān)注是否有Peak outstanding allocates，如果不為0，則需要考慮要增加SESSION數(shù)。數(shù)據(jù)案例核心環(huán)境, AOR-TOR, AOR-EOR, AOR-AOR, AOR-MOR的SESSIONS個(gè)數(shù)都在正常范圍內(nèi), 無Peak outstanding allocates。3.8 DB2 Attachment數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表。DB2 CONNECTION STATISTICS TCB LimitPeak number of TCBsCurrent Pool Thread LimitNumber of Pool Thread WaitsPeak number of Pool Threads in useDB2ENTRY STATISTICSThread LimitThread HWMPthread LimitPthread HWMThread Waits/OverflowsReadyq HWM檢查要點(diǎn)CICSDB2 Interface反映CICS交易使用DB2 THREAD情況，主要關(guān)注THREAD WAIT發(fā)生的情況，包括POOL和DB2ENTRY THREAD。 如果Peak Number TCBs達(dá)到或接近TCB Limit，則需要考慮增加CICSDB2 TCB數(shù) 如果出現(xiàn)POOL THREAD WAIT或者ENTRY Thread Waits/Overflows，則可以考慮增加相應(yīng)的Thread Limit，同時(shí)TCB Limit也要相應(yīng)增加 如果調(diào)整了TCB Limit，SYSIN參數(shù)中的MAXOPENTCBS也要進(jìn)行相應(yīng)的調(diào)整檢查案例核心環(huán)境各AOR的pool thread wait 最多有92次, thread Waits/Overflows最多有75次, 同時(shí)TCB的PEAK使用都接近TCBLIMT=80.鑒于目前核心環(huán)境對(duì)應(yīng)DB2 member的CTHREAD總數(shù)為300*2=600, 而Protected thread總數(shù)為20*8=160, 相對(duì)富余; 而TCB LIMIT總數(shù)80*8=640. 基于Total DB2 TCB LIMIT Total DB2 CTHREAD的原則, 我們建議如下:1) 在與DB2專家協(xié)商后, 將CTHTEAD至少增加為330(最好到400, 由于目前XX行DB2版本為7.1,可先增加到330), 這樣總數(shù)為330*2=660.2) 在CTHREAD增加的基礎(chǔ)上, 相應(yīng)同步上調(diào)DB2 entry DP20DB2E 的 thread limit, 比如從50到80, 總數(shù)為 80 * 8 = 6403) 目前只定義了一個(gè)Priority為HIGH的DB2 entry, 建議增加一類Priority為EQUAL的DB2 entry; IBM建議將交易數(shù)量較大,但DB2資源使用較少的HOT交易定義為HIGH, 而將其他HOT交易定義為EQUAL. 使用DB2 entry可增加thread re-use, 提高訪問DB2效率.4) 目前Pool Thread Priority 定義為HIGH, 這是值得討論的, 建議改為EQUAL.3.9 DBCTL Attachment數(shù)據(jù)來源來自CICS STATISTICS 報(bào)表，收集數(shù)據(jù)時(shí)，需要斷開CICS與IMS的連接；打印STATISTICS報(bào)表時(shí)，使用TYPE=DBCTL參數(shù)。DBCTL SESSION TERMINATION STATISTICS _ DBCTL identifier : DBCTL RSE name : Minimum number of threads : Maximum number of threads : Times minimum threads hit : Times maximum threads hit : Elapsed time at maximum threads : Peak number of thread TCBs : Successful PSB schedules :檢查要點(diǎn)CICSIMS Interface反映CICS交易使用IMS THREAD情況，主要關(guān)注Times maximum threads hit發(fā)生的情況。 如果Times maximum threads hit數(shù)值較高，則需要考慮增加CICSIMS MAXTHRD數(shù)量檢查案例核心環(huán)境AOR:CI21SA11的DBCTL SESSION使用情況：DBCTL SESSION TERMINATION STATISTICS _ DBCTL identifier : IS21 DBCTL RSE name : IS21 Minimum number of threads : 25 Maximum number of threads : 35 Times minimum threads hit : 287 Times maximum threads hit : 15566 Elapsed time at maximum threads : 000-00:47:06.96 Peak number of thread TCBs : 35 Successful PSB schedules : 3641675) 其中Times maximum threads hit達(dá)到15566 次，Elapsed time at maximum threads時(shí)間達(dá)到47分鐘，Times minimum threads hit也有287次。我們建議調(diào)整MAXTHRD到40，并繼續(xù)監(jiān)控THREAD使用情況。如果在各個(gè)LPAR交易均衡的狀況下，Times maximum threads hit依然很高，可以考慮繼續(xù)調(diào)整MAXTHRD數(shù)量。3.10 TCB POOL使用情況數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表。CICS TCB Pool StatisticsPeak TCBs attached in this TCB Pool . . . . . . : Max TCB Pool limit . . . . . . . . :檢查要點(diǎn)當(dāng)Peak TCBs attached in this TCB Pool達(dá)到或接近Max TCB Pool limit定義時(shí)，需要擴(kuò)大Max TCB Pool Limit值。其中，需重點(diǎn)關(guān)注MAXOPENTCBS。數(shù)據(jù)案例核心AOR MAXOPENTCBS目前定義為120, 單個(gè)AOR最多使用到112, 需擴(kuò)充。核心AOR沒有發(fā)現(xiàn)L9 OPEN TCB被使用, 建議客戶可以花較少代價(jià)改造為OPENAPI threadsafe程序, 提高程序執(zhí)行性能.3.11 VSAM文件檢查數(shù)據(jù)來源來自CICS STATISTICS EOD報(bào)表；VSAM LISTCATEOD報(bào)表：FILES - Performance Information0 File Active Excl Cntl Name Strings Strings Current Total Highest Data Index ConflictsVSAM LISTCAT;SPLITS-CI ， SPLITS-CA檢查要點(diǎn)對(duì)于VSAM 文件的檢查，首先需要檢查文件是否出現(xiàn)String Wait，這可以通過檢查EOD報(bào)表中文件性能部分的Wait On Strings統(tǒng)計(jì)信息。如果文件出現(xiàn)String Wait，則在CSD 文件定義中，需要增大String Number。其次，需要檢查文件是否出現(xiàn)大量的CI/CA Split。大量的CI/CA Split對(duì)文件和交易的性能有很大的影響。數(shù)據(jù)案例1) 發(fā)現(xiàn)如下文件使用RLS模式來訪問ESDS文件: File Dataset Name Dataset Name Base Dataset Name (If Applicable) Type RLS _ CSCLOG ESS.PRD.CS10V.CSCLOG ESDS YESPMLF ESS.PRD.AP121V.PMLF ESDS YESPML2 ESS.PRD.AP121V.PML2 ESDS YESPRMLOG ESS.PRD.ISS.CICS.PRMLOG ESDS YES2) 發(fā)現(xiàn)1個(gè)文件存在較多STRING WAIT0FILES - Performance Information +_ 0 File Wait On Strings Excl Cntl Name Strings Total HWM Data Index Conflicts + _ GADTLOGB 1 10927 3 3 2 0 3) 使用LISTCAT檢查VSAM文件的CI/CA SPLIT數(shù)據(jù)分析1) 在RLS模式下使用ESDS文件會(huì)造成CICS hung和可用性的問題,如果一個(gè)CICS分區(qū)在寫ESDS文件時(shí)發(fā)生錯(cuò)誤, 則此ESDS文件可能被LOCK, 直到CICS分區(qū)被重起。 所以不建議在RLS模式下不使用ESDS文件。2)GADTLOGB是ESDS文件,且只有ADD操作, 這是合理的, 不需要增加STRING。3.12 LOGSTREAM檢查數(shù)據(jù)來源來自SMF TYPE 88檢查要點(diǎn)對(duì)DFHLOG和DFHSHUNT檢查，避免出現(xiàn)STAGE DATASET FULL情況，避免出現(xiàn)LOG DASD SHIFT情況。數(shù)據(jù)分析核心系統(tǒng)和貸記卡系統(tǒng): peak # offload次數(shù)核心系統(tǒng)為24, 貸記卡系統(tǒng)為21 可見少量DASD SHIFT AOR在域“BYT DELETED INTERIM ST W/DASD”, 頻繁出現(xiàn)很大數(shù)目 說明”BYT DEL