|
1:ＦＤによるデータ退避 あしか 04/08 13:48 こんにちは、はじめまして。 今回、あるユーザーの環境を社内に構築することになったのですが ＣＧＭＴを接続しているマシンが社内にないため #VOLPRを使って、FDに環境を退避できないかと 社内で試してみたところ、「制御ファイルがオーバーフローしました」というエラーが発生してしまいました。 #NEWSRや#BKUPを使って、テープにデータを退避することは FDでは不可能なのでしょうか？ ご教授よろしくお願いします。 2:Re:ＦＤによるデータ退避 tahrayan 04/08 16:17 こんにちは。 同じマニュアルをお持ちかどうかわからないのですが、 「システム操作法ガイドブック＜メッセージ編＞」のボリューム退避復帰のページをみると、 「制御テーブルがオーバーフローしました」の説明に「実行時メモり不足を検出しました」と書いてあります。 ＯＳバージョンによっては違うかもしれませんので、お持ちのマニュアルで確認してみてください。 それよりも気になるのは、＃ＶＯＬＳＲを使用していることです。 「互換操作法ガイドブック＜パラメータ編＞」のボリューム退避復帰のページをみてください。 そこの注意事項に以下のような内容が書いてあります。 「＃ＶＯＬＳＲで退避復帰対象となるファイル数は９９９ファイルまでです。ただし、一度９９９ファイルを越えたことのある磁気ディスクに関しては退避することができません。」 ＃ＮＥＷＳＲを使ってみてはどうでしょうか。それでもダメでしょうか。 ＶＯＬＳＲ ＝ ＶＯＬＵＭＮ ＳＡＶＥ ＲＥＳＵＭＥ ＮＥＷＳＲ ＝ ＮＥＷ ＳＡＶＥ ＲＥＳＵＭＥ ＮＥＷＳＲの方が新しいユーティリティです。 > #VOLPRを使って、FDに環境を退避できないかと > 社内で試してみたところ、「制御ファイルがオーバーフローしました」というエラーが発生してしまいました。 3:Re:ＦＤによるデータ退避 あしか 04/08 16:57 さっそくの回答ありがとうございました。 先輩に「FDなら、VOLSRじゃない？」と言われて、＃NEWSRは使用しませんでした。退避媒体がFDも＃NEWSRを使用できるものなんですか？ （基本的な質問ですみません） 先ほどのエラーは、上位のマシン、OSで試したところ 解決しました。 ただ、「そんなに容量ないだろう」というファイルのバックアップだけでも、何枚も何枚も媒体の変更を要求されるのですが そういうものなのでしょうか？ 4:Re:ＦＤによるデータ退避 BLUELION 04/08 18:36 > ただ、「そんなに容量ないだろう」というファイルのバックアップだけでも、何枚も何枚も媒体の変更を要求されるのですが > そういうものなのでしょうか？ 的はずれかもしれませんが SYS@FDFなどのファイル管理ファイルも保存されるからではないでしょうか？ また MSD000だとパラメータによっては 他のシステムファイルも保存対象となりますよ 5:Re:ＦＤによるデータ退避 あしか 04/08 18:49 ありがとうございます。 そうなんですね・・・。 ただ、今回は作業時間もそんなに取れないので ライブラリ類は、LBMで、容量いっぱいコピーする、を繰り返し、 その他データファイル類は、allocate JSを作成して とりあえずの環境を持ち帰ることで対応することにしました。 まだ訪問予定もありますので、その際に、必要なデータはいただいて帰ることにします。 コマンドの意味とかやっぱりちゃんと分かってないとだめですね・・・ 6:Re:ＦＤによるデータ退避 bluelion 04/08 21:11 ＳＹＳ＠ＦＤＦなどを持っていくと ファイルのアロックパラメータなどを作るのは簡単ですよ FDFの構造はマニュアルに載ってあります 普通は ＃ＭＡＰなどのリストがかんたんかもしれませんけど ＦＤＦから生成すれば ファイル名などを打たなくてすみますから 7:Re:ＦＤによるデータ退避 BLUELION 04/08 21:29 �����T 8:Re:ＦＤによるデータ退避 tahrayan 04/09 22:49 > さっそくの回答ありがとうございました。 > > 先輩に「FDなら、VOLSRじゃない？」と言われて、＃NEWSRは使用しませんでした。退避媒体がFDも＃NEWSRを使用できるものなんですか？ > （基本的な質問ですみません） > ＃ＮＥＷＳＲでもできます。 私は基本的に＃ＶＯＬＳＲの機能強化バージョンが ＃ＮＥＷＳＲだと思っています。 （でも、何か＃ＮＥＷＳＲでは使えないものもあった ような気がしますが、忘れてしまいました。） だいたい同じ機能を持っていたと思います。 >先ほどのエラーは、上位のマシン、OSで試したところ >解決しました。 やはりメモリ不足ですかね。 無事解決できてよかった。 9:SUL��#LBM#SAB43 温泉好きのうさぎ 04/10 01:58 こんばんは。 まったく本題とは離れますが、 > ライブラリ類は、LBMで、容量いっぱいコピーする、を繰り返し ソースやJS，PMをフロッピーにコピーするのは非常に時間がかかりますよね。 とくにSULのメンバを#LBMでコピーすると、フロッピー１枚で20〜30分ぐらいかかったりします。 そういうときは、#LBMより高速でコピーできる「#SAB43」の使用が便利です。 ご存知無い方が多いと思いますので、簡単に紹介しますと、機能は#LBMと同等で、SUL,JSL,PML,LML間でメンバの追加、置換、コピーを行うものなのですが、高速モードが存在します。 ただし、常に高速モードになるわけではなく、いくつかの条件があります。そのうち主なものが、 (1) 出力先の空領域がコピーしようとするメンバのサイズ（複数指定のときは、その合計）以上あること (2) １メンバのサイズがある大きさ以上（具体的な数値を思い出せませんが、SUは50セクタぐらいだったような、JS,PMはそれより少し小さかったか。） JSやPMは(2)の条件にひっかることが多いので、あまり効果が出ませんが、通常のCOBOLのソースであれば、#LBMの1/3ぐらいの時間でコピーできます。 (1)の条件を考慮すると、効果的な方法として、FDUにアロケートしたのと同じ大きさのSULをMSD上にもアロケートしておき、そこに今回のFDUにコピーしたいメンバを入れます。(MSD同士だと速いので#LBMを使ってもよい) #SAB43のACT=HCOPYでNAM=!として、全メンバを高速コピーする。(進捗表示が画面に出ます) MSD上のSULを２個用意しておいて、交互にそれぞれのコピーを行うようにすれば完璧。 ちょっとわかりにくい説明で申し訳ありません。 10:Re:SUL��#LBM#SAB43 BLUELION 04/11 00:44 こんにちは > ご存知無い方が多いと思いますので、簡単に紹介しますと、機能は#LBMと同等で、SUL,JSL,PML,LML間でメンバの追加、置換、コピーを行うものなのですが、高速モードが存在します。 初めて知りました 試してみます FDUにアロケートしたのと同じ大きさのSULをMSD上にもアロケートしておき、そこに今回のFDUにコピーしたいメンバを入れます。(MSD同士だと速いので#LBMを使ってもよい) 私は同じファイルのサイズで割り付けるのまでは同じですが＃ＡＢＣの複写でファイル全体をコピーします この方法もライブラリ使用率が高い場合は無駄な部分が少なくなるので効果的です |