隨著專案的推進，是時候為下一階段的開發工作做好知識儲備工作了，我們系統底層的主要部分部署在cics平台上，而本人負責底層的開發工作，因此有必要系統地學習一下cics平台。以下是我學習cics平台的一些粗略的學習筆記，在此記下以供日後溫習。
一、本人對cics的初步理解
說到cics當然需要知道它的全稱是什麼了，它的全稱是customer information control system，即客戶資訊控制系統的意思。cics最初出現在os/370上，迄今已經有40多年的歷史了，cics支援多種作業系統，但目前仍然主要用於大型機的作業系統z/os。cics在大型機上的版本依次經歷了1.7版、2.1版、3.1.1版、3.1.2版、3.3版和4.1版等，到cics發展到5.x後便稱為cics ts（cics transaction server）。cics在應用程式方面最顯著的特徵是提供了介面功能和互動功能。
作為cics中的聯機處理，是同批處理相對應的乙個概念。其中批處理是指在使用者不直接干預的情況下，系統對批量資源在規定時間內，進行例行處理的過程。批處理主要有以下特點：
（1）所有需要用到的i/o區和工作區都應在程式中進行定義。
（2）由程式讀入批量的輸入資料。
（3）輸入資料必須在處理開始前準備就緒，在處理過程中不得再次插入。
（4）程式直接向作業系統發出i/o指令。
（5）如果出現故障，處理可重新進行，或從故障點繼續向後處理。
聯機處理是指在使用者直接干預的情況下，系統根據使用者的輸入在短時間內進行互動式處理的過程。聯機處理主要有以下特點：
（1）使用者可以在不同地點，通過不同的終端使用同一臺主機。
（2）資料可以隨時輸入到系統中，而無須積累成批量後再輸入。
（3）對終端的處理請求具有實時性的響應。
（4）輸出資訊通常直接在使用者所在終端上顯示。
（5）可以對同乙個檔案同時進行多種操作。
（6）使用者可以在任何時候通過終端啟動應用程式，而無須經過操作員的排程安排。
cics作為一種中介軟體，是存在於作業系統和應用程式之間的乙個子系統。cics實際上是在作業系統控制下的乙個分割槽中作為乙個主程式執行。而其他聯機應用程式則是在cics的控制下執行的。cics通常是結合db2使用的。db2同cics一樣，也屬於一種中介軟體。cics所處於的位置是作業系統和應用程式之間的事務管理層。借助cics，應用程式不必直接同作業系統打交道，由此可以減輕作業系統的負擔。同時，由於作業系統的負擔得以減輕，因此也可以滿足更多潛在使用者和要求處理的事務。cics作為乙個子系統，為執行於其上的應用程式提供了類似於作業系統的管理功能，主要有：任務管理、檔案管理、程式管理、佇列管理、終端管理、系統服務、恢復機制和外部安全管理。
二、cics中交易和任務
交易（transaction）和任務（task）是cics中的兩個最基本的概念。這兩個概念的產生，個人認為很大程度上是cics是面向事務處理的緣故。在cics中，乙個交易是指一組相關聯的操作序列或為了完成乙個特定功能的一組步驟。交易通常產生於終端和資料庫之間，屬於一種應用過程。乙個交易中既可能只有乙個操作，也可能存在一組操作。cics中的任務是指操作員或用於請求的特定交易的乙個例項。乙個任務實際上就是乙個交易的一次執行過程。如果將交易看作乙個程式，則任務就相當於是乙個程序。
三、cics的基本操作
（1）cics的登入：l cics。
（2）cics的啟動方式：
冷啟動：正常關閉cics，並且全新安裝cics。該重啟方式將會清除某些資訊。
熱啟動：正常關閉cics，但在關閉之前要求所有正在執行的任務依次完成。這種重啟方式實際上為最好的一種方式。
緊急啟動：非正常關閉cics，通常是由於電力故障等外在原因造成的，此時，為保證資料的一致性，cics在重啟後，將回滾所
有未完成的邏輯工作單元。
（3）cics的簽到操作：cesn
（4）cics的退出操作：cesf
（5）與位於控制台中心的操作員通訊: cwto 'hello, administrator!'
（6）將訊息發往其他終端：cmsg 'call tem1' , r=tem1, s ----- 此命令向終端tem1傳送訊息。
如果需要向所有終端傳送訊息，即向所有終端進行廣播，可以使用以下命令：
cmsg 'call all' , r=all , s
（7）對訊息進行查詢：cmac
（8）對指定的cics命令進行解釋：ceci
（9）對cics命令語法的檢查：cecs
（10）瀏覽臨時儲存佇列：cebr
四、cics編譯處理過程
涉及到cics的程式在編譯連線時與普通程式是有所不同的。此外，關於cics在實際中所用到的各種資源，都是需要在cics子系統上進行定義的。cics任務的執行及程式的除錯也同樣需要在cics子系統上進行。
涉及到cics的程式從源**到可載入模組之間的編譯流程通常需要經歷3個處理步驟。這三個步驟依次如下：
（1）cics轉換（cics translation）
（2）編譯（compilation）
（3）連線編譯（link edit）
五、ceda、cemt和cedf的使用
ceda、cemt和cedf是編寫cics程式最常使用的命令。其中，ceda是資源定義命令，cemt是資源檢視和設定命令，cedf除錯程式命令。
（1）在實際應用中，通常首先需要將在ispf中所開發的程式在cics子系統中進行定義。定義程式的相應操作如下：
ceda define program(testpgm) group(testgrp)
以上操作在cics中定義了程式名為「testpgm」的程式。同時，該操作還將這一程式定義在了名為「testgrp」的組中。組在
cics中是用來將各種相關資源存放在一起的，其本身嚴格來說並不屬於一種cics資源。
當定義完資源後，在實際應用之前，還需將所定義的資源進行安裝。所謂安裝，實際也就是將該資源所包含的所有資料讀入記憶體。
原因在於cpu是只能執行讀入記憶體的程式的。安裝也是使用ceda進行的，以下為幾段相應的安裝操作：
ceda install program(testpgm) group(testgrp)
ceda install prog(*) group(testgrp)
ceda install group(testgrp)
以上第一條操作是將testgrp組中的程式testpgm進行安裝；第二條操作則將安裝testgrp組中的所有程式；第三條將安裝
testgrp組中的所有資源。
cics中經常使用的縮寫：
define: 可以簡寫成為d
program: 可以簡寫成為prog
transaction: 可以簡寫成為trans
file: 可以簡寫成為f
terminal: 可以簡寫成為te
group: 可以簡寫成為g
alter: 可以簡寫成為al
inquire: 可以簡寫成為i
set: 可以簡寫成為s
使用ceda也可對已定義後的資源的各種屬性進行修改。例如，可以將某一交易的關聯程式改為其他程式，或者將該交易所在的
組等等。以下操作可以對testpgm組中的tst1交易的相關屬性進行修改。
ceda alter trans(tst1) g(testgrp)
該操作執行後，系統將給出乙個列表，列表中包括所指定的tst1交易的各種屬性資訊。當需要修改某一屬性值時，直接在該列
表中相應的屬性位置修改即可。
此外，若要顯示交易的詳細資訊，可以使用以下命令：
ceda display trans(tst1) g(testgrp)
若要以列表的形式顯示資源的屬性（資源名稱、型別、所在組名以及建立時間），可以使用以下命令：
ceda expand group(testgrp)
（2）cemt主要用於對定義後的資源進行查詢以及設定，通常和ceda的聯絡最為緊密。例如，以下操作將查詢在cics上定義的所有
程式資源。
cemt inquire program(*) = cemt i prog(*)
以上兩條命令是等價的，執行後，將會把cics上所有定義過的程式列表出來。該列表相對於第一種方式中的列表資訊要簡略一
以直接對該程式進行安裝了。
cemt set program(testpgm) new = cemt s prog(testpgm) new
以上操作中的「set」表示此時cemt用於對資源進行設定，而"new"則表示該設定為更新設定。當使用以上方式在cics中更
新程式後，可以通過此時螢幕上顯示的程式長度來判斷是否更新成功。通常情況下，如果程式長度有變化，說明更新成功了。
（3）cedf相當於cics中的乙個程式偵錯程式。使用cedf時，首先在螢幕左上角輸入「cedf」，然後清空螢幕，輸入被除錯程式所
在交易的交易號。此時，系統將首先顯示該交易所生成的任務最初的eib資訊。使用功能pf7和pf8可上翻或下翻輸出資訊，使
用有ctrl鍵執行下一步操作。使用cedf不僅可以顯示程式在單步執行時的資訊，也可以在執行過程中對其進行干預。這種干預體
現了cedf的互動式除錯功能。除了以上干預方式外，cedf通常還有以下幾種干預方式：更改異常條件、通過「noop」或
「nop」跳過某些cics命令、異常終止（abend）乙個任務。
學習平台專案總結
為了以後的面試不至於忘記，覺得有必要做下總結，不然以後忘了很多專案的細節。說下前端部分，我們沒有使用vux來做狀態管理，而是基於flux架構思想實現了自己的狀態管理。總的來說就是 把狀態放到data.js的store裡，把更新狀態的方法也放到data.js裡，再把data.js的store賦值給vu...
學習平台專案總結
為了以後的面試不至於忘記，覺得有必要做下總結，不然以後忘了很多專案的細節。說下前端部分，我們沒有使用vux來做狀態管理，而是基於flux架構思想實現了自己的狀態管理。總的來說就是 把狀態放到data.js的store裡，把更新狀態的方法也放到data.js裡，再把data.js的store賦值給vu...
平台支付總結
一 遊戲支付事項 1 新建乙個平台支付的基類 basesdkplatform 不同平台繼承基類 basesdkplatform 中的支付方法 2 在平台支付的工廠方法類中通過平台型別獲取當前平台的支付類，再呼叫android的支付方法 3 在遊戲內的購買支付介面，如果要加入平台很多的時候，最好新建乙...