メインフレーム
論理分割(論理パーティション (LPAR) ごとに、OSを稼働でき、割当資源を動的に変更できる)
ソフトウェア分割(専用の仮想化用OSを使用し、仮想機械上でOSを稼働でき、割当資源を動的に変更できる)
IBMの場合は、いずれの場合でも専用OS (z/OS, z/VSE, z/TPF) およびLinux for System z が同時稼働できる。(Linux だけを多数稼働させても良い)。
ユニシス (ClearPath Server シリーズ)では、最大8パーティションに分割できる(IBM系の物理分割に相当すると思われる)。
1990年代に各社とも、イーサネット・TCP/IP・各種の連携機能などには対応しているが、オープン系のOS (UNIX, Linux, Windows) そのものを稼働させる方法は、各社で相違がある。大別して外資系(IBM・Bull・ユニシス)は積極的で、国産各社は消極的と言える。
IBMはOS/390以後は専用OSでもUNIX互換環境 (USS) を標準とし、更にLinuxはネイティブ(専用OSを全く使用しない)でも稼働できる。
富士通は、PRIMEQUEST・PRIMEFORCE等で同一筐体にIA/UNIXサーバ (Solaris, Windows Server等)を搭載できる。
日立製作所は一時Linux for MP Seriesを出したが現在出荷はされておらず、現状ほとんどの環境で上位シリーズ (VOS3系)では下位シリーズ (VOS1, VOSK系)ともに、オープン系のOSは稼働しない。
日本電気は各シリーズ (ACOS-6, ACOS-4, ACOS-2系)ともオープン系のOSは稼働しないが、仮想化技術を使用してACOS-4はItanium2に、ACOS-2はXeonに移行した。
Bullは NovaScale 9000 (Itanium2) で、独自OS (GCOS 8) の他、Linux・Windows Serverも稼働できる。
ユニシスは ClearPath Server(独自CPUおよびXeon)で、独自OS (OS2200またはMCP)と、Linux・Windows Serverも稼働できる。
なお、同一筐体であってもオープン系OSをネイティブで稼働する場合は、メインフレームの利点はハードウェア面の信頼性や仮想化などになり、ソフトウェア面(専用OS)の利点・特徴は無くなる。
メインフレーム(ハードウェアおよび専用OS)のセキュリティは、最初から企業などの大規模組織での使用を考慮した、基本設計によるものが大きい。
ユーザーやプログラムは、自分以外のアドレス空間は原則アクセス不可能。(ハードウェアでフラグを持っている。他に起動しているアドレス空間(プロセス)を知る事も不可能。アドレス空間同士の連携はCSAなどメモリ上のデータ域か、SSIなど極めて特殊な権限事前登録後の特定アドレス間のみ。)
ユーザーやプログラムは、自分用に指定された磁気ディスク装置以外は、原則アクセス不可能。(ジョブ制御言語 (JCL) で指定されたデータセット以外は存在を知る事も不可能。動的割当(ダイナミック・アロケーション)も基本的には同様。)
システムの権限が分散されている。(OS管理ユーザ、データ管理ユーザなどが別々に設定できる。オープン系のようなスーパーユーザは存在しない。いわゆるセキュアOS。)
運用上もプログラマとオペレータは分離されている場合が多い。(プログラマはOSのコマンドは使わない、オペレータはプログラムを書くことはない)
ソフトウェアからマイクロコードにアクセスする事はできない。
論理パーティション (LPAR) 間のTCP/IP通信を仮想化した場合、メモリ間となり筐体外に出ない。
オープン系では通常、ネットワーク経由で進入後、脆弱性を攻撃しスーパーユーザに昇格さえできれば、そのコンピュータは完全に支配下に置ける。メインフレームの場合は、仮に同様の攻撃に成功しても、1アドレス空間しか支配できず、他のアドレス空間や他のデータセットへの読み書きもできず、システム全体の管理ユーザーにもなれない。
なお、過去には以下も要因であったが、メインフレーム固有とは言えない。
施錠されたマシンルームに保管され入室が厳しくチェックされていた。
ネットワーク回線は専用線を基本とした。(公衆回線は避けられた)
ネットワークプロトコルが独自で、各セッション単位で集中管理でき、常時監視(ポーリング)されていた。
また「メインフレームのセキュリティが高いのは、数が少なく標的とした攻撃やウイルスが少ないため」という説明が広くされているが、メインフレームには世界中の銀行・政府・軍事情報が格納されていることを考えると妥当ではない。
ただし、上記は全て専用OSの場合であり、UNIXやLinux, Windowsをネイティブで稼働した場合は、OSレベルのセキュリティは、そのOSのレベルとなる。
メインフレーム上で使われている主なプログラミング言語には、当初からの各アーキテクチャ用のアセンブリ言語に加え、伝統的な高級言語であるCOBOLやFORTRANやPL/I、およびC言語・C++・Javaや、各ベンダー独自の4GLなどがある。
メインフレームでは同一アークテクチャ内のCPU命令セットや入出力命令の上位互換が厳密に維持されている場合が多いため、アセンブリ言語は制御系や特に性能を重視する個所などに2010年現在でも使われ続けている。高級言語は普及時期がメインフレーム全盛期と重なった事もあり、商用計算ではCOBOL、科学技術計算ではFORTRANが2010年現在でも広く使われている。なおIBMは1980年代のSAA CPIではCOBOL・FORTRAN・C言語を採用したが、メインフレームではPL/Iを併用し続け、1990年代後半からはJavaも推進している。富士通・NEC・日立などでは伝統的なCOBOLやFORTRANを中核とし、C言語やJavaなどを併用している。
メインフレームはI/Oを含めた平行稼働やワークロード管理により複数業務の並行稼働性に優れている。スループットが安定しているので、大規模バッチ、大規模帳票出力業務などに強い。
メインフレームのスピードはベンチマーク値で表される事が多い。歴史的にはMIPS (million instructions per second) で計測されてきた。MIPSはメインフレームの性能を簡単に比較できる。IBMのメインフレームzSeriesの性能は約26MIPS (z890 Model 110) から20000MIPS以上 (z9-109 Model S54) とされている。
しかし、MIPSは誤解を与える指標である。命令そのものの粒度が異なるため、プロセッサのアーキテクチャの変遷に伴って、MIPSが本来持っていた実行命令数という意味は失われている。MIPSは技術的には意味はなく、単に昔のマシンとの性能比較の目安となっているにすぎない。このためIBMはメインフレームに数種類の負荷をかけて計測するLSPR (Large System Performance Reference) レシオを公表している。
同様のことがUNIXサーバでも見受けられる。顧客は用途に合ったタイプのベンチマークで性能を比較するようになってきた。例えばSPECintやTPC-Cなどである。もっとも、それらのベンチマークも全く問題がないわけではない。顧客が自分のシステムにどういったタイプの負荷がかかるのかを分析することは非常に難しく、結果として単にLSPRの値などを使う事になる。そういった意味でMIPSの使い道は残り、IBMや他のコンサルタントはMIPSを公表し続けている。
2005年(平成17年)の調査によると利用別のシェアにおいて、基幹業務では「汎用機とオフコンが依然7割近く」使われている。特にメインフレームは高い信頼性や大量のトランザクション処理が求められるシステムで使用されている。
企業、官庁、自治体などの基幹業務システム
自治体(市町村)基幹業務システム
装置産業である銀行など大手金融機関(いわゆる、勘定系システムを中心とする「基幹系システム」とも称する計算機群)
交通機関の座席予約システム(CRSやマルスなど)のような、大量のトランザクションの高速処理
大手自動車メーカーの世界規模の部品表管理システム(メインフレームにLinuxを搭載)
航空路管制システム(特に高い信頼性・性能が必要なため、TPFなど特殊なOSを使用している)
日本の産業別の出荷傾向では、トップは一貫して公共機関で、1998年度から2007年度の平均は37%。なお金融機関の平均は19%である。
メインフレームからオープン系へ移行することもある。
東京証券取引所の次期株式売買系システム(メインフレーム→Linux搭載のIAサーバ)
大阪証券取引所の株式売買系システム(メインフレーム→AIX搭載のUnixサーバ)
メインフレーム(正確にはメインフレーム用の専用OS)で稼働しているシステム(業務・プログラム・運用)をオープン系 (Windows・UNIX・Linux等)に移行する場合は、特に以下に考慮する必要がある。単純にコンバージョンできるシステムもあるが、多少とも複雑なのものは、システム構築(設計)時の背景にある、「文化の違い」を把握し、ユーザーに十分説明し、場合によっては割り切りや、マイグレーション断念(メインフレーム継続使用の方が望ましい)などの場合もある。
ただし、以下の考慮点はあくまで商用における一般的な傾向であり、個々のシステムでは限らない。
オープン系は、伝統的にC言語・Java・各種シェルなどが多い。
メインフレームでは、伝統的にアセンブリ言語・COBOL・PL/Iなどが多い。またJCLはシェルと異なり必須であり、論理(プログラム)と物理(オペレータ)を分離している。このため単純コンバージョンすると運用と乖離する場合がある。
オープン系は伝統的に、単純なデータはファイルに、重要なデータは関係データベース管理システム (RDBMS) に格納し加工する傾向が強い。
メインフレームは伝統的に、データはデータセットやVSAMなどに格納して加工後、必要最小限の箇所のみ階層型DBMSまたはRDBMSにロードする傾向が強い。
オープン系は伝統的に、オンラインを中心とし、大規模なバッチは組まない傾向が強い。
メインフレームは伝統的に、オンラインシステムであっても夜間などの大規模なバッチが多く、先行関係も複雑な傾向が強い。
オープン系は伝統的に、応答速度重視のため、ある処理(業務・バッチ・プログラム)の負荷が高くなると、その処理に全力(CPUなどのリソース)をかけてしまう。このため負荷分散・安定稼働のため「サーバ乱立」に陥る傾向がある。ワークロード分散などのツールもあるが、広く使われているとは言いがたく、またジョブまたはトランザクション投入単位でしかない場合が多い。
メインフレームは伝統的に、1台にて多数の処理(業務・バッチ・プログラム)を並行稼働させるよう設計されている。常駐プログラム間やバッチ間で細かいリソース優先順位設定ができ、I/Oも並行稼働性が高い(大量データ転送の際のCPU負荷が少ない)。このため並行稼働・安定稼働・スループットの実績が高いが、逆に1処理当たりの応答速度は遅い場合が多い。
多数の処理が並行稼働しているメインフレームを単純に1台の高速サーバに移行する場合は、特に注意する必要がある。逆に、処理ごとにサーバを分けて回避すると、月次処理など特定処理のピーク時に全サーバのリソースを集約できずにボトルネックとなる場合もある。
オープン系は伝統的に、起動したまま、あるいは定期的な単純な保守(FIX・バックアップ・リブート)の場合が多い。
メインフレームは伝統的に、定型化された運用手順書による専任オペレーターによる工場的な運用(プログラマーやシステムエンジニアは操作が禁止されている)が多い。
オープン系は歴史的にセキュアOSではない。管理者権限を奪われるとシステムのコントロールを掌握されるため、各種の設定・ツールでハードニングを行い、更には最初からセキュアOS(SELinuxなど)を検討する必要がある。
メインフレームは伝統的に、最初からセキュアOSで権限分散を前提に設計・構築・運用がされている。(逆に、本当に全ての場合で必要かはあるが)
オープン系(特にWindows)は伝統的に、製品障害(不具合)にはFixPackや次回バージョンアップで対応する場合が多い。
メインフレームは伝統的に、製品障害(不具合)には単体FIXで対応する場合が多く、大量のFIXの前提(先行関係)を把握するために大規模システム(ユーザ)には専任の技術者を置いている場合もある。
従って、メインフレームではレベル管理が非常に大変な反面、製品障害(不具合)が単体FIX(最低限の修正)で修正できる場合も多いので、重点的な確認テスト(および副作用発生時の単体でのFIX戻し)が可能となり、業務確認を含めた保守工数が最小で済む場合がある。(同様の事はオープン系でも可能な筈だが、ベンダーの対応レベルには差があるのも事実)
メインフレーム(特に専用OS)とオープン系 (Windows, UNIX, Linuxなど)、または異なるアーキテクチャのメインフレーム同士のデータ交換での考慮点には以下などがある。
オープン系はASCII・EUCなど。
メインフレームは、例えばIBM及びIBM互換機(富士通・日立製作所)並びにACOS-4及びACOS-2はEBCDIC。
ただし、SBCSだけならば簡単な変換テーブルで容易に変換可能である(のオプション、iconvコマンド、FederationなどのDBMS機能など)。
またUNICODEや、UNICODEを内部使用するJava、一部メインフレームOSのUNIX互換環境、メインフレーム上のLinuxなどによってもハードルは下がっている。
MS-DOS (Windows)は、レガシー的にはシフトJISによるSBCS/DBCS(日本では)。近年ではUTF-8N。
メインフレームは、JIS漢字コードが基本だが、IBMはIBM漢字コード、富士通はJEF、NECはJIPS、ユニシスはLETS-JとJBIS など細部(ベンダー拡張部分)が異なり、更に年度や外字などの相違もある。またJIS漢字コードの特徴である、SBCS/DBCS混在を可能とする制御コード (SO/SI = Shift-Out/Shift-In) が必要なため、この付加・削除、更にはそれにより発生しうる桁数の変動(画面/帳票レイアウトへの影響)までも考慮する必要がある。
ただし、JIS第一水準・第二水準などの基本的な日本語 (DBCS) は、上記の制御コードさえ考慮すれば、ツールで容易に変換できる(FTPのオプション、iconvコマンド、FederationなどのDBMSの機能など)。
またUNICODEや、UNICODEを内部使用するJava、一部メインフレームOSのUNIX互換環境、メインフレーム上のLinuxなどによってもハードルは下がっている。
通常のオープン系は、階層ファイルシステム。
IBM系(IBM、富士通、日立製作所)の専用OS、並びにACOS-4及びACOS-2は、VTOCでデータセットを管理し、ファイルの内部構造もOSにより標準化されているのが一般的である(→ データセット (IBMメインフレーム) および  も参照)。
主なの構造(簡単なテキストのみの場合)
通常のオープン系は、OSレベルでレコード属性が標準化されていないため、改行コードによりレコードを区別するデザインが一般的。更にCSVも多用する。
メインフレームは、OSレベルでファイル(データセット)ごとに「固定レコード長」属性を持って改行コードは使わないデザインが一般的。
このためレコードごとに改行コードを追加/削除する、末尾のブランクを削除/追加する、場合によっては複数レコードをまとめる、などの考慮が必要になる。
通常のオープン系は、簡単なバックアップはtarなどのコマンドでDDS/DAT72に、重要なデータのバックアップはツールを使用してLTOなどに保管する場合が多い。
メインフレームは、(TAPEとDISKの変更がJCLの指定だけでできるため)容量が大きいもの、使用頻度が低いものはテープ保管し、それを後続バッチで入力とする場合が多い。またテープには「SL (Standard Label)」「NL (No Label)」などのラベルを記入し、専用のカートリッジテープ (CMT/CGMT) やMTが使われることも多い。最近では、カートリッジテープの生産終了に伴い、メインフレームでもLTOに移行しつつある。
現存する各社の主なメインフレームとその系譜は以下の通りである。
過去に存在した主なメインフレームには以下がある(観点によってはメインフレームと呼ばれないものも一部含む)。
Platform Solutions Inc. (PSI)
米PSI社は1999年にアムダール社出身者などにより創立され、ItaniumベースのサーバーでIBMメインフレームをエミュレートし、IBMのOS (z/OS) を稼働させていた。2006年にIBMと相互に訴訟となったが、2008年にはIBMに買収されSystem z事業部に統合された。
T3 Technologies
T3 Technologies社は1999年に創立された。上記のPSI社の技術を使用し、ItaniumベースのサーバーでIBMのOS (z/OS) を稼働させている。2009年に欧州でIBMに対し独禁法訴訟を起こした。