JP2882802B2 - ネットワーク環境の出力サーバ - Google Patents

Description

【発明の詳細な説明】 （産業上の利用分野） この発明はネットワーク環境の出力サーバに関し、特
にネットワーク（例えば、LAN）に接続されたワークス
テーションからの出力要求に基づいて出力を行う出力装
置を制御するネットワーク環境の出力サーバに関する。

（従来の装置） 第５図に従来のネットワーク環境の概念図を示す。図
において、１は同軸ケーブル等で構成されたネットワー
クであり、該ネットワーク１に複数個のワークステーシ
ョン２、３、……、出力サーバ４が接続されている。該
出力サーバ４には、これによって制御される制御装置
５、６、……が接続されている。該出力装置５、６、…
の一つとして、例えばA0版等の大型のプロッタを考える
ことができる。

従来の出力サーバ４は、ユーザに対して均等にサービ
スを行うために、FIFO（First In First Out）方式を
採用していた。また、緊急に出力したいという要求に答
えるために、優先度の機能も付加されていた。

例えば、第６図に示されているように、優先度を表す
ポインタＩ、II、III、…が定義され、ワークステーシ
ョン２、３等から、優先度Ｉを指定して出力要求A1、A
2、A3、A4、A5、A6、B1、A7、A8、A9、A10があり、優先
度IIを指定して出力要求C1、C2、C3があり、優先度III
を指定して出力要求D1、D2があったとすると、前記優先
度Ｉを指定した出力要求のリクエストブロックA1〜A6、
B1、A7〜A10は、最先の出力を表すポインタＩに前記の
順でつながれ、この順で出力の実行が行われる。

また、優先度IIを指定した出力要求のリクエストブロ
ックは、次の出力を表すポインタIIに前記の順でつなが
れ、優先度IIIを指定した出力要求のリクエストブロッ
クは、さらに次の出力を表すポインタIIIに前記の順で
つながれる。

そして、前記優先度Ｉのポインタにつながれた出力要
求が全て実行されると、今後は優先度IIのポインタにつ
ながれた出力要求が実行され、この出力要求の実行が終
わると、優先度IIIのポインタにつながれた出力要求が
実行される。

従来の出力サーバ４はこのような方式で、出力要求の
実行を制御していた。

（発明が解決しようとする課題） しかしながら、前記した従来装置は、該ネットワーク
に接続されたワークステーションが共有的に使用できる
ように構成されているために、ある特定のワークステー
ションから大量の出力要求があった場合に、タイミング
により、この出力要求の中に、他のワークステーション
からの出力要求が入り込んでしまうという問題があっ
た。

例えば、第６図において、ある特定のワークステーシ
ョンからリクエストブロックA1〜A10の大量の出力要求
があったような場合、この出力要求がなされている最中
に他のワークステーションからリクエストブロックB1の
出力要求がくると、図示されているように、リクエスト
ブロックA1〜A10の中に該リクエストブロックB1が混じ
ってしまうという問題があった。

このようなことが起こると、たとえばプロッタでリク
エストブロックA1〜A10に対応する図面の再生出力をし
ているような場合に、途中で何ら関係のないリクエスト
ブロックB1の図面が再生され、ユーザに不便を与えると
いう問題があった。

本発明の目的は、前記した従来装置の問題点を除去
し、あるワークステーションから大量の出力要求があっ
た場合にも、この中に他のワークステーションからの出
力要求が混じらないようにすることにある。

（課題を解決するための手段および作用） 本発明は、この目的を達成するために、出力要求がリ
ザーブコマンドを持っているか否かを判定する手段と、
該リザーブコマンドがあると判定された時に出力サーバ
を専有する手段とを設けた点に特徴がある。

本発明によれば、該リザーブコマンドを付して出力要
求すれば、出力サーバは該出力要求をしたワークステー
ションに専用されることになるので、たとえ大量の出力
要求をした時にもこの中に他の出力要求が混じることが
ない。このため、他の出力要求の実行のために時間を取
られることがないので、該大量の出力を高速で行うこと
ができる。また、他の出力要求が混じらないので、該他
の出力要求によって得られた図面等の紛失を防止できる
というメリットもある。

（実施例） 以下に、図面を参照して、本発明を詳細に説明する。
第２図は本発明の一実施例の概略のシステムブロック図
を示す。

ネットワーク１を介して図示されていないワークステ
ーションから出力要求があると、該出力要求信号は出力
サーバの要求受付部11に入力する。該要求受付部11で
は、ワークステーションからの出力要求が自分の出力サ
ーバに対するものであるか否かの判断をし、自分向けの
出力要求であれば、これを受付ける。

