古い鉄は頑丈なソフトウェアだと思われます。何故ですか？それはソフトウェアが成熟していて、すべてのバグが解消されたからですか？それとも、人々はバグに慣れてきたので、彼らはそれを認識していなくてもそれを回避するからですか？ソフトウェアの仕様は1日目から完璧だったのですが、ソフトウェアが書かれれば、すべてがうまくいったのですか？私は、メインフレームのコンピューティングの時代からどのようになってきたのかを理解しようとしています。誰もが今、TDDが今の道のりであると感じるよう努力していると思っています。なぜメインフレームアプリケーションにバグがありますか？
なぜ地球上にバグがないと思いますか？
IBMは、広く使用されているバグ報告および解決（PMR、APARおよびPTF）のための広範なサポート・インフラストラクチャーを持っています（）。
長年触れられていないメインフレームソフトウェアは、（少なくともその固有性の点で）十分に理解されており、多くのバグが修正されたり回避されている可能性があります。今日開発されている新しいものはすべて、GA（一般的な可用性）から少なくともGA + 36ヶ月までの一定数のバグとパッチを実際に計画しています。実際、IBMの元上司は、バグを計画しているバグの数値を提供することを強いられていました。「バグはありません。
メインフレームは、ほとんどのデスクトップハードウェアとソフトウェアがこれまでに目指すことができるものを超えたRASの原則（信頼性、可用性、保守）espouses - それはもちろんの唯一の私の意見ですが、私はIBMためだ右:-)
よ開発サイクルを経るにつれてバグを修正するコストが大幅に増加することはよく知っています。ユニットテストのバグを修正するのは、お金の両方でと評判。
バグのないソフトウェアをリリースするだけでは膨大な労力とコストがかかりますが、それでも時間がかかることさえありません。
ああ、間違いなくバグがあります - もっと面白い例はthedailywtf.comをご覧ください。つまり、今日の「メインフレーム」アプリケーションのほとんどは、すべての問題を解決するために30年を要しているため、ここ数年で作成されたほとんどのアプリケーションよりも少し有利です。
すべての新しいメインフレームアプリケーションはどのようにして問題を解決しますか？ –
@JoeZitzelberger：彼らは新しいものを作っていません。通常、古いEDIインターフェイスを何らかの種類のWebサービススタックにラッピングするだけです。それはおそらく、存在するバグのない単純なアプリケーションではありません。 –
MVS/OS390/ZOS-CICS/TS-COBOLアプリケーションプラットフォームの死亡に関する噂は、アップルコンピュータとそのニッチプラットフォームの死亡の噂が流れている限り、流通し続けています。メインフレームの世界には多くの新しい開発があります。最初のコメントが認識されるのに十分な皮肉で落とされなかったのなら、ごめんなさい。 –
私はメインフレームに関する経験はありませんが、それはあなたが作った最初のことだと思います。このソフトウェアは数十年前からありました。残っているバグのほとんどは解決されています。
さらに、Y2Kのようなfiascosを忘れないでください。遭遇したバグはすべて解決されており、20年後にはほとんどの状況が発生している可能性があります。しかし、たまに、新しい状況はになり、20年前のソフトウェアも動作を停止させます。
（もう1つの興味深い例は、BSD Unixに見つかったバグです.1年前に発見されました。
プログラミングは、選択されたエンジニアだけがそれに取り組むことができる高度なフィールドだったと思います。現在、プログラミングの世界はあらゆる面で侵入障壁が低く、はるかに大きくなっています。
正式なトレーニングを受けていないCOBOLプログラマーは、しばしばそれはメールルームを運営することからの昇進だった... –
メインフレームソフトウェアにはバグがたくさんありますが、影響を受ける開発者グループが比較的少ないため、公開されていません。メインフレームの開発をしている人に、毎日見ているアベニューの数を聞いてみてください！
ABEND！私はまだそれを時々、悪名高い0C4と呼ぶようです。 –
// SYSABEND DD SYSOUT = A - 非常に長い日の始まりです。 –
影響を受ける開発者ではなく、顧客です。また、メインフレームソフトウェアのバグの影響を受ける人の数は、最近、オーストラリアの最近の銀行破綻のように、ネット上でアカウント情報が入手できず、多くのオンライン取引が数日遅れるなど、巨大なものになる可能性があります。オンラインバンキングインフラストラクチャのすべてのバックエンドであると思われるのは、いくつかのPC上のSQL Serverですか？ :-) – paxdiablo
大きな鉄製メインフレームでデバッガを使用してコアダンプを解析する方法を学びました。彼らはバグのためだけに来たと私を信じてください。あなたは間違っているだけです。
しかし、メインフレームアーキテクチャは、高いストレス下での安定性のために設計されています（非メインフレームシステムと比較しても優れています）ので、そのように優れていると主張できます。しかし、コード賢明？ナーバグはまだそこにあります...
私はメインフレームアプリケーションで作業していました。以前のアプリでは、多くのことをしなかったので、多くのバグはありませんでした。 FORTRANの何千もの行ではないにしても何百行も書いて、今Excelの数式を使って何をするかを書いています。しかし、カード1の列12-26に1つの値を入れ、カード2の列1-5に別の値を入れて、入力を得たプログラムからインタラクティブなISPF画面またはライトから入力を取得したプログラムペン、Calcomp 1012プロッタまたはTektronix 4107ターミナルで出力すると、バグの数が増えました。
私はそれがいくつかのことだと思います。まず、fix-a-bug-recompileのサイクルは、通常、メインフレームではより高価でした。つまり、プログラマはコードを傾けて「動作するかどうか」を知ることができませんでした。 in-your-headのコンパイルと実行時のシミュレーションを行うことで、コンパイラがそれらをキャッチするよりも多くのバグを見つけることができます。
第2に、皆さんとその兄弟は「プログラマー」ではありませんでした。彼らは通常、高度に訓練された専門家でした。今やプログラムは高校の卒業証書で地下室に座っている人から来ます。それは何も問題ありません！それは技術者が20年間専門的にやってきたバグが多い傾向があります。
第3に、メインフレームプログラムは、ネイバーとのやりとりが少ない傾向があります。たとえば、Windowsでは、悪いアプリが、そのシステムの横またはシステム全体をクラッシュさせる可能性があります。メインフレームでは、通常、セグメント化されたメモリがあるため、すべてがクラッシュする可能性があります。あなたの典型的なデスクトップシステム上で実行される膨大な数のわずかな信頼性のあるソースから、何らかのプログラムが不安定になりがちです。
成熟度は間違いなく要因です。 20年前に書かれ、バグを解消するために何度も洗練されてきたCOBOLクレジットカード処理プログラムは、どのプログラムの0.1バージョンよりも問題を起こす可能性は低いです。もちろん、これらの古い書き換えられた無限回プログラムは、通常、維持することがほぼ不可能なスパゲッティコードに終わるという問題があります。
何かのように、それは主にプログラマーとその方法論に依存します。ユニットテストをしていますか？彼らは文書を作成し、クリーンなコードを書くか？彼らはコンパイラにコードをスロープ・アンド・ドロップするだけで、コンパイラがそれらをすべてキャッチすることを期待してバグがあるかどうかを確認しますか？
（オペレーティング・システムではなく）メインフレーム・アプリケーション・ソフトウェアと私の経験はかなり古くなっているが、私の記憶は、アプリケーションの大半は、論理的に、非常に単純ですバッチ・アプリケーションであるということです。
A）読みます入力ファイル
b）の工程各レコード（あなたが大胆な感じている場合は、データベースを更新）
c）は、ジョブを監視するために、約適格事業者のチームを心配する出力ファイル
ないユーザー入力イベントを書きますそれが動くにつれて、外部システムとのやり取りなどがほとんどありません。
ビジネスロジックは複雑になる可能性があります（特に、COBOL 68で書かれており、データベースはリレーショナルではありません）。しかし、それだけに集中すれば、信頼性の高いソフトウェアを作るのは簡単です。
"バッチ"は大きなシステムでは異なる意味を持ちます。バッチ処理は、一般的なUnixシステムで発生する可能性があるように、中断されたり再スケジューリングされたりすることなく、ジョブに対して最大または特定されたCPU時間を与えるよう調整されています（小さな部分）。 上記の3つのステップは、すべてのシステムで同時に働いたのと同じ方法です。今日のメインフレームは、今日私たちがやっているすべてのことをしています。 – Xailor
私は自分自身でメインフレーム用のソフトウェアを使ったことはありませんでしたが、私の父親は1970年代のCOBOLプログラマーでした。
当時のソフトウェアを書いたとき、バグを見つけ出すのは、ソースコードをコンパイルするのと同じくらい簡単ではなく、コンパイラがあなたやプログラムを実行して間違っていたことを見ているエラーメッセージを調べるだけでした。タイピストはプログラムをパンチカードにパンチしなければならなかった。パンチカードはコンピュータに読み込まれ、プログラムの結果がプリントされる。
私のお父さんはいつか誰かが紙の箱でいっぱいのカートを持ってきて、彼が働いていた部屋のドアの隣に置いてくれたと言ってくれました。彼は「それは何ですか？」と尋ねました。その男は「それはあなたのプログラムの結果です」と言いました。私のお父さんは間違いを犯してしまいました。その結果、このプログラムは、木全体を使い果たした可能性のある紙の束の上に大量のぎこちないものを印刷しました。
あなたはあなたの間違いからすぐにその方法を学ぶ...
タッチされていない古いメインフレームソフトウェアがよく理解されているとは必ずしも言えません。それは完全に忘れてしまったことはありませんし、決して壊れていない古いプログラムの1つが起これば、何が起こるか不思議な冷たい汗でマネージャーが目を覚ますでしょう。 私はWindowsソフトウェアで動作します。何も忘れてしまうほど長い間働くことはない！ – Modan
@Modan、*その虚偽の点で*。その* internls *は全く理解できないかもしれませんが（ソースは消えてしまっているかもしれませんが）、過去20年間にそれが崩壊していない場合、その時点ではすべてのゴミデータが対象になります。明日から始める。それが崩れてしまった場合は、回避策を見つけたか、それを置き換えたはずです。 – paxdiablo