Вопрос на интервью: Какие типы наборов данных вы знаете? (What dataset types do you know? What kind of dataset organization do you know?)

Итак, на z/OS не принято говорить "файлы", правильно − наборы данных (однако то, что мы видим внутри HFS/zFS наборов из-под z/OS Unix (Юникса), называем файлами). В z/OS не существует привычных папок (folder, directory), как в других OS, все файлы лежат вместе, одной кучей, на томе (он же диск − Volume, DASD). Дисков может быть несколько. Чтобы обратиться к набору данных, надо знать имя набора и том. Имя набора данных z/OS может быть произвольным набором символов длиной до 44 байт и состоять из нескольких "простых" имен, разделенных точками. Каждое из таких "простых" имен, или, переходя к общепринятому термину, квалификаторов (qualifier), имеет длину до 8 символов, начинается с алфавитного символа и состоит из алфавитно-цифровых символов. Использование таких имен наборов данных позволяет придать плоской структуре иерархию.

Пример набора данных: VASYA.DEVGRP.PROJECT1

Некоторые определения:

SMS (Storage Management Subsystem) − подсистема z/OS, которая может управлять данными ей томами. В пределах этих томов подсистема также может заведовать распределением наборов данных. Согласно описанной политике она может менять имя тома, на котором набор должен быть распределен, характеристики набора и т. д. Тома под управлением SMS называются SMS-управляемыми (SMS-managed). Не SMS тома по-прежнему нужны, например, для загрузки системы.

Каталог (Catalog) – это специальный набор данных, который может хранить сведения о других наборах. Например, имя тома, на котором лежит набор с таким именем. Благодаря этому вы можете обращаться к набору по имени, не указывая имя тома. Наборы, проиндексированные в каталоге, называются закаталогизированными.

Существует 2 основные группы: VSAM (читается [висам]) и non-VSAM наборы данных. При этом чаще всего используются последние.

Non-VSAM наборы

Non-VSAM наборы (они же − обычные) отличаются от Юникс наборов в первую очередь тем, что они record-oriented, в то время как на Юникс файлы − byte-oriented. Запись (Record) набора данных − это последовательный набор байт определенной длины (LRECL). С практической стороны иногда невозможно записать меньше, чем длина записи. Система дополнит запись, например, пробелами. Кроме того что наборы могут иметь записи разной длины, существует разделение наборов данных по формату записи (RECFM), по внутренней организации набора данных (DSORG) и по типу набора данных (DSNTYPE). Рассмотрим сначала разделение по формату записи.

1. Разделение по формату записей (RECFM)

Существуют следующие форматы записей: F, V, U и D.

F - Fixed (RECFM=F)
Наборы данных с записями фиксированной длины. Каждая запись имеет строго определенную длину, одинаковую для всех записей в данном наборе. Такие наборы данных в основном используются для хранения текстовых файлов. Например, для хранения JCL обычно используются такие наборы данных с длиной записи 80. Для исходников С − чаще 160. Хотя я рекомендую придерживаться ограничения 80. Так их удобнее смотреть на z/OS. К тому же возможно, вашу программу будут использовать на других системах (например, AS/400) c похожими ограничениями.

V - Variable (RECFM=V)
Наборы данных с записями переменной длины. Такой набор данных бережнее относится к пространству, однако некоторые текстовые редакторы не поддерживают записи, больше определенной длины. Кроме того, в Fixed наборе легко посчитать смещение любой записи от начала файла (умножение длины записи на номер).

U – Undefined (RECFM=U)
Наборы данных с записями неопределенной длины. Не имеет таких жестких требований, как предыдущие, и возлагает больше ответственности на программистов. Обычно используется (и только он может использоваться) для хранения загрузочных модулей (load modules). Текстовыми редакторами не поддерживается.

D - ASCII Variable (RECFM=D)
Очень похож на V-Format, но существует только на лентах и характеризуется поддержкой ISO/ANSI спецсимволов.

1.1 Блокированные наборы (Blocked datasets)

В дополнение к разделению наборов данных по формату записи, они могут быть блокированными. Блок − это объединение нескольких записей. Блок является единицей чтения/записи с диска. То есть если следующая запись находится в том же блоке, она будет читаться из памяти (буфера, блока). Блок − это не только логическое объединение, но иногда и определенный дополнительный набор управляющих байт на диске, невидимый для пользователя (например, у наборов с записями переменной длины появляется BDW - Block Descriptor Word, состоящий из 4-х байт и содержащий длину блока и некоторые флажки). Если набор данных блокированный, в описании появляется буква B. Получаем – FB (RECFM=FB), VB, DB. Формат U блокированным не бывает.

1.2 Наборы данных с переходящими записями переменной длины (spanned dataset)

Существует системное ограничение на длину блока в 32 760 байт. А так как блок − это вполне осязаемые контрольные байты, появилась необходимость сообщать, что запись может разделять несколько блоков. Обладают этой возможностью только наборы формата V и D и характеризуются буквой S. Получаем: VS, VBS, DS, DBS.

