お手軽バッチ・パフォーマンス改善 – III

By kamii - Last updated: 日曜日, 7月 25, 2010

データセットのI/O効率を上げる(続き)

Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – II

By kamii - Last updated: 日曜日, 7月 25, 2010

データセットのI/O効率を上げる

アプリケーションのバッチ処理では、ファイル(データセット、データベース)に一切アクセスしないものは少ないです。たいていのプログラムはファイルからデータを読み取り、集計や帳票の作成など何らかの業務的な加工処理を行います。またデータを変換して別のファイルに新たなデータとして書き出したり、既存のデータを更新したりします。そのような処理では必ずI/Oを伴いますから、I/O効率を上げることはパフォーマンスの改善に大きく寄与します。ここではI/O効率を見直す中で比較的アプローチしやすいもので考えてみます。

z/OSのDFSMSのマニュアルに、次のような解説があります。
「入出力パフォーマンスは、データを仮想記憶域へと、または仮想記憶域から転送するために必要なプロセッサー時間とチャネル始動/停止時間の両方を削減することによって改善されます。パフォーマンスに影響を及ぼすいくつかの要因を以下に示します。」

最初のアドレス・スペース・タイプについては考える必要はありません。ずいぶんと昔は高いパフォーマンスでジョブを動かすためにJCLのEXEC文にADDRSPC=REALという指定をしたものもあったようですが(V=Rジョブ)、もはや使われてはいないでしょう。V=Rはジョブのメモリーを実記憶に固定します。筆者は自分で使ったことがないので想像ですが、ページング・オーバーヘッドをなくしたり、特別な理由でページングされると困るようなプログラム、I/Oを直接発行するようなプログラムで処理効率を上げるため仮想アドレスと実アドレスが同じであることを前提にしたいプログラムなどのために使われたのだと考えます。
2番目と3番目のブロックサイズとBUFNOは簡単な知識と手間で、意外と効果を得られたりします。4番目のBSAMは今ではアプリケーションプログラムではほとんど使われないため考えなくていいでしょう。COBOLなどのコンパイラーも基本的にはQSAMを使用していると思ってます。
5番目のアクティビティーは、CPUとチャネルが他のジョブで使われていればその間は待たされる、ということです。6番目はデバイスの種類によってI/Oパフォーマンスは変わることを示しています。テープよりはディスク、同じディスクでもモデルによって変わります。またOSからは同じモデルに見えても、ハードウェアとしてのグレードによってもI/Oパフォーマンスは変わります。
残りの2つはz/OSならではのもので、拡張フォーマットやストライピングをサポートした新しいタイプの順次データセットや拡張区分データセットではアクセス効率もよくなっていますが、業務用のデータセットやライブラリーをそれらに移行することになるので、計画的に行う必要があります。規模が大きいと簡単には行かないでしょう。

Filed in オペレーション・運用

お手軽バッチ・パフォーマンス改善 – I

By kamii - Last updated: 日曜日, 7月 25, 2010

パフォーマンス・チューニングというと、とかくRMFレポートと格闘してPARMLIBのIPSやICSのパラメーターをいじる(z/OSではWLMのワークロードやサービスクラスの設定)というイメージがあります。
より細かい現状分析にはRMF(MSPではPDA)レポートなどを見ることは避けられませんが、ここではそんな高度(面倒)なことではなく、もっと身近なもので比較的お手軽にできるパフォーマンス・アップを考えてみます。

いろいろなアプローチがありますが、大きく分けるとCPU使用量を減らすかI/O効率を上げるかになります。
その他にも「待ち」を減らす、というのもあります。ジョブの多重度が上がるほど「待ち」はELAP時間(実行時間)に大きく影響します。CPUを10秒使う、I/Oを100000回行う、といった同じ処理を実行しても、そのジョブしか動かない場合ではELAP時間は30秒なのに、他に別の10ジョブが並行して動いているような場合では2分掛かる、という具合です。このような待ち時間の大小によるパフォーマンスのぶれを調整し、適切なリソース配分やプライオリティ調整をすることもチューニングの大切な作業です。しかしそれはこのトピックの目的とずれてしまうので機会を改めることとし、ここでは採り上げません。このトピックでは個々のジョブ・ステップ単独での効率アップについて見てみます。


