|
1:COBOL資産の移行について まゆちん 09/24 02:57 ターラヤンさん、みなさん始めまして。まゆちんです。 A-VXの事を検索エンジンで調べていたら、このHPの存在を知りました。 私の職場でもExpress5800のA-VX�犬鮖箸辰討泙靴董△海鵑�HPがあったなんて、同士の方がいらっしゃるみたいで嬉しくなりました。 出来れば今後ともよろしくお願いします。 一つご存知だったら教えて頂きたい事があるのですが、私の職場でもそろそろA-VXからオープン系に移行していこうという動きがありまして、その中で資産をどうやって移行していこうか、という話を検討している段階です。 そこで現在、COBOLのアプリケーション、COBOLのアプリケーションが接続していたA-VX/RDB、同じくCOBOLのアプリケーションが接続していたA-VX内のデータファイル、の３つを移行するために、よいツールは無いか、と検討しております。 このうち、COBOLのアプリケーションについてはOpenCOBOLFactory21という実行環境があることを知り、実現出来そうなのですが、残りの２つ（RDB、データファイル）の移行できるツールについては全く分かってないのです。 ツールの一括変換で簡単に出来るとは思っていませんが、そういうツールがあるのかどうかも分かっていない状態です。 NECのHP等見たのですが、勉強不足もあり見つけられませんでした。 よいツール等もしご存知でしたら、ツール名を教えて頂けないでしょうか？ ちなみにターラヤンさんが書かれていた、OpenDatabaseAccessKitのついての記事は読ませて頂きました。 ありがとうございました。 2:Re: COBOL資産の移行について ＥＸＣＨＡＮＧＥ 09/24 22:16 ＊ データの移行は一括変換するのなら現在のＡ−ＶＸ４であればそれほどむずかしいことではないと思いますが。。 ＊ むしろ、データ件数が多く稼働時間の長いシステムの場合、 締処理との関連などで「乗せ換えのタイミング」をどうするのか、とかいった問題のほうが難しいのではないでしょうか？ ＊ 「これを機会にシステム変更を行う」という場合はデータ項目間の整合性のある変換はさらに大変な難しさが発生すると思います。 ＊ 「乗せ換えに関してはデータを甘く見るな」 というのが法則です。 ＊ 一括変換で良いのなら、Ａ−ＶＸ３、Ａ−ＶＸ４の場合、 （１）＃ＮＦＣＮＶ、 ＃ＮＦＬＮＫ などを使用してＣＳＶなどに変換後、他のＤＢに取り込む。 （２）イースト社の「ＳＫＹＬＩＮＫ」を使ってＣＳＶに落とす。 などで可。 レプリケーション機能などもＤＢ定義の変換に使えるかも。。 ＊ Ａ−ＶＸ２（Ｓ７２００）の場合、（１）が使えないとおもうので、手っ取り早いのは（２）の方法かしら。。 ＊＊＊＊ さて、ここから「本題」 ＊＊＊＊ ＊ Ａ−ＶＸが提供されている現在、「Ａ−ＶＸ」−−＞「ＣＯＢＯＬｆａｃｔｏｒｙ」に全面的に置き換える必要があるのでしょうか？ 東芝のようにいわゆる「オフコン」が中止になって「ＴＰ−ＣＡＲＥ」（ＮＥＣでいうところのＡ−ＶＸ実行環境）のようなものに移行せざるを得ないというなら別ですが。。 ＊ 私なら、 （１）すでにＡ−ＶＸで構築したシステムを「リニューアル」する形で高度化する。 （２）「入力系」「照会系」「営業支援系」などでどうしてもＧＵＩを使った画面が必要な場合は、「ＡＶＸ／ＲＤＢアクセスキット」などを使用してＶＢ、ＡＣＣＥＳＳなどで作り込む。 （３）レプリケーション機能（これは無料で付いてくる！！） を活用する。 等々です。 ＊ 一般論として、江須扇さんのおっしゃるとおり、 「現在のＡ−ＶＸの機能を十分生かすべき」だと思いますし、新機能を利用すれば、Ａ−ＶＸ中心でかなりなことが出来ると思います。 ＊ 先ほどの、「ＳＫＹＬＩＮＫ」などもＡ−ＶＸ２の時代から利用できたように思うのですが。。 また、現在のレプリケーションなどはかなり強力な機能だと思うのですが。。 これらをすでに十分利用された上での純オープン系への移行でしょうか？ それともコスト面を考えての移行でしょうか？ 3:Re: COBOL資産の移行について 江須扇 09/25 14:08 はじめまして、江須扇と申します。 宜しくお願いします。 ＥＸＣＨＡＮＧＥさんのレスが既にあがっているのでダブりますが、呼ばれたような気がして出てきました。 Ａ−ＶＸ大好き人間ですので、割引いてお読みください。 移行後のデータベースは何をお使いになるのですか？ それによって違いますが、私なりの経験を踏まえ書きます。 Ａ−ＶＸのＣＯＢＯＬの場合はＲＥＤＥＦＩＮＥＳやマルチレコードまたＯＣＣＵＲＳの繰り返し項目が使えますが、殆どのデータベースがその様な考え方がないと思います。 Ａ−ＶＸのＣＯＢＯＬのコーディング上では、レコード単位で移送（ＭＯＶＥ）して処理している場合もありますが、項目単位でしか処理できない場合もありますので、場合によっては移行システムの開発が必要になると思います。 Ａ−ＶＸの場合は、ハードウェア、ＯＳ（本当のＯＳはＷ２ＫですがＮＥＣが専用Ｈ／Ｗで動作保障をＷ２Ｋ上でしています。）データベース、運用環境、運用ユーティリティが一体でメーカーの動作保障をしています。また、ソフト資産の移行をかなりの部分で保障しております。 従って、旧機種から、新機種にそのまま何も手をくわえなくても移行出来る選択肢も選べます。 つまり、仮に１０００本のプログラムが有った場合。１０００本とも新機種に移行してそれから、あるサブシステムだけ新しくするという事もできます。 しかし、他の機種で移行しようと考えると全てのシステムを移行しないとなりません。システム規模にもよりますが、「取り合えずこの部分はそのままでいい」という選択肢は選べません。 また、苦労して移行しても次の様な問題もあります。 古い話ですが仮にＯｒａｃｌｅ６、ＶＢ４、ＷＮＴで作ったシステムが有ったとすると、それを現時点で移行しようとすると誰も動作保障をしてくれませんし、そのまま移行する手段がありません。（これは、今の最新版を選んでも次回に同じ事が言えると思います。） また、移行の時、ＣＯＢＯＬだけに目が行きますが、データの移行の問題以外に、運用環境等にも注意を払う必要があります。 メニュー等のユーザーインタフェース、ＪＣＬ等のバッチ処理方法、ＪＣＡ等のオンラインの処理などです。 また、ユーティリティもユーザー自身が揃えなければなりません。バックアップユーティリティは何がいいかとか考えなければなりません。 印刷処理も案外忘れがちですが、インチピッチで設計されている専用帳票にＶＢから印刷するのは結構難しいと思います。 バッチ処理の制御ユーティティは何が良いか考えなければなりません。ＮＥＣの場合でもＥＳＭＰＲＯ／ＪｏｂＣｏｎｔｒｏｌｌｅｒとＥＳＭＰＲＯ／ＪＭＳＳがあり「お客さの運用環境に合わせお選びください。」迷ってしまいます。 Ａ−ＶＸの場合はお任せセットなので、「そのな安定食はいやだ」というひとはダメですが、私の様に昼に何を食べたらよいか迷う人間にはうってつけです。 しかも、ＯＳ、ＤＢ、開発言語、運用環境の相性と動作保障はユーザー自身が責任をもってする必要があります。 これをメーカー任せにするという事になると、ＥＸＰ１００の場合は、Ｗ２Ｋ上でＩＦＡＳＰＲＯ／ＲＤＢ、ＡＰ環境／開発セット、ＡＰ環境／クライアント開発セット、ＡＰ環境／実行セット、という事になります。 従って、ここまで揃えるのであれば、究極はＥＸＰ６００のＡ−ＶＸに行き着きます。 この、三段論法は如何でしょうか？ > ターラヤンさん、みなさん始めまして。まゆちんです。 > A-VXの事を検索エンジンで調べていたら、このHPの存在を知りました。 > 私の職場でもExpress5800のA-VX�犬鮖箸辰討泙靴董△海鵑�HPがあったなんて、同士の方がいらっしゃるみたいで嬉しくなりました。 > 出来れば今後ともよろしくお願いします。 > > 一つご存知だったら教えて頂きたい事があるのですが、私の職場でもそろそろA-VXからオープン系に移行していこうという動きがありまして、その中で資産をどうやって移行していこうか、という話を検討している段階です。 > そこで現在、COBOLのアプリケーション、COBOLのアプリケーションが接続していたA-VX/RDB、同じくCOBOLのアプリケーションが接続していたA-VX内のデータファイル、の３つを移行するために、よいツールは無いか、と検討しております。 > このうち、COBOLのアプリケーションについてはOpenCOBOLFactory21という実行環境があることを知り、実現出来そうなのですが、残りの２つ（RDB、データファイル）の移行できるツールについては全く分かってないのです。 > ツールの一括変換で簡単に出来るとは思っていませんが、そういうツールがあるのかどうかも分かっていない状態です。 > > NECのHP等見たのですが、勉強不足もあり見つけられませんでした。 > よいツール等もしご存知でしたら、ツール名を教えて頂けないでしょうか？ > > ちなみにターラヤンさんが書かれていた、OpenDatabaseAccessKitのついての記事は読ませて頂きました。 > ありがとうございました。 4:Re: COBOL資産の移行について tahrayan 09/25 16:09 まゆちんさん、はじめまして。 既にいろいろな方から返事をしていただいているようですので、 データを移行するツールだけ、返事をしておきます。 A-VX4ならば、いろいろな手段があります。 #NFCNVなどは、A-VX標準で付いています。一旦順編成にしてからバッチなどでWindows環境に移行する、ということができます。 標準の機能なので、それなりの機能しかありません。 A-VX/RDBのデータならば、SKYLINKなどを利用することができると思います。その他、私のリンクのところには、いくつか変換するツールを出している会社のアドレスがあります。（使ったことがないものもありますので、どれが良いかはわかりません。） 私が使ったことがあるのは、NECの８番街の「600シリーズ」->「A-VX」->「ソフトウェア一覧」のところにある、Filvertという製品です。 A-VX/RDBもCOBOLのファイルも変換できます。GUIを使って変換もできますし、バッチで一括変換も可能です。 機能としては、まあまあだと思います。 OpenDatabaseAccessKitですが、実は私は使ったことが無いので、実際使えるものなのかどうか、わかりません。そこのところは了承してください。 私自身勉強不足で、最近までA-VX4になってからの新機能はあまり知りませんでした。特に２，３年、オフコン関連の業務から離れておりました。去年の年末に、オフコンについて、新しい連中に教えてほしいということで、オフコンの方に戻ってきました。 教える立場となり、最近の機能についてもいろいろと教える必要ありと言うことで、いろいろと勉強し始めてみたのですが、新機能を含めて、あまりにも知らないことが多すぎ、勉強不足を恥じているところです。 今年に入ってから、暇を見ては、密かに新機能について勉強しているところです。 このサイトは、教育の下調べで集めた資料から、公開してもよさそうなものを出しています。 オフコンの歴史についての情報もたくさん入手したのですが、これらは業務に一切関係ないので、会社の連中に詳細に教えても仕方がない、でもこのまま埋めるにはもったいないと思い、そのような情報を集めてこのサイトを作っています。 5:Re: x2: COBOL資産の移行について（訂正補足追加） 江須扇 09/27 02:43 すいません、一部、誤記がありますので、前文は下記の部分訂正をします。 バッチ処理の制御ユーティティは何が良いか考えなければなりません。ＮＥＣの場合でもＥＳＭＰＲＯ／ＪｏｂＣｏｎｔｒｏｌｌｅｒとＥＳＭＰＲＯ／ＪＭＳＳがあり「お客さの運用環境に合わせお選びください。」とＮＥＣに言われてもこちらも迷ってしまいます。 Ａ−ＶＸの場合はお任せセットなので、「そんな安定食はいやだ」というひとはダメですが、私の様に昼に何を食べたらよいか迷う人間にはうってつけです。 以上 以下補足です。 これをメーカー任せにするという事になると、ＥＸＰ１００の場合は、Ｗ２Ｋ上でＩＦＡＳＰＲＯ／ＲＤＢ、ＡＰ環境／開発セット、ＡＰ環境／クライアント開発セット、ＡＰ環境／実行セット、という事になります。 ＩＦＡＳＰＲＯ／ＲＤＢは http://www.ace.comp.nec.co.jp/ifasrdb/index.htm ですが、ＡＰ環境／開発セット、ＡＰ環境／クライアント開発セット、ＡＰ環境／実行セットに含まれていました。 http://www.ace.comp.nec.co.jp/apset/ メニューはその中にあるＸＭＥＮＵで移行できそうです。 http://www.ace.comp.nec.co.jp/xmenu/index.htm ＪＳはわかりません。 しかし、ここまで、Ａ−ＶＸに似せて移行するなら、ＥＸＰ６００シリーズがあるかぎりこの考え方は中途半端です。 Ａ−ＶＸがなくなるとＮＥＣは表明してないので、なぜこの方法も平行して販売しているかの本音はわかりません。 私はこんな方式で移行するならＡ−ＶＸをお奨めします。 以上 以下追加です。 まゆちんさんはの所のＡ−ＶＸ�犬離弌璽献腑鵝複劭�.９９）はいくですか？ バージョンによってはできない場合もありますが、いろいろな方法で現在のＡ−ＶＸ�犬任皺椎修任后� 具体的なＯＰＥＮ化したい想定が解らないのでＱ＆Ａ式で書きます。 Ｑ１．印刷が１３６桁で制限されパソコンの様に小さくして印刷できない。 Ａ１．ＳＭＡＲＴ�僑釘悗�ＲＤＢ／ＥＵＦ�兇鮖箸┐弌■押殖海梁腓�さにでき、２００桁位可能です。 （ＣＯＢＯの場合はサブルーチンが提供されてないので、自分で１パイト文字−＞２バイト半角に変換が必要です。） また、ＰＣ／ＷＳ−ＥＭＬのページプリンタ系の指定でＬＰ−＞Ａ４、Ａ３−＞Ａ４にするば、見た目の大きさは小さくできます。 さらに、ＲＤＢサーバーやＲＤＢ／ＦＩＬＥアクセスキットでＡＣＣＥＳＳやＶＢ等で作れば可能です。 Ｑ２．画面の桁数行数が少ない。 Ａ２．ＰＣ／ＷＳ−ＥＭＬでは現時点では不可のですが、 Ｑ１．と同じようにＲＤＢサーバー等を利用する方法 Ｗｅｂ連携をする方法等です。（Ｑ３参照） Ｑ３．Ｗｅｂアプリケーションにしたい Ａ３．下記の４種類の方法を選べます。 イントラネット連携＜ウェブ連携＞ ＲＤＢ／ＦＩＬＥアクセスキット＋ＷＥＢＣＯＢＯＬ ＷＥＢｈａｒｍｏ／ＲＤＢＥＵＦ ＡＰアクセスオブジェクト Ｑ４．ＦＡＸ出力したい。 Ａ４．ＦＡＸ連携ライブラリの利用 Ｑ５．メール通知したい Ａ５．メール連携機能の利用 Ｑ６．その他 Ａ６．以下次のページを参照ください。 http://www.ace.comp.nec.co.jp/product/2nd/avx4/avx_home/avxHome.htm 以上 6:Re: COBOL資産の移行について まゆちん 09/29 07: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資産の移行について ＥＸＣＨＡＮＧＥ 09/29 10:14 まゆちんさん、こんにちわ。 ＊ 今回の書き込みを読ませて頂いて背景が少し分かりました。 ＊ Ａ社とまゆちんさんの会社との間がどのようにシステムを分担されているのかよく分かりませんが、また、Ｗｉｎ＋ｏｒａの新システムの主要部分を構築するのが引き続きＡ社なのかもよく分かりませんが、Ａ−ＶＸ−−＞ｏｒａのＤＡＴＡ変換はメイン側でも行われるはずなので、協調して開発ということなら何らかの「共同戦線」もしくは「取引」が可能なのでは？ ＊ 他社（Ａ社）がシステム導入の主導権を持っておられるのでしたら、９ｉのバージョンとかは、まゆちんさんの側で選べない。 とすると、ＡＶＸマシンを残してＯｐｅｎＤＢａｃｃｅｓｓｋｉｔを使う方法は対応バージョンが９．０だったと思うので ９．２の場合ちょっと問題がありそうで、どのみちＡＶＸを残すのは難しい感じでしょうね。。 ＊ メイン側がｗｉｎ＋ｏｒａなのでしたら、「若干小規模なシステム側」の構築が「なぜＣＯＢＯＬなのか」が逆に分かりませんが、やはりこういう場合コンバートの方が早いのでしょうか？ 私はすきっとしたのが好きなので、ｏｒａのツールか、ＶＢとかでやり直したくなっちゃいます。 まあその辺はいろいろ事情がありますでしょうから。。 ＊ すみません。外野席からいろいろ余計なことを申してしまいました。しょせんわれわれは外野席の評論家で、一番大変なのは当事者のまゆちんさんでしょう。 健闘を祈る！！ 8:ＥＸＰＲＥＳＳ５８００／６８０？（ＣＯＢＯＬ資産） 江須扇 09/29 14:53 > COBOLCOBOL�� > EXPRESS 8500/680OS A-VXR �V�� �過� > ��COBOL������COBOL ���T�� �T������ �����R�R�� > COBOLRDBWindows2000Oracle9i > ��COBOL��Windows > Windows Oracle �� > DBOpen Database Access KitA-VX�� > �� �����T�� > COBOL��A-VX > ��Windows Oracle纐�� > ��A-VX > ��OSWindowsOracle �R���t�t���T�� ���s > > A-VX�}���UExpress��100% > A-VX�q���R > > > Windows > ������ > A-VX�UCOBOL纐 ���R���� �p�������R�� �� 9:Re: ＥＸＰＲＥＳＳ５８００／６８０？（ＣＯＢＯＬ資産） ＥＸＣＨＡＮＧＥ 09/29 17:54 ＊ 毎度お騒がせいたしております。ＥＸＣＨＡＮＧＥです。 ＞ 私から見るとＥＸＰ６８０は汎用機の小型化並なのでかなり全体システムは大きいと見ました。 従ってＯｒｃｌｅの場合もＤＢサーバーとアプリケーションサーバーとは別になり、クライントも別になる三層構造になるのではと思いますが違いますか？ ＞ｅｎｄ ＊ そうでしたね。６８０でしたね。気が付きませんでした。 ＊ でも、この案件で、最初っから素朴に分からないのですが、 （特にこれぐらいの大規模なシステムの場合）ＳＫＹＬＩＮＫとかを利用してないっていうのが。。。不思議で。。。 ＞”私たちの会社が”構築した若干小規模な別のCOBOL資産があります。 ＞ｅｎｄ ＞現在のA-VX�献泪轡鵑髻桧靴┐訖佑�いない” ＞ｅｎｄ ＞A-VXに関して正直スキルがありません ＞ｅｎｄ ＊ これらがどう関わっているのかも。。。 そして、 ＞運用環境は基幹システム側の開発の方にお任せ ＞ｅｎｄ 出来るような関係なら、 ６８０で基幹のＡ社がｄａｔａのことも教えてくれるだろうし、 お任せ出来ない関係なら、 ＡＶＸのスキルのないところで ＞ＡＰ環境／開発セット＆ＡＰ環境／実行セットで ＞ｅｎｄ うまくコンバージョンできるのでしょうか？ ＊ う〜〜む、比較的小規模しかあつかったことのない私にはこういう複雑な方程式（関係式）はうまく解けないようです。 10:Re:Ｏｒａｃｌｅ（COBOL資産） 江須扇 09/30 03:39 COBOL��A-VX ��Windows Oracle纐�� ��A-VX ��OSWindowsOracle ������ �U�� ���������� ���� ���� �R�V�����V�T�U �� 11:Re:工数が劇的に減る？（COBOL資産） 江須扇 09/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マシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、 ＞検討の余地あり。） これはどういう意味でしょうか？「若干小規模な別のＣＯＢＯＬ資産」の部分だけの事ですよね。 顧客様自身もＡ−ＶＸの保守はできない運用もできないということでしょうか？ なにも手を加えないのであれば、Ａ−ＶＸのまま移行が一番工数は少ないと思います。 つまり前回の提案のようにこの部分だけ小さなＥｘｐ６００に移行するという考えです。 現状のシステムを改善したというのであれば、 Ａ−ＶＸを熟知している人が改善するのであればやはりＡ?ＶＸでの移行が一番工数が少ないと思います。 Ａ−ＶＸを知らないという前提であれば、 いちから見直しソリューションすべきと思います。その方が工数は少ないと思います。 現状のＣＯＢＯＬ資産を無理やりＯｒａｃｌｅに乗せ替えるが一番工数もかかり保守性も悪いと思います。 あくまでもＡ−ＶＸ大好き人間の戯言と聞き流してください。 |