本文僅針對我遇到的具體情況，未必能通用。
今天測試的時候，應用層同事反應，使用QPBOC進行聯機交易查詢餘額的時候，後臺返回 “作弊卡”（響應碼：34）.
開始尋找並定位問題，一開始沒多想，因爲有旁邊其他的廠商可以順利查詢該卡的餘額，只有我們的失敗，因此直接看 8583 報文。
對比其他正常查詢的廠商的8583報文，細看幾處不一致的地方。排除一些正常的不同點，比如：不可預知數，9F10的MAC，終端計數器，卡片交易計數器。其他還有9F33的不一致，應該也不是問題，不過還是修改成一致測試一下。
結果毫無懸念的，還是不行。然後在別人的POS上試一下，還是可以正常查詢後臺餘額。
看來不是 8583 的問題，那麼下一步，就看一下終端與卡片的交互。
使用smartSpy截獲數據，對比我們的POS與別人的POS數據，發現 GPO 階段，發送給卡片的9C的值不一致。我發送的是 00， 別人發送的是 31。
馬上修復 9C 的問題，問題順利解決。
總結：此問題前後大約花了3-4個小時。其實開始的時候，對比 8583 未果，就應該細緻考慮問題，應該是數據前後不一致引起的，那麼先考慮PDOL涉及的數據，這樣應該可以更快速解決問題。幸虧有smartSpy，否則沒有思考前後不一致，沒有考慮PDOL的問題，會花更多的時間解決此問題。
另外說一下，爲什麼 9C 沒有正常賦值？因爲內核裏面，9C並沒有根據應用的賦值寫進內核。大概原因是測試L2的時候，並不需要9C有別的值，默認爲00即可，因此沒有對9C賦值也沒問題。L2的測試不夠完善，寫內核的時候疏忽沒有獲取應用傳入的值，這兩個原因都有。