Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

[掲示板に戻る]


Re: COBOL資産の移行について まゆちん 2003-9-29 7:35
Re: COBOL資産の移行について EXCHANGE 2003-9-29 10:14
EXPRESS5800/680?(C... 江須扇 2003-9-29 14:53
Re: EXPRESS5800/680?... EXCHANGE 2003-9-29 17:54
Re:Oracle(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は分かりません。すみません。)です。

このホストに別会社A社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。

現在、A社担当分である基幹系の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環境に乗せ替えない)という案も消えた訳ではありません。ありませんが、可能性が薄い状態です。





> * A−VXが提供されている現在、「A−VX」−−>「COBOLfactory」に全面的に置き換える必要があるのでしょうか? 東芝のようにいわゆる「オフコン」が中止になって「TP−CARE」(NECでいうところのA−VX実行環境)のようなものに移行せざるを得ないというなら別ですが。。



> EXCHANGE さん

お返事ありがとうございます。

私が「COBOL Factory」に置き換えようと考えたのは、上記のようにWindowsマシンに移行する、という前提で考えていたためです。現段階ではその前提が崩れる可能性は薄いように思われます。

また、データ移行に関して、#NFCNV、SKYLINK 等の方法をご教授頂いてありがとうございます。

これからホームページ等で調べてみたいと思います。





> バッチ処理の制御ユーティティは何が良いか考えなければなりません。NECの場合でもESMPRO/JobControllerとESMPRO/JMSSがあり「お客さの運用環境に合わせお選びください。」迷ってしまいます。

> A−VXの場合はお任せセットなので、「そのな安定食はいやだ」というひとはダメですが、私の様に昼に何を食べたらよいか迷う人間にはうってつけです。



> 江須扇さん

確かにCOBOLのみでなく、メニューや、バッチ制御など検討すべき点はたくさんあるのですね。

ずいぶん私の考えは抜けがあったように思います。ありがとうございます。

また、おっしゃるとおり同じA-VX で固めてしまうのが個人的には安心出来るのですが、上記の理由で(特にお客様の意向で)それも叶わず、Windowsマシンへの移行を検討している次第です。





> 私が使ったことがあるのは、NECの8番街の「600シリーズ」->「A-VX」->「ソフトウェア一覧」のところにある、Filvertという製品です。

> A-VX/RDBもCOBOLのファイルも変換できます。GUIを使って変換もできますし、バッチで一括変換も可能です。

> 機能としては、まあまあだと思います。



> ターヤランさん

Filvertについてはホームページで少し見たことがあったのですが、何に使うツールかわからなかったため(恥ずかしいです・・)読み飛ばしていました。データファイルもRDBも変換出来るツールだったのですね。

今から調べさせて頂きます。ありがとうございました。





> OpenDatabaseAccessKitですが、実は私は使ったことが無いので、実際使えるものなのかどうか、わかりません。そこのところは了承してください。



> ターヤランさん

もちろんこれだけの情報と意見頂きましたので、後は全て私の責任で調査し直します。

ありがとうございます。

7 Re: COBOL資産の移行について
EXCHANGE 2003-9-29 10:14  [返信] [編集]

  まゆちんさん、こんにちわ。



* 今回の書き込みを読ませて頂いて背景が少し分かりました。



* A社とまゆちんさんの会社との間がどのようにシステムを分担されているのかよく分かりませんが、また、Win+oraの新システムの主要部分を構築するのが引き続きA社なのかもよく分かりませんが、A−VX−−>oraのDATA変換はメイン側でも行われるはずなので、協調して開発ということなら何らかの「共同戦線」もしくは「取引」が可能なのでは?



* 他社(A社)がシステム導入の主導権を持っておられるのでしたら、9iのバージョンとかは、まゆちんさんの側で選べない。 とすると、AVXマシンを残してOpenDBaccesskitを使う方法は対応バージョンが9.0だったと思うので 9.2の場合ちょっと問題がありそうで、どのみちAVXを残すのは難しい感じでしょうね。。



* メイン側がwin+oraなのでしたら、「若干小規模なシステム側」の構築が「なぜCOBOLなのか」が逆に分かりませんが、やはりこういう場合コンバートの方が早いのでしょうか?

 私はすきっとしたのが好きなので、oraのツールか、VBとかでやり直したくなっちゃいます。 まあその辺はいろいろ事情がありますでしょうから。。



* すみません。外野席からいろいろ余計なことを申してしまいました。しょせんわれわれは外野席の評論家で、一番大変なのは当事者のまゆちんさんでしょう。 健闘を祈る!!

8 EXPRESS5800/680?(COBOL資産)
江須扇 2003-9-29 14:53  [返信] [編集]

返信ありがとうございます。江須扇です。



> まず、なぜCOBOL資産を、別のCOBOL環境に移行しようと思っているかについてですが、背景から申し上げます。

> マシンはEXPRESS 8500/680、OSは A-VX検Rは分かりません。すみません。)です。



Express5800/680ですよね。ADとはAiがついてないのなら初期モデルですかね?

多分年代的に1997年〜98年でR1.0〜R2.0ですかね?

