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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

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

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

従来の出力サーバ４は、ユーザに対して均等にサービス
を行うために、Ｆ　Ｉ　Ｆ　Ｏ（Ｆｌｒｓｔ　　Ｉｒ１
Ｆｉｒｓｔ　０ｕｔ）方式を採用していた。また、緊急
に出力したいという要求に答えるために、優先度の機能
も付加されていた。

例えば、第６図に示されているように、優先度を表すポ
インタＩ、■、■、・・・が定義され、ワークステーシ
ョン２．３等から、優先度Ｉを指定して出力要求Ａ１、
Ａ２、Ａ３、Ａ４、Ａ５、Ａ６、Ｂ１、Ａ７、Ａ８、Ａ
９、ＡＩＯがあり、優先度■を指定して出力要求Ｃ１、
Ｃ２、Ｃ３があり、優先度■を指定して出力要求ＤＩ、
Ｂ２があったとすると、前記優先度Ｉを指定した出力要
求のリクエストブロックＡ１〜Ａ６、Ｂ１、Ａ７〜Ａ１
０は、最先の出力を表すポインタＩに前記の順でつなが
れ、この順で出力の実行が行われる。

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

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

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

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

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

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

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

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

本発明によれば、該リザーブコマンドを付して出力要求
すれば、出力サーバは該主力要求をしたワークステーシ
ョンに専６されることになるので、たとえ大量の出力要
求をした時にもこの中に他の出力要求が混じることがな
い。このため、他の出力要求の実行のために時間を取ら
れることがないので、該人岳の出力を高速で行うことが
できる。

また、他の出力要求が混じらないので、３他の出力要求
によって得られた図面等の紛失を防止できるというメリ
ットもある。

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

ネットワーク１を介して図示されていないワークステー
ションから出力要求があると、該出力要求信号は出力サ
ーバの要求受付部１１に人力する。

該要求受付部１１では、ワークステーションからの出力
要求が自分の出力サーバに対するものであるか否かの判
断をし、自分向けの出力要求であれば、これを受付ける
。

受付けられた出力要求信号は、スプール処理部１２に送
られる。該スプール処理部１２は、スプールファイル１
３に対して処理待ちの順序を決める処理を行う、前記出
力要求が通常処理の要求であれば、該出力要求に対して
従来と同様の処理、すなわち第６図で説明したのと同様
の処理を行う。

この時、出力サーバはネットワーク１に接続された全て
のワークステーションに共有的に使用される。

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

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

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

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

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

次に、出力サーバの専有を意味するリザーブコマンド受
付は中か否かの判断をし、受付は中でなければ（ステッ
プＳ２がノウ）、該受付けた出力要求の中にリザーブコ
マンドがあったか否かの判断をする（ステップＳ３）。

該リザーブコマンドがなければ、ステップＳ４に進んで
リリースコマンドありか否かの判断を行い、該リリース
コマンドがなければステップＳ５に進んで、通常の処理
を行う。

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

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

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

この待避処理は、第４図（ｂ）に示されているように、
リクエストブロックＢ１、Ｂ２、Ｂ３がつながっている
ポインタを、待避キューの優先度Ｉのポインタ１′に置
き換え、リクエストブロックＣＩ、Ｃ２がつながってい
るポインタを、待避キューの優先度■のポインタ■′に
置き換えることにより、該リクエストブロックＢｌ、Ｂ
２、Ｂ３、Ｃ１、Ｃ２を待避させ、かつ、処理待ちキュ
ーの優先度１１■のポインタを、前記出力要求に明は渡
す動作を行う。このため、該出力要求から来た優先度Ｉ
のリクエストブロックＡ１〜ＡＩＯは、処理待ちキュー
の優先度Ｉのポインタにつながる。

なお、該出力要求が優先度■の場合には、これが処理待
ちキューの優先度Ｈのポインタにつながることは勿論で
ある。

該リクエストブロックＡＩＯが送られてきた後、リリー
スコマンドが来ると、前記ステップＳ４はイエスとなり
、ステップＳ７に進む。該ステップＳ７では、処理待ち
要求の復元が行われる。すなわち、第４図（Ｃ）に示さ
れているように、待避キューにつながれていたリクエス
トブロックＢ１、Ｂ２、Ｂ３、Ｃ１、Ｃ２が、処理待ち
キューに戻され、図示されているように、処理待ちキュ
ーの優先度■のポインタにリクエストブロックＢ１、Ｂ
２、Ｂ３、Ａ１〜ＡＩＯがつながり、処理待ちキューの
優先度■のポインタにリクエストプロ・ンクＣ１、Ｃ２
がつながる。

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

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

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

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

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

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

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

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

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

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

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

また、このため必要な出力全部を高速に得ることができ
るという効果もある。

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

【図面の簡単な説明】

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

Claims (1)

【特許請求の範囲】
1. （１）複数個のワークステーションが接続されたネット
   ワーク環境の出力サーバにおいて、あるワークステーシ
   ョンから送出された出力要求の中にリザーブコマンドが
   あるか否かを判定する手段と、該リザーブコマンドがな
   い時には出力サーバを共有的に使用し、ある時には該出
   力サーバを専有する手段とを具備し、該リザーブコマン
   ドの受付け中に他の出力要求があった時にはこれを受付
   けないようにしたことを特徴とするネットワーク環境の
   出力サーバ。