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

4.4. ЕLEPHANT в посудной лавке.

До чего умна программа сортировки ОС ЕС! Хочешь — рабочие наборы данных размещай на магнитных лентах (МЛ), хочешь — на магнитных дисках (МД). Хочешь — делай их три, а хочешь — все шесть. Хочешь — дай ей 20K основной памяти, а хочешь — все 400. Короче говоря, у вас масса возможностей. Допустим, вам надо рассортировать набор данных из трех логических записей. Что ж, садитесь и пишите задание. Это не займет у вас и получаса. Только не торопитесь, проверьте как следует. Ведь вы помните, что все рабочие наборы данных — три или больше — должны быть размещены на устройствах одного типа. Или на мл, или на мд. И если это устройство — мд, то не забудьте, что этим наборам данных должны быть выделены непрерывные участки памяти прямого доступа. Иначе вам ваши три записи никогда не рассортировать. Hу вот, наконец, вы отладили свое задание, и оно начало выполняться. Теперь дело за ней, за сортировкой. Она-то уж свое дело знает. Прежде всего, она подумает, какой ей выбрать алгоритм, исходя из конкретных условий применения. У нее есть в запасе (о, мудрые создатели!) Несколько алгоритмов. Если от машинного времени, сэкономленного за счет правильного выбора алгоритма, отнять время, которое ушло на выбор этого алгоритма, то возможно получится положительная величина. Возможно даже, что эта разница в мировом масштабе применения настолько велика, что не выходя за поле положительных чисел, нам удасться отнять от нее машинное время, затраченное на разработку всего многообразия этих алгоритмов, исключая из этого числа любой, первый попавшийся. Hо оставим эту заботу коммерческим директорам. Нас больше волнует другое. Что нам делать, если: — Заранее неизвестно, сколько записей придется рассортировать. То ли 3, то ли 300 000. Эти величины вычисляются в том же задании. — В нашей тесной посудной лавке нет ни трех лишних надежных лентопротяжек, ни трех лишних непрерывных участков дисковой памяти из расчета на максимальный объем сортируемых данных. А ведь у нас мультипрограммный режим, и вероятно, что одновременно "захотят" выполняться две или больше сортировок, хотя и маловероятно, что во всех случаях сортироваться будет много данных. Увы, наш могучий слон будет бить посуду. Все его умные алгоритмы не расчитаны на тесноту. Оптимизируется только время сортировки, без учета ограничений на другие ресурсы. Если ресурсов мало, сортировка не будет выполнена, хотя бы и медленнее. Итак, перед СОД, использующей эту программу сортировки четыре альтернативы. 1. Разбить вычислительный процесс на следующие автоматические стадии: определение требуемых ресурсов для сортировки; генерация задания на сортировку; выполнение этого задания (и т. д. для каждого случая сортировки). 2. Отказаться от средств, критичных к объему дисковой памяти, в том числе и от этой программы сортировки. То есть, написать свою программу, которая "сама" возьмет столько ресурсов, сколько будет возможно, а затем будет сортировать данные столько времени, сколько нужно (быть может, даже целый час!). 3. Иметь всегда достаточное, а точнее, избыточное количество дисковой памяти и распределить память заранее для всех одновременно возможных сортировок, что называется, "от души". 4. Включить в состав СОД человека, который бы умел оценивать сверху предполагаемые размеры сортируемых данных и модифицировал соответствующие задания. Иногда, правда, после нескольких часов потерянного времени, ему бы пришлось чесать в затылке и говорить: — эх, промахнулся! Мне приходилось встречать системы, которые выбрали четвертую альтернативу, реже — третью. Hо никогда — избравшие первые две. А жаль. Большинство ошибок людей в хорошо организованных системах связано с распределением ресурсов.

4.5. Зерна и плевелы.

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