Loading article…
IBM CICS（顧客情報制御システム）は、 z/OSおよびz/VSE上で動作するIBMメインフレームシステム 上のアプリケーションに対し、オンライン・トランザクション管理と接続性を提供する、多言語対応のアプリケーション・サーバーのファミリーです。
CICSファミリー製品はミドルウェアとして設計されており、高速かつ大量のオンライン・トランザクション処理をサポートします。CICSトランザクションは、1つの要求によって開始される処理単位であり、1つ以上のオブジェクトに影響を与える可能性があります。[ 2 ] この処理は通常対話型（画面指向）ですが、バックグラウンド・トランザクションも可能です。
CICSトランザクションサーバー（CICS TS）は、CICSファミリーの最上位に位置し、オペレーティングシステムの機能を拡張または代替するサービスを提供します。これらのサービスは、汎用的なオペレーティングシステムサービスよりも効率的であり、特に多様な端末デバイスとの通信に関して、プログラマにとってより使いやすくなっています。
CICS向けに開発されたアプリケーションは、さまざまなプログラミング言語で記述でき、CICSが提供する言語拡張機能を使用して、ファイル、データベース接続、端末などのリソースとやり取りしたり、Webサービスなどの関数を呼び出したりします。CICSはトランザクション全体を管理するため、何らかの理由でトランザクションの一部が失敗した場合でも、回復可能な変更はすべて元に戻すことができます。
CICS TSは、銀行や保険会社などの大手金融機関で最も広く利用されていますが、フォーチュン500企業や政府機関でもCICSが使用されていると報告されています。また、中小企業でもCICS TSやその他のCICSファミリー製品が利用されています。CICSは、銀行窓口業務アプリケーション、 ATMシステム、産業生産管理システム、保険アプリケーションなど、さまざまな対話型アプリケーションのバックエンドで広く活用されています。
最近の CICS TS の機能強化には、API、フレームワーク、エディター、ビルドツールの選択肢など、開発者エクスペリエンスを向上させるための新機能が含まれており、同時にセキュリティ、回復力、管理といった主要分野のアップデートも提供されています。以前の CICS TS リリースでは、Web サービスとJava、イベント処理、Atomフィード、RESTfulインターフェイスがサポートされていました。
CICS の前身は、シングルスレッドのトランザクション処理システムであるIBM MTCS でした。後に、これらのトランザクションを元のアプリケーション プログラムに変更を加えることなく CICS で実行できるようにするための「MTCS-CICS ブリッジ」が開発されました。IBM の顧客情報制御システム (CICS) は、1966 年にミシガン ベルと共同で初めて開発されました。 [ 3 ]ベン リギンズは、バージニア電力会社の IBM システム エンジニアだったときに、オンライン システムのアイデアを思いつきました。[ 4 ]
CICSは、もともと1966年にイリノイ州デプレーンズにあるIBM開発センターで、公益事業業界の要求に応えるために開発されました。最初のCICS製品は1968年に発表され、Public Utility Customer Information Control System （PU-CICS）という名称でした。すぐに他の多くの業界にも適用できることが明らかになったため、 IMSデータベース管理システムの発表から間もなく、1969年7月8日にCICSプログラム製品の最初のリリースが導入された際に、Public Utilityという接頭辞は削除されました。
その後数年間、CICSはパロアルトで開発され、IBMがより戦略的と考えていたIMSよりも重要度の低い「小規模な」製品とみなされていました。しかし、顧客からの圧力により、CICSは存続しました。1974年にIBMがCICSの開発を終了し、IMSに注力することを決定した際、CICSの開発責任は英国のIBMハースリー拠点に引き継がれました。ハースリー拠点はちょうどPL/Iコンパイラの開発を終えたばかりで、CICSと同じ顧客を多く抱えていました。現在も、インドと米国のIBM研究所からの貢献を受けながら、開発の中核はハースリーで継続されています。
CICSは当初、1965年製のIBM 2741 Selectric（ゴルフボール型）タイプライターベースの端末など、ごく一部のIBM製デバイスのみをサポートしていました。その後、1964年製のIBM 2260や1972年製のIBM 3270といったビデオディスプレイ端末が広く普及しました。
IBMメインフレームの初期の頃は、コンピュータソフトウェアは無料で、コンピュータハードウェアに無料でバンドルされていました。OS /360オペレーティングシステムやCICSなどのアプリケーションサポートソフトウェアは、オープンソースソフトウェア運動が始まるずっと前からIBMの顧客に「公開」されていました。スタンダード・オイル・オブ・インディアナ（アモコ）のような企業は、CICSに多大な貢献をしました。
IBMのデ・プレーンズチームは、ASCIIテレタイプモデル33 ASRのようなIBM以外の一般的な端末のサポートを追加しようと試みたが、小規模で予算の限られたソフトウェア開発チームでは、テストに必要な月額100ドルのハードウェアを購入する余裕がなかった。IBMの幹部たちは、将来も過去と同じように、従来型のパンチカードを使ったバッチ処理が主流になると誤って考えていた。
IBMは、公共事業会社、銀行、クレジットカード会社が、電話交換手が顧客情報に高速でアクセスして更新できる、費用対効果の高い対話型システム（アメリカン航空のSabreコンピュータ予約システムで使用されていた1965年のIBM Airline Control Programに類似）を要求した際、渋々ながら最小限の資金提供しか行わなかった。これは、パンチカードシステムによる夜間のバッチ処理を待つことなく、顧客情報に高速でアクセスして更新するためであった。
CICSがテレタイプModel 33 ASRのサポート付きでアモコに納入された際、OS/360オペレーティングシステム全体（CICS以外のアプリケーションプログラムを含む）がクラッシュするという事態が発生しました。CICSの中核となる端末制御プログラム（TCP）の大部分とOS/360の一部は、オクラホマ州タルサにあるアモコ・プロダクション・カンパニーによって、苦労して再設計および書き直しを余儀なくされました。その後、IBMに返還され、他の企業に無償で配布されました。
顧客情報制御システム（CICS）は、IBMの最も商業的に成功したソフトウェア製品の一つです。発売後、トランザクション処理モニタはIBMのメインフレーム戦略の要となり、最終的に関連ハードウェアの売上高は600億ドルを超えました。CICSは、大量かつ信頼性の高いトランザクション処理を可能にすることで、エンタープライズコンピューティング環境における重要な構成要素としての地位を確固たるものにし、IBMメインフレームエコシステムの主要な推進力であり続けています。
1972年当時、CICSは3つのバージョンで利用可能でした。メモリが非常に限られたDOS/360マシン向けのDOS-ENTRY（プログラム番号5736-XX6 ）、より多くのメモリを搭載したDOS/360マシン向けのDOS-STANDARD（プログラム番号5736-XX7）、そしてOS/360を実行するより大規模なマシン向けのOS-Standard v2（プログラム番号5734-XX7）です。[ 5 ]
1970年初頭、初期リリースの主任設計者であるベン・リギンズを含む多くの開発者がカリフォルニアに移り、IBMのパロアルト開発センターでCICSの開発を続けた。IBMの幹部は、連邦法でソフトウェアのアンバンドリングが義務付けられるまで、ソフトウェアが収益を生み出す製品としての価値を認識していなかった。1980年、IBMの幹部は、IBMパーソナルコンピュータでCICSインテリジェント端末として使用するために、互換性のないIntelチップと比較的未成熟なMS-DOSの代わりに、独自のEBCDICベースのオペレーティングシステムと集積回路マイクロプロセッサチップを提供するべきだというベン・リギンズの強い提案を無視した。
当時の大型プロセッサでさえ処理能力に限界があったため、CICSをインストールする際には、条件付きアセンブリ言語ステートメントの値を設定するために、システム生成（sysgen）に似たプロセスであるCICSGENを実行した後、すべてのCICSシステムモジュールのソースコードをアセンブルする必要がありました。このプロセスにより、各顧客は、使用しない端末タイプのデバイスサポートなど、使用しない機能についてCICS自体からのサポートを除外することができました。
CICSが初期に人気を博した理由は、ハードウェアが非常に高価だった時代において比較的効率的な実装を実現したこと、マルチスレッド処理アーキテクチャを採用したこと、端末ベースのリアルタイムトランザクションアプリケーションを開発する際の比較的容易さ、そしてデバッグや機能拡張を含む多くのオープンソースの顧客貢献などが挙げられる。
CICSの一部は、1980年代と1990年代にトニー・ホーアが率いるオックスフォード大学コンピューティング研究所との協力のもと、 Z記法を用いて形式化されました。イブ・ホルム・ソーレンセンは、 IBMハーズリーと協力し、1982年の発足当初からオックスフォード大学でトランザクション処理プロジェクト自体を率いていました（後にCICSプロジェクト[ 6 ]と改名）。[ 7 ]この研究は1992年にクイーンズ・アワード・フォー・テクニカル・アチーブメントを受賞しました。 [ 8 ] [ 9 ] CICSプロジェクトの一環として、ソーレンセンはエドガー・ダイクストラのガード付きコマンド言語を拡張し、抽象コマンドとしてZスキーマ記法を使用できるようにしました。[ 10 ]
1986年、IBMは分散データ管理アーキテクチャ（DDM）で定義されたレコード指向ファイルサービスに対するCICSのサポートを発表しました。これにより、ネットワークに接続されたリモートコンピュータ上のプログラムが、以前はCICS/MVSおよびCICS/VSEトランザクション処理環境内でのみ利用可能だったファイルを作成、管理、アクセスできるようになりました。[ 11 ]
CICS の新しいバージョンでは、DDM のサポートが削除されています。CICS z/OS の DDM コンポーネントのサポートは 2003 年末に終了し、バージョン 5.2 以降では CICS for z/OS から削除されました。[ 12 ] CICS TS for z/VSE では、DDM のサポートは V1.1.1 レベルで安定化され、将来のリリースでサポートを終了する予定であることが発表されました。[ 13 ] CICS for z/VSE 2.1 以降では、CICS/DDM はサポートされていません。[ 14 ]
CICS Transaction Serverは、バージョン1.2で初めてネイティブHTTPインターフェースを導入し、同時に、グリーン画面の端末ベースのプログラムをHTMLファサードでラップするWeb Bridgeテクノロジーも導入しました。CICS WebおよびDocument APIは、CICS TS V1.3で拡張され、Webブラウザとより効果的に連携するWeb対応アプリケーションの作成が可能になりました。
CICS TS バージョン 2.1 から 2.3 では、CICS にCORBAおよびEJBテクノロジーを導入することに重点が置かれ、CICS 資産を分散アプリケーション コンポーネント モデルに統合する新しい方法が提供されました。これらのテクノロジーは、CICS でJavaアプリケーションをホストすることに依存していました。Java ホスト環境は、多くのリリースで数多くの改良が加えられました。CICS TS バージョン 4.1 リリースでは、JVMSERVER と呼ばれるマルチスレッド JVM リソースが導入され、バージョン 5.1 では 64 ビット JVM テクノロジーを使用するようにさらに強化されました。バージョン 5.1 では、WebSphere Liberty プロファイル Web コンテナーも導入されました。最終的に、WebSphere Liberty はバージョン 5.3 で CICS Transaction Server に完全に組み込まれました。Java を使用して CICS で多数の Web 向けテクノロジーをホストできるようになったため、最終的にネイティブの CORBA および EJB テクノロジーは削除されました。
CICS TS V3.1では、CICS向けにSOAPおよびWSDLテクノロジーのネイティブ実装が追加され、さらにクライアント側HTTP APIによるアウトバウンド通信機能も提供されました。これらのテクノロジーにより、CICSコンポーネントと他のエンタープライズアプリケーションとの統合が容易になり、広く採用されました。COBOLなどの言語で記述された従来のCICSプログラムを、ほとんど、あるいは全くプログラム変更を加えることなく、WSDLで定義されたWebサービスに変換するためのツールも含まれていました。このテクノロジーは、CICSのその後のリリースで定期的に機能強化されました。
CICS TS V4.1およびV4.2では、 Atomパブリッシングプロトコルのネイティブ実装を含む、Web接続機能がさらに強化されました。
最新のWeb対応テクノロジーの多くは、従来の製品リリースとは異なる配信モデルを用いて、CICSの初期リリース向けに提供されました。これにより、早期導入ユーザーは建設的なフィードバックを提供し、統合テクノロジーの最終設計に影響を与えることができました。例としては、TS V2.2向けのSoap for CICSテクノロジープレビューSupportPacや、TS V3.1向けのATOM SupportPacなどが挙げられます。このアプローチは、 CICS TS V4.2のJSONサポート導入にも用いられ、このテクノロジーは後にCICS TS V5.2に統合されました。
CICSにおけるJSONテクノロジーは、以前のSOAPテクノロジーと類似しており、どちらもCICS上で動作するプログラムを最新のインターフェースでラップすることを可能にしました。JSONテクノロジーは、IBM製品であるz/OS Connect Enterprise Editionでさらに強化され、複数のメインフレームサブシステムの資産を活用できるJSON APIの作成に利用されました。
CICSとの連携には、多くのパートナー製品も利用されています。代表的な例としては、JCA準拠のJavaアプリケーションサーバーからCICSに接続するためのCICS Transaction Gatewayの使用や、 WebトラフィックがCICSに到達する前にフィルタリングするためのIBM DataPowerアプライアンスの使用などが挙げられます。
最新バージョンのCICSは、既存のソフトウェア資産と新規のソフトウェア資産の両方を分散アプリケーションフローに統合するための多くの方法を提供します。CICS資産はリモートシステムからアクセスでき、またリモートシステムにアクセスすることも可能です。ユーザーIDとトランザクションコンテキストを伝播させることができ、RESTful APIを構成および管理できます。デバイス、ユーザー、サーバーは標準ベースのテクノロジーを使用してCICSとやり取りできます。さらに、CICSのIBM WebSphere Liberty環境は、新しいテクノロジーの迅速な導入を促進します。
1985年1月までに、1969年に設立されたコンサルティング会社が、ヒルトンホテル、FTDフローリスト、アムトラック、バジェットレンタカー向けに「大規模オンラインシステム」を構築した後、MicroCICSとなるものを発表した。[ 15 ]当初はIBM XT/370とIBM AT/370に重点が置かれていた。[ 16 ]
CICSというと、一般的にはCICSトランザクション・サーバーを指しますが、CICSファミリーとは、トランザクション・サーバー、コネクタ（CICSトランザクション・ゲートウェイと呼ばれる）、およびCICSツールのポートフォリオ全体を指します。
分散プラットフォーム（メインフレームではない）上の CICS はIBM TXSeriesと呼ばれます。TXSeries は分散トランザクション処理ミドルウェアです。クラウド環境と従来のデータセンターで、C、C++、COBOL、Java™、PL/I アプリケーションをサポートします。TXSeries は、 AIX、Linux x86、Windows、Solaris、HP-UXプラットフォームで利用可能です。[ 17 ] CICS は、 IBM iやOS/2などの他のオペレーティングシステムでも利用可能です。z/OS 実装（つまり、CICS Transaction Server for z/OS）は、圧倒的に人気があり、重要です。
VM/CMSには以前は 2 つのバージョンの CICS が利用可能でしたが、どちらもその後廃止されました。1986 年に IBM はCICS/CMSをリリースしました。[ 18 ] [ 15 ]これは開発用途向けに設計された CICS のシングル ユーザー バージョンで、アプリケーションは後にMVSまたはDOS/VSシステムに移行して本番環境で実行されました。[ 19 ] [ 20 ] その後、1988 年に IBM はCICS/VMをリリースしました。[ 21 ] [ 22 ] CICS/VM は部門での使用を目的としたローエンド メインフレームであるIBM 9370で使用することを意図していました。IBM は、部門または支店のメインフレームで実行される CICS/VM を、MVS 用の CICS を実行する中央メインフレームと連携して使用するように位置付けました。[ 23 ]
CICSシステムおよびアプリケーションのプロビジョニング、管理、分析は、CICSツールによって提供されます。これには、パフォーマンス管理、CICSリソースの展開および管理が含まれます。2015年には、CICS Transaction Server for z/OS 5.3のリリースに伴い、4つのコアとなる基盤CICSツール（およびCICS Optimization Solution Pack for z/OS）が更新されました。4つのコアCICSツールとは、CICS Interdependency Analyzer for z/OS、CICS Deployment Assistant for z/OS、CICS Performance Analyzer for z/OS、およびCICS Configuration Manager for z/OSです。
CICS Transaction Server for z/OS では、以下のリリース番号が使用されています。
複数のユーザーが対話型トランザクションを実行するアプリケーションプログラムは、複数の同時トランザクションスレッドをサポートするために、準再入可能である必要がありました。1つのアプリケーションでソフトウェアのコーディングエラーが発生すると、システムからすべてのユーザーがブロックされる可能性がありました。CICSの再入可能／再利用可能な制御プログラムのモジュール設計により、適切な「枝刈り」を行うことで、高価な32KBの磁気コア物理メモリ（オペレーティングシステムを含む）を搭載したコンピュータ上で、複数のユーザーが複数のアプリケーションを実行できるようになりました。
CICSアプリケーションプログラマーは、トランザクションを可能な限り効率的にするために多大な努力を要した。一般的な手法は、個々のプログラムのサイズを4,096バイト（4K）以下に制限することであった。これにより、CICSは現在使用されていないプログラムが占有しているメモリを、別のプログラムや他のアプリケーションのストレージニーズに容易に再利用することができた。 1972年にOS/360に仮想メモリが追加されると、ページングやスラッシングといった非生産的なリソース競合のオーバーヘッドを削減するために、4K戦略はさらに重要になった。
コンパイルされた高水準言語COBOLおよびPL/Iプログラムの効率性は、多くの点で改善の余地があった。COBOLおよびPL/Iのサポートが利用可能になった後も、多くのCICSアプリケーションプログラムはアセンブリ言語で記述され続けた。
1960年代から1970年代にかけてはハードウェアリソースが高価で不足していたため、システム最適化アナリストの間で競争的な「ゲーム」が生まれました。クリティカルパスコードが特定されると、コードスニペットがアナリスト間でやり取りされました。各アナリストは、（a）必要なコードのバイト数を削減するか、（b）必要なCPUサイクル数を削減する必要がありました。若いアナリストは、経験豊富なメンターのやり方から学びました。最終的に、誰も（a）も（b）もできなくなったとき、そのコードは最適化されたとみなされ、彼らは他のスニペットに移りました。アナリストが1人しかいない小規模な組織では、CICSの最適化を学ぶのは非常に遅かった（あるいは全く学ばなかった）のです。
アプリケーションプログラムは多数の同時実行スレッドで共有される可能性があるため、プログラム内に埋め込まれた静的変数（またはオペレーティングシステムのメモリ）の使用は（慣例によってのみ）制限されていた。
残念ながら、これらの「ルール」の多くは頻繁に破られていました。特に、プログラムの内部構造を理解していなかったり、必要なコンパイル時制限オプションを使用しなかったりするCOBOLプログラマーによって、その傾向が顕著でした。その結果、信頼性の低い「非再入可能」コードが生成され、誤ったストレージ違反やCICSシステム全体のクラッシュを引き起こすことがありました。
当初、パーティション全体、すなわちマルチプル仮想ストレージ（MVS）領域は、CICSカーネルコードを含め、同一のメモリ保護キーで動作していました。プログラムの破損やCICS制御ブロックの破損は、システムダウンタイムの頻繁な原因でした。あるアプリケーションプログラムのソフトウェアエラーによって、現在実行中のアプリケーショントランザクションのメモリ（コードまたはデータ）が上書きされる可能性がありました。複雑な一時的なタイミングエラーの原因となっているアプリケーションコードを特定することは、オペレーティングシステムアナリストにとって非常に困難な問題でした。
これらの欠点は、深刻さにもかかわらず、また、質の高いCICSスキルを持つ人材が不足しているにもかかわらず、20年以上にわたるCICSの複数の新リリースで解消されませんでした。これらの欠点は、TS V3.3、V4.1、V5.2でそれぞれストレージ保護、トランザクション分離、サブスペース機能によって対処されました。これらの機能は、アプリケーションが分離して記述されていなくても、オペレーティングシステムのハードウェア機能を利用して、同じアドレス空間内のアプリケーションコードとデータを保護します。CICSアプリケーションのトランザクションは、多くの公共事業会社、大手銀行、その他の数十億ドル規模の金融機関にとって、依然としてミッションクリティカルなものです。
CICSが最初にリリースされたとき、サポートされていたのはIBM 360アセンブラで記述されたアプリケーション・トランザクション・プログラムのみでした。COBOLとPL /Iのサポートは数年後に追加されました。当初はアセンブラ中心だったため、CICSサービスへの要求はアセンブラ言語のマクロを使用して行われました。たとえば、ファイルからレコードを読み取る要求は、CICSの「ファイル制御プログラム」へのマクロ呼び出しによって行われ、次のようになります。
DFHFC TYPE=READ、DATASET=myfile、TYPE=UPDATE、...など。
これが後に「マクロレベルCICS」という用語を生み出すきっかけとなった。
高水準言語のサポートが追加されると、マクロは保持され、コードはプリコンパイラによって変換され、マクロはCOBOLまたはPL/IのCALL文に相当するものに展開されました。したがって、高水準言語アプリケーションの準備は、実質的に「2段階」のコンパイルとなり、プリプロセッサからの出力が高水準言語コンパイラへの入力として供給されました。
COBOL の考慮事項: PL/I とは異なり、IBM COBOL は通常、ポインタ (アドレス) の操作を提供しません。 COBOL プログラマが CICS 制御ブロックと動的ストレージにアクセスできるようにするために、設計者は実質的にハックに頼りました。 COBOLリンケージ セクションは通常、パラメータの受け渡しなどのプログラム間通信に使用されました。 コンパイラは、呼び出し先のプログラムの開始時に設定される、それぞれがリンケージのベース ロケータ(BLL) と呼ばれるアドレスのリストを生成します。最初の BLL はリンケージ セクションの最初の項目に対応し、以下同様です。 CICS では、リストのアドレスをプログラムの最初の引数として渡すことで、プログラマがこれらにアクセスして操作できます。その後、BLL は、CICS またはアプリケーションによって動的に設定され、リンケージ セクション内の対応する構造にアクセスできるようになります。[ 40 ]
1980年代、IBMのハーズリーパーク工場は、後に「コマンドレベルCICS」として知られるようになるCICSのバージョンを開発した。これは、従来のプログラムも引き続きサポートしつつ、アプリケーションプログラムに新しいAPIスタイルを導入したものであった。
典型的なコマンドレベルの呼び出しは次のようになります。
EXEC CICS SEND MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) END-EXECSEND MAPSET コマンドで指定される値は、MAPSET 引数については以下のマップ定義の最初の DFHMSD マクロで使用されている名前、MAP 引数については DFHMSI マクロで使用されている名前に対応します。これは、コンパイル前のバッチ変換ステージで前処理され、埋め込まれたコマンド (EXEC) がスタブ サブルーチンへの呼び出しステートメントに変換されます。そのため、アプリケーション プログラムの後の実行準備には、依然として 2 つのステージが必要でした。マクロ レベルとコマンド レベルのステートメントの両方を使用して、 「混合モード」アプリケーションを作成することができました。
当初、実行時には、コマンドレベルのコマンドはランタイムトランスレータ「EXECインターフェースプログラム」を使用して従来のマクロレベル呼び出しに変換され、その後、ほとんど変更されていないCICSコアプログラムによって実行されていました。しかし、TS V3向けにCICSカーネルが書き直された際、基盤となるインターフェースの多くが変更されたため、EXEC CICSがCICSアプリケーションをプログラミングする唯一の方法となりました。
1990年代初頭に導入されたコマンドレベル専用のCICSは、以前のバージョンのCICSに比べていくつかの利点がありました。しかし、IBMは以前のバージョン向けに作成されたマクロレベルのアプリケーションプログラムのサポートも終了しました。そのため、多くのアプリケーションプログラムは、コマンドレベルのEXECコマンドのみを使用するように変換または完全に書き直す必要がありました。
この頃には、世界中で何百万ものプログラムが存在し、その多くは数十年にわたって運用されていました。これらのプログラムを書き直すと、必ずしも新機能が追加されるわけではなく、新たなバグが発生することがよくありました。CICS V3への移行後も、長年にわたってマクロコードを実行するために、CICS V2のアプリケーション所有領域（AOR）を使い続けたユーザーが相当数いました。
APT InternationalのCommand CICSなどの変換ソフトウェアを使用して、古いマクロレベルのプログラムを実行することも可能でした。[ 41 ]
最近のCICSトランザクションサーバーの機能強化には、多くの最新プログラミングスタイルへの対応が含まれています。
CICS Transaction Server バージョン 5.6 [ 42 ]では、Java 開発者にクラウドネイティブなエクスペリエンスを提供するために、Java のサポートが強化されました。たとえば、新しい CICS Java API ( JCICSX ) を使用すると、モックやスタブのアプローチを使用してユニット テストが簡単になり、開発者のローカル ワークステーションでリモートで実行できます。Maven Central の CICS アーティファクトセットを使用すると、開発者はApache MavenやGradleなどの一般的な依存関係管理ツールを使用して Java の依存関係を解決できます。Maven ( cics-bundle-maven ) および Gradle ( cics-bundle-gradle )用のプラグインも提供されており、Eclipse、IntelliJ IDEA、Visual Studio Codeなどの使い慣れた IDE を使用して CICS バンドルの自動ビルドを簡素化できます。さらに、バージョン 12 ではNode.js z/OS サポートが強化され、起動の高速化、デフォルトのヒープ制限の改善、V8 JavaScript エンジンの更新などが提供されています。Jakarta EE 8 のサポートも含まれています。
CICS TS 5.5では、IBM SDK for Node.jsのサポートが導入され、完全なJavaScriptランタイム、サーバーサイドAPI、およびライブラリが提供され、IBM Z向けの高性能で拡張性の高いネットワークアプリケーションを効率的に構築できるようになりました。
CICS Transaction Server バージョン 2.1 では Java のサポートが導入されました。CICS Transaction Server バージョン 2.2 では、ソフトウェア開発者ツールキットがサポートされました。CICS は IBM の WebSphere 製品ファミリーと同じランタイム コンテナを提供するため、Java EE アプリケーションは CICS と WebSphere 間で移植可能であり、Java EE アプリケーションの開発と展開のための共通ツールが用意されています。
さらに、CICSは既存のアプリケーションプログラムを最新のインターフェースで「ラップ」することに重点を置いており、長年培われてきた業務機能をより現代的なサービスに組み込めるようにしました。これには、レガシーコードをラップするWSDL、SOAP、JSONインターフェースが含まれており、Webアプリケーションやモバイルアプリケーションは、バックエンド機能を大幅に書き換えることなく、コアとなる業務オブジェクトを取得および更新できます。
CICSトランザクションとは、一連の操作をまとめて実行するものです。通常、トランザクションの大部分は、在庫リストの要求や口座への借方・貸方の入力など、比較的単純なタスクです。トランザクションの重要な特徴は、アトミックであることです。IBM Zサーバーでは、CICSは毎秒数千件のトランザクションを容易に処理できるため、エンタープライズコンピューティングの基盤となっています。
CICSアプリケーションはトランザクションで構成されており、トランザクションはCOBOL、PL/I、C、C++、IBM Basic Assembly Language、Rexx、Javaなど、多数のプログラミング言語で記述できます。
各 CICS プログラムはトランザクション識別子を使用して起動されます。CICS 画面は通常、マップと呼ばれる構造体として送信されます。マップは、Basic Mapping Support (BMS) アセンブラ マクロまたはサードパーティ ツールを使用して作成されたモジュールです。CICS画面には、使用する端末の種類に応じて、強調表示されたり、異なる色で表示されたり、点滅したりするテキストが含まれる場合があります。COBOL を介してマップを送信する方法の例を以下に示します。エンド ユーザーがデータを入力すると、CICS からマップを受信することで、プログラムがそのデータにアクセスできるようになります。
EXEC CICS RECEIVE MAPSET ( 'LOSMATT' ) MAP ( 'LOSATT' ) INTO ( OUR-MAP ) END-EXEC .技術的な理由から、コマンドパラメータによっては、引数を引用符で囲む必要があるものと、囲む必要のないものがあります。これは、参照対象によって異なります。ほとんどのプログラマーは、どの引数を引用符で囲むべきかという概念を理解するまで、参考書を見ながらコーディングするか、あるいは、サンプルコードがコピー＆ペーストされ、値を変更するだけで済むような「テンプレート」を使用します。
基本マッピングサポートは、次のようなアセンブラマクロによって画面フォーマットを定義します。これは、物理マップセット（ CICSロードライブラリ内のロードモジュール）とシンボリックマップセット（ PL/I、COBOL、アセンブラなどの構造定義またはDSECT）の両方を生成するようにアセンブルされ、ソースプログラムにコピーされました。[ 43 ]
LOSMATT DFHMSD TYPE = MAP 、X MODE = INOUT 、X TIOAPFX = YES 、X TERM = 3270 - 2 、X LANG = COBOL 、X MAPATTS = ( COLOR 、HILIGHT ) 、X DSATTS = ( COLOR 、HILIGHT ) 、X STORAGE = AUTO 、X CTRL = ( FREEKB 、FRSET ) * LOSATT DFHMDI SIZE = ( 24 、80 ) 、X LINE = 1 、X COLUMN = 1 * LSSTDII DFHMDF POS = ( 1 、01 ) 、X LENGTH = 04 、X COLOR = BLUE 、X INITIAL = 'MQCM' 、X ATTRB = PROT * DFHMDF POS = ( 24 、01 ) 、X LENGTH = 79 、X COLOR = BLUE X ATTRB = ASKIP 、X INITIAL = 'PF7- 8- 9- 10- X 11 - 12 - CANCEL ' * DFHMSD TYPE = FINAL END
z/OS環境では、CICS インストールは、1 つ以上の z/OS システム イメージにまたがる 1 つ以上の「領域」（一般に「CICS 領域」と呼ばれる）[ 44 ]で構成されます。対話型トランザクションを処理しますが、各 CICS 領域は通常、標準JCLステートメントを使用したバッチ アドレス スペースとして起動されます。これは、シャットダウンされるまで無期限に実行されるジョブです。あるいは、各 CICS 領域は、開始タスクとして起動することもできます。バッチ ジョブか開始タスクかにかかわらず、CICS 領域は、メンテナンス (MVS または CICS) のためにシャットダウンされるまで、数日、数週間、あるいは数か月にわたって実行されることがあります。再起動時には、パラメーターによって、起動が「コールド」(リカバリなし) か「ウォーム」(緊急) (ウォーム シャットダウンを使用するか、クラッシュ後にログから再起動する) かが決定されます。リソースが多い大規模な CICS 領域のコールド スタートでは、すべての定義が再処理されるため、時間がかかる場合があります。
設備が複数のアドレス空間に分割される理由は多岐にわたります。例えば、以下のような理由が挙げられます。
一般的なインストールでは、サービスを構成する複数の独立したアプリケーションが使用されます。各サービスには通常、トランザクションを複数の「アプリケーション所有領域」（AOR）にルーティングする複数の「端末所有領域」（TOR）がありますが、他のトポロジーも可能です。たとえば、AORがファイルI/Oを実行しない場合もあります。その場合、AOR内のトランザクションに代わってファイルI/Oを実行する「ファイル所有領域」（FOR）が存在します。これは、当時VSAMファイルが一度に1つのアドレス空間からの回復可能な書き込みアクセスしかサポートできなかったためです。
しかし、すべての CICS アプリケーションがプライマリ データ ソースとして VSAM (または従来は CA Datacom などの他の単一アドレス空間データ ストア) を使用しているわけではありません。多くのアプリケーションは、データベースとして IMS/DB または Db2 を使用し、キュー マネージャとして MQ を使用しています。これらのすべての場合において、TOR はトランザクションを AOR のセットに負荷分散し、AOR は共有データベース/キューを直接使用します。CICS はデータ ストア間で XA 2 フェーズ コミットをサポートしているため、たとえば MQ、VSAM/RLS、および Db2 にまたがるトランザクションでも ACID 特性を維持できます。
CICSは、同一または異なるクラスタ上で動作するアドレス空間間でSNA LU6.2プロトコルを使用した分散トランザクションをサポートしています。これにより、連携する分散アプリケーションによって複数のデータストアのACID更新が可能になります。しかし実際には、システム障害や通信障害が発生した場合、通信ノードのいずれかが復旧していないとトランザクションの処理（バックアウトまたはコミット）が不確定になる可能性があるため、問題が生じます。そのため、これらの機能はこれまであまり広く利用されていません。
1990年代初頭、CICS ESA V3.2がリリースされた当時、IBMはCICSで新しいz/OS Sysplexメインフレームの性能を最大限に活用する方法という課題に直面していた。
Sysplexは、既存のECL （エミッタ結合ロジック）ハードウェアではなく、CMOS （相補型金属酸化膜シリコン）をベースとする予定でした。メインフレーム固有のECLを拡張するコストは、ソニーのPlayStationなどの大量生産用途を持つ系列企業が各世代のCPUの単価を下げるために開発していたCMOSよりもはるかに高額でした。ECLは、ゲートドレイン電流によって発生する熱量が非常に大きいため、CPUを熱伝導モジュール（TCM [ 45 ]）と呼ばれる特殊なモジュールにパッケージ化する必要があり、不活性ガスピストンを備え、冷却のために大量の冷水を配管する必要があったため、ユーザーにとって運用コストも高額でした。しかし、空冷式のCMOSテクノロジーのCPU速度は、当初はECL（特にメインフレームクローンメーカーのAmdahlとHitachiが提供していたもの）よりもはるかに低速でした。これは、CICSのコンテキストにおいてIBMにとって特に懸念事項でした。なぜなら、最大のメインフレーム顧客のほぼすべてがCICSを実行しており、その多くにとってCICSがメインフレームの主要なワークロードだったからです。
Sysplex で同じ総トランザクション スループットを実現するには、ワークロードごとに複数のマシンを並列で使用する必要がありました。しかし、CICS アドレス空間は、準再入可能なアプリケーション プログラミング モデルのため、MVS サブタスクを使用しても、1 台のマシンで一度に約 1.5 個以上のプロセッサを利用できませんでした。並列処理が強化されないと、顧客は CICS ワークロードをスケールアップする際に Sysplex を使用するよりも IBM の競合他社に移行する傾向がありました。IBM 社内では、アプリケーションの上位互換性を破棄して、完全に再入可能なIMS/DCのようなモデルに移行するのが正しいアプローチなのか、それとも顧客が採用していたアプローチを拡張して、マルチ リージョン オペレーション (MRO) を使用して単一のメインフレームのパワーをより完全に活用するのが正しいアプローチなのかについて、かなりの議論がありました。
最終的に、CICSユーザーコミュニティに意見を求めた結果、2番目の方法が採用された。当時、Y2K問題への対応が懸念されていたため、コミュニティは上位互換性を損なうことに強く反対し、主にCOBOL、PL/I、またはアセンブラコードからなる数百万行ものコードを書き直してテストすることに価値を見出せなかった。
IBMが推奨するSysplex上のCICSの構造は、各Sysplexノードに少なくとも1つのCICS端末所有領域を配置し、トランザクションをSysplex全体に分散された多数のアプリケーション所有領域（AOR）にディスパッチするというものでした。これらのアプリケーションが共有リソースにアクセスする必要がある場合は、Sysplexを活用するデータストア（IBM Db2やIMS/DBなど）を使用するか、機能シッピングによってリソース要求をリソースごとに1つのリソース所有領域（ROR）に集中させました。RORには、VSAMおよびCICSデータ表用のファイル所有領域（FOR）、 MQ 、CICS一時データ（TD）、CICS一時ストレージ（TS）用のキュー所有領域（QOR）が含まれます。この構造は、多くのCICS領域を構成および管理する運用上の複雑さを犠牲にして、レガシーアプリケーションとの互換性を維持しました。
その後のリリースとバージョンでは、CICS は VSAM/RLS [ 46 ] 、 zOS 用 MQ [ 47 ]の新しい Sysplex 活用機能を利用することができ、独自のデータ テーブル、TD、および TS リソースを Sysplex 用に設計された共有リソース マネージャであるカップリング ファシリティ(CF) に配置し、ほとんどの ROR の必要性を排除しました。CF は、共有タイムベース、バッファ プール、ロック、カウンタなどのリソースのマッピング ビューを提供し、ハードウェア メッセージング アシストにより、Sysplex 全体でリソースを共有することがポーリングよりも効率的で信頼性が高くなりました (障害発生時に使用する半同期バックアップ CF を使用)。
この頃には、CMOS製品ラインには、CPUあたりのプロセッサ数を増やし、最速のECL製品よりも高い処理能力を持つ個々の製品が存在していた。これらを組み合わせると、32ノード以上で単一のワークロードに対して2桁も高い処理能力を実現できた。例えば、2002年までに、チャールズ・シュワブ社はアリゾナ州フェニックスの2か所に冗長構成のメインフレームSysplexを2台設置し、それぞれ32ノードで1つの共有CICS/DB/2ワークロードを駆動する「MetroPlex」を運用し、ドットコムバブル以前の膨大な量のWebクライアントからの問い合わせに対応していた。
低コストと拡張性の向上を特徴とするCMOSベースのテクノロジーへの移行は、IBMメインフレームシステムの競争環境を根本的に変えました。この技術的移行は、市場の縮小と独自の64ビットアーキテクチャを複製するために必要な多額の設備投資によってさらに悪化し、参入障壁を非常に高くしました。その結果、IBM互換メインフレームシステムの独立系メーカーは徐々に市場から撤退せざるを得なくなりました。[ 48 ] [ 49 ]
CICS のリカバリ/再起動の目的は、障害発生時にオンライン システムへの損害を最小限に抑え、可能であれば完全に排除し、システムとデータの整合性を維持することです。[ 50 ] CICS 領域が障害ではなくシャットダウンされた場合、シャットダウン時に書き込まれたチェックポイントを利用して「ウォーム」スタートが実行されます。CICS 領域は「コールド」スタートを強制することもできます。コールドスタートでは、すべての定義が再ロードされ、ログが消去され、リソースは現在の状態のままになります。
CICSでは、以下のようなリソースがリカバリ可能とみなされます。これらのリソースをリカバリ可能にするには、関連するCICS定義で特別なオプションを指定する必要があります。
CICSは、ユーザーがCICSシステム内で独自のリカバリ/再起動機能を確立できるように、広範なリカバリ/再起動機能も提供しています。一般的に使用されるリカバリ/再起動機能には、以下のようなものがあります。
各CICS領域は、すべてのトランザクションが実行される1つの主要タスクで構成されますが、IBM Db2データへのアクセスなどの特定のサービスは、別のタスク（TCB）を使用します。領域内では、トランザクションは協調的にマルチタスク化されます。つまり、トランザクションは適切に動作し、待機するのではなくCPUを解放することが求められます。CICSサービスはこれを自動的に処理します。
それぞれの固有の CICS「タスク」またはトランザクションには、起動時に独自の動的メモリが割り当てられ、その後の追加メモリ要求は、「ストレージ制御プログラム」（CICS の核または「カーネル」の一部）への呼び出しによって処理されました。これはオペレーティングシステムに類似しています。
CICSシステムは、オンライン核、バッチサポートプログラム、およびアプリケーションサービスで構成されています。[ 51 ]
オリジナルのCICSの中核は、V3までは370アセンブラで記述された多数の機能モジュールで構成されていた。
V3以降、CICSの中核部分はIBMのPL/AS言語（アセンブラにコンパイルされる）を用いてカーネルとドメインの構造に書き換えられた。
以前の構造では関心の分離が強制されていなかったため、プログラム間の依存関係が多く、徹底的なコード分析を行わない限りバグが発生していました。新しい構造はモジュール化が進み、影響なく変更が容易になったため、非常に堅牢になりました。最初のドメインは、以前のプログラム名から末尾の「P」を除いた名前で構築されることがよくありました。たとえば、プログラム制御ドメイン (DFHPC) や一時データドメイン (DFHTD) などです。カーネルはドメイン間要求のスイッチャーとして動作しました。当初、これは頻繁に呼び出されるドメイン (Trace など) ではコストがかかることが判明しましたが、PL/AS マクロを利用することで、ドメイン分離設計を損なうことなくこれらの呼び出しをインライン化しました。
後のバージョンでは、ジャーナル制御プログラム（JCP）に代わる、ログ記録ドメインDFHLGやトランザクションドメインDFHTMなど、完全に再設計されたドメインが追加されました。
CICSにはオンライン機能に加えて、バッチジョブとして実行されるサポートプログラムがいくつかある。[ 52 ]： pp.34–35
CICSの以下のコンポーネントはアプリケーション開発をサポートします。[ 52 ]： pp.35–37
EXEC CICS国によって発音が異なる[ 53 ]
DDM は IBM から提供されなくなり、2003 年 12 月 31 日をもってサポートが終了しました。CICS DDM は、バージョン 5.2 以降の CICS TS では利用できなくなりました。
TS for VSE/ESA V1.1.1 では、CICS Distributed Data Management (DDM) のサポートが安定化されています。IBM は、将来の CICS TS for z/VSE リリースで、CICS DDM のサポートを終了する予定です。
CICS Distributed Data Management (CICS/DDM) は、CICS TS for z/VSE V2.1 ではサポートされていません。
パーソナルコンピュータXT/370ファミリー
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)