受付けられた出力要求信号は、スプール処理部12に送
られる。該スプール処理部12は、スプールファイル13に
対して処理待ちの順序を決める処理を行う。前記出力要
求が通常処理の要求であれば、該出力要求に対して従来
と同様の処理、すなわち第６図で説明したのと同様の処
理を行う。この時、出力サーバはネットワーク１に接続
された全てのワークステーションに共有的に使用され
る。

一方、前記出力要求が、出力サーバを一時専有するこ
とを意味するリザーブコマンドをもったものであれは、
後で詳述するように、今までにスプールファイル13に登
録されていた出力要求のリクエストブロックを待避キュ
ーに一時待避させ、該出力要求のリクエストブロックを
処理待ちキューに登録する。該出力要求の終わりに、リ
リースコマンドが来ると、出力サーバの一時専有が解除
され、前記待避キューに待避していたリクエストブロッ
クが再び元の処理待ちキューに戻される。

スプールファイル13は、前記処理待ちキューにつなが
れたリクエストブロックや、リクエストブロックを待避
キューに一時待避させたり、これを復元したりする作業
が行われたりする処理待ち順序格納エリアと、前記リク
エストブロックに対応する画データが格納される出力画
データ格納エリアを具備している。

スケジューラ14は、一つの出力要求の実行が終わった
時、次にどの出力要求を実行するかを決めるものであ
る。出力装置５、例えばA0版のプロッタは、該スケジュ
ーラ14が決めた出力要求の実行を行う。

次に、本実施例の要部の動作を第３図および第４図に
参照して説明する。第３図は、第２図における要求受付
部11、スプール処理部12およびスプールファイル13の動
作を示すフローチャートであり、第４図は該スプールフ
ァイル13の処理待ち順序格納エリアにおけるリクエスト
ブロックの概念図を示す。

まず、ネットワーク１を介してワークステーションか
ら出力要求が届くと、出力サーバの要求受付部11は自分
宛てか否かの判断をし、自分宛てであればこれを受付け
る（ステップS1）。

次に、出力サーバの専有を意味するリザーブコマンド
受付け中か否かの判断をし、受付け中でなければ（ステ
ップS2がノウ）、該受付けた出力要求の中にリザーブコ
マンドがあったか否かの判断をする（ステップS3）。該
リザーブコマンドがなければ、ステップS4に進んでリリ
ースコマンドありか否かの判断を行い、該リリースコマ
ンドがなければステップS5に進んで、通常の処理を行
う。

いま、該通常の処理が行われたことにより、第４図
（ａ）に示されているように、スプールファイル13の処
理待ち順序格納エリアにおいて、処理待ちキューの優先
度Ｉのポインタに、リクエストブロックB1、B2、B3がつ
ながり、処理待ちキューの優先度IIのポインタに、リク
エストブロックC1、C2がつながったとする。

その後、前記ネットワーク１を介して他の出力要求が
あったとする。この出力要求は、大量の出力要求をする
ために、出力サーバを専有すべく、リザーブコマンドを
付したものであったとする。

該出力要求がくると、前記ステップS1で受付けられ、
ステップS2はノウとなり、ステップS3はイエスになる。
そうすると、ステップS6に進んで、処理待ち要求の待避
処理が行われる。

この待避処理は、第４図（ｂ）に示されているよう
に、リクエストブロックB1、B2、B3がつながっているポ
インタを、待避キューの優先度ＩのポインタＩ′に置き
換え、リクエストブロックC1、C2がつながっているポイ
ンタを、待避キューの優先度IIのポインタII′に置き換
えることにより、該リクエストブロックB1、B2、B3、C
1、C2を待避させ、かつ、処理待ちキューの優先度Ｉ、I
Iのポインタを、前記出力要求に明け渡す動作を行う。
このため、該出力要求から来た優先度Ｉのリクエストブ
ロックA1〜A10は、ステップS5→S9→S4→S5の処理によ
り、処理待ちキューの優先度Ｉのポインタにつながる。
なお、該出力要求が優先度IIの場合には、これが処理待
ちキューの優先度IIのポインタにつながることは勿論で
ある。

該リクエストブロックA10が処理された後、リリース
コマンドが来ると、前記ステップS4はイエスとなり、ス
テップS7に進む。該ステップS7では、処理待ち要求の復
元が行われる。すなわち、第４図（ｃ）に示されている
ように、待避キューにつながれていたリクエストブロッ
クB1、B2、B3、C1、C2が、処理待ちキューに戻され、図
示されているように、処理待ちキューの優先度Ｉのポイ
ンタにリクエストブロックB1、B2、B3、A1〜A10がつな
がり、処理待ちキューの優先度IIのポインタにリクエス
トブロックC1、C2がつながる。

