カタログについて、歴史的経緯と個人的思い出を書いておきます。
もともとメインフレームでは、MVS以前のMVTのころからCVOLという考え方がありました。データセットリストを記憶しておくデータベースみたいなもので、IEHPROGM(このユーティリティは今も現役でしょうか)でコントロールしていました。
世の中にカタログが出てきたのは、VSAMと同時だったように思います。VSAMはアクセスメソッドですが、カタログ自体がVSAMを利用しているので一緒に語るものです。当初VSAMカタログの場合、データセットの管理ということでデータセットの名前、構成はおろかスペース管理までもやろうと考えていました。今のデータベースの考えに近いです。最初にスペースを取って、データセットの大きさを決める。同時にスペースを管理するということは、そのボリュームを管理することになりますから、ボリュームオーナーシップという考え方が必須でした。ボリュームは一個でもVSAMデータセットを作ったら、いずれかのカタログに忠誠を誓うわけです。
ところがこのアーキテクチャは結果的にいろんな問題を引き起こしました。次が代表例です。
・カタログが壊れると、スペース不明のボリュームが大量に出てくる。被害が甚大。
・VSAMに書き込むたびに、カタログへ頻繁にアクセスが起きる。パフォーマンスが低下する。
・カタログごとにエイリアスをもつため、ひとつのボリュームに違うカタログでつけたエイリアスをつけられない。自由にファイルを作れない。

とくに一番目の問題は致命的でした。このころ技術的にはカタログをどうやって救うか、ということが大事なことでした。

それを省みてでてきたのが、ICFカタログです。IDCAMSが機能を大幅に拡張してきたのも、これ以降です。
ICFカタログは、ボリュームごとにVSAMデータセットを管理する、SYS1.VVDS.Vボリューム名　という管理データセットを作ります。それでVSAMを管理します。この考え方でSPACE管理とボリュームのオーナーシップはなくなりました。VSAMデータセットの大きさはVTOC情報と一致するのです。ただし、どえらいエクステンションを許すようになりましたが。また、カタログはボリュームへのポインターに過ぎないので,VSAMも非VSAMデータセットも同様に管理できるようになりました。カタログが壊れても再構築が簡単になりました。

昔話はここまでです。
さて、オープン系を見ると、フォルダーという階層型ファイル管理ばかりです。確かに書類とフォルダーというオフィスにあるメタファーを利用しているため、理解が簡単という面はあります。一方で、ファイルの名前にユーザーはものすごく無頓着です。メインフレームのユーザーはカタログのエイリアスで整理する習慣が身にそまっているので、ついつい、フォルダー名に応じたファイル名などをつけようとしてしまいます。どちらが便利なのでしょうか？
私はオープン系はディスクの発達が急速だったため、それほどボリューム数が必要なかったことが幸いしていると思います。１００個もディスクをつけているシステムなんてあるのでしょうか。ボリュームが数個であるのなら、階層型フォルダーのほうが便利なのでしょう。メインフレームのようにUCBの許す限り多くのボリュームを取り付けられる（しばしばオフライン）の場合、ボリューム名を知らなくてもファイル名のルールでアクセスできるほうが便利なのでしょう。