Google
オフコン練習帳内を検索
インターネット全体を検索

NECオフコン関連
オフコン一般
情報

トップ  >  ライブラリへのメンバ登録に関する案

ライブラリへのメンバ登録に関する案

3.1 SYS@LMLには自分で作ったLMを置かない

既に説明したようにSYS@LMLにあるLMはDEV=やFIL=を省略できます。いろいろなLMは全部SYS@LMLに入れてしまえば、RUNコマンドで楽できます。

ということで、どんどんSYS@LMLに入れてしまいがちですが、ここにはいくつかの落とし穴があります。

(1)SYS@LMLはサイズの拡張が面倒である。

A−VXは一度ファイルを作った後にさらにサイズを増やすのが結構面倒です。特にシステムファイルであるSYS@LMLの場合は一筋縄にはいきません。

何でもかんでもSYS@LMLに入れていくと、最初は余裕があったのにいつの間にかファイルオーバーフローになってしまうということがよくあります。
そうなると半日がかりでSYS@LMLのサイズを拡張するという作業を行わなければならなくなります。
普通のLMLであれば、一度LML内を全バックアップ -> LMLを削除 -> 大きなサイズで同じ名前のLMLを作る -> バックアップしたものを戻す、という作業手順でできるので、まだましです。(これも大変ですが・・・。)

(2)どれが自分のところで作ったLMかわからなくなる

SYS@LMLの中には既にいろいろなLMが入っています。
システムユーティリティやSMART、COBOLといった有償ソフトウェアも入っています。

システムユーティリティは、頭に「#」が付くので判別できます。しかしSMARTやCOBOL、RDB/EUFといった有償ソフトウェアのLM群はそのようなものは付きません。
何でもSYS@LMLに入れていくと、自分のところで作ったLMなのか、NECから買った有償ソフトウェアのLMなのか、区別が付かなくなってしまいます。

いろいろな場面で不都合が起きます。例えば新しいオフコン(Express5800/600シリーズ)を買ったとします。おそらく古いオフコンのSYS@LMLに入っている自分のところのLMを新しいオフコンに入れる作業をするでしょう。
どれが自分のところのかよくわからないので、LMのコピー漏れが発生してしまったり、せっかく新しいSMARTを購入したのに間違えて古いSMARTを上書きコピーしてしまったり、ということが起こりえます。

上のような不都合があるので、LMはSYS@LMLに入れるべきではありません。

考えてみれば、「SYS@LML」はWindowsのシステムフォルダに相当します。
システムフォルダに自分の作ったプログラムを入れる人はあまりいないでしょう。
おそらく適当なフォルダを作って、そのフォルダにプログラム(.exe等)を入れて、そのフォルダにパスを通すのではないでしょうか。
A−VXも同じです。適当なライブラリファイル(LML)を作って、そこにLMを入れるべきです。

------------------

