DIPS-OSは，他の商用OSと同様にタイムシェアリングシステム（TSS）用およびリアルタイムシステム（RTS）用に2系統に分けて当初より開発／提供を進めてきた．しかし，OSが2系統あることは，TSSとRTSの複合処理形態など，後に高度化していくOS機能への新たなニーズに対する適応性に限界を生じ，また，両OSに対する共通的な改変の要因たとえば新ハードウェアへの対応などについてOSの機能追加，維持管理上の2重投資を要することなど支障を生ずる．
DIPSにおいては，このため既存のTSS，RTS各系統用OSの基本機能を共通にするとともにTSS，RTSにそれぞれ特有の機能を各々パッケージとして切り出し，サービスシステムによって異なる機能部分を選択可能な構成とすることによってOSを標準化することとし，これを104-02OSとして統合した形で開発することとなった．
既存の2系統のOSを統合するに当たっての基本構造は，
- （a）TSS，RTS両機能を既存サービスとの連続性を維持した上で提供できること
- （b）両機能をサービスシステムごとに取捨選択できること
を満足している必要があった．これより基本構造は，TSS機能をRTS機能と同様にOS基本機能の上で動作する1パッケージ（TSP：タイムシェアリングパッケージ）として実現することとなった．また，ベースとしては，RTS用の104-01OSを用いることになった．
統合方式としては，相違点を，ベースとなるOSに追加して実現する方式，基本機能を一部OSに追加し，その上でTSPの機能として実現する方式，104-01OSの方式に1本化し，統一する方式が，それぞれの機能構成の差異を配慮して選択された．
そのほか，通信制御機能はOSの一部としてこれまで実現されてきたが，ネットワークアーキテクチャとして標準化する動きが各社であり，電電公社でもデータ通信網アーキテクチャDCNAとしてOSから独立させパッケージ化を行った．同時に，ネットワークリソースの仮想化なども行われた．この後のDIPS-OSの機能拡張は，超大型のハードウェアから超小型のハードウェアまでを含めて，すべて1つのOSとして実現されていくことになった．
タイムシェアリングシステム（TSS）用OSとリアルタイムシステム（RTS）用OSの統合を図ることによる主たる経済効果は，（1）維持管理経費の削減，（2）機能拡充などに対する重複投資の回避および（3）資料・訓練などの1本化であった．
- 参考資料
- 図にDIPSソフトウェアの階層アーキテクチャを示す．図のように，DIPSのソフトウェアは4つの階層アーキテクチャで構成されており，以後もこのアーキテクチャに基づいて開発が進められていった．図の中の第1階層における制御プログラム（EXEC）が，DIPS-OSのことである．