アプリケーションプログラム自身が使うCPU使用量を減らす

CPUについてはプログラム論理の見直しで使用量を削減するのは、元がよほどひどいプログラムでない限りあまり大きな期待はできません。そういう箇所を見つける苦労の割りには効果が薄いです。現実的にはコンパイラーのオプション(OPTIMIZE)によって最適化されたコードを生成する、という感じでしょうか。最適化は実行コードとストレージ量の2つの観点によって行われます。
またコンパイラーで注意すべきことの1つとしてデバッグオプションの付けっぱなしがあります。何らかの理由で後から1本だけ直してテストしたものが、誤ってデバッグオプションが付いたまま運用されてしまったようなケースです。本来なら不要な命令を常に実行し続けることになります。何かあったときに調べられないと困るから、デバッグオプションははずせないという考え方もありますが、基本的には本番の運用では不要でしょう。

その他にもタイミングを取るためにループで待ち合わせるプログラムなどがあると極端なCPUを使うことがあります。普段は通らないが何らかのケースの状態が起きるとタイミングを取る必要が生じて、それをループで行っているようなプログラムがあるとそこでCPUが極端に使われます。常に通るところでループしていれば簡単にわかりますが、月に数回とかたまにとかの頻度でしかループによる待ち合わせロジックを通ることがなく、しかもループ時間もそう長くない、という場合はみつけにくいです。
一般的にメインフレームのプログラムではアプリケーション側がループで待ち合わせるような作り方はしないのですが、COBOLなどにはタイマー待ち合わせ(SLEEP)などの機能がないので、ループの中で現時刻を得て一定時間が過ぎたかをチェックしてループから抜けたり、データセットの特定のレコードを何度も読み出してその内容が変わっていたら待ち合わせ終了にするなどのロジックが作られることもあります。このようなケースではプログラムの修正が必要なので、お手軽チューニングの範疇を超えますが、実際にそういうこともあり得るのだと知っておくといいでしょう。


Filed in オペレーション・運用

ENQ/DEQ

By kamii - Last updated: 土曜日, 6月 26, 2010

ENQ/DEQ:プログラムが排他制御に使うAPIサービスのこと

OSの重要な機能のひとつに「資源の逐次化」があります。排他制御とも呼ばれ、メモリーやデータセットなど複数のプログラムで取り合いになるリソースを順番に使わせるものです。複数のプログラムを同時に動かすマルチ・タスキングをサポートするOSには欠かせないものです。

MVSでは一般のアプリケーション・プログラムが排他制御を行うAPIサービスとしてENQ/DEQというアセンブラー言語用マクロ命令を用意しています。ENQが排他制御のために資源を使う権利を得るもので、DEQは逆にその権利を解放します。

