「メインフレーム・コンピューター」で遊ぼうこんな時代に今さらメインフレーム・コンピューターに取り組むハメになったみんなが助けあうサイトです。RSSWordPress.orgコスパのいい社内システムの作り方メインフレームを扱っていると、軽い開発やメンテナンスにリソースを割けない、しかし、BPCも考えねば。解決策のひとつがクラウドにおくFileMakerです。次のような手順でBSAMによりPDSのメンバーディレクトリを読み格納されているメンバー名を調べてから、その後でBPAMにより個々のメンバーの処理を行うようなプログラムを作る際の注意点。DYNALLOCDIRを読むためにBSAMでOPEN(RECFM=F,KEYLEN=8,BLKSZ=256)DIRをCLOSE今度はBPAMでOPEN※3と4の間にUN-ALLOCとRE-ALLOCを入れないと、4のOPEN時にJFCBに残っているKEYLENがセットされてしまう。このためBPAMのREADでレングスエラーが起きてしまう。各ディレクトリ・ブロックの最終メンバーを示すキー部が不要ならQSAMでもディレクトリ・ブロックはアクセスできる。QSAMならキーは処理しないのでJFCBにKEYLENは入らない。(僕は使ったことがないが)今のMVSのDFSMSにはDESERVマクロがあるからBSAMやQSAMでディレクトリ部を読む必要はなく、DFPのサービスでメンバーリストが作れる。MSPではGETDTRYマクロが使えるから最初からBPAMでOPENしておけばよい。VOS3ではディレクトリ読み取りのサービスはないのでディレクトリ部をPSデータセットとしてアクセスしなければならない。22:19はじめまして。現在、メインフレーム(富士通のXSP環境)において、開発作業を行っていますが、とても困っています。以下に、質問があります。区分編成ファイル(POファイル)に格納されている全てのCOBOLソースメンバーそれぞれの更新日時(タイムスタンプ)や各メンバーの内容を読み込む為のプログラムをCOBOL(アセンブラではなく)で作成したいのですが、どのようにすればよいでしょうか。具体的に教えて頂ければ、ありがたいです。以上、よろしくお願い致します。14:44まずは質問にお答えします。区分データセットのディレクトリ部は、それ自体が順編成データセットなので、JCLのFD文で定義すればアクセスできます。XSPでもそこは同じでしょう。COBOLはキー付きデータセットをサポートしていないので、ディレクトリ本体のみをブロック単位で読むことになります。区分データセットとかを考えないで、nバイトのブロックサイズを持つ、固定長の非ブロック化レコードのファイルとしてアクセスしてみて下さい。ディレクトリのデータ部のブロックサイズの大きさや、ブロック内のメンバーエントリーの構造などは、マニュアル(データ管理解説書、マクロ命令文法書)に載っているはずですから参照して下さい。XSPではMSPと違って、メンバーエントリーにはSHORT/LONGの2種類があったり、独自の構造を持っています。何をどこに書いているかはデータ管理のマニュアルではなく、PFDのマニュアルになります。公開されていれば載っているはずです。公開されていなくても、PFDのメンバーリスト画面と実際のデータを見比べれば、ほぼわかると思います。当方は富士通のマニュアルを見ることができないので、詳細はご自身でお調べ下さい。MVS3.8用のサンプルをアップしたので必要なら参考にして下さい。XSPに関する記述は記憶を頼りに書いていますが、必ずマニュアルで確認して下さい。ディレクトリが読み込めれば、メンバー名がわかりますから、そのメンバーをアクセスすればいいのですが、アセンブラーと違い、COBOLではBPAMやダイナミックアロケーションが使えませんから、メンバーに対応したFD文を予め定義し順編成ファイルとしてアクセスすることになります。ディレクトリを読みながら、同時に見つけたメンバーをアクセスすることができません。最初のプログラムで読むべきメンバーを決め、そのメンバーを読む、次のプログラムを実行するJCLを生成するような処理になると思います。次に個人的な意見です。XSPでしたらLIBEユーティリティでメンバーディレクトリーの編集・印刷、メンバー内容の編集・印刷ができるはずです。メンバー名に*だか+を指定することで全メンバーの印刷もできたかと記憶してます。LIBEの出力では目的を達成できないのであれば、プログラミングになりますが、COBOLでなら直接ディレクトリを読むより、LIBEの出力リストをCOBOLで読んで加工する方が簡単かも知れません。22:43はじめまして、やすゆきと申します。今度XSPから、MSPへの移行のプロジェクトを担当します。XSPのJCLをまず、MSPに移行して動作確認をするのが最初の仕事です。XSPのJCLを手修正して、MSPに移行するのは可能ですが、間違いが起きるだろうし、時間がかかります。XSPからMSPへのコンバージョンのプログラムを作ろうと考えています。POの各メンバーを、インプットファイルとして、コンバージョンのプログラムを作りたいのです。アウトプットも出来ればPOのメンバーにしたいです。私が知ってる限り、JSECOPY(PO→PO),JSDGENER(PS→PS)ですよね。現在はXSPの各メンバーをPSファイルに手でコピーして、それを入力ファイルとして、変更後のアウトプットもPSデータで作成して、それから手作業で、POのメンバーにコピーしようかと考えてますが、一つずつメンバーをコピーするのは非効率なので、ライブらイー全体で全メンバーを読んで、コンバージョンプログラムを使って、編集し、アウトプットもPOのメンバー単位で作成したいのです。16:12私なら商用プログラム(お客さんにお金出して買ってもらうユーティリティーなど)であれば、PDS単位で処理できるようにプログラムを設計しますが、自分(自社)だけが使う移行のための一発プログラムなら面倒なPDSのディレクトリアクセスなどしません。JCLでメンバー名まで指定すれば、1つのメンバーは単なるPSファイルになるので、PSを処理するプログラムを作り、メンバー分だけステップを増やして対応します。メンバー数が多すぎるなら適用な数でジョブを分ければ済みます。何もメンバーを一旦別のPSファイルにコピーなどしなくても、JCLで直接メンバーを指定すれば事足ります。JCLを作る、という手間だけは掛かりますが。他にもftpでメンバーを全部PCに落としてPC側で修正しMSPへアップするような方法もあります。Windowsでプログラミングできるならそんな方法もあります。コンバージョンのJCLを作るのが大変なら、IEHLISTやLIBEでメンバーリストを出して、それをプログラムで読み、JCLを作ることも考えられます。してもライブラリー単位で処理したいなら、データ管理のGETDTRYマクロを使えばPDS内にどのようなメンバーが存在してるかを知ることができます。メンバーリストが作れれば、BPAMで全メンバーを処理するか、個々のメンバー毎にDYNALLOCしてQSAMでメンバー単位にOPEN/GET/CLOSEのサイクルで処理を繰り返すか、いかようにもプログラムは作れます。様ご丁寧にありがとうございます。JCLでメンバー指定すれば、PSファイルですよね。事前に移行前のライブラリーをコピーして、OUTPUT用のライブラリーを作成しておけばいいですよね。OUTOUT用もメンバー指定して、DSP=SHRにすれば、単なるPSで処理できまますね。OUTPUTにしてけば、新規イメージ(コンバート後)の内容が出力されますもんね。本当に勉強不足でお恥ずかしいです。ご丁寧に教えて頂いてありがとうございました。