そろそろ買い換え時期のマシンと言うところでしょうか?



> このホストに別会社A社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。



共にそのEXP680(Express5800/680を以下略して書きます。)上で構築されているのですよね。

私から見るとEXP680は汎用機の小型化並なのでかなり全体システムは大きいと見ました。

従ってOrcleの場合もDBサーバーとアプリケーションサーバーとは別になり、クライントも別になる三層構造になるのではと思いますが違いますか?



> 現在、A社担当分である基幹系のCOBOL資産(アプリケーション、RDB、データファイル)は現行マシンより、Windows2000+Oracle9iマシンに移行される事が決定しています。(ここで何故移行される事になったかは、残念ながら私には分かりません。)

> そこで私たちの話になるのですが、弊社担当分であるCOBOL資産についてはどうするか、を検討しているのですが、以下の理由でWindowsマシンへの移行を行うように方針が固まりつつあります。

> ・インターフェースする基幹部分がWindows + Oracle になるので合わせる。

> (DBリンクキット、Open Database Access Kitによって現行のA-VX献泪轡鵑里泙沺

> という選択肢もあるとは思うのですが)



A−VX犬魄楾圓スムーズに出来るという人がいるという前提ですが、「若干小規模な別のCOBOL資産」EXP640Aiか620Aiクラスにダウンサイジングして基幹システムのOracleにはOpenDatabaseAccesskitで参照更新をするという方法もありますが、



> ・COBOLのアプリケーションはともかく、現在のA-VX献泪轡鵑魄靴┐訖佑いない。

> そのためWindowsマシン + Oracleに乗せ替え、今後の保守性を上げたい。

> (私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。

> そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。)



ということであれば、切り離してAP環境/開発セット&AP環境/実行セットで小規模のEXP100シリーズで基幹システムには、DBリンクで参照更新するということですね。

運用性の統一という事で運用環境は基幹システム側の開発の方にお任せということであらば楽チンですね。



> ・お客様の意向

> (現在のA-VXマシンは出来れば捨てたい。また新サーバとしてExpressの購入は100%無理。

> 現在のA-VXマシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、

> 検討の余地あり。)

>

> 以上の理由から、Windowsマシンへの移行が有力となってきました。

> そこで移行ツールでどれだけの事が出来るのかを検討するために、「移行ツール名を教えて欲しい」という前回のご挨拶になったわけです。

> ただ、「お客様の意向」に書きましたとおり、現在のA-VXマシンを残しておく(別サーバのCOBOL環境に乗せ替えない)という案も消えた訳ではありません。ありませんが、可能性が薄い状態です。



お客様には現在のバージョンは低いので移行ツールを載せるという前提で最小のExp620Aiか620Ai−Sは用意してもらったほうが良いと思います。

620Ai−Sはハードは680Ai等から比べれば一桁違いますのでお手軽です。ただ、COBOL85、RDBサーバー、A−VX/NET、EUF兇世肇廛蹈瀬トを揃えるとそれなりの値段になります。

有償ソフトでハード以上の値段になるかもしれません。

保険の意味でもなにかと便利と思いますので是非ご検討して見てはいかがかと思います。



9 Re: EXPRESS5800/680?(COBOL資産)
EXCHANGE 2003-9-29 17:54  [返信] [編集]

* 毎度お騒がせいたしております。EXCHANGEです。



> 私から見るとEXP680は汎用機の小型化並なのでかなり全体システムは大きいと見ました。

 従ってOrcleの場合もDBサーバーとアプリケーションサーバーとは別になり、クライントも別になる三層構造になるのではと思いますが違いますか?

>end



* そうでしたね。680でしたね。気が付きませんでした。



* でも、この案件で、最初っから素朴に分からないのですが、

  (特にこれぐらいの大規模なシステムの場合)SKYLINKとかを利用してないっていうのが。。。不思議で。。。

 





>”私たちの会社が”構築した若干小規模な別のCOBOL資産があります。 >end



>現在のA-VX献泪轡鵑髻桧靴┐訖佑いない” >end

>A-VXに関して正直スキルがありません >end

 

* これらがどう関わっているのかも。。。



そして、

>運用環境は基幹システム側の開発の方にお任せ >end

出来るような関係なら、

680で基幹のA社がdataのことも教えてくれるだろうし、



お任せ出来ない関係なら、

AVXのスキルのないところで

>AP環境/開発セット&AP環境/実行セットで >end

うまくコンバージョンできるのでしょうか?



* う〜〜む、比較的小規模しかあつかったことのない私にはこういう複雑な方程式(関係式)はうまく解けないようです。

10 Re:Oracle(COBOL資産)
江須扇 2003-9-30 3:39  [返信] [編集]

追伸です。



>・COBOLのアプリケーションはともかく、現在のA-VX献泪轡鵑魄靴┐訖佑いない。

>そのためWindowsマシン + Oracleに乗せ替え、今後の保守性を上げたい。

>(私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。

>そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。)



私も古いOracleしか知りませんので最新版はわかりませんが、

むかし講習会に出たとき、Oracleの担当者が「デフォルト(規定値、標準値)で設定すると巧く動きません、こことこととここの値はこれこれに変更してください。」と言うのがたくさん有り、

