Я хочу попробовать поэкспериментировать с нашим сообществом. Идея вот в чем: собрать материал (FAQ) по z-теме, который ляжет в основу для написания технической статьи для сообщества. Конечно можно сказать, что все можно найти в гайдах IBM и все это и так знают, но для новичков это не прокатывает - они лезут в гугл и ничего не находят. Тема относительная несложная и для мозгов, исковерканных linux и unix, достаточно близкая - z/FS. Хочу набрать некий FAQ или чего попродвинутее. От сообщества нужно, чтобы люди приводили свои какие-то приемы (пусть даже достаточно распространненые) по работе с z/FS из практики (JCL, алгоритмы действий и т.д.). Список обсуждаемых вопросов - абсолютная свобода, чего хотите.
Я начну с самого банального и простого:
Подготовка VSAM LDS для монтирования под zFS
Файловая система z/UNIX содержится в наборах данных zFS, которые представляют собой линейные VSAM-датасеты. Линейный VSAM-датасет - это набор данных, поддерживающий байт-ориентированную адресацию записей. Данный вид VSAM-датасетов не содержит никакой дополнительной внутренней контрольной информации, в отличии от других видов VSAM.
Пример джоба, который форматирует датасет в формате VSAM LDS (здесь и далее предполагается, что у пользователя есть все необходимые права доступа):
Код
//INITLDS JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1), // NOTIFY=&SYSUID //******************************************************* //* JOB TO INIT VSAM LINEAR DATASET (LDS) //* //* TO CONVERT TO 3390 CYLINDERS MULTIPLY THE NUMBER //* OF MB BY 1.4 AND THEN MULTIPLY BY 2 //* //* FOR EXAMPLE: ((5,000 MB)* (1.4 CYL/MB))*2=14,000 CYL //******************************************************* //DEFINE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //AMSDUMP DD SYSOUT=* //DASD0 DD DISP=OLD,UNIT=3390,VOL=SER=CUST01 //SYSIN DD * DEFINE CLUSTER (NAME(ABC.DTS) - VOLUMES(CUST01) - [b][color=#ff0000]LINEAR[/color][/b] CYL(800 100) SHAREOPTIONS(3)) /* //FORMAT EXEC PGM=[b]IOEAGFMT[/b],REGION=0M, // PARM=('-aggregate ABC.DTS -compat') //SYSPRINT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //CEEDUMP DD SYSOUT=* //*
Джоб состоит из двух шагов: 1. Инициализация датасета в формат LDS с помощью утилиты IDCAMS. 2. Форматирование датасета с помощью утилиты ioeagfmt.
Далее датасет можно монтировать внутри консоли UNIX subsystem (USS) или командой TSO (точка монтирования должна существовать): 1. Из консоли USS: /usr/sbin/mount -f ABC.DTS -t ZFS /u/myuser/abcdts
2. Командой TSO/E: MOUNT FILESYSTEM('ABC.DTS') TYPE(ZFS) MODE(RDWR) MOUNTPOINT('/u/myuser/abcdts')
Сообщение отредактировал art - Сб, 22.06.2013, 00:33
Далее датасет можно монтировать внутри консоли UNIX subsystem (USS) или командой TSO (точка монтирования должна существовать):
Пока лишь добавлю, что монтирование в USS требует привилегий superuser (как и в UNIX), в то время как подготовка z/FS и создание точки монтирования, вообще говоря, привилегий не требуют.
Примечания: 1) поскольку у файлов отсутствуют характеристики, указание RECFM/LRECL/BLKSIZE при их обработке стандарными утилитами (то есть BSAM/QSAM) обязательно 2) FILEDATA=TEXT и RECFM=F требуют, чтобы длина всех строк файла (до NL = '15'x) была одинакова и равнялась LRECL, в противном случае при чтении возникнет I/O ERROR WRONG LENGTH RECORD
Добавлено (24.06.2013, 11:23) --------------------------------------------- Выполнение скриптов и программ в JCL - BPXBATCH vs AOPBATCH
BPXBATCH не позволяет указать наборы данных в STDIN, STDOUT, STDERR, только файлы, из-за чего приходится использовать вспомогательные шаги с копированием наборов данных в файлы и обратно
в отличие от BPXBATCH, AOPBATCH позволяет указать наборы данных в STDIN, STDOUT, STDERR, так что вспомогательные шаги не нужны.
Добавлено (24.06.2013, 11:29) --------------------------------------------- - использование стандарных программ z/OS UNIX
Код
//IRXJCL EXEC PGM=BPXBATCH,PARM='sh sleep 5'
пожалуй, самый простой (но, надеюсь, полезный) пример. Для реализации этой функции существует множество доморощенных программ (TSOWAIT etc.), о которых можно забыть
Сообщение отредактировал Gregory - Ср, 26.06.2013, 14:31
Очень часто используется. Для работы с файловыми системами zFS большими чем 4 Гб необходимо при создании VSAM DS использовать Extended addressability в DATA CLASS.
Ещё говорят zFS работает быстрее HFS, но к сожалению точных данных по производительности привести не могу.
На мой взгляд все вкусняшки zFS начинаются в сисплексе, так как приносит она на z платформу распределённую файловую систему для USS. В общем работает почти как POHMELFS, только название попроще
Сообщение отредактировал stas9132 - Ср, 26.06.2013, 12:34
много молодых работают в USS с WebSphere там и тд и им пофигу что там снизу, HFS или zFS. А тех, кому не пофигу, все равно к настройке не допустят. Есть даже типа админы USS, которые слова zFS не знают.
IMHO вопрос для обсуждения поставлен несколько неопределенно. Обсуждается именно zFS (vs HFS)? или шире, z/OS UNIX вообще? Если вопрос ограничен только zFS [vs HFS], то ничего удивительного, что источник иссяк, так как с двух шагов этот источник [zFS]от другого источника [HFS]уже не отличить - с точки зрения пользователя вообще не видно разницы.
IMHO: zFS используется слабо. В z/OS-ах, к которым я имею доступ, используется HFS. И пока как-то незаметно, чтобы от HFS отказывались, несмотря на
Цитата
The z/OS® Distributed File Service zSeries® File System (zFS) is the strategic z/OS UNIX® file system that is suggested to be used instead of the Hierarchical File System (HFS), beginning with z/OS V1R7. (REDP-4328-0)
и
Цитата
Therefore, in z/OS V1R7 an official migration tool, BPXWH2Z, is delivered with z/OS to support installations in replacing HFS with zFS.
Сообщение отредактировал Gregory - Пт, 05.07.2013, 10:39
Системы нашего заказчика практически целиком переведены на ZFS, причем, достаточно давно. В HFS были и есть ограничения, которые иногда приводили к весьма неприятным последствиям.
Парочка навскидку:
1. Если в HFS записывать информацию от суперпользователя и ФС переполняется, то в результате можно получить HFS, который даже после освобождения места будет выдавать ошибку при попытке записи, те по факту становится ReadOnly (размонтировать/смонтировать не помогает). Лечится созданием нового HFS и копированием туда всего дерева, а потом заменой оригинального. Если запись велась от рядового пользователя, ошибка не проявляется. Ошибка тянулась на протяжении нескольких версий z/OS, актуально ли сейчас - не знаю.
2. Если HFS смонтирован на чтение в более чем одной системе, и, между системами нет GRS, то при попытке перемонтировать эту ФС на запись в одной системе - она полностью отвалится на второй системе. Эта "фича" появилась в одной из версий z/OS "by design".
ZFS - это журналируемая ФС, что весьма нелишне для производства. Возможностей у нее больше. В z/OS 1.13 обещана параллельная запись с нескольких узлов в общий ZFS без потери производительности. Как оно на самом деле - будет понятно после миграции на 1.13.
Хинты пока такие: 1. (Уже было) Создавать ZFS желательно SMS-управляемым, в DataClass-е с расширенной адресацией, иначе предел объема - 4 ГБ. 2. В параметрах конфигурации ZFS-сервиса (IOEFSPRM) указать автоматическое распределение экстентов у агрегата (aggrgrow=on) 3. Ознакомиться с книгами из коллекции "zSeries File System (zFS) Administration" и запомнить команду zfsadm.
