Здесь я опишу все виды наборов данных. Не за один заход, но все будет. Будем бороться с Зосовской безграмотностью. (разрешаю админу править русский. В нем я как-то похуже)
Вопрос на интервью: Какие типы наборов данных вы знаете? (What dataset types do you know? What kind of dataset organization you know?)
Итак. На z/OS не принято говорить слово "файлы", правильно - Наборы Данных. (однако, то что мы видим внутри HFS/zFS наборов из под z/OS Unix(Юникса) называем файлами). В z/OS не существует привычных папок (folder, directory) как в других ОС, все файлы лежат вместе одной кучей на томе (он же диск - 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 наборы данных. При этом чаще всего используются последние.
1. Non-VSAM наборы
Non-VSAM наборы (они же - обычные) отличаются от Юникс наборов в первую очередь тем, что они record-oriented, в то время как на Юникс файлы byte-oriented. Запись (Record) набора данных - это последовательный набор байт определенной длины. С практической стороны вопроса иногда будет невозможно записать меньше, чем длина записи. Система дополнит запись, например пробелами. Поэтому первое разделение наборов идет по типу записи. (а точнее ее длины) Итак, существуют следующие форматы наборов: F, V, U и D.
F - Fixed Наборы данных с записями фиксированной длины. Каждая запись имеет строго определенную длину, одинаковую для всех записей в данном наборе. Такие наборы данных в основном используются для хранения текстовых файлов. Например для хранения JCL обычно используются наборы с длиной записи 80. Для исходников С чаще 160. Хотя я рекомендую придерживаться ограничения 80. Так их удобнее смотреть на z/OS. К тому же возможно вашу программу будут использовать на других системах(например AS/400) c похожими ограничениями.
V - Variable Наборы данных с записями переменной длины. Такой набор данных бережнее относится к пространству, однако некоторые текстовые редакторы не поддерживают записи длинее определенной длины. Кроме того в Fixed наборе легко посчитать смещение любой записи от начала файла. (умножение длины записи на номер)
U - Undefined Наборы данных с записями неопределенной длины. Не имеет таких жестких требований как предыдущие и возлагает больше ответственности на программистов. Обычно используется (и только он может использоваться) для хранения загрузочных модулей (load modules). Текстовыми редакторами не поддерживается.
D - ASCII Variable Очень похож на V-Format, но существует только на лентах и характеризуется поддержкой ISO/ANSI спец символов.
(продолжение следует...)
Худая корова еще не газель!
Сообщение отредактировал XOpen - Пт, 17.10.2008, 17:57
ну это в общем случае стоит такое ограничение - чтобы нельзя было исказить начальное сообщение ветки форума, чтобы было понятно, с чего все началось. Для вас, если не хватит, я эту цифру изменю, так что пишите в удобном ритме.
В дополнению к формату, наборы данных могут быть блокированными. Блок - это объединение нескольких записей. Блок является единицей чтения/записи с диска. Тоесть, если следующая запись находится в том же блоке, то она будет читаться из памяти (буфера, блока). Если набор данных блокированный, в описании появляется буква B. Получаем - FB, VB, DB. Формат U блокированным не бывает.
1.2 Стандартные наборы (standard datasets)
Блок, это не только логическое объединение, но иногда и определенный набор управляющих байт на диске невидимый для пользователя. (например у VB наборов появляет BDW - Block Descriptor Word, состоящий из 4х байтов и содержащий длину блока и некоторые флажки, в том числе и о том, что продолжение записи в следующем блоке) Существует возможность писать короткие блоки - содержащие не все записи, которые могли бы туда поместиться. Стандартные наборы запрещают создание коротких блоков. Исключение - последний блок файла. Также, каждая дорожка содержит одинаковое колличество блоков, в результате чего система очень быстро может посчитать физический адрес любой записи. В описании такого набора появляется буква S. Однако, относится это только к наборам формата F. Следовательно имеем всего две комбинации: FS и FBS.
1.3 Наборы данных с расширенными записями переменной длины (spanned dataset)
Существует системное ограничение на длину блока в 32 760 байт. А так как блок это вполне осязаемые контрольные байты, появилась необходимость сообщать, что запись может разделять несколько блоков. Обладают этой возможностью только наборы формата V и D и характеризуются буквой S. Получаем: VS, VBS, DS, DBS. Типичная ошибка путать значение буквы S на конце FBS и VBS.
1.4 Иерархический набор данных (HFS dataset - Hierarchical File System)
В z/OS есть свой встроенный Юникс - z/OS Unix (он же USS - Unix System Services, он же OE - Open Edition). Так вот, HFS наборы данных - это контейнеры для хранения юникс файлов и всей иерархии директориев. Структуру данных наборов знает только Юникс, и работать с файлами внутри набора можно только с помощью средств Юникса. HFS набор нельзя открыть в простом редакторе.
1.5 z/OS файловая система (z/FS - z/OS File System)
z/FS является более продуманной заменой HFS, хотя и не может ее пока полностью заменить. С точки зрения Юникс пользователя не отличима от HFS. В z/OS реализуется на базе линейного VSAM.
Попытка обойти ограничение в 65 535 треков на одном томе для последовательного файла. Кроме того, записи необязательно сохраняются в том же формате и порядке, как они видны пользователю. Создается такой файл с указанием DSNTYPE=EXTENDED и может находиться только на дисках под управлением SMS. В остальном имеет теже характеристики, что и простые последовательные файлы. С точки зрения работы пользователя - неотличим. (не поддерживает EXCP и BDAM)
1.7 Набор данных типа "Большой" (LARGE dataset)
DSNTYPE=LARGE. Альтернативная попытка обойти ограничение в 65 535 треков. В отличии от расширенных форматов данный тип не требует дисков с SMS управлением. Для работы доступны методы доступа QSAM, EXCP, BSAM.
Худая корова еще не газель!
Сообщение отредактировал XOpen - Пт, 17.10.2008, 15:05
А, это - превышение лимита - да. Есть такое. Щас большинство движков ограничивают размер сообщения. Причина - ускорение доступа к базе данных, где лежит контент. Так что и статьи приходится раскладывать по кусочкам, и сообщения форума. А вы пишите в эту тему - я потом из сообщений статью соберу и положу в соответствующий раздел.
Прежде всего я хочу выразить свою благодарность автору. Я полагаю, что данная статья будет очень полезна. Поэтому прошу рассматривать мои замечания не как, боже упаси, критику, а как попытку сделать хорошую вещь еще лучше :-)
0. Предлагается начать со следующего:
В системах Windows и Unix данные организованы в виде файлов и каталогов (папок, folder). При этом каталоги образуют иерархическую структуру а файлы никакой структуры не имеют, они представляют собой поток байтов ("ведро байтов"). Образно можно представить организацию данных Windows как "лес" из "деревьев", на которых "растут" простые однообразные "листья". Организация данных Unix в целом аналогична, но все "деревья" соединены в одно большое "дерево", (файловые системы монтируются в единую файловую систему), "ветви" этого дерева могут соединяться "лианами" (символические линки), а кроме простых листьев (обычных файлов) могут быть листья особенные (специальные файлы устройств, fifo-файлы). В отличие от этой модели данных, классическая модель данных z/OS это плоская структура, но зато ее "файлы" всегда имеют структуру, и эта структура может быть весьма сложной (VSAM). Использование термина "набор данных" вместо "файл" как раз и подчеркивает это существенное отличие. Имя набора данных z/OS вообще говоря может быть произвольным набором символов длиной до 44 байт, но практически всегда используются не произвольные, а "регулярные" имена. "Регулярное" имя набора данных состоит из нескольких "простых" имен, разделенных точками. Каждое из таких "простых" имен, или, переходя к общепринятому термину, квалификаторов, имеет длину до 8 символов, начинается с алфавитного символа и состоит из алфавитно-цифровых символов. Использование таких имен наборов данных позволяет придать плоской структуре иерархию. (примечание: набор данных может иметь нерегулярное имя, в том числе и содержащее произвольные шестнадцатеричные коды, но такие наборы данных не могут быть зарегистрированы в каталоге, кроме того, в большинстве систем права доступа пользователя просто не позволят ему создать подобный набор данных). ------- продолжение следует ------
Добавлено (16.10.2008, 18:32) --------------------------------------------- 1.2 "Блок, это не только логическое объединение, но и определенный набор управляющих байт на диске невидимый для пользователя. Существует возможность писать короткие блоки - содержащие не все записи." Трудно понять, что именно имеется в виду под загадочным "определенный набор управляющих байт на диске невидимый для пользователя"... Подразумевается поле счета? По-моему, подобные сентенции не делают текст более понятным... Вместо этого предлагается следующее:
1.2 Наборы данных с характеристикой FBS. В общем случае блоки набора данных с записями фиксированной длины (FB) могут иметь различную длину, но при этом длина любого блока должна быть кратна длине записи. Так, например, набор данных с характеристиками FB и длиной записи 80 может состоять из трех блоков длиной 800, 160 и 320 байтов. Для того, чтобы создать набор данных с блоками разной длины необходимо определенные усилия, и обычно набор данных с записями фиксированной длины состоит из блоков одинаковой длины, возможно, за исключением последнего. Для того, чтобы отметить этот факт, используется характеристика FBS, которая означает записи фиксированной длины со стандартным размером блока. Характеристика FS не имеет смысла. ------- продолжение следует ------
Добавлено (16.10.2008, 18:56) --------------------------------------------- 1.3 Для формата записи VBS в русскоязычной литературе использовался термин "расширенные записи переменной длины". Наверное, "сцепленные" более точный перевод английского "spanned", но тем не менее я бы предложил следовать сложившейся терминологии.
1.4 Не могу согласиться с тем что "С точки зрения пользователя PDS ничем не отличается от PDSE". PDSE позволяет дописывать данные в конец раздела (DISP=MOD,DSN=LIBRARY(MEMBER)). В PDS для того чтобы дописать данные в конец раздела нужно переписать весь раздел, DISP=MOD запрещено. Кроме этого, PDSE обеспечивает более широкие возможности совместного использования набора данных, ну и, как отмечено выше автором, не требует реорганизации. Некоторые данные, как то программые объекты, могут размещаться только в PDSE. В то же время некоторые наборы данных операционной системы не могут быть PDSE и должны быть только классическими PDS.
1.5 Набор поколений Я бы предложил излагать это позже, после описания каталога. Кроме этого: - общепринятый термин это "группа поколений данных" а не "набор поколений", что, кстати, более точно соотвествут оригинальному "Generation Data Group"; - русский термин "точка входа" существует и означает нечто совсем иное нежели чем "GDG base", а английский термин "GDG entry" я нигде не встречал. Предлагается сохранить оригинальный английский термин GDG base. - "... и опционально номер версии (Version number)". Последний квалификатор имени всегда имеет вид GnnnnVmm, так что слово "опционально" здесь несколько неуместно. - "Если вы задали 5, то при создании 6го набора, 1й автоматически удаляется". Не обязательно так, возможно использование двух стратегий - либо удаление самого старого (NOEMPTY) либо удаление всех поколений (EMPTY). В последнем случае 6ой станет 1ым и единственным - GDG base это не "специальный тип набора, физически им не являющийся" а просто одна из записей каталога, вот и еще одна причина по которой я и предлагаю вначале описать каталог. ------- продолжение следует ------
Да не, спасибо за любые коментарии, и за критику тоже. Критика (ну кроме русского языка и стиля) она только помогает возвыситься еще выще.
Я вообще думал, что на сайте кроме админа больше никто не живет
В мыслях я уже боролся с необходимостью вдаваться в особенности именования наборов, прав доступа, sms-менеджмент... но как то показалось, что слишком много получится. Посему остановился только на типах, и максимально коротко и доступно. Хотелось донести хотя бы до тех, кто умеет читать в интернете, что на тот вопрос на собеседовании нельзя отвечать: "Да, конечно, я создавал наборы данных!" или "Я создавал ДБ2-наборы" (это линейные висамы) Ну и просто подумал, что вряд ли вообще кто то здесь видит всю картину наборообложения
Предлагаю сделку. Вы пишете все что касается наборов, кроме типов и потом мы ссылаемся друг на друга... или соединяемся. (по размеру будет видно)
6. Каталог наборов данных В общем случае для операций с набором данных необходимо указывать имя этого набора данных и идентифицировать устройство на котором этот набор находится, подобно тому, как это делается в Windows, где кроме имени файла необходимо указывать имя диска и путь. Важным свойством z/OS является наличие централизованного каталога наборов данных, использование которого позволяет находить набор данных только по имени. Можно сказать, что операционная система как правило автоматически регистирирует наборы данных в каталоге (не совсем точно, но я считаю что так допустимо...). Очень грубым и приблизительным аналогом каталога z/OS в Windows является Registry.
Предлагаю также вместо "z/Unix" и "Юникс" использовать официальный термин "z/OS UNIX", чтобы не путать с z/Linux и не создавать ложного впечатления, что речь идет о какой-то другой операционной системе, а не о подсистеме в составе z/OS! Сравнительно недавно мне пришлось самому разубедить человека, который был вполне уверен в том, что его задание передает данные "в другую систему Unix", а потом "запускает в этом Unix sftp"... На самом деле, конечно, это была z/OS UNIX и все процессы выполнялись в той же самой системе. А если учесть еще и то, что на той же установке с z/OS в другом LPAR может и в самом деле работать z/Linux, или в z/VM выполняются z/OS и z/Linux в одном LPAR, то становится ясно, что с терминами надо бы поаккуратнее, чтобы не способствовать возникновению новых ересей :-))
...русскоязычной литературе использовался термин "расширенные записи переменной длины" Fixed! Нет у меня русских книжек.
Предлагаю также вместо "z/Unix" и "Юникс" использовать официальный термин "z/OS UNIX" Fixed!
- общепринятый термин это "группа поколений данных" Fixed!
Выжимка из доки:
Quote
A generation data group (GDG) base is allocated in a catalog before the generation data sets are cataloged. Each GDG is represented by a GDG base entry. Use the access method services DEFINE command to allocate the GDG base.
Согласен. Но хотелось бы и что то русское. ГДГ база ? Худая корова еще не газель!
Сообщение отредактировал XOpen - Чт, 16.10.2008, 19:34
Позволю себе отклонится от основной темы. 1) Критика ошибок в русском языке, особенно вульгарных заимствований из английского тоже помогает возвысится. Если мне соискатель на собеседовании скажет, что он "создавал наборы данных", то я поморщусь. А если он заявит, что "бровзает" эти наборы - собеседование закончится, ибо язык - знаковая система, и для программиста склонность к вульгарному заимствованию равносильна неспособности различать знаковые системы. А это - профнепригодность. 2) По поводу статьи - я справлюсь с размером, вы главное напишите и отредактируйте, он у Лишака статья про парасистемных программистов огромная, и ничего, воткнута на сайт. Было бы что поместить, а там как-нибудь с божьей помощью пристроим. 3) Про содержание статьи. О наименовании НД лучше бы написать, а про SMS можно и пропуститть, я думаю. Потому как у IBM та книжка, где использование НД, все внятно про SMS рассказывает для тех, кого данная тема кровно коснулась. С почтением и благодарностью за сделанный труд - противный Админ
Не по теме: (можно в новый топик перенести - поспорить) 1) Нам важнее, чтобы человек прошел собеседование с американцами. Да и в работе мы почти никогда не говорим ни одного общепринятого русского термина. Да, тросянка, но не надо перестраиваться при митингах зато потом. И как уже тут видно, иногда русских аналогов просто нет. 2) Скорее я имел в виду отдельную статью. Тогда и мне работы меньше и автор может собой подписаться 3) Проблема в том, что очень много наборов живут только на SMS дисках. А логика попадания наборов пользователей на конкретный диск - уже тоже давно в SMS.
Трудно понять, что именно имеется в виду под загадочным "определенный набор управляющих байт на диске невидимый для пользователя"... Подразумевается поле счета? По-моему, подобные сентенции не делают текст более понятным... Вместо этого предлагается следующее:
Подразумевается Block Descriptor Word (BDW) который кушает реальные 4 байта на диске. (CKD это еще глубже) FS - реально существующий тип. В моем понимании система отслеживает равное колличество неблокированных записей на каждом треке. Чтобы положение любой записи вычислялось формулой.
- "... и опционально номер версии (Version number)". Последний квалификатор имени всегда имеет вид GnnnnVmm, так что слово "опционально" здесь несколько неуместно.
Имелось в виду, что номер не растет обычно. Но глобально наверно согласен. Худая корова еще не газель!
(разрешаю админу править русский. В нем я как-то похуже) 
Ну и просто подумал, что вряд ли вообще кто то здесь видит всю картину наборообложения 