「こりゃダメだ」と私はすごすごと会場をさった記憶があります。

昔のOrcleのチューニングはそれりに、F1のピットクルー並に専門知識が必要と思っておりました。

今のOrcleは誰でも使えるのですか?



またVBでODBCで作った更新処理がやたらと時間がかかったのですが、「なんとかSQL」で作ったらあっというまに終わったというマヌケな話もありました。

テーブルスペースやテーブルもいいかげんに登録したらすぐにオーバーフローして困りました。名前は忘れましたが、ロールバック用のエリアがすくなかったので、バッチ更新途中でこけてしまった記憶もありつらい記憶ばかりです。



以前にも書いたREDEFINESやOCCURSにはくれぐれもご注意を召されるように。。。。



11 Re:工数が劇的に減る?(COBOL資産)
江須扇 2003-9-30 13:52  [返信] [編集]

再度の追伸です。



>マシンはEXPRESS 8500/680、OSは A-VX検Rは分かりません。すみません。)です。



8500というのはN8500でNEC社内ではN型番と言っているものかもしれません。



ちなみに当初のExpresss5800はN8500型番でした。

現在でもExp100シリーズはそのようです。

Exp600シリーズは現在はN8600型番と思います。

N型番はNECの営業以外は何のことかわかりません。

私もN8500−xxxと言われたもまったく解かりません。

本体前面に書いてある商品名



EXPRESS5800/6X0xxxx

             Xは1、2、4、5、7、8、9

               xxxxは無印、AD、Ai、Ai−s



で通常は表現しております。

もし、マシンを見る機会があればご確認ください。



>・COBOLのアプリケーションはともかく、現在のA-VX献泪轡鵑魄靴┐訖佑いない。

>(私も半月前よりこの担当に配属され、A-VXに関して正直スキルがありません。



これはまゆちんさんの会社のメンバーの事ですか?

というとは乗せ買え以前に、現状の状況を確認する事も難しいのではと思います。

COBOLソース、SMARTのパラメータ、ユーティリティのパラメータ、メニュー、データベース定義等はどのように確認して移行を考えていらっしゃるのですか?



>そのためWindowsマシン + Oracleに乗せ替え、今後の保守性を上げたい。



Windowsマシンとはサーバーの事ですか?

個人的には基幹業務系のミッションクリティカルシステムはやっぱりUNIXと思います。

クライアントはA−VXもWinodowsマシンです。

現状のA−VX−COBOLベースのバッチシステムをそのまま乗せ替えるのは、「木に竹を接ぐ」で無理があります。

現状のソリューションを見直し1からOracleにあったシステムを作るのが本筋と思います。

即時更新とストアードプロシージャにしてOracleに合ったシステムにしないと保守性は上がりません。



>そのため、OSはWindowsに、データはOracleにして、誰でも扱えるようにしたい、という思いです。)



誰にもとは誰でしょう、少なくとも私は扱えません。(関係ないですね)



しかし、A−VXは奥が深くないので覚えてしまえば、トラブル無く使えますが、

Windowsは次から次えと新しいものが出てきて、95、98、Me、NT、2K、XPと同じようで、少しづつ違い、私には訳が解からない現象でいつも悩まされています。

こんなOSで基幹業務をやりたいとは思いません。

ましてや前回も書きましたがOracleは奥が深く底なし沼に落ちそうで大変怖いです。



>このホストに別会社A社の方が構築した基幹系のCOBOL資産があり、この資産を活用するための私たちの会社が構築した若干小規模な別のCOBOL資産があります。

>現在、A社担当分である基幹系のCOBOL資産(アプリケーション、RDB、データファイル)は現行マシンより、Windows2000+Oracle9iマシンに移行される事が決定しています。(ここで何故移行される事になったかは、残念ながら私には分かりません。)

>そこで私たちの話になるのですが、弊社担当分であるCOBOL資産についてはどうするか、を検討しているのですが、以下の理由でWindowsマシンへの移行を行うように方針が固まりつつあります。

>・お客様の意向

>(現在のA-VXマシンは出来れば捨てたい。また新サーバとしてExpressの購入は100%無理。

>現在のA-VXマシンを残しておくという考えは、今回の対応において工数が劇的に減るのであれば、

>検討の余地あり。)



これはどういう意味でしょうか?「若干小規模な別のCOBOL資産」の部分だけの事ですよね。

顧客様自身もA−VXの保守はできない運用もできないということでしょうか?

なにも手を加えないのであれば、A−VXのまま移行が一番工数は少ないと思います。

つまり前回の提案のようにこの部分だけ小さなExp600に移行するという考えです。

現状のシステムを改善したというのであれば、

A−VXを熟知している人が改善するのであればやはりA?VXでの移行が一番工数が少ないと思います。

A−VXを知らないという前提であれば、

いちから見直しソリューションすべきと思います。その方が工数は少ないと思います。

現状のCOBOL資産を無理やりOracleに乗せ替えるが一番工数もかかり保守性も悪いと思います。



あくまでもA−VX大好き人間の戯言と聞き流してください。



BluesBB ©Sting_Band