1.3 Стандартные наборы (standard datasets)

Существует возможность писать короткие блоки, содержащие не все записи, которые могли бы туда поместиться. Стандартные наборы запрещают создание коротких блоков. Исключение − последний блок файла. Каждая дорожка содержит также одинаковое количество блоков, в результате чего система может очень быстро посчитать физический адрес любой записи. В описании такого набора появляется буква S. Однако относится это только к наборам формата F. Следовательно, имеем всего две комбинации: FS и FBS. Типичная ошибка − путать значение буквы S на конце FBS и VBS.

1.4 Наборы данных с управляющими символами

Все записи всех форматов, кроме VSAM, могут содержать управляющие символы для принтера. Существует 2 группы управляющих символов: машинные коды (mashine code) и ANSI коды. Машинные коды характеризуются наличием буквы М, тогда как ANSI характеризуются наличием буквы A. Примеры: FBM, FBA, FBSM, UM и т. д.

1.5 Наборы данных с запрошенным track overflow
z/OS больше не поддерживает возможность track overflow. Характеризовались такие наборы буквой T, например FBT.

2. Разделение по типу наборов данных (DSNTYPE)

По типу наборы данных делятся на:
- BASIC
- EXTREQ и EXTPREF
- LARGE
- PDS и LIBRARY
- HFS
- PIPE

Рассмотренные ранее наборы данных относятся к типу DSNTYPE=BASIC.

2.1 Последовательные наборы данных с расширенным форматом (Extended-format sequential datasets)

DSNTYPE=EXTREQ или DSNTYPE=EXTPREF. Попытка обойти ограничение в 65 535 треков на одном томе для последовательного файла. Кроме того, записи не обязательно сохраняются в том же формате и порядке, как они видны пользователю. В остальном данные наборы могут содержать все расмотренные выше форматы записей. Создаются данные наборы только на дисках под управлением SMS. С точки зрения работы пользователя − неотличимы от простых наборов (не поддерживаются методы доступа EXCP и BDAM).

2.2 Наборы данных для больших массивов (LARGE dataset)

DSNTYPE=LARGE. Альтернативная попытка обойти ограничение в 65 535 треков. В отличие от расширенных форматов, данный тип не требует дисков под SMS управлением. Для работы возможны методы доступа QSAM, EXCP, BSAM.

2.3 Библиотечные наборы данных (Partitioned dataset)

DSNTYPE=PDS и DSNTYPE=LIBRARY. На z/OS не существует привычных папок (folder), как в других OS, однако потребность группировать объекты существует. Библиотечный набор можно представить как папку первого уровня. Этот набор может содержать в себе как бы другие последовательные файлы, которые называются разделами (members). Библиотечный набор не может содержать в себе другой библиотечный набор. Разделы, в свою очередь, не могут иметь имя длиннее 8-ми символов. Библиотечные наборы делятся на: PDS (oн же PO) и PDSE (он же PO-E, он же LIBRARY). С точки зрения пользователя, PDS почти ничем не отличается от PDSE, однако последний имеет более продвинутую внутреннюю структуру. Основные преимущества PDSE:
- не надо периодически сжимать (IEBCOPY compress);
- несколько пользователей могут править разные разделы одновременно;
- повышенная производительность доступа к разделам.

2.4 Иерархические наборы данных (HFS dataset - Hierarchical File System)

DSNTYPE=HFS. В z/OS есть свой встроенный Юникс − z/OS Unix (он же USS - Unix System Services, он же OE - Open Edition). Так вот, HFS наборы данных − это контейнеры для хранения Юникс файлов и всей иерархии директориев. Структуру данных этих наборов знает только Юникс, и работать с файлами внутри набора можно только с помощью средств Юникс. HFS набор нельзя открыть в простом редакторе.

2.5 Особые файлы типа FIFO (first-in first-out, PIPE, named PIPE)

DSNTYPE=PIPE. Файл, являющийся связующим звеном между программами. Запись, помещенная первой в такой файл, будет считана тоже первой. Одновременно несколько программ могут писать в PIPE и несколько программ могут читать PIPE. PIPE не является набором данных, это файл внутри Юникс файловых систем (HFS или zFS). То есть DSNTYPE=PIPE следует использовать только при необходимости обратиться к нему из z/OS (например, из JCL).

3. Разделение по внутренней организации данных (DSORG)

По внутренней организации данных наборы делятся на:
- PS (Physical sequential data set) – известные нам последовательные наборы;
- PO (Partitioned data set) – известные нам библиотечные наборы;
- IS (Indexed sequential data set) – индексно-последовательные наборы данных;
- DA (Direct access data set) – наборы данных прямого доступа.

3.1 Индексно-последовательные наборы данных (IS - Indexed Sequential data sets)