実際はたいていの場合、SYS@LMLに何でも突っ込んであるのではないかと思います。(#ABCを使ったライブラリの見方はこちら

これはおそらく理由があり仕方がないことです。
昔のオフコンのハードディスクのサイズは30メガバイトや100メガバイトしかなく、その中でやりくりしなければならなかったのです。いろいろなファイルを作るだけの容量が無かったため、何でもSYS@LMLに入れざるを得なかったのです。

今はハードディスクの容量も大きくなったので、今後はできるだけSYS@LMLに入れないようにしたほうが良いと思います。(今SYS@LMLあるものを別のところに変えるのはリスクが大きいので、やらないほうがいいです。)

3.2 自作のJSやPMはシステムライブラリに入れないほうがいいか?

「自分のところのLM」はSYS@LMLに入れないほうがいいと書きました。
「自分のところで作ったJSやPM」もSYS@JSLやSYS@PMLに入れないほうが良いのでしょうか?

私の考えとしては、入れてもいいと思っています。
SYS@JSLやSYS@PMLは、SYS@LMLと比べるとサイズの拡張が簡単です。(あくまでもSYS@LMLと比較するとであって、やっぱりそれなりに大変です。)そして最初は何も入っていないので、自分のかどうかわからなくなるということもありません。

LMはユーザのライブラリに入れているので、RUNコマンドで実行する時にはDEV=やFIL=を付けなければなりません。
これでは不便です。LMの実行を簡単にする為に、SYS@JSLやSYS@PMLを利用します。
例えば、
「MSD001」の「USERLML」に「AAA」という「自分のところで作ったLM」を入れます。
下のようなJSを作り、「AAA」という名前にして、SRV(MSD000)のSYS@JSLに入れます。


/RUN AAA,DEV=MSD001,FIL=USERLML;
/>;


RUNコマンド行で「AAA;」として実行すると、まず「SYS@JSL」のJS「AAA」が実行され、RUNステートメントで指定された「MSD001」の「USERLML」にあるLM「AAA」が最終的に実行されることになります。
LMはユーザライブラリに入れても、同名のJSをSYS@JSLに入れておけば、簡単にLMを実行できるようになります。

3.3 A−VXならばメニューに登録すべし

A−VXの正しいシステムのあり方は、普段使うLMやJSやPMは全てメニューに登録して、業務は必ずメニュー画面から選択して始めるようにする、ということです。
RUNコマンド行から入力して業務プログラムを開始するということは、A−VXの本来の思想からはずれていると思います。
LMをメニューに登録しさえすれば、カーソルを動かすかメニュー番号を指定するだけでLMを実行できるようになるので、わざわざLMをSYS@LMLに入れる必要性はありません。

メニューに全て登録するようにすれば、JSやPMもSYS@JSLやSYS@PMLに入れる必要性はなくなります。メニューのPMだけ、SYS@PMLに入れればいいのです。(JSやPMはSYS@JSL、SYS@PMLに入れておいても全然問題ないと私個人は思います。)

そして普段使うメニューは初期プログラムとしてシステムに登録します。
初期プログラムとは、操作開始した時(簡単に言うと端末を起動したり、PC/WSエミュレータを起動した時)に、自動的に実行されるプログラムのことです。
RUNコマンドでメニューのPMを実行しなくても、メニュー画面が自動的に立ち上がるので、メニューのPMをSYS@PMLに入れる必要もなくなります。

ちなみにOCF機能を有効にすると、オペレータ毎にどのメニューを起動するか指定することができます。例えばAさんがPC/WSエミュレータでオフコンにつなげるとメニューAを自動起動、BさんだとメニューBを起動するといった具合です。

今までの話を整理すると下のようになります。

  • 「自分のところで作ったLM」「自分のところ所有のLM」をSYS@LML以外のLMLに入れる。
  • 必要に応じてJSやPMを作る。これはSYS@JSLやSYS@PMLに入れても、別にユーザライブラリファイルを作ってそこに入れてもどちらでも良い。
  • 上記のLMやJSやPMを全部メニューに登録する。
  • メニューを初期プログラムに登録する。

3.4 メニューに登録すればセキュリティも高まる

A−VX付属のメニューはRUNコマンドも実行できるようになっているため使えませんが、RUNコマンドを使えないようにしたメニューを使うことでセキュリティを高めることもできます。
A−VXに詳しい人ならば、例えばRUNコマンド行からシステムユーティリティ#DUMPを起動して、直接ファイルの中身を見ることができてしまいます。印刷だってできてしまうので、最近の情報セキュリティの話上まずいことになります。
(ちなみに幸か不幸かA−VXに詳しい人が少ないということが、A−VXの最高のセキュリティになっています。そういう意味ではいろいろな情報を漏らしている私のサイトはセキュリティホールということになります。)
全てメニューに登録してRUNコマンドから勝手にユーティリティや他人のプログラムを実行できないようにすることができれば、権限のない人が勝手にファイルを見るということができなくなります。
(本当にRUNコマンド行を実行できないようにすると保守作業ができなくなるので、運用管理者だけ何らかの形で(隠しで)RUNコマンドに抜けることができるようにしておく工夫が必要となります。)

OCF機能でファイルなどにセキュリティを掛けておいて、さらにメニューでガードすれば完璧ですね。

OCF機能ありにするとSYS@PMLのみオペレータ毎に作ることができます。(SYS@PMLはローカルファイル、SYS@LMLやSYS@JSLはグローバルファイルになる。)これはSMARTのプログラム(PM)をオペレータ毎にSYS@PMLに入れることができるようにするためだと思われます。
SYS@PMLがオペレータ毎にあるローカルファイルならば、他人のSMARTプログラムは実行できないので、これもセキュリティ対策の1つになります。

最初に#DUMPで誰でもファイルの中身を見ることができると書きましたが、#DUMPを業務で一切使用しないのならば#DUMP自身に機密保護を掛けて、管理者しか使用できないようにするのもひとつの手です。