一括処理の最新版管理は？

過去の桐井戸端ＢＢＳ　（桐ver.５）

774	一括処理の最新版管理は？	デザイア	1998/12/9-12:23
こんにちは。 Ver.5のユーザーですが、桐も一括処理（プログラム）もテーブル（データ）もサーバーに置く運用に浸りきってます。不特定多数のクライアントの接続ありうべし（オープンセサミのライセンスの範囲で）との前提でやってますので、これしかないという頭になってしまっているのですが、Accessでは常識らしいですが、桐もVer.7からソフト・プログラムはクライアントに置くようになったらしいですね。この場合、各クライアントのプログラムの最新版管理はどうやって行うのか、どなたかご教授いただけませんでしょうか。クライアントを特定した上での律儀な帳簿管理（性格的にやりきれるか怪しい）？起動ごとにプログラムをダウンロードする？関係クライアントHDを共有しておいて更新用プログラムを作っておく？実運用のノウハウを教えてください。よろしくお願いします。以上
775	Re:	ikjun	1998/12/9-15:43
記事番号774へのコメント > Ver.5のユーザーですが、桐も一括処理（プログラム）もテーブル（データ）も > サーバーに置く運用に浸りきってます。　ちょっと待ってください。「桐も」というのは桐のプログラムそのものという味ですよね？これってマニュアルに載っている方法ですか？（Ｖ５はとっくの昔にお蔵入りしているので、こちらでは確認できないのですが？）この使い方だと、オーバーレイプログラム（KIRI.OVLというやつ）もサーバーに置くことになりますよね。　オーバーレイプログラムは、基本メモリに一度に読み込めないプログラムを少しずつ、必要に応じて呼び出すプログラムの集まりのはずです。　昔、スピードを上げるために、オーバーレイプログラムだけＲＡＭディスクに置いた覚えがあります。それだけで、かなり早くなった記憶があります。もっともＶ５でのことだったか記憶にありません　これでは桐が動いている間ひっきりなしにKIRI.OVLをサーバーに読みに行くことになり、不必要にトラフィックが増大するはずです。　あくまでも、理論上の話であり、実際にはやったことがありませんので、わたしの勘違いかも知れません？または、桐自体が対応した仕様になっていれば問題はないと思いますが、基本的には最低プログラム本体だけは、ローカルで持つというが昔から一般的だったと思います。　もし、私の懸念が当たっていても、実際にはキャッシュが利いて、理論どおりにはならないとは思いますが、それでも不特定多数（何人でしたっけ？）の運用というのは、時間帯が重なれば、だいじょうぶかな？と気になります。　桐を同時に多数で使おうとすると、なんだか遅くなって不安定になるなんてことありませんか？　テンポラリファイルはどこに作成するようになってますか？これも通常ならサーバーだと、かなりまずいような気がするのですが？ > この場合、各クライアントのプログラムの最新版管理はどうやって行うのか、ど > なたかご教授いただけませんでしょうか。 > > クライアントを特定した上での律儀な帳簿管理（性格的にやりきれるか怪しい） > ？　起動ごとにプログラムをダウンロードする？　関係クライアントHDを共有し > ておいて更新用プログラムを作っておく？　たしか、管理専用のソフトがあるはずです。使う予定がないのでうろ覚えですが、マイクロソフトにもあるはずです。（たぶん、高いと思う。） >実運用のノウハウを教えてください。　とのことですので遠慮しようと思ったのですが、最初がどうしても気になって回答してしまいました。
779	Re:	SAM	1998/12/9-17:57
記事番号775へのコメント私も桐V5をネットワークで使用してました。桐のプログラムは、サーバーにインストールし、必要ユーザー分のオープンセサミをこれもサーバーにインストールするはずです。どこのクライアントでもサーバーから起動できます。（但し、オープンセサミの登録分だけ）どこのクライアントからでも起動できるのでとても便利ですよ。オープンセサミがなくても、１ユーザー分どこのクライアントからでも起動できます。
780	Re:	デザイア	1998/12/9-20:37
記事番号775へのコメント >　あくまでも、理論上の話であり、実際にはやったことがありませんので、わた >しの勘違いかも知れません？または、桐自体が対応した仕様になっていれば問題 >はないと思いますが、基本的には最低プログラム本体だけは、ローカルで持つと >いうが昔から一般的だったと思います。インストールプログラム KV5.COM 初期画面でインストール先をローカルドライブかサーバドライブか選択するようになってますので、マニュアル違反ではありません。ご指摘のとおり、KIRI.OVL もサーバーにあります。レスポンスはさほど問題になっていません。　ただし、KIRICNTL.SYS が以前問題になったことがあります。これをクライアントがつかんだままハングしたことが数回あり、全桐クライアントに全く応答がなくなりました。まあ、ハングすれば当たり前でしょうか。当時事態がわからなかったときは真剣にあせりましたが。 >　もし、私の懸念が当たっていても、実際にはキャッシュが利いて、理論どおり >にはならないとは思いますが、それでも不特定多数（何人でしたっけ？）の運用 >というのは、時間帯が重なれば、だいじょうぶかな？と気になります。 > >　桐を同時に多数で使おうとすると、なんだか遅くなって不安定になるなんてこ >とありませんか？　ときどき、妙に反応がおそいなというときはあります。それから、我々のサーバーの安定度は前に書いたとおりです。ここんところはご機嫌もよろしかったのですが、メモリを64MB、HDを4GBに増強したとたん、皮肉にも本日また落ちました。　incomplete packets received と出ており、今回は桐とは無関係のようです。 >　テンポラリファイルはどこに作成するようになってますか？これも通常ならサ >ーバーだと、かなりまずいような気がするのですが？　サーバーです。特に問題にはなっていません。　不特定多数っていうのは、無理なんでしょうか。
784	Re:	ikjun	1998/12/9-21:35
記事番号779へのコメント　こんばんは！よろしくお願いします。 >私も桐V5をネットワークで使用してました。 >桐のプログラムは、サーバーにインストールし、必要ユーザー分のオープンセサミを >これもサーバーにインストールするはずです。 >どこのクライアントでもサーバーから起動できます。 >（但し、オープンセサミの登録分だけ） >どこのクライアントからでも起動できるのでとても便利ですよ。 >オープンセサミがなくても、１ユーザー分どこのクライアントからでも起動できます。　そうだったんですか？当時[Netware]の価格が偉く高く、（５から６台つなぐのに２００万くらいとられたことがある。）ファイル単位の排他制御しかできない桐など使う気がせず、ｄＢＭＡＧＩＣにしたことがある。　ところで、タイトルの一括処理の最新版管理は、難しいことではなく、専用の共通フォルダを設け、ファイルの日時を比較して、あたらしいものがあったら、複写するプログラムを定期的に動かせばいいような気がします。　ただ、エンドユーザが勝手に一括処理を変えて独自バージョンを作っていたら、意味をなさないので、パスワード管理がかかせないでしょうね。　せいぜい、何十人単位なら、その程度でいいような気がします。　専用ソフトというのは、例えばシステム管理部の人間が全員で一斉に全社員のパソコンをバージョンアップしようとすると、一週間はかかるというようなばあいに管理と配布をおこなわせるソフトのようです。
785	Re:	ikjun	1998/12/9-23:53
記事番号780へのコメント > インストールプログラム KV5.COM 初期画面でインストール先をローカルドライ >ブかサーバドライブか選択するようになってますので、マニュアル違反ではあり >ません。ご指摘のとおり、KIRI.OVL もサーバーにあります。レスポンスはさほど >問題になっていません。　問題はイーサネットのトラフィックだと思うのですが？ NETWAREのサーバーそのものデーターアクセスはむしろ下手なローカルより早いので、２台や３台の同時にアクセスはなんの問題もないと思うのですが、それが、何１０台になるとチリもつもればで問題になることがありうるのではないかと思います。それで、非常にKIRI.OVLが気になったのです。　NETWAREにはトラフィックなどのＬＯＧをとる機能があると思いますので、それを確認しているのなら、問題はないと思いますが？ >　ただし、KIRICNTL.SYS が以前問題になったことがあります。これをクライアン >トがつかんだままハングしたことが数回あり、全桐クライアントに全く応答がなく >なりました。まあ、ハングすれば当たり前でしょうか。当時事態がわからなかった >ときは真剣にあせりましたが。 >　ときどき、妙に反応がおそいなというときはあります。　これは、一時的にイーサネットの限界近くまでトラフィックが増大している可能性があります。すぐにNETWAREのモニターかＬＯＧを見たほうがいいかもしれません。イーサーネットは限界近くになると急激に転送スピードが落ちる性質があります。　正直よく覚えてないのですが、デザイアさんのところはわりと接続台数が多かったと記憶してます。結果次第ではなんらかの手を打ったほうがいいかもしれません。 >それから、我々のサーバー >の安定度は前に書いたとおりです。ここんところはご機嫌もよろしかったのですが、 >メモリを64MB、HDを4GBに増強したとたん、皮肉にも本日また落ちました。 >　incomplete packets received と出ており、今回は桐とは無関係のようです。　これは不完全なデータの入ったパケットを受信したということですから、トラフィック増大によるデータ衝突のせいの可能性は十分に考えられると推定しますが？　かなり、以前になにかの雑誌でNETWAREは結構落ちると読んだことがあります。ただ、データが破壊されることはあまりないとも書いてありました。ある程度は仕方のないことかもしれません。　ただ、トラフィックはほっといても増大する傾向のあるものですから、そのせいなら、悪くなることはあっても良くなることはあり得ませんので、確認することをお勧めします。単なる杞憂だとは思うのですが？ >>　テンポラリファイルはどこに作成するようになってますか？これも通常ならサ >>ーバーだと、かなりまずいような気がするのですが？ > >　サーバーです。特に問題にはなっていません。　であれば、問題ないのでしょうが、通常であればなるべくイーサーネットに流れるデータは少なく、集中しないように設計するはずです。すべてをサーバーに置くというのは、スタンドアロンであれば、ハードディスクに流れるはずのデータがすべてイーサネットを流れることになり、１００ＢＡＳＥならともかく、１０ＢＡＳＥなら集中すれば、データの衝突が頻繁に起きる可能性はあるような気がします。 >　不特定多数っていうのは、無理なんでしょうか。　不特定多数という問題ではなく、トラフィックが一時的に限界を超えないかどうかが問題だと思います。私はNETWAREの素人ですので、導入した業者があるなら相談してみたらどうでしょう。指摘してもなんのことかわからない業者なら別ですが？
788	Re:	デザイア	1998/12/10-02:53
記事番号787へのコメントやっぱり、都度ダウンロードさせるしかないんでしょうか？その線でやってみます。
790	Re:	はまだ	1998/12/10-12:45
記事番号785へのコメント　桐Ｖ５に関して、桐システムの置き場所はＳＡＭさんの言われるとおり、サーバです。桐Ｖ７からはマニュアルに書かれているいるとおり、システムの置き場所はクライアント側にかわりました。（よってＶ７には桐セサミがありません。）トラフィックの件ですが、データーベースアプリを使う限り、データはサーバ側におくのが基本だと思います。後はクライアント数（身の丈）に応じて、アクセスや桐等のファイル共有型（スタンドアロン型）のデータベースを使うか、オラクルやＳＱＬサーバ等のクライアントサーバ型のデータベースを使うかだと思います。　私しては、いろいろな情報を聞く限りファイル共有型（スタンドアロン型）のクライアント数の限界（快適に使える）は７～８クライアントではないかと感じています。

戻る