|
1:ライブラリファイルを丸ごとDOS形式にしたいのです ろろけい 01/17 17:48 この掲示板にはいつもお世話になっております。 また質問させてください。 ライブラリファイル（ＬＭとかＰＭとかＪＳとかです）を、まるごと、Windows形式（#NFCNVでいうDOS形式）に変換する手段はありますでしょうか？ これをやりたい理由は、以下のようなことです。 私の会社は、オフコンが各拠点にあります。 私が、本社でプログラムを作ったり修正したりして、その都度各拠点に配布します。 昔は、プログラムを直すたびに、拠点の数だけＦＤにコピーして、それを郵送してバージョンアップをしていましたが、今はＶＰＮでつながっているので、下記のような流れで拠点に配布しています。 １．プログラム修正完了。 ↓ ２．配布するプログラムを、#LBMのSELECTで順編成ファイルに出力。 ↓ ３．２で作ったファイルを、#NFCNVで「無変換」でDOS形式に変換。 ↓ ４．ＶＰＮでつながっている拠点のオフコンサーバに３で作ったファイルをコピー（Windows上での操作）。 ↓ （以降拠点側で） ↓ ５．３の逆。 ↓ ６．#LBMのCOPY（またはADD）で拠点のプログラムを更新。 ＰＭやＪＳも、２の部分でSUFに出力し、３の前に「SUFから#FLCNVで順編成に変換」という作業を挟んで、同じように配布しています。 質問が長くてすみません。 １つや２つのプログラムであれば、上記の流れでも大して時間はかからないのですが、多くのプログラムを修正した場合に、プログラム数×拠点数なので、かなり大変になってしまうのです。 というわけで、 移行用の一時的なライブラリファイルを作り、 ↓ そこに今回配布すべきプログラムを入れて、 ↓ それを丸ごとDOS形式に変換して拠点へ送り、 ↓ 拠点側で逆向きの#LBMを実行する。 という流れを夢見ているのです。 どなたか参考になる情報をお持ちの方がいらっしゃれば、教えてくださいませ。 よろしくお願いいたします。 5:Re:ＲＦＡはだめですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） 江須扇 01/20 12:38 はじめまして、江須扇と申します。 すでに解決されてので、違う視点で申し上げます。 Ａ−ＶＸ／ＮＥＴはご存知でしょうか？ ＶＰＮで繋がっているという事であれば、ＴＣＰ／ＩＰでの Ａ−ＶＸ／ＮＥＴのリモートファイルアクセスで直接 やり取りができると思います。 弊社では、ＶＰＮで直接オフコン同士をＡ−ＶＸ／ＮＥＴ し、ＲＦＡ、ＶＷＳ共に使っております。 ＲＦＡでデータの集配信もしております。 業務運用でも問題は出ておりません。 ただ、インタネットＶＰＮを使っているので、年に１回程、 プロバイダーでのネットワークトラブルがあり接続できない 事ありました。 的外れですか？ 6:Re:ＲＦＡはだめですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） ろろけい 01/21 09:44 江須扇さんこんにちは。 よろしくお願いいたします。 これまた恥ずかしながら、Ａ−ＶＸ／ＮＥＴというキーワードも、初めて目にしました…。 このサイト内のオフコン用語辞典でＲＦＡのところを見ると、 ＞アクセスしたいファイルをボリュームカタログに登録するか、装置タイプ指定でRMSnnnと指定する。 この「装置タイプ＝RMSnnn」というあたりが、とても気になります。 これはもしかして、的、大当たりな予感がしています！ まずは、マニュアルＣＤを引っ張り出してきて、関連部分の勉強から始めます。 貴重なヒントを、ありがとうございました。 結果は後日、報告させていただきます。 7:Re:ＲＦＡはだめですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） ろろけい 01/21 10:33 あれ…。 「後日」ではなく数分後の書き込みですけれども…。 Ａ?ＶＸ／ＮＥＴというものは、まずは有償ソフトを買って登録しなければ使えない、ようですね…。 「あたりまえだ！」と言われそうですね。すみません。 マニュアルは普通に手元にあるので、標準で備わっている機能なのかと思ってしまったのですが、そうではなさそうですね。 これを利用すると、私がやりたいこと（＝更新プログラムの全拠点への配付）が、とても簡単に実現できそうなのですが、本社＋１０拠点分購入したら、百万近くになってしまいそうです…。 拠点間のやりとりが、プログラムの書き換え程度である現状では、これを導入するのは難しそうです。 全社のデータを一括して処理するような状況になってくれば、話は違ってくるかも知れないですけど。 とは言え、「Windows上でのデータは拠点間で自由にやりとりできているのに、オフコンだけはそれができなくて不便だ。」という声は社内のそこらじゅうから出てきているのも確かなので、オフコンを今後もずっと使っていくのであれば、Ａ−ＶＸ／ＮＥＴを導入するメリットも出てくるかも知れません。 なんとか導入できるように、働きかけていこうと思います。 江須扇さん、貴重な情報をありがとうございました。 8:Re:ＲＦＡはだめですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） 温泉好きのうさぎ 01/21 13:59 A-VX/NETを利用すると、たとえば、 #LBM; PRD=PRN999_ MDE=RMS010_ MFI=A-LML_ ACT=COPY_ IDE=MSD_ IFI=B-LML_ ... このような指定をすることにより、あたかも自サーバー内で処理するのと同じ感覚で、拠点の A-LML に、本社の B-LML のプログラムをコピーすることができます。 問題はやはり費用でしょうね。ソフトの希望小売価格は14万円だと思います。また、ソフトの有償登録だけではなく、MM5のSGをしなければならず、質問者様ご自身でできないのであれば、誰かに依頼しなければなりません。 いずれも導入時のみ必要とは言え、拠点の数が多いのでけっこうな金額になるのではないでしょうか。 9:Re:ＲＦＡはだめですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） ろろけい 01/21 15:27 温泉好きのうさぎさん、こんにちは。 やはり、そうなのですね。 A-VX/NETを入れて設定が完了すれば、そんなに簡単に、拠点のプログラムを更新できるのですね。 マニュアルを少し見てみましたが、#FLCNVなど他のいくつかのユーティリティでも、同じように使えるそうで。 A-VX/NET環境をお持ちの方が、うらやましい限りです(>_<)。 いつか、その環境を手に入れる日を夢に見つつ、現時点では、ＦＤ作戦とファイル変換作戦の併用でプログラムの配信を地道に行っていきます…(^^; ありがとうございました。 10:Re:DOS�� 江須扇 01/21 21:41 ＞Ａ−ＶＸ／ＮＥＴというものは、まずは有償ソフトを買って登録しなければ使えない、ようですね…。 ＞「あたりまえだ！」と言われそうですね。すみません。 大変失礼しました。 有償ソフトである事を説明しておりませんでした。 Ｗｉｎｄｏｗｓの場合は、新バージョンが出る毎に、 オプション機能（有償ソフト）を取り込んできました。 有償ソフトのＯｆｆｉｃｅもプレインストールして販売しています。 貴社の様に拠点が多い場合は、Ａ−ＶＸ／ＮＥＴは必須と思います。 これは販売する側の問題です。 当然販売する側の営業かＳＥが提案すべき事項です。 Ａ−ＶＸは基本ＯＳ以外に、 ＣＯＢＯＬ ＳＭＡＲＴ２ ＲＤＢ／ＥＵＦ２ Ａ−ＶＸ／ＮＥＴ ＲＤＢサーバー ＢｉｚＲｅｐｏｒｔｉｎｇ 統合管理ツール メーカーは標準にすべきであり、 販売会社はセットで販売すべきと考えております。 ＞とは言え、「Windows上でのデータは拠点間で自由にやりとりできているのに、オフコンだけはそれができなくて不便だ。」 大変失礼な質問ですが、 拠点間のＡ−ＶＸのマスタ、データの伝送はどうしているのですか？ 販売会社は過去に何も提案しなかったのですか？ なぞが残ります。 「だからオフコンはＷｉｎｄｏｗｓよりレベルが低い」と思われるのは悲しいですね。 11:Re:ＶＰＮ環境であれば（ライブラリファイルを丸ごとDOS形式にしたいのです） 江須扇 01/22 10:44 ＶＰＮ環境であれば、拠点の利用目的にもよりますが、 拠点はＰＣ／ワークステーションエミュレータのみにし、 直接本社サーバーに接続するというのはどうでしょうか？ ファイル共有 プリンタ出力 等 解決しかねればならない問題もありますが、プログラムメンテナンスは集中管理できます。 あと、データ転送だけですが、Ａ−ＶＸ３以降であれば、 Ａ?ＶＸ ＲＤＢ／ＦＩＬＥアクセスキットが使えるので、 クライアント側に、Ｓｍａｒｔ／ｃｓ ｌｉｇｈｔを導入し （有償ソフト） ファイル転送プログラムを作るというのも一案です。 ただし、プログラムメンテナンスの問題は残りますが・・・・ 蛇足ばかりで、すいません 12:Re: ろろけい 01/22 11:20 私の会社が特殊なのかどうかはわかりませんが、顧客情報や売上情報を始め、ほぼすべてのデータが、拠点ごとに単独で動いていて、顧客マスタの更新なども、すべて、拠点に任せています。 全社の数字をまとめる段階ではオフコンから離れて、Windows側でやっていて、そこでの転記作業は、手動の部分もあれば、ここで勉強した「オフコン→Excel連携」等を使って自動化されてる部分もあります。 こういう状態なので、オフコン上で拠点間のやりとりが必要になるのは、ほぼ、プログラムが更新されたときのみなのですね。 VPN等で拠点間がつながる前から全拠点にオフコンが入っていたので、今でもそのころの流れのまま、情報が完全には全社統一になっていないわけです。 この状態で業務に支障はないので、あえて大きな改造をしていない、というのもありますが。 ところで、私の会社では、オフコンに関する部分は、１００％社内（私を含めた二人のシステム担当者）で構築しています。 私ももう一人も、COBOLのソフト会社を経験してますので、今のところは、外部の力を借りずになんとかなっています。 もしかしたらこれが、販売会社さんが過去に何も提案してこなかった理由のひとつかも知れませんね。 「ろろけいさんの会社は、オフコンに関しては（ろろけいさんたちがそれなりに詳しいので）多くは語るまい。」みたいな。 これはもちろん、私の想像ですけどね。 ただ、「なんとかなっている」ように思っていたのですが、せっかくのオフコンの進化を、あまり利用できていないんだなとも、感じました。 どうしても「費用」という壁が立ちはだかってしまうのですが、せっかく全拠点にオフコンが揃っていて、すべてVPNでつながっているのですから、これをもっと利用すべきだなと感じている、今日このごろです。 江須扇さん、いろいろな情報をありがとうございます。 今後もぜひ、いろいろと教えてくださいませm(__)m 13:Re:ＦＤＴＯＯＬはどうですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） 江須扇 01/28 23:11 あれから、いろいろ考えました。 ＃ＶＯＬＳＲでＬＭＬファイルをＦＤに退避し、 それを＃ＮＦＣＮＶできないかとも考えましたが、 テストしてみたら、 ＃ＶＯＬＳＲは特殊な書き込みで不可能のようです。 ＞A-VXIVである６拠点に関しては、今までどおりの方法でなんとか乗り切りますかね。 キーワードはやはりＦＤで、Ａ−ＶＸ０１仕様と旧ＩＴＯＳ仕様を 変換できるＡ−ＶＸ４でも動作するＴＯＯＬがあります。 ドライブは固定になっているので、ＦＤの入れ替え作業は発生するので拠点での作業が必要ですが理論的には可能です。 （中間ファイルがＴＥＭＰ０００がディスクにできるのですが、キャンセルすると消えてしまします。） http://www.nec.co.jp/pfsoft/a-vx/FDCnv/fdcnv.html#FDCNVTOOL 操作が拠点でできないということであれば、 噂ではこのＴＯＯＬの素になったＴＯＯＬあるそうです。 それは、ＮＥＣから各拠点や保守部門へ、修正用のＦＤを配布する為のもので、 ネットワークで配布したＡ−ＶＸ０１仕様のファイル（Ｗｉｎｏｄｏｗ仕様）を 旧ＩＴＯＳ仕様に変換できるＴＯＯＬです。 販売店等に相談されたらいかかでしょうか？ それも難しい場合は＃ＬＢＭを連続的に実行して、 ＳＥＬＥＣＴしたファイルを結合し＃ＮＦＣＮＶ 拠点では分解して＃ＬＢＭでライブラリーに戻す ＣＯＢＯＬのプログラムを作るというのはどうですか？ 14:Re:ＦＤＴＯＯＬはどうですか？（ライブラリファイルを丸ごとDOS形式にしたいのです） ろろけい 01/30 12:02 あ！江須扇さん！こんなところに！(^^; ツリーの一番下ばっかり気にしてたので、この書き込みに気づくのが遅れました(^^; ほんとに、いろいろな情報をありがとうございます。 拠点での作業、特に物理的な作業（ＦＤ入れ替え等）は極力避けたいので、今回のヒントの、２つ目か３つ目がよさそうですね。 特に、COBOLプログラムを作ってしまう！ってのは、あまり考えてなかったけど、うまく仕上げれば、もしかしたらそれがいちばんすっきりするかも知れませんね。 現在手作業でやっている、#LBM、#FLCNV、#NFCNVなどのパラメータ群をうまく組み立てて、システムサブルーチンの「CBLRUN」や「SYSSPAWN」で制御する、って感じですよね？ 作り上げるまでにはけっこう試行錯誤が必要な気はしますが、やってみる価値はありそうです。 ちょっとがんばってみます。 ありがとうございました！ |