[掲示板に戻る]

---

Re: そのまんまＡ−ＶＸが欲しい（ＮＥ... 江須扇 2015-5-12 21:42

Re: そのまんまＡ−ＶＸが欲しい（ＮＥ... こんこん 2015-5-13 20:32

Re: まずはＳＭＡＲＴ／ＣＳ（ＮＥＣの... 江須扇 2015-6-3 11:08

---

1	Re: そのまんまＡ−ＶＸが欲しい（ＮＥＣの新しいＣＯＢＯＬ）
	江須扇 2015-5-12 21:42  [返信] [編集] ＣＯＢＯＬ　ＳＥ　Ｖ１　は カタログなどでは簡単に移行を強調してますが 実際はそのまんまでは使えずかなりめんどくさい 移行作業が必要です。 特にＰＭやＪＳは全く使えないのではと思います。 どちらにしても全自動移行ツールはあるのだろか？ メーカーに先を見越したロードマップがなく いままでは旧Ａ−ＶＸ（ＩＴＯＳ）から新Ａ−ＶＸへの移行は そのままコピーで動きました。 販売店もユーザーもそれに乗っかりました。 これが良かったのですがいまとなっては仇になっています。 つまり、ＷｉｎｄｏｗｓのようにＯＳが進化するごとに そのまんまでは使えないという制限が入り移行時に 当たり前の様に見直しがありました。 逆にＡ−ＶＸはそれがなかったツケがどっと来たという感じです。 旧バージョンから次のバージョンは動作がするが開発はできないというような制限をつけてほしかった。 例えばＳＭＡＲＴはＳＭＡＲＴ２に成った時、１バージョンの移行はＯＫだがその次はできなくって すべてＳＭＡＲＴ２の開発としてその次はＳＭＡＲＴ／ＣＳだけのリリースでＳＭＡＲＴ２も使えなくなるというよな考え方です。 ＲＤＢＱもＲＤＢＱ２になってもそのまま使い続けていましたが 使えなくしてＲＤＢサーバーからのツールしか使えないようにした方が良かったのではと思います。 どんどんツールをオープン化して最後にデータベースを移行してくださいというロードマップがあれば良かったのです。 しかしそうしなかったメーカーは責任があると思います。 現時点ではレガシーデバイスは動かないが 標準のＷｉｎｄｏｗｓサーバーで動作するＡ−ＶＸ／ＲＤＢをリリースして欲しいと思います。 もちろんＡ−ＶＸ／ＮＥＴもＰＣ／ＷＳ−ＥＭＬもＬＭもＰＭもＪＳも動くようにして欲しい。 但し次を考え開発はできないという制限です。 ツールも基本的にはオープンのものを使います。 ＲＤＢサーバーよＲＤＢ／ＦＩＬＥアクセスキット使って開発をするという考え方です。 データもオープン系のツールで確認するという方法です。
2	Re: そのまんまＡ−ＶＸが欲しい（ＮＥＣの新しいＣＯＢＯＬ）
	こんこん 2015-5-13 20:32  [返信] [編集] 『個人用ＡＶＸとして』として意見を書きましたが、実際には実務でも十分耐えられると思います。 ただし足回り(通信、印刷)はいろいろ考えなければなりませんが…
3	Re: まずはＳＭＡＲＴ／ＣＳ（ＮＥＣの新しいＣＯＢＯＬ）
	江須扇 2015-6-3 11:08  [返信] [編集] いきなりマイグレーションは難しいのでＡ−ＶＸ運用のままで Ａ−ＶＸ　ＲＤＢ／ＦＩＬＥアクセスキットを利用して 【第１ステップ】 としてＳＭＡＲＴ、ＳＭＡＲＴ２を排除する為に にすべてＳＭＡＲＴ／ＣＳに移行を考えます。 ここで運用可否かどうかわかり、ＣＯＢＯＬに移行するかどうか ＪＳをどうするかが見えてくると思います。 【第２ステップ】 としてＣＯＢＯＬを移行ですがＣＳＥがアクセスキットに対応しているかどうか解らないので ＣＯＢＯＬ８５　Ｐｒｏに移行するしかないと思います。 ＷＳ−ＥＭＬ環境で実行を考えるので、 エミュレータを２つ使うややこしい環境になるのではと思います。 メニュー等の移行ができると思います。 【第３ステップ】 としてＤＢの移行ですが、いきなりメジャーなＯｒａｃｌｅへ 移行するが安全をみてＩＦＡＳＰＲＯ／ＲＤＢに移行するという考え方です。 メリットとしては現状を運用しながらサブシステム単位でも移行可能と考えます。 現状のＡ−ＶＸを引っ張れるだけ引っ張るという事です。 何年も掛けるのでコストは掛かると思いますが大きなトラブルは 避けられます。 スクラックビルドで だらだらとするのは嫌だという方には向かないですが・・・・