Записки парасистемного программиста

Hо вернемся к ППП оргвыц. Для всех, кто хочет автоматизировать львинную долю неблагодарной ручной, рутинной работы по организации вычислительного процесса в вц коллективного пользования, этот пакет представляет лакомый кусок. Давайте вкусим его и попробуем немного пожевать, но только осторожно. А то, не успеем мы еще войти во вкус, как послышится хруст сломанного зуба, и будет больно. Это в лакомом куске оказался кусочек гравия. Давайте, вместе рассмотрим его как следует под микроскопом. ОС ЕС позволяет указывать местонахождение наборов данных двумя способами. Первый способ — через каталог системы, таблицу, где для каждого (каталогизированного) набора данных указаны имя тома, на котором этот набор данных находится, и тип устройства. Второй способ — тип устройства и имя тома указываются в задании каждый раз, когда в нем встречается имя этого набора данных. С точки зрения удобства управления СОД (в данном случае — ППП оргвыц) лучше всю информацию о том, где какой набор данных находится, сконцентрировать в каталоге, тем самым, уменьшив и избыточность этой информации. В самом деле, оргвыц работает с десятком наборов данных, но в разных точках своих процедур на языке управления заданиями (ЯУЗ) ОС ЕС он ссылается на них около пятидесяти раз. Думаете, это делается через каталог? Как бы в насмешку над пользователем, в отдельных случаях это сделано через каталог, но тут же, рядом еще одна ссылка на тот же набор данных, но уже с указанием тома. Нам пришлось основательно порыться в этом лакомом куске, чтобы выковырять из него все кусочки гравия, то есть избыточную информацию. — Чем же плоха избыточная информация? Какая разница, как ОС "доберется" до набора данных? Главное — результат. Вот, если бы не было информации, и задание закончилось бы аварийно… — Мог бы возразить создатель этого пакета. Да, все верно. Все процедуры ЯУЗ будут работать, и контрольный пример, несомненно, пройдет. Hо что делать бедным, несчастным парасистемным программистам, которым нужно будет перенести какие-то наборы данных с одного тома на другой. В каталоге они, естественно это отметят, а потом — либо просматривай все тексты процедур ЯУЗ на предмет выковыривания гравия, либо ломай зубы. Избыточная информация нужна для обнаружения и исправления ошибок, а не для расширения штатного расписания подразделения парасистемных программистов.

Этюд.

В некотором ВЦ разработали программное обеспечение некоторой СОД в среде ОС ЕС. Все модули этой сод написаны на языке PL/1, оттранслированы и отредактированы с полным разрешением внешних связей. В таком виде загрузочные модули (ЗМ) записаны в библиотеку. Это означает, что, если программы A, B, C и D содержат предложение CALL W в исходном тексте, то в библиотеке зм они будут храниться в следующем виде: AW, BW, CW, DW. Теперь представим себе, что в нашей СОД головных программ — 21 штука, а программ, которые вызываются этими головными — 214. По листингам легко определить, какие программы вызывают программу х, но никак не наоборот: какими программами вызывается программа х.

Кроме того, к каждой головной программе редактор связей щедро присоединил программы периода выполнения из библиотеки транслятора PL/1, размножив их, таким образом, в количистве 21 экземпляр. Hо бог с ним, с объемом внешней памяти под библиотеку зм. Пусть разработчики восторгаются количеством команд в своем детище. Радоваться им не долго, так как эту СОД они сделали, что называется, "для себя". В один прекрасный день они нашли ошибку в программе Z, которая используется… Очень трудно сказать точно, где она используется. Примерно в 17 из 21 головных модулей. Ошибочка не очень страшная, почти все работает. Hо, если запятая следует за пробелом, а длина записи больше 72 байт…

В общем, нужно исправлять. Для этого нужно исправить исходный текст программы Z, оттранслировать ее, а затем отредактировать заново все 21 головных модулей, так как трудно сказать, какие из них не пользуются услугами программы Z. Вот тут-то и начинается самое интересное. Исправление пришлось делать, что называется, "на живом теле", в рабочем экземпляре библиотеки зм, чтобы как можно быстрее исправить эту ошибку, хотя бы в тех головных модулях, которые должны использоваться в ближайшее время. Исправление затянулось на две недели. При этом, пользователи несколько раз получали неверные результаты, так как никто не знал, какие модули требуют исходных данных еще в "старом" виде, а какие — в "новом". При редактировании одного модуля произошла ошибка, которую не заметили, и модуль был неработоспособен двое суток. Два других модуля просто забыли отредактировать, и ошибку нашли только через месяц.