

               К А Т А Л О Г     Д И С К Е Т О К

     (Заметки к программному средству ведения каталога)

                            Л. З. Альперович
                           (Москва, тел. 386-59-36 д.)


     Когда количество дискеток превысило 100,  я стал за-
    мечать,  что поиск программ на них превратился в сво-
    еобразную карточную игру.  Мне это надоело, и я напи-
    сал   программу   на  языке  FOXBASE  для  облегчения
    всяческих манипуляций с информацией  о МАТобеспечении
    своего ВЦ.
     Средство не было задумано, как товарный продукт, по-
    этому:
     1. Я извиняюсь за отсутствие комментарий  в  тексте.
    Правда, язык FOXBASE настолько прозрачен, что всякий,
    кто хоть на чем-то программировал, разберется и так.
     2. Программу нужно рассматривать,  как "рыбу", кото-
    рую можно воспроизводить и потреблять на свой вкус. Я
    не претендую на авторство.

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

     Вся информация  каталога сосредоточена в одном файле
    MAT.DBF,  одна запись относится к некоторой абстракт-
    ной  единице,  которую я назвал (вероятно,  неудачно)
    "Программный продукт".
     Этой единицей может быть:
     - произвольный файл (программа, текст, архив и т.д.)
     - отдельная дирректория
     - россыпь файлов
       и др.
     Все зависит от семантической целостности образа еди-
    ницы, хранимого в голове пользователя. Для меня, нап-
    ример,  модуль  RE.COM  и пакет QC2 пребывают в одной
    сфере забот.
     Каждая единица характеризуется,  прежде всего, своим
    8-ми символьным именем и 3-х символьным расширением.

     При всей неопределенности понятия логической единицы
    базы каталога, должно  соблюдаться следующее требова-
    ние: каждая дискетка отражается по меньшей мере одной
    записью.
     Это значит,  что  если   некоторый   пакет,   скажем
    PARADOX, занимает  10  дискеток,  то  в базе каталога
    должно бать не менее 10 записей,  различимых хотя  бы
    номером дискеток (и, вероятно, имеющих код PARADOX).

     Состав полей записи (в скобках длина):
     - код имени программного продукта (8)
     - расширение имени (3)
     - полное имя (48)
     - редакция (6)
     - классификация (8)
     - номер (первой) дискетки (3)
     - количество дискеток, занятых продуктом (2)
     - номер коробки (3)
     - резервное поле (3)
     - размер продукта в байтах (8)
     - дата(8)
     - источник приобретения (12)
     - резервное поле (10)
     - резервное поле (1)

     Наличие большого числа резервных полей говорит о не-
    совершенстве первоначального замысла и о  его  эволю-
    ции. Естественно,  все  это требует переделки,  что и
    предполагается. Присутствовало  и  поле   типа   memo
    (предпоследнее), но я впоследствии от него отказался.
    Потерялась ценность полей редакции и классификации.

     Для программы  каталога принципиально необходимы по-
    ля:
     - код имени
     - расширение имени
     - полное имя
     - номер первой дискеты
     - количество дискеток
     - номер коробки
     Остальные поля могут участвовать лишь  в сортировках
    при выдаче отчета.

     Все программное обеспечение состоит из 4-х процедур:
     MAT.PRG     - головная
     MATIDR1.PRG - экранная "заставка"
     MATA.PRG    - просмотр и корректировка каталога
     MATI.PRG    - выдача отчета

     В состав  этих  средств входит и два форматных файла
    для выполнения операции REPORT:
     REP2.FRM    - краткий отчет
     REP3.FRM    - полный отчет
     Разумеется, их можно быстро изменить операцией MODIFY
    REPORT в FOXBASE.

     Если что-то  нужно еще к этому добавить, пожалуйста,
    но я не знаю, что.

