Сб, 05.10.2024, 08:27
Приветствую Вас Гость | RSS
Главная | EAV volumes - Форум | Регистрация | Вход
Форма входа
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
EAV volumes
XOpenДата: Пн, 24.11.2008, 13:48 | Сообщение # 1
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
До z/OS V1R10, было ограничение в 65 520 цилиндров на том. Теперь появился новый тип дисков - extended address volume (EAV). Может содержать от 65 521 цилиндров. Максимальный размер теперь 262 668 цилиндров. (и есть планы по увеличению) Глобальный плюс - можно иметь меньше томов, что облегчает управление ими.

Адрес трека теперь выглядит как CCCCcccH, при этом ссс - это старшие биты, а СССС младшие биты адреса.

Пространство выше линии выделяется кратно цилиндрам. (будет округляться до ближайшего)

В настоящий момент лежать выше линии могут только VSAM наборы данных. При этом, если запрашивается размер от 10 цилиндров, они автоматически идут за линию. (это уже открывает большие возможности для приложений типа DB2 или файловой системы zFS(помним - это Linear VSAM))


Худая корова еще не газель!
 
akostДата: Вт, 25.11.2008, 12:41 | Сообщение # 2
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Во-во, я как раз планирую такие тома попробовать. Для Линукса, VM и для OS, может быть.
 
akostДата: Вт, 25.11.2008, 12:44 | Сообщение # 3
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Вот мне интересно, когда IBM снимет ограничение на 65 535 дорожек для не-VSAM НД на одном томе. Страшно мешает.
 
XOpenДата: Вт, 25.11.2008, 14:47 | Сообщение # 4
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
тут еще прикол, что за линией система выделяет цилиндры кратно 21.(откуда такое число??) Тоесть использовать EAV оптимально только для реально больших наборов.

Добавлено (25.11.2008, 14:47)
---------------------------------------------

Quote (akost)
Вот мне интересно, когда IBM снимет ограничение на 65 535 дорожек для не-VSAM НД на одном томе. Страшно мешает

Так ведь давно сняли. Хочешь extended-PS, хочешь LARGE...


Худая корова еще не газель!
 
akostДата: Вт, 25.11.2008, 16:18 | Сообщение # 5
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Quote (XOpen)
Так ведь давно сняли. Хочешь extended-PS, хочешь LARGE...

ага.... для таких - сняли. я хочу DA!!
 
XOpenДата: Вт, 25.11.2008, 16:59 | Сообщение # 6
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
DA - это тупиковая ветвь эволюции в наш век SMS environments....

Худая корова еще не газель!
 
akostДата: Вт, 25.11.2008, 17:11 | Сообщение # 7
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Quote (XOpen)
DA - это тупиковая ветвь эволюции в наш век SMS environments....

Не могу согласиться. DA - быстрые и отдают все программисту. А SMS - просто чтобы удобнее распределять все же, а не бегать в уже распределенные наборы.
 
XOpenДата: Вт, 25.11.2008, 19:06 | Сообщение # 8
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
А что DA отдает программисту ? Любую логику от фазы луны можно организовать и в просто последовательном и в линейном VSAM. Единственно там есть возможность идти сразу по физ адресу. А значит адреса надо хранить в виде ключей где то в начале файла и... они становятся бесполезными, если набор переместят. А вычислять в начале, я так же могу RBA из VSAM пособирать и будет тоже довольно быстро.

Вот преимущество линейного над остальными VSAM мне лучше видется. Работай себе с памятью и сохраняй иногда. А в других VSAM начинается : чтобы перезаписать, надо все равно сначала прочитать старую. Уже при создании на меня накладывают ограничение на длину записи, пусть и диапазон и тд и тп. После этого сразу понятно почему DB2 и z/Unix сбежали в линейные в итоге.

Что я не могу понять, так это почему нет редактора для VSAM в системе сразу. Таже DITTO наглядно показывает что это возможно...


Худая корова еще не газель!
 
akostДата: Вт, 25.11.2008, 19:20 | Сообщение # 9
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Не надо обижать DA - на нем стоит ADABAS, который был написан задолго до появления VSAM-наборов. Так вот у данной уважаемой и распространенной в мире СУБД наборы конечно привязаны к месту - и что? Их никто никогда не перемещает и работает утилитами. Ну и ладно! Зато все написано на EXCP и за 30 лет отлажено вдоль и поперек, я вообще проблем с ядром не помню уже много-много лет...
А вот VSAM, на который она тоже умеет становиться, постоянно дискутируется в их форуме как проблемный.
По уму, так файловую систему ОС надо оставить в покое - а для будущего сделать новую, типа JFS или еще какой, на уровне native, и потихоньку ее развивать. А то старая система вся в заплатках.
 
XOpenДата: Ср, 26.11.2008, 12:56 | Сообщение # 10
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
А что такое файловая система в z/OS понимании? Это вроде как каталог + методы доступа + типы наборов для меня. И они как раз потиху добавляют новое и удаляют старое.

