Записки парасистемного программиста - [13]

//АLРНА DD DSNАМЕ=ВLIN,SРАСЕ=(ТRК,20),UNIТ=SYSDА, //
DISР=(NЕW,САТLG),VОL=SЕR=КОМ

Вы его узнали, а программа системного ввода, почему-то, не может. Это, видите ли, ниже ее достоинства. Она, видите ли, предупреждала, что ошибаться — плохо. Теперь же она наступит хладнокровно на раненого и пойдет себе дальше, не оглядываясь, сказав хорошо знакомую не знающей английского Светочке фразу "JOB NOT RUN! JСL ERROR!" Постой, программа системного ввода, не спеши. Вот тебе кувшин с живой водой, окропи раненого. Прежде всего, живая вода проверит, какие слова отличаются от наших на один символ. И вот уже исправлены DCNAME на DSNAME, а SPASE на SPACE. От мелких ран не осталось и рубцов, можно приниматься и за ранения средней тяжести. Сделаем это так: разделим число символов в "неправильном" слове пополам с недостатком. Полученное число даст нам длину сравниваемой левой (правой) части нашего слова с левой (правой) частью возможных ключевых слов. И вот уже исправлены DDD на DD, CATGL на CATLG, DIPS на DISP.

Hе смейтесь, настоящие системные программисты. Я знаю, сейчас вы скажете, что с таким же успехом DDD можно исправить на DCB, что UCATLG можно исправить на UNCATLG и на CATLG, что этим не поможешь "именам собственным" (ALPHA, BLIN, SYSDA), что SPACE-(TRK, 20) так вообще не исправить на Sрасе=(TRK, 20) и что такие удобства увеличивают вероятность скрытой ошибки. Все это верно, но все-таки, не пора ли нам делать не только языки, замечающие ошибки, но и языки их исправляющие? Если мы должны быть суровы и беспощадны к самим себе, к профессионалам, то не пора ли нам пожалеть практикантку Светочку? Ей, несчастной, и нужно то всего лишь рассчитать один разок поле в ванне с электролитом. Hу какое ей дело до наших с вами "JOB NOT RUN"!

4.9. Пуганые вороны и стреляные воробьи.

Этюд.

Один системный программист внедрил систему пакетной отладки программ (нечто вроде первого уровня "пирамиды"), которая позволяла пользователю отказаться от перфокарт. То есть, сначала, конечно, исходные тексты вводились с перфокарт, а затем, хранились в библиотеке. Очень удобная система, но пользоваться ей начинали неохотно. Все-таки, приятно, когда твоя родная программа лежит у тебя в тумбочке. Кто их знает, эти магнитные диски. Дунь на них, и информации — как не бывало. А перфокарты — вот они. И обугленные можно вводить. Максимум, чего удалось добиться системному программисту — это "синхронной" работы пользователей с библиотекой и со "своей" колодой карт, в которой они добросовестно и почти всегда правильно отслеживали изменения в библиотеке. Только несколько самых прогрессивных программистов-пользователей успели очистить свои тумбочки, когда случилось несчастье. Системный пограммист по ошибке уничтожил символьную библиотеку. После этого стрелянный системный программист создал живучую "программно-административную" систему редких и частых копирований с такими правилами техники безопасности, каким могли бы позавидовать и "котлонадзор" и пожарники.

Hо было уже поздно. С тех пор прошло уже много времени, но тумбочки программистов все еще скрипят под тяжестью перфокарт. Любое техническое изделие обеспечивается регламентирующими его эксплуатацию правилами. Hе распространяется этот обычай только на пограммное обеспечение. Существует богатый устный фольклор, составленный парасистемными программистами, о том, когда и какие дампы делать, есть даже литература по этому поводу, но мне не приходилось встречать соответствующие рекомендации в документации по программному обеспечению, в том числе, и по ОС ЕС. И еще один вывод из этой истории. Если СОД, которую вы сделали или внедрили, загубит чью-то работу, то вас ждет тяжелая участь. И поделом, самолеты должны взлетать с первого раза, а взлетев — садиться. Еще этюд. Ппп "вист" вводит данные с терминалов. Представим себе, что пять — десять операторов подготовки данных после трех часов плодотворной работы узнают, что машина "сломалась" и им нужно начинать все сначала. Судя по всему, такая ситуация не исключена, так как разработчики этого ППП заявили, что они еще не думали над тем, что произойдет, если во время модификации запортится управляющая информация в базе данных. Это значит, что нужно возвращаться к дампу. Допустим, такая ситуация будет возникать раз в пять лет, все равно я не хотел бы быть тем, кто сообщит бедным девушкам с подготовки данных столь страшную весть, даже если они знают, что "вист" делал не я. Разработчики ППП "Вист", видите ли, не подумали об этом. Hо ведь с этого нужно было начинать делать пакет программ.

4.10. Эшелонированная оборона.

Энтропия — грозный противник любой СОД. Вооруженная случаем, она наносит свои удары в самых непредвиденных местах, стремясь прорвать нашу оборону, сорвать планы нашего наступления, и если удастся, то уничтожить нашу СОД. Она не так слепа, как кажется, на ее стороне законы больших чисел, естественного, если хотите, отбора самых удачных каверз. Законы больших чисел приводят к законам "бутерброда", "где тонко, там и рвется" и т. п. Первую линию обороны — автоматическую реакцию программного обеспечения на сбои людей и техники мы уже рассмотрели. Когда эта линия обороны прорвана, в бой вступают люди. Рассмотрели мы и еще одну линию обороны, ее силы и средства — системы страхового копирования и восстановления программ и данных. Чаще всего — это вторая линия обороны, но я считаю, что эта линия должна быть третьей. А что же во второй линии? Там должны стоять проверенные в боях, прошедшие сквозь огонь и воду, пусть даже и поредевшие от потерь войска. Эти так просто не отступят.