Почему приложения мейнфреймов не имеют ошибок?

I used to work on mainframe apps. The earlier apps didn't have many bugs because they didn't do much. We wrote hundreds if not thousands of lines of FORTRAN to do what you'd do with a couple of formulas in Excel now. But when we went from programs that got their input by putting one value in columns 12-26 of card 1, and another value in columns 1-5 of card 2, etc, to ones that took input from an interactive ISPF screen or a light pen and output on a Calcomp 1012 plotter or a Tektronix 4107 terminal, the bug count went up.

There are no bugs in main frame software, only features.

There asre PLENTY of bugs on mainframe software, they are just not publisized as much due to the relatively small group of developers affected. Just ask someone who does mainframe development how many ABENDS they see on a daily basis!

I learned to use debuggers and analyse core dumps on big iron mainframes. Trust me they only came about because of bugs. You're just plain wrong.

However mainframe architectures have been designed for stability under high stress (well compared to say non mainframe systems) so maybe you can argue they are better in that way. But code wise? Nah bug are still there...

Мой опыт работы с прикладным программным обеспечением для мэйнфреймов (в отличие от операционных систем) довольно устарел, но я помню, что большинство приложений являются пакетными приложениями, которые логически очень просты:

а) Прочитать входной файл
б) Обработайте каждую запись (если хотите, обновите базу данных)
c) Напишите выходной файл

Отсутствие событий ввода пользователем, о которых нужно беспокоиться, команда квалифицированных операторов для мониторинга выполнения задания, небольшое взаимодействие с внешними системами и т. д. и т. д.

Теперь бизнес-логика может быть сложной (особенно, если он написан на COBOL 68 и база данных не реляционная), но если это все, на чем вам нужно сосредоточиться, проще создать надежное программное обеспечение.

Я никогда не работал над программным обеспечением для мэйнфреймов, но мой отец был программистом на COBOL в 1970-х.

Когда вы писали программное обеспечение в те дни, обнаруживать ошибки было не так просто, как компиляция исходного кода и просмотр сообщений об ошибках, которые компилятор выплевывает вам, или запуск вашей программы и проверка того, что она делает не так. Машинистке приходилось вставлять программу в перфокарты, которые затем считывались в компьютер, который распечатывал результаты вашей программы.

Мой отец сказал мне, что однажды кто-то пришел с тележкой, полной коробок с бумагой. и поставил их рядом с дверью комнаты, где он работал. Он спросил: «Что это ?!», и парень сказал ему: «Это результат вашей программы».

While I don't have experience with mainframes, I'm guessing it's the first point you made: the software has been around for decades. Most remaining bugs will have been worked out.

Besides, don't forget fiascos like Y2K. All of the bugs people have stumbled on have been worked out, and in 20 years most situations will probably have occured. But every once in a while, a new situation does manage to come along that makes even 20-year old software stop working.

(Another interesting example of this is the bug found in, I believe, BSD Unix. It was found a year or so ago, and it's been around for 20 years without anyone running into it).

Oh, they definitely have bugs--see thedailywtf.com for some more entertaining examples. That said, most of the "mainframe" applications one sees today have had 30 years to get all the kinks worked out, so they have a bit of an advantage over most applications created in the last few years.

Я думаю, это несколько вещей. Во-первых, цикл исправления ошибки-перекомпиляции обычно был более дорогостоящим в мэйнфреймах. Это означало, что программист не мог просто набросать код и «посмотреть, работает ли он». Выполняя внутреннюю компиляцию и симуляцию во время выполнения, вы можете обнаружить больше ошибок, чем позволить компилятору их уловить.

Во-вторых, никто и их брат не были «программистами». Обычно это были высококвалифицированные специалисты. Теперь программы идут от парней, сидящих в подвале с аттестатом о среднем образовании. Ничего страшного в этом нет !!! но в нем, как правило, больше ошибок, чем у инженера, который профессионально занимается этим в течение 20 лет.

В-третьих, программы для мэйнфреймов, как правило, меньше взаимодействуют со своими соседями. В Windows, например, плохое приложение может привести к сбою следующего за ним или всей системы. На мэйнфреймах обычно есть сегментированная память, поэтому все, что может вызвать сбой, - это она сама. Учитывая множество вещей, выполняемых на вашей типичной настольной системе из всех видов незначительно надежных источников, это имеет тенденцию делать любую программу в некоторой степени нестабильной.

Определенно важным фактором является зрелость. Программа обработки кредитных карт COBOL, которая была написана 20 лет назад и постоянно совершенствовалась для устранения ошибок, с меньшей вероятностью будет иметь проблему, чем версия 0.1 любой программы. Конечно, есть проблема в том, что эти старые переписанные бесконечные программы обычно заканчиваются спагетти-кодом, который почти невозможно поддерживать.

Как и все, это зависит главным образом от программиста (ов) и их методологии. Они проводят модульное тестирование? Они документируют и пишут чистый код? Они просто вставляют код в компилятор, чтобы увидеть, есть ли какие-нибудь ошибки (надеясь, что компилятор сможет их все отловить)?

I think programming was just an advanced field that only chosen engineers could work in it. The world of programming now is much much bigger with lower entry barriers in every aspect.