Я бы пару наборов данных вообще выкинул:
1. ESDS, RRDS, VRRDS, потому что есть KSDS(добавил бы RRN только ему), а для скорости есть Linear. Место на современных дисках не так критично.(да и не хранит большие базы никто в этих наборах)

2. Fixed бы тоже выкинул. В текстах Variable его заменяет. Для скорости опять же в Linear. В идеале написать редактор для U и только его оставить для non-VSAM.


Худая корова еще не газель!
 
akostДата: Ср, 26.11.2008, 14:15 | Сообщение # 11
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Quote (XOpen)
А что такое файловая система в z/OS понимании? Это вроде как каталог + методы доступа + типы наборов для меня. И они как раз потиху добавляют новое и удаляют старое.

так я ж и говорю - не надо старую систему файловую, а именно - формат VTOC курочить. Надо сделать новую структуру диска, и туда тянуть все новое, а старые диски, VTOC и каталог оставить нетронуто. А они потихоньку модифицируют старые структуры данных.
Он, в VM есть старая структура минидисков, диски OS и новая (уже привычная) структура. И никого это не шокирует - старые приложения запущены на старых мд, новые реализовываются на новых, форматировать можно так и этак. Есть же сейчас и ICF-каталоги, и старые VSAM-каталоги.
А может, это и глупость я предлагаю.
В общем, непринципиально все это.
 
GregoryДата: Ср, 26.11.2008, 20:26 | Сообщение # 12
Генерал-майор
Группа: Доверенные
Сообщений: 482
Репутация: 22
Статус: Offline
если позволите заметить, VTOC уже давно как Вы выразились, "раскурочили" -- его заменил VVDS. Каталог тоже только ICF, все что было до того (SYSCTLG, VSAM каталог c CRA) вообще не поддерживается. И я, как и Xopen, считаю, что DA это атавизм и анахронизм. Организации DA и IS имели смысл во времена 7Мб дисков и 256Кб памяти, то есть ЕС1020, а сегодня какой смысл в этом?
 
akostДата: Чт, 27.11.2008, 11:58 | Сообщение # 13
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Quote (Gregory)
если позволите заметить, VTOC уже давно как Вы выразились, "раскурочили" -- его заменил VVDS

ну не совсем заменил, скорее - дополнил.

Quote (Gregory)
Каталог тоже только ICF, все что было до того (SYSCTLG, VSAM каталог c CRA) вообще не поддерживается.

Что, совсем не поддерживается? Мне казалось, что для совместимости они понимают как минимум VSAM каталоги c CRA. Или я ошибаюсь?

А вообще... Ну не могу я отделаться от ощущения, что такие "эволюционные" изменения, которые вытворяет IBM с файловой системой, не на пользу делу. Я понимаю субъективность своих же доводов, и согласен с вами всеми по поводу архаичности DA и IS наборов, но эклектичность файловой системы OS таки достает.

 
XOpenДата: Чт, 27.11.2008, 13:13 | Сообщение # 14
Генерал-майор
Группа: Администраторы
Сообщений: 325
Репутация: 4
Статус: Offline
C одной стороны иметь возможность выбрать оптимальный вид файла по быстродействию - это плюс. IBM дает как бы возможность использовать особености железа. С другой стороны имеем студентов с БОЛЬШИМИ и ЖАЛОБНЫМИ глазами. Плюс, часто проект усложняется, и даже если ESDS подходил вначале, дальше без KSDS никак и приходится переписывать код. И все эти сложности ради маленькой прибавки скорости или места на диске, которая уже давно решается увеличением дисков или процессоров. (некоторые даже считают, что это надежнее и дешевле, чем труд программистов) И осталось вспомнить, что диски в стойках уже давно виртуальные. И дает ли это реальный выйгрыш - большой вопрос. (шутка ли кеш в 32 гига)

Тоесть в идеале должен быть один тип файлов smile

Вот приходил тут Юникс-парень и очень удивлялся, что нельзя сишным open() открыть любой файл. Как же так? В Юниксе вот можно. Я ему говорю, зато смотри тут можно прям на дорожки головку ставить. Могешь так в Юниксе? Он и сникся. И хотя честь мейнфрема была защищена, сам я подумал - и правда, а нафик все это? Универсальность все же лучше скорости. Большая часть приложений уже давно не пишется на ассемблере. Тоесть люди готовы жертвовать скоростью работы в угоду другим плюсам...


Худая корова еще не газель!
 
akostДата: Чт, 27.11.2008, 16:16 | Сообщение # 15
Admin
Группа: Администраторы
Сообщений: 619
Репутация: 5
Статус: Offline
Елки, да не надо ничего изобретать - ну добавьте независимо от ОС-овской файловой системы поддержку давно известной блочной CMS-дисковой системы или тот же JFS на уровне дисков! Ну есть же на мэйнфреймах VM, в котором и своя блочная, и ОС-система! И никаких проблем со студентами!
 
  • Страница 1 из 1
  • 1
Поиск: