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

３．１　SYS@LMLには自分で作ったＬＭを置かない

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

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

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

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

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

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

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

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

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

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

考えてみれば、「SYS@LML」はＷｉｎｄｏｗｓのシステムフォルダに相当します。
システムフォルダに自分の作ったプログラムを入れる人はあまりいないでしょう。
おそらく適当なフォルダを作って、そのフォルダにプログラム（.exe等）を入れて、そのフォルダにパスを通すのではないでしょうか。
Ａ−ＶＸも同じです。適当なライブラリファイル（LML）を作って、そこにＬＭを入れるべきです。

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

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

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

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

３．２　自作のＪＳやＰＭはシステムライブラリに入れないほうがいいか？

「自分のところのＬＭ」はSYS@LMLに入れないほうがいいと書きました。
「自分のところで作ったＪＳやＰＭ」もSYS@JSLやSYS@PMLに入れないほうが良いのでしょうか？

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

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

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

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

３．３　Ａ−ＶＸならばメニューに登録すべし

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

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

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

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

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

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

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

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

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

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

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