ＮＥＣのオフコン情報掲示板（いろいろ）
| ＮＥＣのオフコンに関しての最新情報、面白い話、昔の思い出、何でも自由に書いてください。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
| Re: 将来６００シリーズは巨大なドンガラ（空洞）と化すか？ | |
| ターラヤン 2004-1-26 16:51:58
[返信] [編集] 極一部の人は、最近はホスト集中に戻ってきたとか言っていますが、 やはり分散形態が一般的だと思いますし、 Ａ−ＶＸの上で動くソフトとWindows上のソフトを複数のサーバに分けて、 運用した方がより安定するのは確かだと思います。 （Ａ−ＶＸをwindows上で動かしている限りは、Windows上の変なソフトの 影響をA-VX側が受けてしまう可能性は否定できませんし。） 一方、やはり世間の流れから見れば、徐々にA-VX上のソフトをWindows 上で動くようにしたいという話もあり、だんだんA-VX上で動くソフトを 減らしていく傾向にあるのではないかと思います。 （オフコンのサイトを立ち上げている私としては、残念な話ですが。） そして残ったソフトもWindows上のソフトと連携させて動かすもののみ となってしまうのかもしれません。 ただ、そういう使い方をするところは、空洞になった段階で全部Windowsに 行ってしまい、600シリーズは捨ててしまうのではないでしょうか。 逆に今まで通りA-VXを使用しつづけるところは、空洞になることもなく、 600シリーズを十分に使い尽くす可能性もあります。 結局空洞にするかどうかは使い方次第だと思います。 | |
| 「将来６００シリーズは。。」 の（注釈）です | |
| ＥＸＣＨＡＮＧＥ 2004-1-25 22:08:19
[返信] [編集] > 「ＲＤＢＱ」や「ｓｋｙｌｉｎｋ」で大規模な検索をかけると「業務側」がグッと遅くなったり止まったりした記憶がおありではないだろうか？ ＊ Ａ−ＶＸをよくご存じない方が誤解してはいけないので、上記の部分に注釈を付け加えておく。 ＊ 正確には「グッと遅くなったり、しばし止まったようになったり」というのが正しい。 我がＡ−ＶＸにおいてはＷｉｎｄｏｗｓのように負荷がかかってハングアップしてしまうなどということは、まずありえないことである。 ＊ 筆者が恐れるのはＷｉｎｄｏｗｓ上で、Ａ−ＶＸの業務とＷｉｎｄｏｗｓ上の負荷のかかる業務とを同時に稼働させた場合、Ｗｉｎｄｏｗｓの道連れになってＡ−ＶＸ業務までコケてしまうことである。 | |
| 将来６００シリーズは巨大なドンガラ（空洞）と化すか？ | |
| ＥＸＣＨＡＮＧＥ 2004-1-25 20:42:18
[返信] [編集] ＊ 日本Ｕｎｉｓｙｓという会社のＨＰを訪れて、この会社の汎用機「ＣＳ７８０１−１８５」や「ＣＳ７４０２」「ＣＳ７２０１」などの資料をごらんいただきたい。 ここではＣＭＰというテクノロジーが使われ従来型ホスト系ＯＳと新しいオープン系ＯＳ（といってもＷｉｎｄｏｗｓのことだが）を同じ筐体内で同時に稼働させるようになっている。 ＣＳ７２０１に至ってはすべてのＣＰＵがインテル製で、ホストＯＳの方はインテルＣＰＵ上にエミュレーションソフトをかませてその上で稼働し、また同時にＷｉｎｄｏｗｓも稼働するようになっている。これは一見我らが６００シリーズと非常によく似たやり方にみえる。 ＊ ところでＵｎｉｓｙｓのようなやり方は現代のホスト系マシンではそれほど特異な方法ではない。それどころか「ホストＯＳ」を中心に据えながら同一筐体内で「ｗｉｎｄｏｗｓ」さらには「Ｌｉｎｕｘ」など複数のオープン系ＯＳを稼働させ連携を計るという方法はホストの世界では今日主流となっているといえる。 ＊ こういう観点から見れば、ＮＥＣが７００シリーズから始めて６００シリーズに至る一連の製品でＷｉｎｄｏｗｓ上でＡーＶＸを稼働させてきた方法論は時代の本流に沿ったやり方であるといって間違いないだろう。（ハードだけをＰＣ系に換えＯＳはホスト系ＡＳＰのみの改良で押し通す富士通はまさにオフコン原理主義といえるかもしれない） ＊ さて、６００シリーズに携わっておられる技術者、担当者の方は最近になって何か「あること」に気づいておられるのではないだろうか？ ハードウェア、とりわけメモリ、ディスクなどの低価格化で６００シリーズにおいても新モデル（直近では６００ｘｉ）が発売されるたびにスペックは拡大し続け、今や下位モデルにおいても少し増設すればメモリ１Ｇ以上、ディスク１００Ｇなどというのが十分可能になった。 ＊ 問題は、さてそこで、だ。 旧Ｓ７２００（オフコン）のわずかディスク９００ＭＢ×２台程度で「基幹業務」をこなしていたシステムの「資産継承」を「スムーズ」に行ったところで「はた」と困ってしまうのだ。 余ったディスク領域を一体何に使えば良いのか？ 現時点においてはこうした考えは「一瞬、担当者の頭をよぎる程度のもの」かもしれない。 ＭＳＤを（使わないと分かっていても）大きめに取ったり、ＮＴ連携領域と称するものを「将来きっと使うだろう」などといって大きめに取ったり。。作業する者はある程度自分を納得させることはできるだろう。 しかし「今後さらに新製品が出てどんどん容量が大きくなったとき一体どうすれば良いのか？」 ＊ こういった問題を経営者が聞きつければ「それでは１ランク下のモデルを買えば！」と叫ぶだろうが、主催者側（供給側？業界側？）はそうもいかないだろう。オープン化の流れを吸収し、顧客の求める新しい領域（「貴重なデータの活用」「複数サーバＴＣＯの削減」等）を切り開き、業界を繁栄させるためには、Ｕｎｉｓｙｓ社が行っているような「１台で？？台の効果」がぜひとも必要なのである。 ＊ こういうと、読者は「６００シリーズはすでに前述の通りＡ−ＶＸとｉｎｄｏｗｓが同時に稼働して利用できるシステムとして設計されているのではないか？」と思われるかもしれない。 それは正しいが、ある意味で間違っている。 実は６００シリーズのやり方とＵｎｉｓｙｓのやり方には大きな違いがある。 ＊ Ｕｎｉｓｙｓの方式では、複数のＣＰＵ、巨大なメモリを持っていても、それらは「論理的な区画」によって分割されておりそれぞれの「区画」に別々の資源（ＣＰＵ等）を割り当てることが出来る。 つまり「区画間の負荷」を調整、制御出来るのである。 ＊ 翻って我が「６００シリーズ」を考えてみよう。 まず、純オフコン（Ｓ３１００、Ｓ７２００等）だった頃を思い出して欲しい。「ＲＤＢＱ」や「ｓｋｙｌｉｎｋ」で大規模な検索をかけると「業務側」がグッと遅くなったり止まったりした記憶がおありではないだろうか？（業務ソフトウェア側で大量の検索を行なって言う場合も同様である）この種のＤＢ検索はＡ−ＶＸの場合ほとんどが全件検索になってしまい、ＣＰＵに大きな負荷がかかってしまう。 この傾向は６００になっても同様である。（もちろんＣＰＵ性能が劇的に向上している分だけ改善しているのは事実ではあるが。） そして、ＲＤＢＱ２等で大量の検索をかけているときＷｉｎｄｏｗｓのタスクマネージャで観察すれば分かるが、ＣＰＵ使用率がグッと高くなるが、メモリ使用量はほとんど増えていない。 ＊ Ａ−ＶＸ側ソフトウェアからＤＢ検索させる場面で、ｏｒａｃｌｅやＳＱＬサーバなどを同時に稼働させて「情報系」を構築したり、ＴＳ機能を使ってｏｆｆｉｃｅなどを集中管理しようとしても、同じＷｉｎｄｏｗｓｗ上で稼働しているためお互いの負荷を制御しにくくなってしまい、運用上非常に問題があるといえる。 「ｗｉｎｄｏｗｓ上でＡ−ＶＸが稼働する」といいつつ、ＮＥＣのカタログなどを見ていると拡張された部分はほとんど「別サーバ」になっているのはそのためではないだろうか？ そして、ほとんどのｗｉｎｄｏｗｓ業務を別サーバにしてしまった状況で残っている連携機能は富士通の純粋オフコンＯＳでも可能な程度の変更機能なのである。 （ということは、ｗｉｎｄｏｗｓはｉｎｔｅｌチップとＡ−ＶＸの間の単なる「巨大なファームウェア」にすぎなくなってしまい、ｗｉｎｄｏｗｓと共存させた意味はあまりなくなってしまうのである。） ＊ 負荷のかかる業務は結局Ａ−ＶＸのみしか出来ないとすれば、前述のＲＤＢＱの動作をみても分かるようにメモリをある程度を超えて増やしてもあまり意味はなく、基幹業務のみでは増大し続けるディスクをいつかもてあまして、有効利用できなくなってしまうのではないだろうか？ ＊ かくて、将来の６００シリーズにおいては、 有り余るハードウェア資源を前にして、 顧客に 「手のひらサイズに近づいていく下位機種を勧めるか」 「必要だと偽って、巨大なドンガラ（空洞）を販売するか」 のいずれかの道を歩むことになってしまうのではないだろうか？ ＊ 以上は、筆者の独断と偏見に満ちた見解であり、最新の６００シリーズ上で負荷のベンチマークを行ったわけではないので、不正確である可能性は高い。 しかし、筆者の心配事が杞憂であることを祈る。 | |
| （続報）謎の６２０ｘｉ−Ｓについて | |
| ＥＸＣＨＡＮＧＥ 2003-12-31 12:39:11
[返信] [編集] ＊ その後いろいろ調べてみましたが、 （１）ＯＳは、Ｗｉｎｄｏｗｓ−ｓｅｒｖｅｒではなく、ＸＰまたは２０００のプロフェッショナルを使用。もちろんＡ−ＶＸ０１がインストールされているので、Ａ−ＶＸのサーバとして使う分には特に問題なし。 （２）基本構成では、バックアップ装置、ＵＰＳ、アレイは付いていない（オプションで可。ただしアレイはミラー）。 （３）ＷＳ台数は３台まで？タスク数５まで？（いずれも未確認情報） （４）利用できない主なユーティリティソフトまたは機能 ＊ ＯＳＶ−ＧＵＩ実行 ＊ ＦＡＸ連携 ＊ ＯｐｅｎＤａｔａｂａｓｅＡｃｃｅｓｓＫｉｔ ＊ ＢｉｚＲｅｐｏｒｔｉｎｇ ＊ ジョブ起動ユーティリティ ＊ ＰｒｉｎｔＶｉｅｗ という感じです。 いずれもＮＥＣに確認したわけではありませんので、担当セールスにご確認頂きたいのですが、 もし上記の通りだとすれば、やはりターラヤンさんのご指摘通り、 従来機能中心で比較的小規模な方向きでしょうか。 積極的に新機能を使いたい方や、今後端末を拡張する可能性のある方は６２０ｘｉ以上を選択すべきでしょう。 （中小の会社の場合６２０ｘｉは賢い選択かもしれません） | |
| Re:６２０ｘｉ−ｓの件（補足） | |
| 江須扇 2003-12-26 3:45:47
[返信] [編集] ６２０ｘｉ−ｓは最低限の構成になっているので、 ターラヤンさんの説明の通り ＵＰＳが無い ｂａｃｋｕｐ装置が無い（ＦＤＵだけ） という事で、例えばネットワークでカバーするという事考えた場合、 Ａ−ＶＸ／ＮＥＴを入れるだけでも有償ソフトなのでそれなりに費用がかかります。 また、開発マシンとしてＣＯＢＯＬ８５とＳＭＡＲＴ２（ＥＵＦ機能の代替も兼ねて）と合わせて３有償ソフトを入れるとハードと同じ位の費用が掛かりそうです。 ところで、今回のｘｉシリーズは６４０Ａｉ−Ｒに相当するものはなくなったのでしょうか？ 高さが１Ｕでしたが今回の６４０ｘｉのラックモデルは５Ｕです。 ラックに複数台いれるとすぐいっぱになりそうです。 そこで、ちょっと早とちりですがひょっとして次のＯＳでは、 一台の中で複数のＡ−ＶＸを立ち上げることできエミュレータはｐｏｒｔ番号で切り替えてできるというようなことを考えているのではと思っております。 Ａ−ＶＸ／ＮＥＴでやり取りできるが主ＯＳ以外はＰＣ／ＷＳ−ＥＭＬだけで周辺装置は使えないという制約はあると思いますが・・・ | |
| ６２０Ａｉ-Ｓ／６２０ｘｉ-Ｓについて | |
| ターラヤン 2003-12-23 16:11:42
[返信] [編集] 返事が遅くなりましたが・・・。 > ＊ 「６２０Ｘｉ−Ｓ」という機種ですが、価格がＡ−ＶＸ込みで定価ベースで８２万円 、保守料金３７００円／月という話でした。 > スタンドアロンというわけではなさそうなので、純粋なＰＣサーバベースと比べてもかなり魅力のある価格だな、と思いました。（それともこれはスタンドアロンしかだめなモデルなのでしょうか？？ ターラヤンさん、ご存じでしたらお教えください！！） 江須扇さんの書いているように、Windows側のOSがWindows2000Professional/WindowsXPとクライアント系になっています。詳しくは忘れてしまいましたが、クライアント系OSだと、サーバ系のOSと比べて、接続できるコンピュータ台数の最大数が少なかったような気がします。 それからお安くするためか、ＵＰＳやバックアップ装置が標準で付いていない、あまり使わない？ハードが付けられない、あまり使わない？Ａ−ＶＸの機能がはずされている点が気になるところでしょうか。 でもＩＴＯＳ／Ａ−ＶＸのソフトは問題なく使用できるはずですし、ハードについてもたとえ使えないものがあっても代替の接続方法や装置があるので、普通に使う分には問題ないと思います。 Ｓ３１００やＳ７２００のリプレースで、あまり新規の機能を使わずに、今まで使っていたソフトをそのまま使おうという人向けのような気がします。（あくまでも個人的な意見です。） ついでですが、 >例えば、７００シリーズの時代には、ウィルスチェックのソフトひとつとっても、種類が少なくて困りましたものね。。 Ｓ７２００やＳ３１００ならば、（クライアントにＰＣを使っていなければ）、コンピュータウィルスとは無縁ですよね。 ６００シリーズもＡ−ＶＸだけならウィルスとは無縁なのですが、Ｗｉｎｄｏｗｓ側が影響を受けてしまいます。 | |
| ６２０ｘｉ−ｓの件 | |
| 江須扇 2003-12-23 3:06:48
[返信] [編集] > ＊ 「６２０Ｘｉ−Ｓ」という機種ですが、価格がＡ−ＶＸ込みで定価ベースで８２万円 、保守料金３７００円／月という話でした。 > スタンドアロンというわけではなさそうなので、純粋なＰＣサーバベースと比べてもかなり魅力のある価格だな、と思いました。（それともこれはスタンドアロンしかだめなモデルなのでしょうか？？ ターラヤンさん、ご存じでしたらお教えください！！） 正確なことは解りませんが、 Ｅｘｐｒｅｓｓ５８００／６１０ｘｘ ＷＮＴ、Ｗ２ＫのＷｏｒｋｓｔａｔｉｏｎ Ｅｘｐｒｅｓｓ５８００／６２０ｘｘ−ｓ ＷＮＴ、Ｗ２ＫのＷｏｒｋｓｔａｔｉｏｎ、ＸＰｐｒｏｆｅｓｓｉｏｎａｌ Ｅｘｐｒｅｓｓ５８００／６２０ｘｘ以上 ＷＮＴ、Ｗ２Ｋ、２００３Ｓｅｒｖｅｒ となっています。 ６１０は純粋はスタンドアロンですが６２０ｘｘ−ｓはＷＳは接続可能と思います。 但しＷｉｎＯＳがサーバーでないのでその制限があると思います。 たとえは、ＲＤＢ／ＦＩＬＥアクセスキット等がマルチでは使えないと思います。Ａ−ＶＸだけのマルチワークと思いました。 正確にはやはりＮＥＣに確認してください。 | |
| 従来型「オフコン」から新「６００ｘｉシリーズ」への移行検討の方へ | |
| ＥＸＣＨＡＮＧＥ 2003-12-17 16:33:27
[返信] [編集] ＊ ターラヤンさんが「現物を見た人はいませんか？」とおっしゃっておられましたが、残念ながらわたくしもまだ６００Ｘｉの現品にはお目に掛かっておりません。 ＊ 機能、性能に関する（主に営業担当からの）説明と、カタログなどより判断して、従来型の「オフコン」から「６００Ｘｉ」に移行を考えておられる方（考えておられる会社）に参考になりそうなこと、気づいたことなどを書いてみました。 ＊ Ｓ７２００（もっと古い３１００／ＡＸＸ）などからの移行検討の場合。。。 まず、図体（筐体とも呼ばれています）があまりに小さくなっていますので、ちょっとショック（落胆？）をおうけになるでしょう。 そのかわり、正直言って移行後は「あまりにも処理速度が速くなった」のに驚かれると思います。とくに専用端末などをお使いだった方には隔世の感があるでしょう。価格もかなりお安くなっていますし、なによりも「保守料金」が安いのがうれしい。 以前の経験では、７２００／８０を使っていた会社（端末５０台程度）でも６４０で十分ＯＫでした。「再リースできるので、まだまだ使うんじゃ！」という社長さんもおられるかもしれませんが、「７２００保守料金」と「新６００＋新保守料金」を比較すると、買い換えてもさほどＵＰしなかったりするので、よく研究してみてください。 それに出来ることは、格段に拡大していますし。。（特にオープン連携） このパターンは、「○○屋の牛丼」ではありませんが「安い、速い、うまい」にきっと満足されるでしょう。 ＊ ７００シリーズからの移行を検討している方の場合。。 スタイルは基本的には同じなのですが、ＩＮＴＥＬベースになったために、使える道具（ハード、ソフト）が格段に多くなっています。例えば、７００シリーズの時代には、ウィルスチェックのソフトひとつとっても、種類が少なくて困りましたものね。。 それにやはり、小型化、スピードアップがすばらしいです。 あと、オープン連携機能が充実しています。７００シリーズの頃は、ＮＴ上で動かすのが精一杯という感じでしたから。。 それに比べると、６００系（特にＡｉ以後）は、Ａ−ＶＸを動かすのにかなり余裕があるみたいです。そのため実際に使える連係機能がかなり増えています。 ＊＊ （便利だな、と思った機能について） ＊＊ （１） ＢｉｚＲｅｐｏｒｔｉｎｇ Ｖ２．０ Ａ−ＶＸからの印刷を編集して、ｗｉｎｄｏｗｓの各種フォントを利用したり、図形、バーコード、ロゴ、イメージデータ、等を貼り付けて印刷できる機能。Ｗｅｂブラウザでの帳票参照も可能で、インターネットでの帳票配信も出来ます。 従来の印刷パスからデータを取得して利用できるみたいです。（アプリの修正なしでレイアウト変更可能、インストールとＳＧのみで利用出来るようです） ホスト系のコンピュータは「フォント」「イメージ」など、帳票の表現力の点で欲求不満があっただけに、この機能は私としては一番うれしい機能と思いました。 （２）Ａ−ＶＸ／ＡＰアクセスオブジェクト Ｖ２．０ ｗｉｎｄｏｗｓアプリケーションからＡ−ＶＸ上のＣＯＢＯＬアプリケーションを起動したり、データのやりとりが出来ますので、これを使ってモバイル端末（ｉモード端末）からインターネット経由で在庫問い合わせ、注文入力などが出来るでしょう。（ＷＥＢサーバ、セキュリティを考慮した環境、データやりとりのためのアプリ追加は、もちろん必要ですが。。） ほかにもたくさんありますが、この辺で。。 最後に一つだけ気づいたこと。 ＊ 「６２０Ｘｉ−Ｓ」という機種ですが、価格がＡ−ＶＸ込みで定価ベースで８２万円 、保守料金３７００円／月という話でした。 スタンドアロンというわけではなさそうなので、純粋なＰＣサーバベースと比べてもかなり魅力のある価格だな、と思いました。（それともこれはスタンドアロンしかだめなモデルなのでしょうか？？ ターラヤンさん、ご存じでしたらお教えください！！） ＊ なお以上は、あくまでも私の個人的な感想ですので、「参考」とお考えください。 詳しくは代理店などの営業担当者によくご確認ください。 | |
| Re: ＮＥＣ ＣＯＢＯＬ の違い 補足 | |
| ターラヤン 2003-12-17 16:02:28
[返信] [編集] 回答ありがとうございます。 > 話は長くなりましたが、ＯＳは別物でＣＯＢＯＬソース互換ということで、再コンパイルは必要でした。 > ファイル管理等は互換性があったので、データやプログラムはハードウェア的に同一機器があれば、ＦＤ等で移行はできました。 > ただし、ＩＳＡＭファイルはありませんでしたので、あくまで順編成ファイルとしての移行でした。 ＩＴＯＳ以前と以後では、プログラムはソース互換。 ＩＴＯＳ以降現在までは、バイナリ互換。 データはずっと使えたということですね。 他社のオフコンは、ＯＳ名称が変わると、ソース互換なので再コンパイルが必要ということがありましたが、ＮＥＣのはＩＴＯＳ->Ａ−ＶＸ１０・・・->Ａ−ＶＸ０１では再コンパイル必要なし。 最下位モデルから最上位モデルまで同じＯＳなので、モデルを変えたために再コンパイルする必要もなし。 ただし、ＮＥＣのオフコンは、かつてＳ３１００系とＳ３０５０系があり、その間は（だいたい）ソース互換なので、シングルアーキテクチャとは言えない。（操作方法などの統一をしようとはしていた。） 今他社のオフコンについて書こうと思い、情報を整理しています。 他社オフコンは、新モデルや新ＯＳになったときに、前モデルと比べて、どの程度互換性があるのかというところをまとめていたのですが、逆にＮＥＣのオフコンは昔はどうだったのかと思い質問しました。 （私のところにある先人の残した資料は、基本的なことは知っていることを前提に書かれているので、当時を知らない私にはよくわからないところがあります。これがわかれば、ＮＥＣオフコンの歴史の項をもっと詳しく書くことができるのですが・・・。） | |
| Re: ＮＥＣ ＣＯＢＯＬ の違い 補足 | |
| 江須扇 2003-12-17 3:39:24
[返信] [編集] > ところで私の資料では、ＯＳ−４のＣＯＢＯＬは、ＩＴＯＳになった時に再コンパイルしなければならなかったようですが、それで間違い無いでしょうか。 はい、間違い有りません。 > つまり、ＯＳ−４とＩＴＯＳ−４の間では、バイナリレベルの互換は無かったということでしょうか？ 元々、１９７３年にオフコンが発表されたとき、それ以前のＮＥＡＣ１２４０はＣＯＰＣＯＤＥＲというアッセンブラーが基本で機械語も直接わかるような１０進のワードマシンでした。 つまり、ＯＳはまったく有りませんでした。 旧１００が出た当時はＯＳと言う表現では無く、ＭＯＮＩＴＯＲと称して、電源を入れたら読み込み日付と時間を入れていました。 説明ではハードでもソフトでもないファームウェアの読み込みと言われました。 その後、他社との対抗上かっこ悪かったのか、後半ではＯＳ−４という名称にしましたが、ＩＴＯＳに比べたら比較になりません。 ただ、ファイル管理やエラー表示また、ＳＯＲＴやＦＬＣＮＶなどのユーティリティは一応できておりました。 ユーティリティのパラメータの入れ方は踏襲しておりました。 話は長くなりましたが、ＯＳは別物でＣＯＢＯＬソース互換ということで、再コンパイルは必要でした。 ファイル管理等は互換性があったので、データやプログラムはハードウェア的に同一機器があれば、ＦＤ等で移行はできました。 ただし、ＩＳＡＭファイルはありませんでしたので、あくまで順編成ファイルとしての移行でした。 > ご存知でしたら教えてください。 | |
| 新しいExpress5800/600シリーズの話題は？ | |
| ターラヤン 2003-12-16 17:12:04
[返信] [編集] 新しいExpress5800/600シリーズを見た人はいないのでしょうか。 ｉＥＸＰＯ２００３には展示してあったそうなので、もし行かれた方がいらっしゃったら、どんな感じだったのか教えてください。 本当ならば、私が行ってネタにするべきだったのですが、仕事が忙しくて行くことができませんでした。 この新機能があったとか、何か話題があると良いのですが。 １２月に入ってから、急にサイトのカウンタが毎日６０〜７０ぐらい回るようになったので、もしかすると新しいExpress5800/600の情報を求めて来ている方がいらっしゃるのではないかと思ったので。 | |
| Re: ＮＥＣ ＣＯＢＯＬ の違い 補足 | |
| ターラヤン 2003-12-16 15:21:17
[返信] [編集] >>１９８０年ＪＩＳ ＣＯＢＯＬに準拠ということですがその後の表現でもＡＮＳＩ７４ＣＯＢＯＬですね >>ＩＴＯＳ ＣＯＢＯＬ８５ １９８７年ＪＩＳ ＣＯＢＯＬに準拠ということですがその名の通りＡＮＳＩ８５ＣＯＢＯＬですね（１９８７?現在） コボラーの方なので、おそらく知っているのでしょうが・・・、 ＣＯＢＯＬのことをあまり知らない方も見ているかもしれないということで、 ＣＯＢＯＬの仕様は、コダシルのＣＯＢＯＬが決まった後に、ＡＮＳＩのＣＯＢＯＬがそれを参考に決定され、次にＩＳＯ、ＪＩＳと前のものを参考に決まっていくので、ＡＮＳＩとＪＩＳでは数年の差があります。 ところで私の資料では、ＯＳ−４のＣＯＢＯＬは、ＩＴＯＳになった時に再コンパイルしなければならなかったようですが、それで間違い無いでしょうか。 つまり、ＯＳ−４とＩＴＯＳ−４の間では、バイナリレベルの互換は無かったということでしょうか？ ご存知でしたら教えてください。 | |
| ＮＥＣ ＣＯＢＯＬ の違い 補足 | |
| 江須扇 2003-12-12 3:44:52
[返信] [編集] ＣＯＢＯＬの古いマニュアルがあったので補足します。 ＯＳ?４ ＣＯＢＯＬ４Ｅ 旧１００時代です（１９７３〜７８） ＩＴＯＳ ＣＯＢＯＬ４ 旧１００の継承用（１９７８〜？） ＩＴＯＳ ＣＯＢＯＬ 当初は”高級”がついていた（１９８４〜？） １９８０年ＪＩＳ ＣＯＢＯＬに準拠ということですがその後の表現でもＡＮＳＩ７４ＣＯＢＯＬですね ＩＴＯＳ ＣＯＢＯＬ８５ １９８７年ＪＩＳ ＣＯＢＯＬに準拠ということですがその名の通りＡＮＳＩ８５ＣＯＢＯＬですね（１９８７〜現在） ＣＯＢＯＬ４のコンパイラーは”や＝の代替で旧１００が使っていた＠や＃を可能としていました。 ＣＯＢＯＬのコンパイルのパラメータ ＣＯＭＰＩＬＥ ＭＯＤＥ； ＣＭＯ＝ＮＡＴＩＶＥ・・・ＣＯＢＯＬモード ＣＯＢＯＬ４・・・ＣＯＢＯＬ４互換モード ＣＯＢＯＬ８５のコンパイルのパラメータ ＣＯＭＰＩＬＥ ＭＯＤＥ； ＣＭＯ＝ＮＡＴＩＶＥ・・・ＣＯＢＯＬ８５モード ＣＯＢＯＬ７４・・・ＣＯＢＯＬ互換モード と言うことで、３つのＣＯＢＯＬは一世代前をオプションで利用可能としていました。 | |
| Re:x3:Ａ−ＶＸのパッケージ | |
| 江須扇 2003-12-11 14:48:36
[返信] [編集] > ＊ 高級ＣＯＢＯＬ？？？？ そんなのってあったのですか。。 > 知りませんでした。 ＣＯＢＯＬ４はＡ−ＶＸ以前の旧１００（赤１００）のＯＳ４のＣＯＢＯＬ仕様を継承したものだったと思います。１９７８年頃の話なので、曖昧な記憶です。 なにせそのＣＯＢＯＬはＩＦ命令もＧＯＴＯ命令ぐらいしか書けなくて二重のＩＦが出来なかったと思います。パックデータも使えなかったと思います。 > ＊ ＣＯＢＯＬ４については、リコー関係の方が使っているのを見たことはあります。漢字のところが””（ダブルクウォーテーション）に囲まれたアルファベットなどのコードが並んでいて分かりにく?い！！という印象だけが。。 漢字は１６進入力でした、リコーはこの時点ではカタカナ２文字で漢字ＯＮＯＦＦコードで囲むというわかりやすい方法でしたね。 しかし、逆にこの方法が後で１バイト２バイトの混在モードが使えないという足かせになりましね。 > ＊ ＲＩＣＯＭはＡＣＥＰＣＲＴ（ＸＸ，ＸＸ）、ＤＩＳＰＣＲＴ（ＸＸ，ＸＸ） っていう画面入出力でしたね。 これはまさしく、リコーがＮＥＣと提携した時の旧１００時代のＣＯＢＯＬ仕様を取り込んだものです。 > ＊ 「高級ＣＯＢＯＬ」というのはＣＯＢＯＬ４、ＣＢＬ８５とどういう風に違っていたのでしょうか？漢字属性がＮＣ””になったのはどの時点からでしょうか？？ 高級ＣＯＢＯＬはＣＯＢＯＬ４に比べて”高級”ということで、普通のＣＯＢＯＬです。コンパイルモードにＮＡＴＩＶＥモードとＣＯＢＯＬ４互換モードがあり、画面は互換モードはＡＣＥＰＣＲＴ、ＤＩＳＰＣＲＴが使えたと思います。ＮＡＴＩＶＥモードはＳＣＲＥＥＮ ＳＥＣＴＩＯＮだと思います。 ＣＯＢＯＬ８５が出てからはただのＣＯＢＯＬに名称変更したと思います。ＣＯＢＯＬ８５のコンパイルモードで互換モードがこのＣＯＢＯＬのことです。 ８５との違いはＥＮＤ−ＩＦ等の８５年仕様が使えないことです。 その他ＣＲＴ−ＳＴＡＴＵＳがＣＯＢＯＬ８５ではＨＴＡＢ（Ｒｅｔｕｒｎ）とＳＫＩＰキーが違いますが、ＣＯＢＯＬでは同じでした。 画面の動きが違ってしまうので、ＣＯＢＯＬで作ったプログラムをＣＯＢＯＬ８５でコンパイルするときは互換モードにする必要がありました。 その後の仕様強化はＣＯＢＯＬ８５だけと思います。 例えば１バイト２バイトの混在入力ＭＩＸモード等や 副画面や矢印キーのＣＲＴ−ＳＴＡＴＵＳが使えるようになったことなどです。 報告書機能や分類機能はＣＯＢＯＬでもあったと思います。 ＲＤＢ機能や日本語処理機能はどこまであったかははっきり覚えておりません。 > ＊ 余談ですが、ＮＣを使わず、””で囲んでオープンフィールドにすると、何か漢字の組み合わせによってうまく表示できない場合がありますね。 ひらがなの一部でコンパイルエラーになりましね。 > ＊ さて、ＣＯＢＯＬ２００２はＡ−ＶＸに搭載される予定は全くないのでしょうか？ オブジェクト指向や、例外処理なども出来るみたいです。 本気でＡ−ＶＸを売るならＣＯＢＯＬ対応ＯＳとしてサポートすべきと思いますがコンパイラーを開発する要員をＮＥＣは今でも抱えているのでしょうか？ > ＞販売管理、生産管理など個別要素の多いシステムは個別システムで作られているかパッケージと称してもかなりカストマイズをいれているのでそのまま、Ａ−ＶＸで生き延びているというパターンが多いようです。 > ＊ ＮＥＣのオフコンパッケージというのは、もともとソースも提供されていたのですか？ 日本事務器や大塚商会等の大手デーラーは自社パッケージを開発していたので、ソースは社内では自由にしていたと思います。 中小デーラーはメーカパッケージと称してＳＥＡ／Ｉ ＡＰＬＩＫＡが出てきたのですがこれはデーラーにはソースは提供されていたようです。 ＳＥＡ／ＩはＣＡＳＥツールですので部品提供というだったような 気もします。 その後のＳｕｐｅｒＡＰＬＩＫＡ ３ＳＡＰＬＩＫＡはソースは非公開でした。各社のデーラーパッケージはどこまでがパッケージでどこまでがプロトタイプかよくわかりません。そのデーラーの考え方で、エンドユーザーまでソースを公開した場合もあると思います。 > ＞しかし、個別に作るのであれば今でもＣＯＢＯＬで作るＡ−ＶＸには価値があると考えます > > ＊ 私も同感です。「保守がしやすい」「確実に資産継承出来る安心感」それにオープン系と違って「いろいろ余計なことに煩わされずに業務分析、ロジックに注力出来る」等々。。 > > ＊ 問題は、ＮＥＣさんがＡ−ＶＸに関する中長期の方針（ロードマップ）を明確に表明してくれたら。。ということです。 > Ａ?ＶＸを打ち切る場合でもそれとほぼ互換の「実行環境」を提供する予定である、とかそういった見通しがはっきりあればユーザさんも安心して「新規」を開発できるのではないでしょうか？ > 今もところ、ＮＥＣを「信じるほかない」という。。。 同感です。 | |
| Re: Ａ−ＶＸのパッケージ | |
| ターラヤン 2003-12-11 11:54:21
[返信] [編集] >＞販売管理、生産管理など個別要素の多いシステムは個別システムで作られているかパッケージと称してもかなりカストマイズをいれているのでそのまま、Ａ−ＶＸで生き延びているというパターンが多いようです。 > >＊ ＮＥＣのオフコンパッケージというのは、もともとソースも提供されていたのですか？ 昔のことなので詳細は忘れましたが、いろいろな処理が部品化というかサブシステム化されていて、何十種類もの部品の中から適したものを積み木のように処理を組み上げていくと。 さらに金額や個数などの桁数など細かい部分はパラメータで指定できるようになっていたはず。 （建前上は）ヒアリング用の用紙があって、それに従って質疑をしていけば、自然とできるというもの。 すっかり忘れたので、もしかしたらＮＥＣのパッケージではないかもしれません。 もちろんパッケージソフトを作っている会社によって、仕組みは千差万別でかなり自由度の高いものから、ほとんど変更の余地の無いものまでいろいろありました。 インターフェース部分の仕様が公開されていて、出力部分（伝票とかです）は簡易言語を使って自分で作るのもあったはず。 | |
| Re: Ａ−ＶＸのパッケージ | |
| ＥＸＣＨＡＮＧＥ 2003-12-11 9:54:03
[返信] [編集] ＊ 高級ＣＯＢＯＬ？？？？ そんなのってあったのですか。。 知りませんでした。 ＊ なにせ、以前申し上げたように、ＮＥＣのＣＯＢＯＬに関しては、ＣＢＬ８５しかやったことがありませんでしたので。。 ＊ ＣＯＢＯＬ４については、リコー関係の方が使っているのを見たことはあります。漢字のところが””（ダブルクウォーテーション）に囲まれたアルファベットなどのコードが並んでいて分かりにく?い！！という印象だけが。。 ＊ ＲＩＣＯＭはＡＣＥＰＣＲＴ（ＸＸ，ＸＸ）、ＤＩＳＰＣＲＴ（ＸＸ，ＸＸ） っていう画面入出力でしたね。 これは、後でＯＳ２上で実行環境になったとき（７３５Ｄ等）も、同じようなサブルーチンが提供されていました。 でも、ＡＳ／４００（ＲＩＣＯＨ−ｉ７４０）では画面ファイルでの入出力でしたのでちょっと操作上の不統一がありました。 ＊ 「高級ＣＯＢＯＬ」というのはＣＯＢＯＬ４、ＣＢＬ８５とどういう風に違っていたのでしょうか？漢字属性がＮＣ””になったのはどの時点からでしょうか？？ ＊ 余談ですが、ＮＣを使わず、””で囲んでオープンフィールドにすると、何か漢字の組み合わせによってうまく表示できない場合がありますね。 ＊ さて、ＣＯＢＯＬ２００２はＡ−ＶＸに搭載される予定は全くないのでしょうか？ オブジェクト指向や、例外処理なども出来るみたいです。 ＞販売管理、生産管理など個別要素の多いシステムは個別システムで作られているかパッケージと称してもかなりカストマイズをいれているのでそのまま、Ａ−ＶＸで生き延びているというパターンが多いようです。 ＊ ＮＥＣのオフコンパッケージというのは、もともとソースも提供されていたのですか？ ＞しかし、個別に作るのであれば今でもＣＯＢＯＬで作るＡ−ＶＸには価値があると考えます ＊ 私も同感です。「保守がしやすい」「確実に資産継承出来る安心感」それにオープン系と違って「いろいろ余計なことに煩わされずに業務分析、ロジックに注力出来る」等々。。 ＊ 問題は、ＮＥＣさんがＡ−ＶＸに関する中長期の方針（ロードマップ）を明確に表明してくれたら。。ということです。 Ａ−ＶＸを打ち切る場合でもそれとほぼ互換の「実行環境」を提供する予定である、とかそういった見通しがはっきりあればユーザさんも安心して「新規」を開発できるのではないでしょうか？ 今もところ、ＮＥＣを「信じるほかない」という。。。 | |
| Ａ−ＶＸのパッケージ | |
| 江須扇 2003-12-11 3:44:19
[返信] [編集] > はじめまして、江須扇さん。それにしても、皆さん、 > マニアックですねぇ（笑）そういう私も、まだ、 > 懐かしい、あのＣＯＢＯＬ４を使用しています。 返信ありがとう御座います。 ＣＯＢＯＬ４ですか。 ＤＩＳＰＣＲＴとＡＣＥＰＣＲＴ命令があるやつですか？ ＲＩＣＯＨはＣＯＭＰＯＳシリーズのＣＯＢＯＬはこれにならって 画面の命令をカストマイズしてあったと思います。 その後、ＮＥＣは高級ＣＯＢＯＬ、ＣＯＢＯＬ８５と進化したと思います。 > 表紙のオフコン関係情報欄に「ｉシンポ」の記載がありましたね。 > ご意見がありましたら…というので、下記の内容でＮＥＣに投げて > みました。 今回のＡ−ＶＸ０１のＷｅｂ頁の下の方を見てもＥＸＰＬＡＮＮＥＲ／Ａという ＳＥＡ／ＩＡＰＬＩＫＡ → ＳｕｐｅｒＡＰＬＩＫＡ ３ＳＡＰＬＩＫＡ （ここまでＡ?ＶＸ） その後のＡＰＬＩＫＡ（Ｗｉｎｏｄｗｓ版の名前は忘れました）からＷｉｎｄｏｗｓ対応になりその後継となるパッケージが載ってますね。 つまりＮＥＣはパッケージはＷｉｎｄｏｗｓ側のＯＳで動かせという事のようです。 財務会計、給与計算等は切り出してパソコンパッケージに切り替えている場合が多いようです。 販売管理、生産管理など個別要素の多いシステムは個別システムで作られているかパッケージと称してもかなりカストマイズをいれているのでそのまま、Ａ?ＶＸで生き延びているというパターンが多いようです。 完全固定パッケージ（カストマイズできない）システムを選択肢とする場合は、やはりオープンシステムのパッケージを選ぶしかないようです。 しかし、個別に作るのであれば今でもＣＯＢＯＬで作るＡ−ＶＸには価値があると考えます。 （作れる人が少なくなってる現実はありますが・・・・・） 以上 > > *―――――――――――――――――――――* > > A―VXアプリケーションパッケージの不足とA―ＶＸの今後について > > 弊社では自社開発品、パッケージソフトの両方を使用してきました。数年前から、リストラ等で要員が減り、自社開発が難しくなってきました。ディーラーのパッケージソフト購入を検討するにもA―VX対応のパッケージは姿を消しつつあります。また、以前にも指摘されたようにA―VXに精通しているＳＥも姿を消しつつあります。他のユーザーの方で、パッケージを使用されている場合、どういうところから入手されているのでしょうか。弊社で現在使用のパッケージは２０年以上前に購入したもので、必要に応じて自社で修正を繰り返してきました。今後、人手不足もあり、このような修正も出来なくなってくると思います。他の方々も同様な使い方をされているのでしょうか。 > > 長年使ってきたA―VXは、使用し易く安定度にも満足していますが、今後、会社の世代交代を考えた場合、業務パッケージが入手できなくなってくると、ＰＣ系への前面移行も検討課題になってきます。ＮＥＣとして、Ａ―ＶＸ系の業務パッケージの供給については、どのように考えているのでしょうか。今後、Ａ―ＶＸユーザー維持、拡大を意図しているなら最も基幹的な部分ではないでしょうか？ > それとも、Ａ―ＶＸの拡販や維持は意図せず、ただ現ユーザーの現時点での便宜のみを重視しＰＣ連携のミドルウエア等のツールを提供することに徹していくのでしょうか。 > Ａ―ＶＸに対して、どのような方向性を考えているのか…ＮＥＣの考えをお聞かせください。 > > *-------------------------- > > すると、、会場ではお答えできる内容ではないとのことで、 > 後日、ｏｓ開発部門の方が見えました。 彼らのＡＶＸ > に対する思いもわかりました。 > が、、、やはり、というか、拡販する意図は、会社的には > あまり積極的ではないような感じでした。考えてみると > オフコン全盛期には、いろんな講習会があったけど、今 > は、そんなもの全くないんじゃないでしょうか。 > 後継者を育てるにも、ちょっと難しい状況ですね。あと > １０年、２０年後にどうなってしまうのか。。自然消滅 > してしまうのか。ちょっと不安です。その頃には、もう > 私もいないでしょうが（笑） > 話の中で出たのですが、やはりというか、新規にＡＶＸ > を買うユーザーはいないそうです。現状、他社のオフコン > からの乗り換え。ＰＣサーバーにしたけど、問題があって > 戻ってきた客とのことでした。 > > つまらない話をくどくど書いてしまいました。おつきあい > ありがとうございました。 > | |
| Re:x3:Ｗｉｎｄｏｗｓアプリ立ち上げＰＧ | |
| ＥＸＣＨＡＮＧＥ 2003-12-10 19:55:31
[返信] [編集] ＊ Ａ−ＶＸ用パッケージソフトについて > 弊社では自社開発品、パッケージソフトの両方を使用してきました。数年前から、リストラ等で要員が減り、自社開発が難しくなってきました。ディーラーのパッケージソフト購入を検討するにもA―VX対応のパッケージは姿を消しつつあります。また、以前にも指摘されたようにA―VXに精通しているＳＥも姿を消しつつあります。 ＊ 私はＡＶＸでのパッケージというのは使ったことがなかったので、「最近少なくなっている」ということに全く気づきませんでした。 ＊ 困ったことですね。。 でも、パッケージを開発する人から見ればいわゆる「オープン系」で作った方が市場が広いですから、どうしてもそうなっちゃうんでしょうね。 何でするか？ときかれたら、かくいう私でも、ＡＶＸでするのは「前からＡ−ＶＸの顧客」相手であって、新規は「オープン系」で作ろうと思いますもんね。。 ＊ こういう場（オフコン練習帳）を使って「Ａ−ＶＸ版オープンソース運動」をやってはどうでしょうか？ 自社で開発されたソフトを基にして公開してもかまわないという作品も出てくるかも。。 ＊ あと、こういう場でいろいろ技術情報の交換が出来ればきっとすばらしいでしょうね。 | |
| それはそれでいいのでは。。（等身大のＡＶＸ） | |
| ＥＸＣＨＡＮＧＥ 2003-12-10 19:15:49
[返信] [編集] ＊ はじめまして、ＣＢＬ４さん。 ＊ すごいですね、わたしはＣＯＢＯＬ８５しかやったことがありません。（そのころはＲＩＣＯＭしてましたので。。） ＊ ＮＥＣ（供給側）のＡＶＸに対する雰囲気なども、興味深く読ませて頂きました。 それと、会場のその場で確固たる見解を出さずに、個別面談で本音の説明に来られるところも、やはり「隠れ」っぽい感じでしょうか？！ ＊ 私は、ＩＢＭのＡＳもかじったことがあるので、思うのですが、「ホスト系のオフコン」で最後まで残るのはきっとＩＢＭだけでしょう。メーカ側の熱意も違いますし、実際ＯＳ、ユーティリティの作りの深さと先進性が全く違います。なんと言っても「ホスト系」の元祖です。そこに老舗の実力と意地を感じます。 ＊ もはや（ＡＶＸも含めて）日本のオフコン（＝中規模ホスト系コンピュータ）の時代と役割は過去のものとなったと思います。 ＊ ＯＳの開発や拡張には多額の「予算」が必要でしょうし、その予算は製品がどんどん売れてこそまかなえるという、現実的な問題もあるでしょう。 それにもまして、ＮＥＣの開発のトップの方々から見れば、 現在の世界的ＯＳ技術レベル、将来的技術動向と比較して、 「ＡＶＸという技術が」どの程度のレベルのものか「見えてしまう」のではないでしょうか？ ＊ ただひとつ、私の狭い経験から書かせて頂きたいのは、 （いろんなお客様のシステムを作らせて頂きましたが） 中小のお客様ほど、ＡＳよりもＡＶＸの方が「操作もわかりやすく、より好きだ」とおっしゃられた、という事実です。 ＊ もともとＡＶＸは頭でっかちなＯＳではなく、日本の中小企業を想定した「実際的な」製品であったと思います。 その考え方は、今のＡＶＸ４，ＡＶＸ０１などにも引き継がれていて、「過去のオフコン資産」を生かしつつ「オープンな世界」と連携していく、「安い費用」で「慣れた操作性」の中で、「新しいもの」を容易に取り込んでいく、やり方ではないでしょうか？ （実際、現在でもＡＶＸ４で作ったシステムはコストパフォーマンスから見て「実際的でけっこういける」という感じですから。。） ＊ 私は今考えると、ＡＶＸをＷｉｎＳｅｒｖｅｒ上に乗せる（ｗｉｎｄｏｗｓの中へ包み込んだというべきか？）というＮＥＣのやり方の中に、なにか一種の（日本的）「やさしさ」をすら感じてしまいます。 ＊ もう、「時代は終わった」のですが、「中小企業、とりわけ、会社は一定規模ではあっても、ＩＴ専門スタッフのいない企業ではまだ必要とされている部分」もかなりあります。 ＊ ＮＥＣは、ＡＶＸをｗｉｎｄｏｗｓのなかに入れることで、 「顧客が実際に必要とする限り生き延びさせよう」としているように見えます。 ＊ やがて「一人去り、二人去り」していつかは消えていくのでしょうが、それはそれでいいのではないでしょうか。 ＊ それよりもＮＥＣが現在のＡＶＸユーザを、少しずつ「新しい世界」へ「導いて」いってくれればよいと思っています。 劇的ではなくっても少しずつ改良をしながらソフトランディングさせてくれればよいのです。 顧客にとって重要なことは、「長年ＮＥＣを使ってきたが、今後もＮＥＣについて行けば間違いない」と感じるられることなのでしょう。 | |
| Re:x3:Ｗｉｎｄｏｗｓアプリ立ち上げＰＧ | |
| ＣＢＬ４ 2003-12-10 7:54:59
[返信] [編集] はじめまして、江須扇さん。それにしても、皆さん、 マニアックですねぇ（笑）そういう私も、まだ、 懐かしい、あのＣＯＢＯＬ４を使用しています。 表紙のオフコン関係情報欄に「ｉシンポ」の記載がありましたね。 ご意見がありましたら…というので、下記の内容でＮＥＣに投げて みました。 *―――――――――――――――――――――* A―VXアプリケーションパッケージの不足とA―ＶＸの今後について 弊社では自社開発品、パッケージソフトの両方を使用してきました。数年前から、リストラ等で要員が減り、自社開発が難しくなってきました。ディーラーのパッケージソフト購入を検討するにもA―VX対応のパッケージは姿を消しつつあります。また、以前にも指摘されたようにA―VXに精通しているＳＥも姿を消しつつあります。他のユーザーの方で、パッケージを使用されている場合、どういうところから入手されているのでしょうか。弊社で現在使用のパッケージは２０年以上前に購入したもので、必要に応じて自社で修正を繰り返してきました。今後、人手不足もあり、このような修正も出来なくなってくると思います。他の方々も同様な使い方をされているのでしょうか。 長年使ってきたA―VXは、使用し易く安定度にも満足していますが、今後、会社の世代交代を考えた場合、業務パッケージが入手できなくなってくると、ＰＣ系への前面移行も検討課題になってきます。ＮＥＣとして、Ａ―ＶＸ系の業務パッケージの供給については、どのように考えているのでしょうか。今後、Ａ―ＶＸユーザー維持、拡大を意図しているなら最も基幹的な部分ではないでしょうか？ それとも、Ａ―ＶＸの拡販や維持は意図せず、ただ現ユーザーの現時点での便宜のみを重視しＰＣ連携のミドルウエア等のツールを提供することに徹していくのでしょうか。 Ａ―ＶＸに対して、どのような方向性を考えているのか…ＮＥＣの考えをお聞かせください。 *-------------------------- すると、、会場ではお答えできる内容ではないとのことで、 後日、ｏｓ開発部門の方が見えました。 彼らのＡＶＸ に対する思いもわかりました。 が、、、やはり、というか、拡販する意図は、会社的には あまり積極的ではないような感じでした。考えてみると オフコン全盛期には、いろんな講習会があったけど、今 は、そんなもの全くないんじゃないでしょうか。 後継者を育てるにも、ちょっと難しい状況ですね。あと １０年、２０年後にどうなってしまうのか。。自然消滅 してしまうのか。ちょっと不安です。その頃には、もう 私もいないでしょうが（笑） 話の中で出たのですが、やはりというか、新規にＡＶＸ を買うユーザーはいないそうです。現状、他社のオフコン からの乗り換え。ＰＣサーバーにしたけど、問題があって 戻ってきた客とのことでした。 つまらない話をくどくど書いてしまいました。おつきあい ありがとうございました。 |
| 新規投稿 | スレッド表示 | ツリー表示 | 投稿順表示 | i-mode | トップ |
BluesBB ©Sting_Band