До z/OS V1R10, было ограничение в 65 520 цилиндров на том. Теперь появился новый тип дисков - extended address volume (EAV). Может содержать от 65 521 цилиндров. Максимальный размер теперь 262 668 цилиндров. (и есть планы по увеличению) Глобальный плюс - можно иметь меньше томов, что облегчает управление ими.
Адрес трека теперь выглядит как CCCCcccH, при этом ссс - это старшие биты, а СССС младшие биты адреса.
Пространство выше линии выделяется кратно цилиндрам. (будет округляться до ближайшего)
В настоящий момент лежать выше линии могут только VSAM наборы данных. При этом, если запрашивается размер от 10 цилиндров, они автоматически идут за линию. (это уже открывает большие возможности для приложений типа DB2 или файловой системы zFS(помним - это Linear VSAM))
тут еще прикол, что за линией система выделяет цилиндры кратно 21.(откуда такое число??) Тоесть использовать EAV оптимально только для реально больших наборов.
DA - это тупиковая ветвь эволюции в наш век SMS environments....
Не могу согласиться. DA - быстрые и отдают все программисту. А SMS - просто чтобы удобнее распределять все же, а не бегать в уже распределенные наборы.
А что DA отдает программисту ? Любую логику от фазы луны можно организовать и в просто последовательном и в линейном VSAM. Единственно там есть возможность идти сразу по физ адресу. А значит адреса надо хранить в виде ключей где то в начале файла и... они становятся бесполезными, если набор переместят. А вычислять в начале, я так же могу RBA из VSAM пособирать и будет тоже довольно быстро.
Вот преимущество линейного над остальными VSAM мне лучше видется. Работай себе с памятью и сохраняй иногда. А в других VSAM начинается : чтобы перезаписать, надо все равно сначала прочитать старую. Уже при создании на меня накладывают ограничение на длину записи, пусть и диапазон и тд и тп. После этого сразу понятно почему DB2 и z/Unix сбежали в линейные в итоге.
Что я не могу понять, так это почему нет редактора для VSAM в системе сразу. Таже DITTO наглядно показывает что это возможно...
Не надо обижать DA - на нем стоит ADABAS, который был написан задолго до появления VSAM-наборов. Так вот у данной уважаемой и распространенной в мире СУБД наборы конечно привязаны к месту - и что? Их никто никогда не перемещает и работает утилитами. Ну и ладно! Зато все написано на EXCP и за 30 лет отлажено вдоль и поперек, я вообще проблем с ядром не помню уже много-много лет... А вот VSAM, на который она тоже умеет становиться, постоянно дискутируется в их форуме как проблемный. По уму, так файловую систему ОС надо оставить в покое - а для будущего сделать новую, типа JFS или еще какой, на уровне native, и потихоньку ее развивать. А то старая система вся в заплатках.
А что такое файловая система в z/OS понимании? Это вроде как каталог + методы доступа + типы наборов для меня. И они как раз потиху добавляют новое и удаляют старое.
Я бы пару наборов данных вообще выкинул: 1. ESDS, RRDS, VRRDS, потому что есть KSDS(добавил бы RRN только ему), а для скорости есть Linear. Место на современных дисках не так критично.(да и не хранит большие базы никто в этих наборах)
2. Fixed бы тоже выкинул. В текстах Variable его заменяет. Для скорости опять же в Linear. В идеале написать редактор для U и только его оставить для non-VSAM.
А что такое файловая система в z/OS понимании? Это вроде как каталог + методы доступа + типы наборов для меня. И они как раз потиху добавляют новое и удаляют старое.
так я ж и говорю - не надо старую систему файловую, а именно - формат VTOC курочить. Надо сделать новую структуру диска, и туда тянуть все новое, а старые диски, VTOC и каталог оставить нетронуто. А они потихоньку модифицируют старые структуры данных. Он, в VM есть старая структура минидисков, диски OS и новая (уже привычная) структура. И никого это не шокирует - старые приложения запущены на старых мд, новые реализовываются на новых, форматировать можно так и этак. Есть же сейчас и ICF-каталоги, и старые VSAM-каталоги. А может, это и глупость я предлагаю. В общем, непринципиально все это.
если позволите заметить, VTOC уже давно как Вы выразились, "раскурочили" -- его заменил VVDS. Каталог тоже только ICF, все что было до того (SYSCTLG, VSAM каталог c CRA) вообще не поддерживается. И я, как и Xopen, считаю, что DA это атавизм и анахронизм. Организации DA и IS имели смысл во времена 7Мб дисков и 256Кб памяти, то есть ЕС1020, а сегодня какой смысл в этом?
если позволите заметить, VTOC уже давно как Вы выразились, "раскурочили" -- его заменил VVDS
ну не совсем заменил, скорее - дополнил.
Quote (Gregory)
Каталог тоже только ICF, все что было до того (SYSCTLG, VSAM каталог c CRA) вообще не поддерживается.
Что, совсем не поддерживается? Мне казалось, что для совместимости они понимают как минимум VSAM каталоги c CRA. Или я ошибаюсь?
А вообще... Ну не могу я отделаться от ощущения, что такие "эволюционные" изменения, которые вытворяет IBM с файловой системой, не на пользу делу. Я понимаю субъективность своих же доводов, и согласен с вами всеми по поводу архаичности DA и IS наборов, но эклектичность файловой системы OS таки достает.
C одной стороны иметь возможность выбрать оптимальный вид файла по быстродействию - это плюс. IBM дает как бы возможность использовать особености железа. С другой стороны имеем студентов с БОЛЬШИМИ и ЖАЛОБНЫМИ глазами. Плюс, часто проект усложняется, и даже если ESDS подходил вначале, дальше без KSDS никак и приходится переписывать код. И все эти сложности ради маленькой прибавки скорости или места на диске, которая уже давно решается увеличением дисков или процессоров. (некоторые даже считают, что это надежнее и дешевле, чем труд программистов) И осталось вспомнить, что диски в стойках уже давно виртуальные. И дает ли это реальный выйгрыш - большой вопрос. (шутка ли кеш в 32 гига)
Тоесть в идеале должен быть один тип файлов
Вот приходил тут Юникс-парень и очень удивлялся, что нельзя сишным open() открыть любой файл. Как же так? В Юниксе вот можно. Я ему говорю, зато смотри тут можно прям на дорожки головку ставить. Могешь так в Юниксе? Он и сникся. И хотя честь мейнфрема была защищена, сам я подумал - и правда, а нафик все это? Универсальность все же лучше скорости. Большая часть приложений уже давно не пишется на ассемблере. Тоесть люди готовы жертвовать скоростью работы в угоду другим плюсам...
Елки, да не надо ничего изобретать - ну добавьте независимо от ОС-овской файловой системы поддержку давно известной блочной CMS-дисковой системы или тот же JFS на уровне дисков! Ну есть же на мэйнфреймах VM, в котором и своя блочная, и ОС-система! И никаких проблем со студентами!
