ＮＥＣのオフコン情報掲示板（ノウハウ系）
| ＮＥＣのオフコンを活用するためのノウハウを話し合うための掲示板です。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| ■▲▼ | ||
| 1 | RDBQでのデータデータディクショナリの分け方 | |
| Tama 2005-4-22 12:24:00
[返信] [編集] RDBQを起動すると通常はSYS@DDFを読み込みますがこれ以外 のファイルから読み込むことは可能でしょうか？ 現在、表定義が300以上になり一覧から探すのも大変なので EIGYOU@DDF、KEIRI@DDFなど部門ごとに整理したいと思って います、よろしくお願いします。 | ||
| 2 | 良い方法はないのかも | |
| ターラヤン 2005-4-26 1:19:00
[返信] [編集] こんにちは。 誰か良い方法を知っているかなと思っていたのですが、 どうも良い方法はなさそうですね。 たしかにたくさんの表定義をしていると、探すのは 大変かもしれません。何か良い方法があるとよいのですが。 | ||
| 3 | Re:良い方法はないのかも | |
| MAKI 2005-4-26 10:23:00
[返信] [編集] > こんにちは。 > > 誰か良い方法を知っているかなと思っていたのですが、 > どうも良い方法はなさそうですね。 > > たしかにたくさんの表定義をしていると、探すのは > 大変かもしれません。何か良い方法があるとよいのですが。 > RDBで使う表は、SYS@DDF以外に、SYS@DBDIRとか SYS@CATとかが関係しているのでDDFの使い分けは 難しいだろうなと思って見ていたのですが。 マニュアルを見直してみたところ RDBQ2のマニュアルの環境設定の中に、表の階層表示 が設定できるように書いてありました。 ＃DDMの補助機能で表の階層化もできるようです。 SYS@DDFの中で表定義を階層化して使えということの ようです。 ただし、RDBQでは使えないみたいです。 実行環境がないのでこちらでは確認できません。 あしからず。 | ||
| 4 | Re:良い方法はないのかも | |
| Tama 2005-4-26 12:26:00
[返信] [編集] みなさん、Ｒｅｓありがとうございます。 あれから私もマニュアルを読み返したりと色々調べてみたのです がSYS@DDF以外を使用するのはどうやら無理そうですね。 MAKIさんに教えて頂いた階層化ですが、説明書を見ながら試して みたところグループ化できました。 #DDMでグループを登録してRDBQ2で階層化表示に切り替えたら登 録したグループで表示されました。 ただ、社内ではRDBQ2は使用していなかったので担当者を集めて 一から教育のしなおしが必要になりそうです。 | ||
| 5 | 一度「ＲＤＢＱ２」を使うと！！ | |
| ＥＸＣＨＡＮＧＥ 2005-4-26 21:24:00
[返信] [編集] > ただ、社内ではRDBQ2は使用していなかったので担当者を集めて > 一から教育のしなおしが必要になりそうです。 > ＊ よく古くからＡ−ＶＸを使ってきたベテランの方ほど、 ＲＤＢＱにこだわりのある方がおられます。 しかし、一度「ＲＤＢＱ２」を覚えて使ってみると、 使い勝手が良いので、 とてもＲＤＢＱへ戻りたいとは思わなくなります。 ＊ もっとも、ＳＫＹＬＩＮＫを使いかけると、 さらに使い勝手が良くて。。 とてもＲＤＢＱ、ＲＤＢＱ２へ戻りたくなくなります。 同時に、オフコンの殺風景さを実感してしまいます。 ＊ ところで、ＳＫＹＬＩＮＫから見たときに Ａ−ＶＸディレクトリツリーが階層構造に見えるように 出来ないのかなあ？？ | ||
| 6 | Re:RDBQでのデータデータディクショナリの分け方 | |
| アレックス 2005-4-27 11:17:00
[返信] [編集] 皆さんはじめまして、お邪魔いたします。 ＳＹＳ＠ＤＤＦへの併合は必要ですが、ＪＣＬを作成すれば可能 です。 /ASSIGN EFN=EIGYOU@DDF,OEFN=SYS@DDF; /RUN RDBQ,DEV=MSD; /> ; こんな感じです。 ユーザー側のＤＤＦを修正した際は必ずＳＹＳ＠ＤＤＦに併合 してください。 | ||
| 7 | Re:「RDBQでのデータデータディクショナリの分け方」に関心 | |
| 富山清風 2005-4-27 20:15:00
[返信] [編集] > /ASSIGN EFN=EIGYOU@DDF,OEFN=SYS@DDF; > /RUN RDBQ,DEV=MSD; > /> ; 上記方法に関心しました。 さっそく、動作確認してみました。ＯＫでした。 最初、Tamaさんの質問をみた時は、絶対不可能だと思っていましたし､ 「返信」がなかなかないので、全国のだれがみても不可能ではないかと思っていました。が、そんな方法があったとは！！ 関心しきりです。 皆さんも、「不可能」とは思わずにどんどん質問して、 「不可能」を「可能」にしましょう。 「オフコンの和」をもっともっと広げましょう | ||
| 8 | Re:RDBQでのデータデータディクショナリの分け方 | |
| ターラヤン 2005-4-28 0:36:00
[返信] [編集] > 皆さんはじめまして、お邪魔いたします。 アレックスさん、はじめまして。 > ＳＹＳ＠ＤＤＦへの併合は必要ですが、ＪＣＬを作成すれば可能 > です。 > >/ASSIGN EFN=EIGYOU@DDF,OEFN=SYS@DDF; >/RUN RDBQ,DEV=MSD; >/> ; ASSIGNを使って、ファイル名を変更するのですか。 正直そんな方法は思いつきませんでした。 SYS@DBDIRなどの構造を考えると、ちゃんとできるのかと疑問もあるのですが、 実際に問題なく使えているのなら、これで分けることができるということですね。 それにしても、すばらしい。 | ||
| 9 | Re:RDBQでのデータデータディクショナリの分け方 | |
| Tama 2005-4-28 12:50:00
[返信] [編集] このような方法は思いつきませんでした。 ＪＳを作ってメニュー登録しておけばよさそうですね。 Ａ−ＶＸを使いはじめて十数年ですがずっと悩んでい たのですっきりしました。 | ||
| 10 | Re:RDBQでのデータデータディクショナリの分け方 | |
| ＥＸＣＨＡＮＧＥ 2005-4-28 13:41:00
[返信] [編集] > /ASSIGN EFN=EIGYOU@DDF,OEFN=SYS@DDF; > /RUN RDBQ,DEV=MSD; > /> ; > > こんな感じです。 > ユーザー側のＤＤＦを修正した際は必ずＳＹＳ＠ＤＤＦに併合 > してください。 > ＊ まったくすばらしい！！ 私もそう思います。 ＊ ＪＣＬで／ＡＳＳＩＧＮを使って実ファイルを割り当てるとい うやり方は、ＮＥＣ以外のオフコンでは一般的に使われていま すが、ＮＥＣではあまり使っていないように思います。 ＊ それにしても、こういうところで／ＡＳＳＩＧＮを使うという のは誰も思いつかない手法ですね。スゴイ。 ＊ ちなみに私は、もっと単純で ＤＢ表の参照権にＨ１（販売関連）、Ｋ１（経理関連）とかを 設定しておいて、オペレータコードごとに （Ａ−ＶＸで全ての業務ＡＰを操作するオペレータ）： セキュリティコードに、Ｈ１、Ｋ１の両方を含ませる。 （ＲＤＢＱ２で販売のみを検索するオペレータ）： セキュリティコードに、Ｈ１のみを含ませる。 （ＲＤＢＱ２で経理関連のみを検索するオペレータ）： セキュリティコードに、Ｋ１のみを含ませる。 等々、、とやって部門ごとのセキュリティと兼ね備えて のぞかせるようにしていました。 特に仮想表（結合表も含めて）を作っておいて これに参照権を設定する、とすることで 表の数は増えますが、オペレータごとにＤＢの見え方を コントロールすることができるかと思います。 （それにＲＤＢＱの段階で結合表を作成できない操作員も 多々ありますし。。） | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | Ａ−ＶＸのＬＭをＥｍａｉｌで送る方法はありますか？ | |
| 富山清風 2005-4-18 20:21:00
[返信] [編集] いつも楽しくみています。 非常に初歩的な質問ですが、 Ａ−ＶＸ(ITOS)のＬＭをＥｍａｉｌで送る方法はありますか？ この掲示板をみておられる方々は、いろいろな方法をご存知かとおもいますので、いい回答をお待ちしております。 | ||
| 2 | Re:Ａ−ＶＸのＬＭをＥｍａｉｌで送る方法はありますか？ | |
| MAKI 2005-4-18 22:35:00
[返信] [編集] > いつも楽しくみています。 > > 非常に初歩的な質問ですが、 > Ａ−ＶＸ(ITOS)のＬＭをＥｍａｉｌで送る方法はありますか？ > > この掲示板をみておられる方々は、いろいろな方法をご存知かとおもいますので、いい回答をお待ちしております。 > やったことはないんで自信はないんですが。 LMのメンバーは、レコード長２５６のSEQファイルに落とすことが できます。（逆もできます） LM→SEQは、＃LBMのSELECT SEQ→LMは、＃LBMのコピーだったと思います。 で、SEQファイルは、＃NFCNVで、PCのファイルにすることが できますね。 Emailで一回に送れるデータ量が気になりますが、 ファイルを圧縮すれば送信はできそうな気がします。 参考まで。 | ||
| 3 | Re:Ａ−ＶＸのＬＭをＥｍａｉｌで送る方法はありますか？ | |
| ターラヤン 2005-4-19 0:07:00
[返信] [編集] > いつも楽しくみています。 > > 非常に初歩的な質問ですが、 > Ａ−ＶＸ(ITOS)のＬＭをＥｍａｉｌで送る方法はありますか？ こういう方法もあります。 ＬＭをフロッピーディスクに入れる。 フロッピーディスクのイメージをＷｉｎｄｏｗｓのバイナリ イメージに変換してメールで送る。 相手先で、バイナリイメージからフロッピーディスクに戻す。 フロッピーディスクからＬＭを取り出す。 バイナリイメージにするには、例えばシステムポート株式会社 の「仮想FDファイル変換」ツールがあります。 http://www.systemport.co.jp/download/index.htm システムポート株式会社のＨＰ の製品情報のところにあります。 ちなみにＡ−ＶＸと相性が悪いようで、Express5800/600シリーズ 上（サーバ上）で、この「仮想FDファイル変換」ツールを インストールするとＡ−ＶＸが正しく動かなくなります。 600シリーズ以外のＰＣを使う必要があります。 あとは、ＮＥＣのＡ−ＶＸ０１形式フロッピーディスク変換ツール を使う手もあります。 入手方法は、現在２つあります。最近の６００ｘｉシリーズ （正確にはＯＳがＡ−ＶＸ０１のもの）には標準で付いている ので、それを使用する。 最近、ＮＥＣの販売店向けのＨＰに公開されたので、そこから 入手する。 （販売店に入手をお願いするとか、何らかの手段で入手して ください。） やり方は、 変換ツールで変換すると、フロッピーディスク上にＰＡＦＤＵ０００ という名前のファイルができるので、それをメールに添付して送る。 相手先では、いったんＰＡＦＤＵ０００を１．４４ＭＢのフロッピー ディスクに入れて、それを変換ツールで従来の形式の フロッピーディスクに戻す。 ただし、こちらは本来の用途ではないので、何か問題が発生する 可能性もあり。 私自身は、この方法で何度かメールのやりとりして問題なく相手 に渡せています。 どちらの方法もフロッピーディスクをそのままバイナリ化する ので、１ＭＢぐらいのファイルになりますが、 ＬＺＨとかＺＩＰで圧縮するとかなり小さくなります。 特に、フォーマットした直後のフロッピーディスクならば、 かなり小さくなります。 逆に使い込んだ（要するにいろんなファイルが入れたり、 削除したりしたフロッピーディスク） だと、（データが削除されていても、内部にごみデータとして 残っているので）あまり圧縮が利かずにあまり小さくならない ことがあります。 フォーマットしたばかりのフロッピーディスクを使い、送りたい ＬＭだけを入れると良い。 | ||
| 4 | 補足です。 | |
| ターラヤン 2005-4-19 0:12:00
[返信] [編集] > あとは、ＮＥＣのＡ−ＶＸ０１形式フロッピーディスク変換ツール > を使う手もあります。 > 入手方法は、現在２つあります。最近の６００ｘｉシリーズ > （正確にはＯＳがＡ−ＶＸ０１のもの）には標準で付いている > ので、それを使用する。 > 最近、ＮＥＣの販売店向けのＨＰに公開されたので、そこから > 入手する。 > （販売店に入手をお願いするとか、何らかの手段で入手して > ください。） ＮＥＣの販売店向けのＨＰにあるのは、６００シリーズ（無印、 Ａｉ、ｘｉ）で汎用に使えるツールです。 たぶん本来の公開の意図としては、Ａ−ＶＸ０１にバージョン アップする人用だと思います。 こういう使い方をしてＯＫかどうか不明ですが、逆にこのような 使い方は許さないとも書いていない。 | ||
| 5 | Re:やってみました | |
| 富山清風 2005-4-19 18:05:00
[返信] [編集] MAKIさん さっそくのご回答ありがとうございます。 以下の手順でテスト的に実行してみたところ、うまく出来そうですね。 送信側:STEP-1:#LBM__:ACT=SELECTでLMを256のSEQファイルヘ 送信側:STEP-2:#NFCNV:OP(256のSEQ)→PCへ 送信側:STEP-3:ﾒｰﾙ___:添付して、送る 受信側:STEP-4:#NFCNV:PC→OP(256のSEQ)へ 受信側:STEP-5:#LBM__:ACT=COPY等で256のSEQファイルよりLMファイルへ ＬＭが２５６のＳＥＱにセットできるとは！！ なんでも聞いてみるものですね まだ、質問があったら、聞ますのでよろしくお願いします。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ＭＩＸ項目の１，２バイト文字判断 | |
| うどん 2005-4-13 10:41:00
[返信] [編集] お世話になります。 早速ですが、ＭＩＸ項目内の文字を１バイトか２バイトか判断するのに （ＣＯＢＯＬ内で）何か良い手は無いでしょうか？ やりたい事は、送先住所というＭＩＸ項目を伝票に出力したいのですが、 横幅の印字文字が限られている為、自動で改行しないいけません。 改行というのがくせ者で、２バイト文字が離れない(?)様にしないと 文字化けしてしまいます。 現在のフォーマットは、日本語（Ｎタイプ）で定義されているので 気にしなくて良かったのですが．． 宜しくお願い致します。 | ||
| 2 | Re:ＭＩＸ項目の１，２バイト文字判断 | |
| 富山清風 2005-4-13 13:03:00
[返信] [編集] 「うどん」さん、こんにちは。 私は以下のようにして判断しています。 １バイトづつ順次チェックし、下記テーブルと照合し、 「Ａ」であれば、ANKであり、 「Ｊ」であれば、全角の前半であるため、 次の１バイト（全角の後半）と合わせて２バイトすなわち全角１文字として扱っています。 ちなみに、下記の表は、「A-VX�献瓮奪察璽鹸浜�３説明書の付録ＢのＢ−６に記載されているものを使っています」 以上ですが、お役にたてば幸いです。 ----------end | ||
| 3 | Re:ＭＩＸ項目の１，２バイト文字判断 | |
| うどん 2005-4-13 18:07:00
[返信] [編集] 富山清風さん さっそくの回答ありがとうございます。 ２バイト文字の１バイト目が、A-VX�献瓮奪察璽鹸浜�３説明書の 付録ＢのＢ−６の表にある値(１６進)なら２バイト文字という形で 解釈しました。 テストプログラムを作成して動かしましたが、半角スペース(40H） も２バイトとして認識してしまいますよね？ 表の見かたが間違っているのでしょうか？ | ||
| 4 | Re:ＭＩＸ項目の１，２バイト文字判断 | |
| 富山清風 2005-4-13 18:23:00
[返信] [編集] 列と行が逆ではないですか？ | ||
| 5 | 勘違いしてました | |
| うどん 2005-4-14 15:52:00
[返信] [編集] > 列と行が逆ではないですか？ 思いっきり勘違いしてました。 例えば、チェックしたい値が”P2”(16進でD7)なら、前回提示頂いた ソース内の CON-CNV-T-1 のインデックスの値が、216の値を参照 するという事ですね。 (CON-CNV-T-1(216)の値は”A”なので、１バイト文字となる) あと、コボルで16進にする命令とか無いですよね？ | ||
| 6 | Re:勘違いしてました | |
| 富山清風 2005-4-14 18:46:00
[返信] [編集] > あと、コボルで16進にする命令とか無いですよね？ 方法は色々あると思いますが私し以下のようにしています。 参考までに | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | #SAB43の高速モードコピーの速度を実測 | |
| 温泉好きのうさぎ 2005-4-11 11:31:00
[返信] [編集] SULのメンバをMSDからFDUにコピーするのに要する時間を、#LBMと#SAB43それぞれについて、実測してみました。 テストデータとして、次の3種類のものを用意しました。(言語タイプはCOBOL、SULの大きさは3800セクタ) (1) 1本当り2000ステップ、90セクタのメンバが36本、合計3240セクタ (2) 1本当り2000ステップ、655セクタのメンバが5本、合計3275セクタ (3) 10000ステップ、3268セクタのメンバが1本、3268セクタ いずれも、出力先のFDUのSULは、初期化し空の状態です。また、測定中他にジョブは動いておらず、負荷の無い状態です。 (1) #LBMでは、18分47秒、#SAB43では、3分22秒 (2) #LBMでは、18分02秒、#SAB43では、1分05秒 (3) #LBMでは、17分51秒、#SAB43では、48秒 予想を上回る絶大な効果があると思われます。 特に、サイズが大きなメンバほど、効果が発揮されています。 こんどは、逆方向の、FDUからMSDへのコピーも測定しました。 (1) #LBMでは、8分52秒、#SAB43では、9分32秒 (2) #LBMでは、8分50秒、#SAB43では、9分22秒 (3) #LBMでは、8分47秒、#SAB43では、9分17秒 こちらでは、高速モードコピーの威力が発揮されるどころか、#LBMのほうが速いという結果になってしまいました。 なお、計測は腕時計の秒針を見て行いました。また、マシンやＯＳ、フロッピー等による差もあると思われますので、あくまでこの情報は参考としてお取り扱いください。 | ||
| 2 | Re:#SAB43の高速モードコピーの速度を実測 | |
| 富山清風 2005-4-12 18:41:00
[返信] [編集] 「#SAB43」を始めて知りましたが、公に使用していいＬＭなのですか？ | ||
| 3 | Re:#SAB43の高速モードコピーの速度を実測 | |
| ターラヤン 2005-4-12 21:02:00
[返信] [編集] 知りませんでした。 ものすごく高速ですね。 マニュアルに書いてある内容を見る限り、＃ＳＡＢ４３は 新システム体系ユーティリティの一部で、本来内部で呼び出される ものみたいですね。 直接実行して、単独でも動かすことができるというわけですか。 今度フロッピーディスクにコピーするときに使用してみます。 | ||
| 4 | Re:#SAB43の高速モードコピーの速度を実測 | |
| 温泉好きのうさぎ 2005-4-13 16:18:00
[返信] [編集] > 公に使用していいＬＭなのですか？ SYS@LMLに入っている以上、誰がどう使おうと、何ら問題ないと考えています。 もちろん「自己責任」であることは、言うまでもありません。 誤った使い方をして、ファイルを初期化したり、データを壊したとしても、誰に文句も言えません。 そのため、責任能力が無かったりスキルの低いユーザーには、使ったり、教えたりしないほうが賢明だと思われます。 従って、誰が見るかわからない掲示板では具体的なパラメータの説明や記述を控えています。わかる人が見ればわかりますから。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| ■▲▼ | ||
| 1 | ＦＤによるデータ退避 | |
| あしか 2005-4-8 13:48:00
[返信] [編集] こんにちは、はじめまして。 今回、あるユーザーの環境を社内に構築することになったのですが ＣＧＭＴを接続しているマシンが社内にないため #VOLPRを使って、FDに環境を退避できないかと 社内で試してみたところ、「制御ファイルがオーバーフローしました」というエラーが発生してしまいました。 #NEWSRや#BKUPを使って、テープにデータを退避することは FDでは不可能なのでしょうか？ ご教授よろしくお願いします。 | ||
| 3 | Re:ＦＤによるデータ退避 | |
| あしか 2005-4-8 16:57:00
[返信] [編集] さっそくの回答ありがとうございました。 先輩に「FDなら、VOLSRじゃない？」と言われて、＃NEWSRは使用しませんでした。退避媒体がFDも＃NEWSRを使用できるものなんですか？ （基本的な質問ですみません） 先ほどのエラーは、上位のマシン、OSで試したところ 解決しました。 ただ、「そんなに容量ないだろう」というファイルのバックアップだけでも、何枚も何枚も媒体の変更を要求されるのですが そういうものなのでしょうか？ | ||
| 4 | Re:ＦＤによるデータ退避 | |
| BLUELION 2005-4-8 18:36:00
[返信] [編集] > ただ、「そんなに容量ないだろう」というファイルのバックアップだけでも、何枚も何枚も媒体の変更を要求されるのですが > そういうものなのでしょうか？ 的はずれかもしれませんが SYS@FDFなどのファイル管理ファイルも保存されるからではないでしょうか？ また MSD000だとパラメータによっては 他のシステムファイルも保存対象となりますよ | ||
| 5 | Re:ＦＤによるデータ退避 | |
| あしか 2005-4-8 18:49:00
[返信] [編集] ありがとうございます。 そうなんですね・・・。 ただ、今回は作業時間もそんなに取れないので ライブラリ類は、LBMで、容量いっぱいコピーする、を繰り返し、 その他データファイル類は、allocate JSを作成して とりあえずの環境を持ち帰ることで対応することにしました。 まだ訪問予定もありますので、その際に、必要なデータはいただいて帰ることにします。 コマンドの意味とかやっぱりちゃんと分かってないとだめですね・・・ | ||
| 6 | Re:ＦＤによるデータ退避 | |
| bluelion 2005-4-8 21:11:00
[返信] [編集] ＳＹＳ＠ＦＤＦなどを持っていくと ファイルのアロックパラメータなどを作るのは簡単ですよ FDFの構造はマニュアルに載ってあります 普通は ＃ＭＡＰなどのリストがかんたんかもしれませんけど ＦＤＦから生成すれば ファイル名などを打たなくてすみますから | ||
| 7 | Re:ＦＤによるデータ退避 | |
| BLUELION 2005-4-8 21:29:00
[返信] [編集] 追伸：＃ＦＬＣＮＶの隠し機能でＣＯＰＹしないと出来なかったと思います | ||
| 8 | Re:ＦＤによるデータ退避 | |
| ターラヤン 2005-4-9 22:49:00
[返信] [編集] > さっそくの回答ありがとうございました。 > > 先輩に「FDなら、VOLSRじゃない？」と言われて、＃NEWSRは使用しませんでした。退避媒体がFDも＃NEWSRを使用できるものなんですか？ > （基本的な質問ですみません） > ＃ＮＥＷＳＲでもできます。 私は基本的に＃ＶＯＬＳＲの機能強化バージョンが ＃ＮＥＷＳＲだと思っています。 （でも、何か＃ＮＥＷＳＲでは使えないものもあった ような気がしますが、忘れてしまいました。） だいたい同じ機能を持っていたと思います。 >先ほどのエラーは、上位のマシン、OSで試したところ >解決しました。 やはりメモリ不足ですかね。 無事解決できてよかった。 | ||
| 9 | SUL等のコピーは#LBMより高速の#SAB43がお勧め | |
| 温泉好きのうさぎ 2005-4-10 1:58:00
[返信] [編集] こんばんは。 まったく本題とは離れますが、 > ライブラリ類は、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 2005-4-11 0:44:00
[返信] [編集] こんにちは > ご存知無い方が多いと思いますので、簡単に紹介しますと、機能は#LBMと同等で、SUL,JSL,PML,LML間でメンバの追加、置換、コピーを行うものなのですが、高速モードが存在します。 初めて知りました 試してみます FDUにアロケートしたのと同じ大きさのSULをMSD上にもアロケートしておき、そこに今回のFDUにコピーしたいメンバを入れます。(MSD同士だと速いので#LBMを使ってもよい) 私は同じファイルのサイズで割り付けるのまでは同じですが＃ＡＢＣの複写でファイル全体をコピーします この方法もライブラリ使用率が高い場合は無駄な部分が少なくなるので効果的です | ||
| 11 | 訂正 | |
| 温泉好きのうさぎ 2005-4-11 11:30:00
[返信] [編集] 高速モード使用の条件について、ユーティリティ説明書に詳しく書いてありました。私の書いた内容は間違っておりました。 以下、説明書を一部引用します。（表の部分が見にくいと思います。） ＜以下引用開始＞ 高速モードを”使用する”と指定することにより、以下の条件が満たされている場合にライブラリメンバの複写を高速に行います。 ・複写先（出力側のファイルがあらかじめ初期化されている。） ・複写対象メンバが下記のサイズである。 ［高速化の基準値］ 指定装置−ファイルタイプ SUL/JSL/PML CUL LML ＭＳＤ→ＭＳＤ 600ステップ以上 300セクタ以上 100セクタ以上 ＦＤＵ→ＭＳＤ 1800ステップ以上 700セクタ以上 300セクタ以上 ＭＳＤ→ＦＤＵ 60ステップ以上 20セクタ以上 300セクタ以上 （上記は１メンバのサイズです） ＜以上引用終わり＞ SUL,JSL,PMLで差は無いようです。入出力の装置によってかなり条件が違うようです。 この件に関して、テストデータの測定の結果を、別スレッドにて立ち上げました。ご確認ください。 | ||
| 12 | 結果ご報告 | |
| あしか 2005-4-12 10:51:00
[返信] [編集] みなさん、いろいろな情報をありがとうございました。 先週、環境調査に行ってきました。（みなさんの情報に気づかずに・・・） 10,000弱のSULのコピーをLBMで行い、１時間以上かかったため LMのコピーは次回に見送りました。（あまり時間がとれないため） アロケートJSを作成するつもりでしたが 現地にその機能がなく、作成できませんでした。 SYS@FDFのことも勉強して、再度行く予定です。 | ||
| 全部読む 最新50 1-100 板のトップ リロード | ||
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band