VM領域は、VOSアプリケーションにおいて共有可能なアドレス空間として頻繁に使用される。これは複数のプロセスが同一のアドレスセットにアクセスすることを可能にする非常に効率的な方法である。主な欠点は、VOSの仮想メモリ制限により領域が2GBを大幅に下回ることに制限される点であり、この使用は他の目的に利用可能なVMを削減する。
アドレス空間は、アドレスをバイナリファイルにマッピングし、ファイルI/O操作を通じてそれらのアドレスにアクセスすることで、ファイルシステム経由でも共有できる。これにより仮想マシン領域のサイズ制限が解消され、専用に割り当てられていた仮想マシンが解放される。領域ロックによる協調も可能となるが、特に実際のディスクI/Oが関与する場合、共有仮想マシンへの直接アクセスよりもはるかにコストが高い。
Posixアプリケーションでは、この目的のためにバイナリモードのストリームファイルを使用することがある。ftruncate（EOFの位置を拡張する機能のために使用される）によってアドレス空間の希望サイズを設定し、その後ファイル内のデータを読み書きする領域へ移動する。このようにしてファイルはアドレス空間のバッキングストアとして機能し、プロセスはfseek/fread/fwriteなどのファイル指向インターフェースを用いて空間を共有する。
64ビットストリームファイル（リリース17.2で導入）以前では、通常のストリームファイルはスパース化できず、EOFの拡張にはバイナリゼロのブロックを明示的に割り当てて書き込む必要があるため、VOSでは非常にコストがかかる処理でした。 例えば、必要なアドレス空間が2GBの場合、VOSは524,288ブロックのディスク領域を要求します。実際にはバイナリゼロ以外の値を含む領域はごく一部であるにもかかわらずです。64ビットストリームファイルでは、この種のアプリケーションがVOS上で効率的に動作し、実際に必要なディスク容量のみを消費します。 Posixアプリケーションは、大容量ファイル対応でビルドされる場合、自動的に64ビットストリームファイルの恩恵を受けます。ファイルが2GBを超える成長が見込まれない場合でも、このパフォーマンス向上を得るためにビルドを行うべきです（詳細はOpenVOS POSIX.1リファレンスマニュアルR502「既存アプリケーションの64ビットストリームファイル環境への移植」を参照）。
ネイティブVOSアプリケーション、すなわちs$インターフェースを利用するアプリケーションにおいても、ファイルベースの共有アドレス空間を同様に使用することが可能です。VOSはこの技術を使用する際、ディスクI/O特長 大幅に特長 数多くの特長 を提供しており、本質的にCPU使用量を主要なコストとしています。リリース17.2におけるスパース64ビットストリームファイルの導入により、この共有アドレス空間へのアプローチはさらに魅力的になりました。
メモリ常駐ファイルとRAMファイル
メモリ常駐ファイルはset_open_optionsコマンドで識別されます。ディスクキャッシュの設定可能な領域がメモリ常駐ファイル用に確保されます。利用可能な物理メモリやキャッシュの他の用途に応じて、最大9～10GBまで設定可能です。メモリ常駐ファイルのブロックは、キャッシュに一度読み込まれれば、その総量がキャッシュの割り当て領域を超えない限り、以降のディスク読み込みが発生しません。超過した場合、直近で参照されたブロックのみがこの利点を維持します。
RAMファイルは非永続的なデータを含むファイルであり、アプリケーションの使用終了時にディスクへ書き込む必要のないデータを含む場合に有用です。set_ram_fileコマンドを使用できますが、s$delete_file_on_closeが呼び出されたファイルは、その時点から自動的にRAMファイルとして扱われます。
メモリ常駐ファイルは後続のディスク読み取りを発生させませんが、ブロックは依然として一定間隔で書き込まれ、キャッシュ内で許可される変更済みブロック数は他のファイルと同様に制限されます。 変更ブロック制限は、ファイルのクローズやフラッシュ時に数百万ブロックの書き込みが発生する事態を防ぐためです（4GBファイルは100万ブロックを占有）。この制限により、書き込み速度を上回るデータ変更を行うアプリケーションの速度が低下する可能性があります。RAMファイルは、ファイルが非アクティブ状態でもデータをディスクに書き込む必要が一切ないため、この種のスロットリングを回避します。
メモリ常駐RAMファイルを使用すると、キャッシュメモリ内にアドレス空間が提供され、ほとんどのディスクI/Oを回避できます。このアドレス空間は、利用可能な物理メモリ（仮想メモリではなく）に基づくキャッシュサイズによってのみ制限されます（キャッシュマネージャは物理メモリにアクセスするためにVMアドレスを共有します）。 注記：単一ファイルベースのアドレス空間は最大512GBまで拡張可能ですが、キャッシュの常駐領域を超えると、少なくとも最近参照されていないブロックについてはI/O上の利点が失われます。
例
ストリームファイルの内容は、バイト指向のオペコードでs$seq_positionを使用してアクセスし、s$read_raw/s$write_rawで検査または変更できます。64ビットストリームファイルは、ファイル内で使用されている領域（つまり、非ゼロに設定されている領域）を除き、実質的なディスク容量を必要とせずに最大512GBまで可能です。
例えば、
create_file scratch -organization stream64 -extent_size 256
これにより「scratch」という名前のDAE-256ファイルが作成されます
set_ram_file スクラッチ
これにより、このファイルは変更されたブロック数に関連するスロットリングを回避し、キャッシュへの無制限アクセスが可能になります。また、バックグラウンド処理時やキャッシュが枯渇して他の目的に必要となる場合を除き、ディスク書き込みを完全に回避できます。これはs$set_ram_fileを介してプログラム的にも実行可能です。最後の開いているプロセスがファイルを閉じると、キャッシュ内のデータは破棄され、ディスク書き込みが発生することはありません。このコマンドを使用する際、ファイルは空である必要があります。
set_open_options スクラッチ -キャッシュモード メモリ常駐
これにより、このファイルのブロックが可能な限り多く、無期限にキャッシュ内に保持されます。実際の数は、set_tuning_parametersコマンドで設定されたキャッシュサイズとメモリ常駐率の関数となります。
以下のシーケンスは、プログラムによる使用例を示しています（test_system_calls を使用して説明）：
tsc: s$attach_port p scratch
tsc: s$open p -io_type update
さて、約512 GBのアドレス空間を提供します：
tsc: ストリームファイルの延長 p 549235720192 (s$control EXTEND_STREAM_FILE)
そして、それを使ってデータを保存します：
tsc: s$seq_position_x p bwd_by_bytes 3 (現在の位置は拡張後EOF)
tsc: s$write_raw p END
tsc: s$seq_position_x p bof
tsc: s$write_raw p START
tsc: s$seq_position_x p fwd_by_bytes 2000
tsc: s$write_raw p 2000
注記: s$seq_position は、絶対バイトオフセットへの位置指定もサポートするオペコードに対応しています。
結果は次のようになります。ファイルはディスク上でわずか2つのデータブロックを占めるだけです：
..dump_file スクラッチ -簡易
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:04:17 est
ブロック番号1
000 53544152 54000000 00000000 00000000 |START………..|
010 00000000 00000000 00000000 00000000 |…………….|
=
7D0 00000000 00323030 30000000 00000000 |…..2000…….|
7E0 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
ブロック番号 131870736
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00454E44 |………….END|
注記：ブロック1および131870736はキャッシュ内に存在し、通常はディスクに書き込まれていません。ただし、キャッシュリソースが逼迫した場合に必要となる可能性に備え、ディスク領域は確保されています。上記のdump_fileコマンドはディスクを読み取っているのではなく、キャッシュされたブロックを認識しています。
RAMファイルが無効化されると（どのプロセスでも開かれなくなると）、VOSはファイルを切り詰めます（変更されたブロックをディスクに書き込むことを回避し）、すべてのディスク領域を解放します。通常の状況下では、上記の一連の処理により、最終的に破棄される2つのファイルマップブロックの書き込みを除き、ディスクI/Oは一切発生しません。
tsc: s$close p
ファイルは空で、ディスク容量を一切占有していません：
tsc: ..dump_file 仮ファイル
%swsle#Raid4>otto>d-3>new>scratch 15-02-25 16:07:12 est