Тип набора данных, поддержка которого прекращена с z/OS V1R7 (даже функция OPEN). Функционально ISAM подобен KSDS, но без альтернативных ключей (ключ может быть только один) и с необходимостью периодической реорганизации. Использует аппаратные команды для поиска по ключу, расходует меньше дискового пространства, чем KSDS. Идейным наследником является VSAM. В системах, предшествующих z/OS V1R7, можно осуществить конвертацию из ISAM в VSAM.

3.2 Набор данных прямого доступа (DA - Direct access data sets)

Набор данных с прямой организацией и соответствующий ему метод доступа BDAM позволяет заполнять записями пространство, отведенное набору данных, практически как угодно. Позволяет вычислять местоположение записи каким угодно алгоритмом в зависимости от ее содержимого (или от фазы луны) и писать запись в заданное место: например, логически разделить пространство на 256 кусков и писать записи в зависимости значения в первом байте в подходящий кусок. Позволяет разместить в начале набора (к примеру, на первых 10 дорожках) какой-нибудь свой индекс с указателями на записи и т. д. Понятно, что это требует больших усилий от программиста, почему DA используется сравнительно редко. В DA нет никаких накладных расходов: что создали, то и имеем − и могут быть задействованы аппаратные ключи.

3.3 Неперемещаемые наборы данных

Наборы могут содержать информацию, жестко завязанную на физическом расположении набора данных на диске. Если такой набор скопировать или переместить, он становится не пригодным для работы. Отмечаются такие наборы символом U.
Пример: PSU (DSORG=PSU), DAU, ISU, POU.

4. Группа поколений данных (GDG - Generation Data Group)

Уже известные нам типы наборов можно объединять в группы поколений данных. Создается специальная запись в каталоге (GDG base) − общее имя всех наборов в данной группе. Система у всех новых наборов будет достраивать в имени порядковый номер (Generation number) и номер версии (Version number).
Пример набора из GDG: VASYA.DEVGRP.PROJECT1.G0001V00
При этом в каталоге есть запись VASYA.DEVGRP.PROJECT1, которая видится как набор, но на самом деле, просто запись в каталоге (GDG base) .

В результате чего в JCL при обращении к набору из группы, мы можем указывать как абсолютное имя, так и относительное:
GDGBASE(0) − последний созданный набор.
GDGBASE(-1) − предыдущий созданный набор (номер генерации в имени может быть и выше).

GDGBASE(+1) − новый набор. Система сама назначит ему имя, согласно правилам выше.
То есть вы можете 5 раз запустить один и тот же JCL и получить 5 разных наборов в результате каждого запуска (в обычной жизни приходиться править JCL, чтобы задать новое имя набора данных).
Кроме этого, можно задать, сколько поколений следует хранить. Например, если вы задали 5, то при создании 6-го набора, 1-й автоматически удаляется (поведение при опции по умолчанию − NOEMPTY).

VSAM наборы

Существует 5 видов VSAM наборов: RRDS, ESDS, KSDS, VRRDS, LINEAR.

ESDS подобен последовательному файлу:
- записи могут быть разной длины;
- записи можно добавлять только в конец;
- удалить запись нельзя, но можно пометить ее как неактивную;
- запись можно поменять, но при этом нельзя изменить ее длину;
- для любой записи можно получить ее относительный адрес (RBA - Relative Byte Address);
- не имеет первичного индекса, но можно построить альтернативный индекс .

RRDS подобен столбику кирпичиков (слотов):
- получить запись можно по её порядковому номеру 1,2,3...(RRN - Relative Record Number). Номера идут по возрастанию и допускаются пропуски. (1,2,5,6,9...) Номер записи − это атрибут записи, и он не может быть изменен;
- записи можно удалять, добавлять, редактировать;
- все записи одинаковой длины;
- набор не может иметь индексов.

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

VRRDS фактически представляет собой реализацию RRDS на базе KSDS:
- получить запись можно по её порядковому номеру;
- существует неявно задаваемый первичный индекс (содержит порядковые номера записей);
- записи могут быть разной длины.

Linear − стоящий особняком набор данных, который отличается от других по принципу работы с ним. В отличие от остальных наборов данных, Linear VSAM не имеет записей, а состоит как бы из 4-х окошек. Вы можете задать соответствие выбранного участка памяти (4К*n) и участка набора данных. Участок может быть задан по смещению от начала набора (4К*m). В результате создания этой связи (функция MAP) данные копируются в этот участок памяти, и дальнейшая работа осуществляется как с обычной памятью. По завершении работы необходимо сохранить данные обратно в набор (функция SAVE).

z/OS файловая система (z/FS - z/OS File System)

z/FS является более продуманной заменой HFS, хотя и не может пока полностью заменить ее. С точки зрения Юникс-пользователя, z/FS неотличима от HFS. Несмотря на наличие собственного имени, z/FS реализуется на базе линейного VSAM.