[掲示板に戻る]
 
Re: COBOL資産の移行について まゆちん 2003-9-29 7:35
|
Re: COBOL資産の移行について ＥＸＣＨＡＮＧＥ 2003-9-29 10:14
|
|
ＥＸＰＲＥＳＳ５８００／６８０？（Ｃ... 江須扇 2003-9-29 14:53
|
Re: ＥＸＰＲＥＳＳ５８００／６８０？... ＥＸＣＨＡＮＧＥ 2003-9-29 17:54
|
|
Re:Ｏｒａｃｌｅ（COBOL資産） 江須扇 2003-9-30 3:39
|
|
Re:工数が劇的に減る？（COBOL資産） 江須扇 2003-9-30 13:52
|
| 6 | Re: COBOL資産の移行について |
| まゆちん 2003-9-29 7:35
[返信] [編集] EXCHANGEさん、 江須扇さん、ターラヤンさんお返事ありがとうございました。 また返事が遅れましてすみませんでした。 ここまでご意見頂けるとは思っていなかったため、大変嬉しい気持ちです。 勉強不足な私ですが、今後ともよろしくお願いします。 まず、なぜCOBOL資産を、別のCOBOL環境に移行しようと思っているかについてですが、背景から申し上げます。 マシンはEXPRESS 8500/680、OSは A-VX�検�Rは分かりません。すみません。）です。 このホストに別会社Ａ社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。 現在、Ａ社担当分である基幹系のCOBOL資産（アプリケーション、RDB、データファイル）は現行マシンより、Windows2000＋Oracle9iマシンに移行される事が決定しています。（ここで何故移行される事になったかは、残念ながら私には分かりません。） そこで私たちの話になるのですが、弊社担当分であるCOBOL資産についてはどうするか、を検討しているのですが、以下の理由でWindowsマシンへの移行を行うように方針が固まりつつあります。 ・インターフェースする基幹部分がWindows ＋ Oracle になるので合わせる。 （DBリンクキット、Open Database Access Kitによって現行のA-VX�献泪轡鵑里泙沺� という選択肢もあるとは思うのですが） ・COBOLのアプリケーションはともかく、現在のA-VX�献泪轡鵑魄靴┐訖佑�いない。 そのためWindowsマシン ＋ Oracleに乗せ替え、今後の保守性を上げたい。 （私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。 そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。） ・お客様の意向 （現在のA-VXマシンは出来れば捨てたい。また新サーバとしてExpressの購入は100%無理。 現在のA-VXマシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、 検討の余地あり。） 以上の理由から、Windowsマシンへの移行が有力となってきました。 そこで移行ツールでどれだけの事が出来るのかを検討するために、「移行ツール名を教えて欲しい」という前回のご挨拶になったわけです。 ただ、「お客様の意向」に書きましたとおり、現在のA-VXマシンを残しておく（別サーバのCOBOL環境に乗せ替えない）という案も消えた訳ではありません。ありませんが、可能性が薄い状態です。 ＞ ＊ Ａ−ＶＸが提供されている現在、「Ａ−ＶＸ」−−＞「ＣＯＢＯＬｆａｃｔｏｒｙ」に全面的に置き換える必要があるのでしょうか？ 東芝のようにいわゆる「オフコン」が中止になって「ＴＰ−ＣＡＲＥ」（ＮＥＣでいうところのＡ−ＶＸ実行環境）のようなものに移行せざるを得ないというなら別ですが。。 ＞ EXCHANGE さん お返事ありがとうございます。 私が「COBOL Factory」に置き換えようと考えたのは、上記のようにWindowsマシンに移行する、という前提で考えていたためです。現段階ではその前提が崩れる可能性は薄いように思われます。 また、データ移行に関して、＃NFCNV、SKYLINK 等の方法をご教授頂いてありがとうございます。 これからホームページ等で調べてみたいと思います。 ＞ バッチ処理の制御ユーティティは何が良いか考えなければなりません。ＮＥＣの場合でもＥＳＭＰＲＯ／ＪｏｂＣｏｎｔｒｏｌｌｅｒとＥＳＭＰＲＯ／ＪＭＳＳがあり「お客さの運用環境に合わせお選びください。」迷ってしまいます。 ＞ Ａ−ＶＸの場合はお任せセットなので、「そのな安定食はいやだ」というひとはダメですが、私の様に昼に何を食べたらよいか迷う人間にはうってつけです。 ＞ 江須扇さん 確かにCOBOLのみでなく、メニューや、バッチ制御など検討すべき点はたくさんあるのですね。 ずいぶん私の考えは抜けがあったように思います。ありがとうございます。 また、おっしゃるとおり同じA-VX で固めてしまうのが個人的には安心出来るのですが、上記の理由で（特にお客様の意向で）それも叶わず、Windowsマシンへの移行を検討している次第です。 ＞ 私が使ったことがあるのは、NECの８番街の「600シリーズ」->「A-VX」->「ソフトウェア一覧」のところにある、Filvertという製品です。 ＞ A-VX/RDBもCOBOLのファイルも変換できます。GUIを使って変換もできますし、バッチで一括変換も可能です。 ＞ 機能としては、まあまあだと思います。 ＞ ターヤランさん Filvertについてはホームページで少し見たことがあったのですが、何に使うツールかわからなかったため（恥ずかしいです・・）読み飛ばしていました。データファイルもRDBも変換出来るツールだったのですね。 今から調べさせて頂きます。ありがとうございました。 ＞ OpenDatabaseAccessKitですが、実は私は使ったことが無いので、実際使えるものなのかどうか、わかりません。そこのところは了承してください。 ＞ ターヤランさん もちろんこれだけの情報と意見頂きましたので、後は全て私の責任で調査し直します。 ありがとうございます。 |
|
| 7 | Re: COBOL資産の移行について |
| ＥＸＣＨＡＮＧＥ 2003-9-29 10:14
[返信] [編集] まゆちんさん、こんにちわ。 ＊ 今回の書き込みを読ませて頂いて背景が少し分かりました。 ＊ Ａ社とまゆちんさんの会社との間がどのようにシステムを分担されているのかよく分かりませんが、また、Ｗｉｎ＋ｏｒａの新システムの主要部分を構築するのが引き続きＡ社なのかもよく分かりませんが、Ａ−ＶＸ−−＞ｏｒａのＤＡＴＡ変換はメイン側でも行われるはずなので、協調して開発ということなら何らかの「共同戦線」もしくは「取引」が可能なのでは？ ＊ 他社（Ａ社）がシステム導入の主導権を持っておられるのでしたら、９ｉのバージョンとかは、まゆちんさんの側で選べない。 とすると、ＡＶＸマシンを残してＯｐｅｎＤＢａｃｃｅｓｓｋｉｔを使う方法は対応バージョンが９．０だったと思うので ９．２の場合ちょっと問題がありそうで、どのみちＡＶＸを残すのは難しい感じでしょうね。。 ＊ メイン側がｗｉｎ＋ｏｒａなのでしたら、「若干小規模なシステム側」の構築が「なぜＣＯＢＯＬなのか」が逆に分かりませんが、やはりこういう場合コンバートの方が早いのでしょうか？ 私はすきっとしたのが好きなので、ｏｒａのツールか、ＶＢとかでやり直したくなっちゃいます。 まあその辺はいろいろ事情がありますでしょうから。。 ＊ すみません。外野席からいろいろ余計なことを申してしまいました。しょせんわれわれは外野席の評論家で、一番大変なのは当事者のまゆちんさんでしょう。 健闘を祈る！！ |
|
| 8 | ＥＸＰＲＥＳＳ５８００／６８０？（ＣＯＢＯＬ資産） |
| 江須扇 2003-9-29 14:53
[返信] [編集] 返信ありがとうございます。江須扇です。 > まず、なぜCOBOL資産を、別のCOBOL環境に移行しようと思っているかについてですが、背景から申し上げます。 > マシンはEXPRESS 8500/680、OSは A-VX�検�Rは分かりません。すみません。）です。 Ｅｘｐｒｅｓｓ５８００／６８０ですよね。ＡＤとはＡｉがついてないのなら初期モデルですかね？ 多分年代的に１９９７年〜９８年でＲ１．０〜Ｒ２．０ですかね？ そろそろ買い換え時期のマシンと言うところでしょうか？ > このホストに別会社Ａ社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。 共にそのＥＸＰ６８０（Ｅｘｐｒｅｓｓ５８００／６８０を以下略して書きます。）上で構築されているのですよね。 私から見るとＥＸＰ６８０は汎用機の小型化並なのでかなり全体システムは大きいと見ました。 従ってＯｒｃｌｅの場合もＤＢサーバーとアプリケーションサーバーとは別になり、クライントも別になる三層構造になるのではと思いますが違いますか？ > 現在、Ａ社担当分である基幹系のCOBOL資産（アプリケーション、RDB、データファイル）は現行マシンより、Windows2000＋Oracle9iマシンに移行される事が決定しています。（ここで何故移行される事になったかは、残念ながら私には分かりません。） > そこで私たちの話になるのですが、弊社担当分であるCOBOL資産についてはどうするか、を検討しているのですが、以下の理由でWindowsマシンへの移行を行うように方針が固まりつつあります。 > ・インターフェースする基幹部分がWindows ＋ Oracle になるので合わせる。 > （DBリンクキット、Open Database Access Kitによって現行のA-VX�献泪轡鵑里泙沺� > という選択肢もあるとは思うのですが） Ａ−ＶＸ�犬魄楾圓�スムーズに出来るという人がいるという前提ですが、「若干小規模な別のＣＯＢＯＬ資産」ＥＸＰ６４０Ａｉか６２０Ａｉクラスにダウンサイジングして基幹システムのＯｒａｃｌｅにはＯｐｅｎＤａｔａｂａｓｅＡｃｃｅｓｓｋｉｔで参照更新をするという方法もありますが、 > ・COBOLのアプリケーションはともかく、現在のA-VX�献泪轡鵑魄靴┐訖佑�いない。 > そのためWindowsマシン ＋ Oracleに乗せ替え、今後の保守性を上げたい。 > （私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。 > そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。） ということであれば、切り離してＡＰ環境／開発セット＆ＡＰ環境／実行セットで小規模のＥＸＰ１００シリーズで基幹システムには、ＤＢリンクで参照更新するということですね。 運用性の統一という事で運用環境は基幹システム側の開発の方にお任せということであらば楽チンですね。 > ・お客様の意向 > （現在のA-VXマシンは出来れば捨てたい。また新サーバとしてExpressの購入は100%無理。 > 現在のA-VXマシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、 > 検討の余地あり。） > > 以上の理由から、Windowsマシンへの移行が有力となってきました。 > そこで移行ツールでどれだけの事が出来るのかを検討するために、「移行ツール名を教えて欲しい」という前回のご挨拶になったわけです。 > ただ、「お客様の意向」に書きましたとおり、現在のA-VXマシンを残しておく（別サーバのCOBOL環境に乗せ替えない）という案も消えた訳ではありません。ありませんが、可能性が薄い状態です。 お客様には現在のバージョンは低いので移行ツールを載せるという前提で最小のＥｘｐ６２０Ａｉか６２０Ａｉ−Ｓは用意してもらったほうが良いと思います。 ６２０Ａｉ−Ｓはハードは６８０Ａｉ等から比べれば一桁違いますのでお手軽です。ただ、ＣＯＢＯＬ８５、ＲＤＢサーバー、Ａ−ＶＸ／ＮＥＴ、ＥＵＦ�兇世肇廛蹈瀬�トを揃えるとそれなりの値段になります。 有償ソフトでハード以上の値段になるかもしれません。 保険の意味でもなにかと便利と思いますので是非ご検討して見てはいかがかと思います。 |
|
| 9 | Re: ＥＸＰＲＥＳＳ５８００／６８０？（ＣＯＢＯＬ資産） |
| ＥＸＣＨＡＮＧＥ 2003-9-29 17:54
[返信] [編集] ＊ 毎度お騒がせいたしております。ＥＸＣＨＡＮＧＥです。 ＞ 私から見るとＥＸＰ６８０は汎用機の小型化並なのでかなり全体システムは大きいと見ました。 従ってＯｒｃｌｅの場合もＤＢサーバーとアプリケーションサーバーとは別になり、クライントも別になる三層構造になるのではと思いますが違いますか？ ＞ｅｎｄ ＊ そうでしたね。６８０でしたね。気が付きませんでした。 ＊ でも、この案件で、最初っから素朴に分からないのですが、 （特にこれぐらいの大規模なシステムの場合）ＳＫＹＬＩＮＫとかを利用してないっていうのが。。。不思議で。。。 ＞”私たちの会社が”構築した若干小規模な別のCOBOL資産があります。 ＞ｅｎｄ ＞現在のA-VX�献泪轡鵑髻桧靴┐訖佑�いない” ＞ｅｎｄ ＞A-VXに関して正直スキルがありません ＞ｅｎｄ ＊ これらがどう関わっているのかも。。。 そして、 ＞運用環境は基幹システム側の開発の方にお任せ ＞ｅｎｄ 出来るような関係なら、 ６８０で基幹のＡ社がｄａｔａのことも教えてくれるだろうし、 お任せ出来ない関係なら、 ＡＶＸのスキルのないところで ＞ＡＰ環境／開発セット＆ＡＰ環境／実行セットで ＞ｅｎｄ うまくコンバージョンできるのでしょうか？ ＊ う〜〜む、比較的小規模しかあつかったことのない私にはこういう複雑な方程式（関係式）はうまく解けないようです。 |
|
| 10 | Re:Ｏｒａｃｌｅ（COBOL資産） |
| 江須扇 2003-9-30 3:39
[返信] [編集] 追伸です。 ＞・COBOLのアプリケーションはともかく、現在のA-VX�献泪轡鵑魄靴┐訖佑�いない。 ＞そのためWindowsマシン ＋ Oracleに乗せ替え、今後の保守性を上げたい。 ＞（私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。 ＞そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。） 私も古いＯｒａｃｌｅしか知りませんので最新版はわかりませんが、 むかし講習会に出たとき、Ｏｒａｃｌｅの担当者が「デフォルト（規定値、標準値）で設定すると巧く動きません、こことこととここの値はこれこれに変更してください。」と言うのがたくさん有り、 「こりゃダメだ」と私はすごすごと会場をさった記憶があります。 昔のＯｒｃｌｅのチューニングはそれりに、Ｆ１のピットクルー並に専門知識が必要と思っておりました。 今のＯｒｃｌｅは誰でも使えるのですか？ またＶＢでＯＤＢＣで作った更新処理がやたらと時間がかかったのですが、「なんとかＳＱＬ」で作ったらあっというまに終わったというマヌケな話もありました。 テーブルスペースやテーブルもいいかげんに登録したらすぐにオーバーフローして困りました。名前は忘れましたが、ロールバック用のエリアがすくなかったので、バッチ更新途中でこけてしまった記憶もありつらい記憶ばかりです。 以前にも書いたＲＥＤＥＦＩＮＥＳやＯＣＣＵＲＳにはくれぐれもご注意を召されるように。。。。 |
|
| 11 | Re:工数が劇的に減る？（COBOL資産） |
| 江須扇 2003-9-30 13:52
[返信] [編集] 再度の追伸です。 ＞マシンはEXPRESS 8500/680、OSは A-VX�検�Rは分かりません。すみません。）です。 ８５００というのはＮ８５００でＮＥＣ社内ではＮ型番と言っているものかもしれません。 ちなみに当初のＥｘｐｒｅｓｓｓ５８００はＮ８５００型番でした。 現在でもＥｘｐ１００シリーズはそのようです。 Ｅｘｐ６００シリーズは現在はＮ８６００型番と思います。 Ｎ型番はＮＥＣの営業以外は何のことかわかりません。 私もＮ８５００−ｘｘｘと言われたもまったく解かりません。 本体前面に書いてある商品名 ＥＸＰＲＥＳＳ５８００／６Ｘ０ｘｘｘｘ Ｘは１、２、４、５、７、８、９ ｘｘｘｘは無印、ＡＤ、Ａｉ、Ａｉ−ｓ で通常は表現しております。 もし、マシンを見る機会があればご確認ください。 ＞・COBOLのアプリケーションはともかく、現在のA-VX�献泪轡鵑魄靴┐訖佑�いない。 ＞（私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。 これはまゆちんさんの会社のメンバーの事ですか？ というとは乗せ買え以前に、現状の状況を確認する事も難しいのではと思います。 ＣＯＢＯＬソース、ＳＭＡＲＴのパラメータ、ユーティリティのパラメータ、メニュー、データベース定義等はどのように確認して移行を考えていらっしゃるのですか？ ＞そのためWindowsマシン ＋ Oracleに乗せ替え、今後の保守性を上げたい。 Ｗｉｎｄｏｗｓマシンとはサーバーの事ですか？ 個人的には基幹業務系のミッションクリティカルシステムはやっぱりＵＮＩＸと思います。 クライアントはＡ−ＶＸもＷｉｎｏｄｏｗｓマシンです。 現状のＡ−ＶＸ−ＣＯＢＯＬベースのバッチシステムをそのまま乗せ替えるのは、「木に竹を接ぐ」で無理があります。 現状のソリューションを見直し１からＯｒａｃｌｅにあったシステムを作るのが本筋と思います。 即時更新とストアードプロシージャにしてＯｒａｃｌｅに合ったシステムにしないと保守性は上がりません。 ＞そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。） 誰にもとは誰でしょう、少なくとも私は扱えません。（関係ないですね） しかし、Ａ−ＶＸは奥が深くないので覚えてしまえば、トラブル無く使えますが、 Ｗｉｎｄｏｗｓは次から次えと新しいものが出てきて、９５、９８、Ｍｅ、ＮＴ、２Ｋ、ＸＰと同じようで、少しづつ違い、私には訳が解からない現象でいつも悩まされています。 こんなＯＳで基幹業務をやりたいとは思いません。 ましてや前回も書きましたがＯｒａｃｌｅは奥が深く底なし沼に落ちそうで大変怖いです。 ＞このホストに別会社Ａ社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。 ＞現在、Ａ社担当分である基幹系のCOBOL資産（アプリケーション、RDB、データファイル）は現行マシンより、Windows2000＋Oracle9iマシンに移行される事が決定しています。（ここで何故移行される事になったかは、残念ながら私には分かりません。） ＞そこで私たちの話になるのですが、弊社担当分であるCOBOL資産についてはどうするか、を検討しているのですが、以下の理由でWindowsマシンへの移行を行うように方針が固まりつつあります。 ＞・お客様の意向 ＞（現在のA-VXマシンは出来れば捨てたい。また新サーバとしてExpressの購入は100%無理。 ＞現在のA-VXマシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、 ＞検討の余地あり。） これはどういう意味でしょうか？「若干小規模な別のＣＯＢＯＬ資産」の部分だけの事ですよね。 顧客様自身もＡ−ＶＸの保守はできない運用もできないということでしょうか？ なにも手を加えないのであれば、Ａ−ＶＸのまま移行が一番工数は少ないと思います。 つまり前回の提案のようにこの部分だけ小さなＥｘｐ６００に移行するという考えです。 現状のシステムを改善したというのであれば、 Ａ−ＶＸを熟知している人が改善するのであればやはりＡ?ＶＸでの移行が一番工数が少ないと思います。 Ａ−ＶＸを知らないという前提であれば、 いちから見直しソリューションすべきと思います。その方が工数は少ないと思います。 現状のＣＯＢＯＬ資産を無理やりＯｒａｃｌｅに乗せ替えるが一番工数もかかり保守性も悪いと思います。 あくまでもＡ−ＶＸ大好き人間の戯言と聞き流してください。 |
BluesBB ©Sting_Band