次のプログラムは、複数のタスクでメモリー内の共用領域を更新する場合のENQ/DEQを使用した排他制御の例です。

         :
         ENQ   (RESQNAME,RESRNAM1,E,L'RESRNAM1,STEP),RET=USE
         LTR   15,15
         BNZ   SHORT_WAIT   排他制御に失敗したらSHORT_WAITへ飛ぶ
         :
         :
         テーブル内データの更新処理を行う
         :
         :
         DEQ   (RESQNAME,RESRNAM1,L'RESRNAM1,STEP),RET=HAVE
         :


         :
RESQNAME DC    CL8'SHRTABLE'
RESRNAM1 DC    CL32'USER-ACCOUNT-TABLE'
         :

ENQ/DEQでは排他制御の対象になる資源は、あらかじめ決められているわけではなく、サービスの利用者が自由に設定できます。プログラム内のメモリー領域でもいいし、データセット、ファイル内のレコードなど何でもかまいません。ただデータセット全体やデータベース内のレコードなどは、プログラムが自分で直接排他制御するよりは、DD文のDISPパラメーターやデータベースが提供する排他制御の機能を使うことが一般的です。
このサンプルでは、競合してアクセスするテーブル領域に名前を付けて排他制御の資源名にしています。資源名はQ名とR名に分かれ2階層で分類できるようになっています。ENQマクロでは、資源の名前(Q名とR名)、排他の方法(占有/共用)、排他の範囲を指定して排他制御を要求します。
排他の範囲はSCOPEと呼ばれ、ENQマクロではSTEP(同一空間内)、SYSTEM(同一OS内の複数空間)、SYSTEMS(複数OSにまたがる複数空間)が指定できます。

ENQで獲得した排他制御は、資源を使い終わったらすみやかにDEQによって解放しなければなりません。どの資源にどのような名前を付け、どのタイミングで排他制御を行うかはすべてアプリケーション・プログラムのデザインとして決め、決められたとおりにプログラミングしなければなりません。MVSは排他制御のためのメカニズムは提供しますが、アプリケーションが正しい排他制御をしているかまではチェックできません。仮に排他制御が必要なメモリー領域をENQせずにアクセスしてもCPUはそのまま命令を実行してしまいます。あくまでも、決められたルールは決められた通りに守っている、ことが前提のしくみであることを知っておく必要があります。

ENQ/DEQを使うためには最低でもプログラムはアセンブラー言語で作成される必要があります。あるいはアセンブラー言語で排他制御用サブルーチンを作成し、それを呼び出すかです。COBOLなどで作成されたアプリケーションでは、プログラムが資源を直接排他制御することは少なく、アクセスメソッドやデータベース、TPモニターの排他制御機能によって間接的に排他制御を行うのが一般的です。


ENQ/DEQの他、MVSにはOS自身などの制御プログラムが使う「ロック」という排他制御サービスもあります。こちらはENQ/DEQのように任意の資源を指定できず、OSがあらかじめ定めたごく少ない種類の資源のみ排他制御できますが、ENQ/DEQよりはるかに少ないオーバーヘッドで処理できます。また制御プログラムではハードウェアの機能によってメモリー内のフィールドをCPU命令によってロックする方法も使われます。

Filed in キーワードから(何が知りたいですか)

正しい構文?のPARMLIBメンバーなのにIPLエラーになる?

By kamii - Last updated: 水曜日, 6月 23, 2010

MVSの動き方を決める重要なシステム設定パラメーターとして、PARMLIBメンバーがあります。元々はSYS1.PARMLIBという名称の区分データセットが使われていました。現在ではインストール時のカスタマイズによって異なるDSNにしたり、PARMLIBライブラリーを複数のデータセットに分散することもできます。

ずいぶん以前のMVSでは、PARMLIBメンバーにエラーがあるだけでもIPLが止まってしまうため、パラメーター・メンバーの修正にはずいぶんと気を使ったものです。運用で使用しているメンバーを直接直さずに代替のメンバーを作り、そちらを修正する。あるいは現行のメンバー内容をコピーした代替メンバーを作っておき、もしIPLに失敗したら、代替メンバーのパラメーターでIPLし直す、などはよく行われました。これらはIPLができないとOSが起動しないのでエラーを起こしてしまったメンバーを直したり元に戻したりすることができないからでもありました。
しかしOS/390、z/OSとなった現在のMVSでは、PARMLIBメンバーのパラメーター定義や値に誤りなどがあってもよほどのものでない限り、エラーは無視され(警告はされる)IPLが途中で止まるようなことはなくなりました。

そんな中で「これのどこがエラー?」と見えてしまいそうなものをひとつ。

コメントの終わり位置が悪いためエラーとなる

NJEのテストをするためOS内にテスト用の代替JES2を追加した

落ち着いて見ればわかりますが、このような一見すると正しく見え、どこがおかしい?という類のものはなかなか原因を見つけられないというもののひとつでもあります。そうでなくてもIPLでエラーが出たりすると、(自分が直したのが原因であることが明白で)あせりが先に立ってしまったりするものです。

Filed in オペレーション・運用

SYSLOG

By kamii - Last updated: 金曜日, 6月 18, 2010

SYSLOG:System LOG、システム・ログ

システム・ログは、MVS上でのシステムの活動状況や、すべてのジョブからのコンソール・メッセージなどが時系列に記録される、JES2スプール内のSYSOUTデータセットでシスログ(SYSLOG)と呼ばれます。
コンソールに出力される様々なメッセージのうち、センターによって不要と扱われるメッセージなどはコンソールへの出力が抑止されるようなカスタマイズも行われていますが、システム・ログにはすべて記録されます。マスター・スケジューラーは、JES2と連係してシスログを処理します。

システム・ログには、MVS上でのシステムの活動状況が時系列に記録されているため、障害発生時の重要な問題識別の資料となります。特に、他のジョブからの要求を受けてサービスを提供するサーバー・プログラムや、他のジョブやサブシステム等にサービスを要求したり連係して動作したりするようなプログラムでは、障害となったジョブ以外のジョブやOSから関連するメッセージなどが出されている場合もあります。すべてのジョブからのメッセージが記録されているシステム・ログは有効な調査用資料となります。


システム・ログの出力

SYSLOGは、OSコマンドW(WRITELOG)によって出力することができます。

「W L」と入力すれば、IPL以降または前回のWRITELOGコマンド投入からその時点までのSYSLOGを、LクラスのSYSOUTとして印刷またはライター出力することができます。クラスを省略すれば、センターで指定したデフォルト・クラスが使われます。SYSLOGを保管する場合は、XWTRで、DASDあるいはTAPEに順データセットとしてコピーすることができます。


システム・ログの参照

SDSFには、SYSLOGの参照機能(LOG)があります(管理者またはオペレーター権限が必要)。これを利用すれば、WRITELOGコマンドを使わなくても、スプール内のSYSLOGデータセットを直接参照できます。ジョブ出力のSYSOUTと同様に、特定の文字列を検索したり、内容をデータセットにコピーしたりできます。
MSPではECS、VOS3ではSYSLOG2を利用すれば、SYSLOGを参照できます。

MVSではPTコマンドをによってSYSLOGを簡単な操作で任意のデータセットにコピーすることができます。コピーする範囲を「開始時刻 開始日付 終了時刻 終了日付」で指定することもできます。


システム・ログのフォーマット(MVS)


システム・ログのフォーマット(MSP,VOS3)

Filed in キーワードから(何が知りたいですか)

KBKARCS

By kamii - Last updated: 木曜日, 6月 17, 2010

ARCS(ARChives Service program):富士通OSにおけるDASDボリューム・ユーティリティー

ARCSは富士通のメインフレーム用ソフトウェアで、DASDボリューム上のデータの退避、復元、複写、移行を行うユーティリティーです。KBKARCSはそのプログラム名です。マニュアル「ARCS使用手引書」に詳細が記載されています。MSPおよびXSPで利用できます。

Filed in キーワードから(何が知りたいですか)

IEHLIST

By kamii - Last updated: 木曜日, 6月 17, 2010

IEHLIST:DASDボリューム、区分データセットのリスティング・ユーティリティー

IEHLISTは(z/OS)における、DASDボリュームまたは区分データセット・ディレクトリーのリスティングを行うユーティリティー・プログラムの名前です。MSPではJSGLIST、VOS3ではJSFLISTとして提供されています。プログラム名は異なるものの、JCLもSYSIN制御ステートメントも含め、基本的に互換ユーティリティーです。

DASDボリュームのVTOCや区分データセットのディレクトリーのリストアップを行うことはよくあります。ボリューム内にどのようなデータセットがあるのか?、データセット内にどのようなメンバーがあるのか?を調べることは運用や開発の現場でしばしば起こります。

ユーティリティーの実行サンプルはこちらをご覧下さい。

IEHLISTは古くからあるユーティリティーで、基本ユーティリティーの1つでもありますが、リストの見やすさという点では今ひとつです。z/OSであれば、VTOCやディレクトリーの各フィールドを詳細に見る必要がないのであれば、VTOCリストやメンバーリストなどはISPFをバッチで呼び出す方がより見やすいリストを得ることができます。

//         JOB (acct),name,CLASS=A,MSGCLASS=B,REGION=4M
//*********************************************************************
//*        ISPF BACTH SESSION SAMPLE JCL
//*********************************************************************
//ISPBATCH PROC
//BLDCLST  EXEC PGM=IEBGENER
//SYSPRINT DD DUMMY
//SYSUT2   DD DISP=(,PASS),DSN=&&CLIST(ISPFCMD),
//            UNIT=VIO,SPACE=(TRK,(1,1,1)),
//            DCB=(RECFM=FB,BLKSIZE=0,LRECL=80)
//SYSIN    DD DUMMY
//*
//ISPFRUN  EXEC PGM=IKJEFT01,DYNAMNBR=256
//SYSPROC  DD DISP=(OLD,DELETE),DSN=&&CLIST
//ISPPROF  DD UNIT=SYSDA,SPACE=(TRK,(15,1,10)),
//            DCB=(RECFM=FB,BLKSIZE=6160,LRECL=80)
//ISPLLIB  DD DISP=SHR,DSN=ISP.SISPLOAD
//ISPPLIB  DD DISP=SHR,DSN=ISP.SISPPENU
//ISPMLIB  DD DISP=SHR,DSN=ISP.SISPMENU
//ISPTLIB  DD DISP=SHR,DSN=ISP.SISPTENU
//ISPSLIB  DD DISP=SHR,DSN=ISP.SISPSLIB
//         DD DISP=SHR,DSN=ISP.SISPSENU
//SYSTSPRT DD SYSOUT=*
//*
//PRTLIST  EXEC PGM=IEBGENER,COND=(0,NE,ISPFRUN)
//SYSPRINT DD DUMMY
//SYSUT1   DD DISP=(OLD,DELETE),DSN=ISPFJOB.&SYSUID..SPF1.LIST
//ISPLOG   DD DISP=(OLD,DELETE),DSN=ISPFJOB.&SYSUID..SPFLOG1.LIST
//SYSUT2   DD SYSOUT=*
//SYSIN    DD DUMMY
//         PEND
//*********************************************************************
//IEFPROC  EXEC ISPBATCH
//BLDCLST.SYSUT1 DD *,DLM='++'
/* CLIST FOR ISPF BATCH SESSION */
/* PRINT VTOC LIST */    代わりにLEVEL(UAP1)とDS名レベルを指定してもよい
ISPEXEC LMDINIT LISTID(LID)  VOLUME(WRKVOL)
ISPEXEC LMDLIST LISTID(&LID) OPTION(SAVE) STATS(YES)
ISPEXEC LMDFREE LISTID(&LID)
END
//ISPFRUN.SYSTSIN DD *
  PROFILE PREFIX(ISPFJOB)           /* AVOID ISPF-LOG ENQ CONTENTION */
  ISPSTART CMD(%ISPFCMD)            /* ISPF EXECUTION COMMANDS CLIST */
//
//

ISPFのLMサービスによるVTOCリストの出力サンプルです。LMサービスでの出力であれば、PDFの3.4ユーティリティーに近い形のリスト出力を得ることができます。
PDSのメンバーリストであれば次のようなCLISTをBLDCLST.SYSUT1 DD文に記述すればで出力できます。

//BLDCLST.SYSUT1 DD *,DLM='++'
/* PRINT PDS MEMBER LIST */
ISPEXEC LMINIT  DATAID(DDVAR) DATASET('USR1.LINKLIB') ENQ(SHR)
ISPEXEC LMPRINT DATAID(&DDVAR) INDEX
END

ISPFバッチはこちらにものサンプルがあります。

Filed in キーワードから(何が知りたいですか)

RACFユーザー登録

By kamii - Last updated: 木曜日, 6月 17, 2010

RACFに新しいユーザーを登録するには、RACFコマンドを使用します。RACFコマンドはTSOにて発行でき、バッチセッションでも使用できます。

RACFに新しいユーザーを登録する

RACFに一般リソースとしてTSOアカウント名とログオン・プロシージャー名を登録する



RACFに新しいユーザーを登録するが、TSOアカウントはACCOUNTコマンドで登録する

当然ながらADDUSERやACCOUNTコマンドは権限のあるユーザーでなければ使用できません。

Filed in ありがたいサンプルJCL

CICS概説

By takao - Last updated: 火曜日, 6月 15, 2010

トランザクション処理

CICSとは、Customer Information Control Systemの略で、IBMのソフトウェアプロダクトとして売られています。
もともとは、ガス会社が「顧客管理」のために作ったオンラインコントロールプログラムでした。なぜ、「オンラインコントロール」が必要なのでしょうか?
まず、オンライン処理、すなわちトランザクション処理の考え方について説明しておきます。
端末から最初にメッセージが送られてきます。汎用機前提の話しですから、いろいろ考えられます。「売上げを見たい」「人事管理」「お客ごとの状況を見たい」さまざまあるでしょう。このメッセージについて、どこから来たメッセージか(誰からか)?どのプログラムで処理をすればいいのか?が自動的に決定され、予定されているプログラムで処理をし、出力メッセージを端末に向かって返したらトランザクション処理はひとつ完了です。
ウェブアプリケーションに例えると、URLに相当するものはあらかじめサーバーでもっており、さらにウェブサーバーとTCP/IPとCGIが行う処理をひとまとめで面倒をみていることになります。
そのかわり、あらかじめ個々の端末の属性を事前定義してありますから、ディスプレイ、プリンターといった装置に応じた処理が可能です。

CICSはIBMのイギリス ハーズレー研究所で開発されており、オンライン処理における先進的な取り組みを続けました。後に説明するプログラムコントロールの簡便さと相まって、多くのオンラインシステムのインフラとして使われています。

CICSとアプリケーションプログラム

CICSは EXEC CICSで始まる呼び出し(API)で処理が始まります。サポートしているプログラム言語はCOBOL,C,C++,Java,PL/I, RPG,にS/390アセンブラーさらに、High Performance Java(HPJ)と多彩です。
とはいえ、CICSで使われているプログラム言語は、IBM COBOL, Merant(旧MicroFocus) COBOLが圧倒的に多いと思われます。

CICSはIMSとは異なり、すべてのアプリケーションとCICSサービスは「問題プログラム」状態で、ひとつの仮想空間で稼働します。(MROについては触れません)つまりコントローラ自身も同じアドレス空間で動いています。このアーキテクチャはパフォーマンスの面では優れているのですが、怪しい挙動のアプリケーションにはかなり無防備です。IMSとの比較でよくいわれることです。

CICS構成要素

CICSは、ターミナルコントロール、タスクコントロール、プログラムコントロール、ストレージコントロールとファイルコントロールから構成されています。
各々、図のようにTCT,PCT,PPT,FCTというコントロールテーブルをもっています。COMMAREAはセッションの間存在するデータ用のサービスです。あるトランザクションの状況を次のトランザクションに伝えることができます。また、I/O処理にも使われます。


次に各コントロール機能について概略を説明します。

ターミナルコントロール

CICSはもともと、SNAベースで作られました。すべてのメッセージの送受信はVTAM経由です。メッセージが送られてくると、Terminal Control Table(TCT)内のターミナルIDを見て、どのターミナルとのやりとりかを認識します。
エンドユーザーがログインし、トランザクションコードによりトランザクションを要求すると、まずCICSはターミナルの状況をチェックします。チェック内容としては、該当トランザクションを受け付けていいターミナルなのか、正しいユーザー権限があるかといったことです。
CICSはメッセージの最初の4文字をトランザクションID(TRID)と見なします。この情報はCICSタスクコントロールに渡され必要に応じ、要求を処理する、新しいタスクが作られます。

タスクコントロール

タスクコントロールはCICSタスクの状況を管理しています。タスクは一見、並行して稼働しますが、プロセス時間と割り当ての優先度をコントロールしなければなりません。例えば、新規のトランザクション受付けより先に、トランザクションログ処理は優先します。CICSは独自の内部マルチタスクにより、トランザクション処理をするアプリケーションをコントロールします。
タスクコントロールは、トランザクションを処理するタスクを生成します。CICSタスク下で稼働するプログラムのすべての情報はあらかじめCICS Program Control Table(PCT)に登録されていなければなりません。PCTはCICSタスクのひとつのエントリーです。
タスクコントロールはPCT内のTRIDを見つけます。次にCICSストレージコントロールにタスクに関連したコントロールブロックの作成の依頼をし、プログラムコントロールにアプリケーションプログラムのロードを依頼します。

プログラムコントロール

Cプログラムコントロールはアプリケーションプログラムのロードと削除を担当します。トランザクション処理がタスクとしてスタートすると、プログラムコントロールはアプロケーションプログラムに関連したタスクに制御権を渡します。
多くのタスクが同じアプリケーションプログラムを使うことがあります。プログラムコントロールはメモリーにはひとつのプログラムしか置きません。それぞれのタスクは別々に存在します。そうやって多くのユーザーがひとつの物理的アプリケーションプログラムのコピーを並行して共有して使うことができます。

ストレージコントロール

OS/390などの環境下では、CICSは仮想記憶領域内を完全にコントロールします。ストレージコントロールは、仮想記憶域の獲得、コントロール、開放を担当します。この仮想記憶域はCICS自身がロードされている空間です。
管理されている仮想領域は、プログラム、I/Oエリア、ワーク用スペースなどなどに使われます。
ストレージコントロールはストレージをプールとして管理しています。要求ごとに、CICSアプリケーションやCICSの中核のサービスにストレージリソースを割り当てたり開放したりします。

CICS COMMAREAは特別な保管域です。これはトランザクションをまたがって、データが受渡される機能です。COMMAREAは仮想的な会話として別プログラムにデータを渡せます。
データはCICS RETURNコマンドが出されると保管されます。同じターミナルから入力メッセージがやってくると、関連づけられたCOMMAREAとTRIDにコントロールが渡されます。

さらに、トランザクションのタイプ(COMMAREAインターフェーストランザクション)によってはこのインプットもアウトプットもCOMMAREAにできます。このようなトランザクションは、RPCのような使い方がされます。この場合、トランザクション内に端末にデータを表現する、プレゼンテーションコードはありません。

ファイルコントロール

ファイルコントロールはディスクファイルの共有が可能となっています。すべてのファイルコントロールに関係するデータブロックおよびバッファーはCICS File Control Table(FCT)内にあります。FCTはCICSに関連づけられたファイルごとにエントリーができます。これは複数のトランザクションによる複数のREADやUPDATE処理を矛盾を起こさずに処理できます。CICSは同時に同じレコードを二人のユーザーがアップデートすることがないように管理しています。
ファイルコントロールはファイルやデータベースの整合性も管理します。リカバリーリスタートは特別なジャーナルファイルとディスクを前提としたリカバリーデータによりなされ、トランザクションのACID属性を保証しています。これは2フェーズコミット方式で行わrます。DBMSもやはり2フェーズコミットをサポートしますから、CICS RecoveryRestartの際にデータは保護されます。

タイマーサービス

タイマーサービスはアプリケーションが時間に依存したコントロールをする機能を提供します。例えば、特定のトランザクションを特定の時間に起動したり、特定の時間が来たら通知する、といったことです)

トランザクション処理用端末

GUIはターミナルの力によります。327xのようなキャラクターベースのターミナルはCUI(Character oriented User Interface)といいますが、基本的に24行、80+アルファ文字から構成されます。

ホストコンピュータ内でターミナルスクリーンイメージをアプリケーションプログラムは生成します。
スクリーンイメージは特定の場所をフィールドとして解釈したほうが簡単です。CICSのユーティリティでBMS(Basic Mapping Support)でスクリーンイメージを生成できます。

01 +ACCOUNT FILE: +RECORD DISPLAY
02
03 +ACCOUNT NO:+_________ +LASTNAME: +________________________|
04 +FIRSTNAME:+________________________+? MI:+_+ TITLE:+_____|
05 +PHONE:+______________ +ADDRESS: +___________________________________|
06 +___________________________________|
07 +___________________________________|
08? +INFO: +_____________________________________________________________________|
09
10? +HISTORY: BALANCE PLAN AMOUNT PAID AMOUNT
11 +________ __/__/_____ _____________ __/__/_____ _____________
12 +________ __/__/_____ _____________ __/__/_____ _____________
13 +________ __/__/_____ _____________ __/__/_____ _____________
14 +________ __/__/_____ _____________ __/__/_____ _____________
15 +________ __/__/_____ _____________ __/__/_____ _____________
16 +________ __/__/_____ _____________ __/__/_____ _____________
17 +________ __/__/_____ _____________ __/__/_____ _____________
18 +________ __/__/_____ _____________ __/__/_____ _____________
19
20
21
22 +_______________________________________________________________________________

PCの3270エミュレータは、3278,3270,3178といったメジャーなターミナルをサポートしていますし、GUIでさらに使い勝手をよくすることが可能です。

ネットワーク

CICSはSNAを基本としています。3270データストリームはレイヤー5に相当するプロトコルです。基本的に文字を送るものなので、今から見るとかなり狭い帯域でも問題はありません。
Filed in メインフレーム・ソフトウェア