さて、前記リザーブコマンドの受付け中に、他のワー
クステーションからネットワーク１を介して出力要求が
あった場合には、前記ステップS2がイエスとなり、ステ
ップS8に進んで受付け不可の信号が該ワークステーショ
ンに送出される。

この結果、該他のワークステーションから来た出力要
求のリクエストブロックが前記リクエストブロックA1〜
A10の間に入り込むことはない。

以上のように、本実施例によれば、一連の出力要求中
に他の出力要求が入り込むのを回避できるので、ユーザ
に不快感を与えたり、出力された書類が他のユーザの書
類に紛れ込んで、紛失したりすることがないという効果
がある。

なお、前記コマンドに、即時という指定をすれば、即
時に出力することができる。例えば、前記第４図の例に
おいて即時という指定があった場合には、同図（ｃ）の
リクエストブロックがA1〜A10、B1〜B3の順になり、該
リクエストブロックA1から出力の実行が開始されること
になる。

また、前記コマンドに時間指定をすることも可能であ
る。該指定を行えば、指定した時間が来た時に、出力の
実行がなされることは勿論である。

第１図は本発明の要部の機能ブロック図を示す。

要求受付け手段21で受付けられた出力要求信号は、コ
マンド分離・判定手段22において、コマンドの分離と判
定が行われる。該手段22において、リザーブおよびリリ
ースコマンドがないと判定されると、通常処理手段23が
動作して、該出力要求のリクエストブロックをファイル
26の処理待ち順序格納エリアの処理待ちキューにつなぐ
動作をする。

一方、リザーブコマンドであると判定された時には、
待避手段24が働いて、ファイル26の処理待ち順序格納エ
リアの処理待ちキューにつながれていたリクエストブロ
ックを待避キューにつなぎ、処理待ちキューを該出力要
求に明け渡す動作をする。

リリースコマンドであると判定された時には、復元手
段25が動作して、該待避キューに待避させていたリクエ
ストブロックを、処理待ちキューに戻す動作をする。

なお、前記リクエストブロックに対応する出力画信号
はファイル26中の出力画データ格納エリアに格納され
る。27はスケジューラ、28はプロッタ等の出力手段であ
る。

（発明の効果） 以上の説明から明らかなように、本発明によれば、リ
ザーブコマンドを付して出力要求をすれば、リリースコ
マンドが入力してくるまで、出力サーバを専有できるの
で、特定のユーザが緊急かつ大量の出力を行う際に、他
のユーザ出力と混じらない形で出力を得ることができる
という効果がある。

また、前記リザーブコマンドを付された出力要求に優
先度が付されている場合には、該リザーブコマンドの解
除後に、必要な出力全部を該優先度に応じて高速に得る
ことができるという効果もある。

さらに、即時と指定した場合には、出力結果を他のユ
ーザのそれと混じらない形で、即時にかつ高速で得るこ
とができる。

【図面の簡単な説明】

第１図は本発明の要部の機能ブロック図、第２図は本発
明の一実施例のシステムブロック図、第３図は該実施例
の動作を説明するためのフローチャート、第４図は該実
施例の動作の説明図、第５図は従来のネットワーク環境
の概略図、第６図は従来の出力サーバの動作の説明図で
ある。 １……ネットワーク、２、３……ワークステーション、
４……出力サーバ、５、６……出力装置、11……要求受
付部、12……スプール処理部、13……スプールファイ
ル、14……スケジューラ

Claims (1)

(57)【特許請求の範囲】
1. 【請求項１】複数個のワークステーションが接続された
   ネットワーク環境の出力サーバにおいて、 あるワークステーションから送出された出力要求の中
   に、該出力サーバを専有することを意味するコマンドが
   あるか否かを判定する手段と、 該コマンドがない時には該出力サーバを共有的に使用
   し、ある時には該出力サーバを専有する手段と、 前記コマンドを有する出力要求の中の優先度を判定する
   手段とを具備し、 前記コマンドの受付け中に他の出力要求があった時には
   これを受付けないようにし、前記コマンドを有する出力
   要求は、該コマンドの受付け解除後に前記優先度を判定
   する手段によって判定された優先度に従って処理される
   ようにしたことを特徴とするネットワーク環境の出力サ
   ーバ。