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

Question

Похоже, что old iron - это надежное программное обеспечение.Почему это так?Это потому, что программное обеспечение настолько зрелое, что все ошибки были исправлены?Или это потому, что люди настолько привыкли к ошибкам, что даже не распознают их и не работают над их устранением?Были ли спецификации программного обеспечения идеальными с самого первого дня, и как только программное обеспечение было написано, все просто заработало?Я пытаюсь понять, как мы прошли путь от дней мэйнфреймовых вычислений, которые все сейчас считают просто работой, до ощущения, что TDD - это правильный путь.

Answer 1

Как вы думаете, почему у них нет ошибок?

У IBM есть огромный инфраструктура поддержки для сообщения об ошибках и их устранения (PMR, APAR и PTF), которая активно используется.

Программное обеспечение для мэйнфреймов, к которому не прикасались в течение многих лет, безусловно, будет хорошо изучено (по крайней мере, с точки зрения его особенностей) и, скорее всего, в нем будет исправлено или устранено множество ошибок.Все новые разработки, разрабатываемые в настоящее время, на самом деле планируют определенное количество ошибок и исправлений от GA (общей доступности) до как минимум GA + 36 месяцев.На самом деле, мой бывший начальник в IBM не хотел, чтобы его заставляли сообщать цифры о запланированных ошибках в строке:"Не были планирование иметь какие-либо ошибки».

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

Это потому, что IBM слишком хорошо знает, что стоимость исправления ошибок значительно возрастает по мере продвижения по циклу разработки — гораздо дешевле исправить ошибку при модульном тестировании, чем исправить ее в производстве, с точки зрения обоих денег. и репутация.

На выпуск только программного обеспечения без ошибок затрачивается много усилий и средств, но даже они не всегда делают это правильно.

Answer 2

В программном обеспечении основного фрейма нет ошибок, только функции.

Answer 3

Раньше я работал над приложениями для мэйнфреймов.В более ранних приложениях не было много ошибок, потому что они мало что делали.Мы написали сотни, если не тысячи строк FORTRAN, чтобы сделать то, что вы сейчас сделали бы с парой формул в Excel.Но когда мы перешли от программ, которые получали входные данные путем помещения одного значения в столбцы 12–26 карты 1, а другого значения в столбцы 1–5 карты 2 и т. д., к программам, которые получали входные данные с интерактивного экрана ISPF или источника света. пера и вывода на плоттер Calcomp 1012 или терминал Tektronix 4107, количество ошибок увеличилось.

Answer 4

В программном обеспечении для мэйнфреймов МНОЖЕСТВО ошибок, но они не так широко публикуются из-за относительно небольшой группы разработчиков, затронутых ими.Просто спросите кого-нибудь, кто занимается разработкой мэйнфреймов, сколько аварийных ситуаций он видит ежедневно!

Answer 5

Я научился использовать отладчики и анализировать дампы ядра на больших железных мейнфреймах.Поверьте мне, они появились только из-за ошибок.Вы просто ошибаетесь.

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

Answer 6

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

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

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

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

Answer 7

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

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

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

Так ты быстро учишься на своих ошибках...

Answer 8

О, у них определенно есть ошибки — посетите сайт thedailywtf.com, чтобы увидеть еще несколько занимательных примеров.Тем не менее, большинству приложений для мэйнфреймов, которые мы видим сегодня, потребовалось 30 лет, чтобы проработать все недостатки, поэтому они имеют некоторое преимущество перед большинством приложений, созданных за последние несколько лет.

Answer 9

Хотя у меня нет опыта работы с мэйнфреймами, я предполагаю, что это первое, что вы отметили:программное обеспечение существует уже несколько десятилетий.Большинство оставшихся ошибок будут устранены.

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

(Еще один интересный пример — ошибка, обнаруженная, по-моему, в BSD Unix.Его нашли около года назад, и он существует уже 20 лет, и никто с ним не столкнулся).

Answer 10

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

Answer 11

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

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

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

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

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