Обнаружил такую вещь. Если у вас есть два некаталогизированных набора с одинаковым именем на 2х разных дисках - вы не можете открыть их одновременно!!! Потому что блокировка идет только по имени набора без диска(ENQ SYSDSN). Я в шоке, пью зеленый чай чтобы успокоиться. Худая корова еще не газель!
О! Я таки на те же грабли тоже налетал! Еще на курсах в 2001 году заспорили с преподавателем, я не верил, что нельзя открыть 2 некаталогизированных наборы с одним именем. Он предложил попробовать)). Результат мы понимаем. Думаю, что наличие пользовательских некаталогизированных одноименных наборов в системе - это все-таки странность. Все указывает, что наборы надо каталогизировать и в будущем некаталогизированных НД не будет. А вот Вам такие наборы, если не секрет, зачем? P.S. Из-за высокого содержания тимина некоторые сорта зеленого чая возбуждают. Займитесь аутотреннингом))).
Пишешь DISP=SHR и открываешь СОВЕРШЕННО СПОКОЙНО. Ага. Именно "совершенно спокойно". Читать как написано. Остался только морально-нравственный аспект такого поступа Написав SHR, ты как бы даешь торжественное обещание, что будешь только читать, а писать - ни-ни! Подписку дал - тебя допустили. А будешь ли ты выполнять это обещание - этого никто не проверит. И за невыполнение никто не покарает. Вот так-с... "Знание законов освобождает от ответственности"
Кстати, в Мерзком Оффтопике та же фигня, по-моему: если кто-то где-то открыл на запись некий файл.тхт, то фиг ты откроешь в другом каталоге файл с таким же именем. Но в отличие от нашего случая, там блокировка, похоже, встроена в open, так что фиг обойдешь. (Если ошибаюсь - не бейте сильно - не знаю я Мерзкого Оффтопика, и знать не хочу)
Знамо дело, DISP=SHR - это синоним того, что ОС снимает с себя ответственность. Это понятно))). Речь шла, как я понимаю, о корректном открытии некаталогизированных одноименных наборов на разных дисках. И неучет того, что некаталогизированные наборы с одинаковыми именами могут располагаться на разных дисках и запрещение открытия на запись таких наборов (как и их создание) с DISP=OLD (или NEW) вполне можно считать ошибкой или темным наследием прошлого. Я таки (по дурному характеру) понастаиваю - ситуация с наличием некаталогизированных одноименных наборов на разных дисках есть несколько противоестественная и искусственная и сама по себе есть источник ошибок. В Мерзком Оффтопике я в Паскале открывал одноименные файлы в разных каталогах, но в имени был полный путь! Правда, не помню, в какой версии Оффтопика я это делал - похоже, дико давно, как бы не в Win98 еще... Или уже позже? В целом Оффтопик закрываем - там от компилятора к компилятору и от версии к версии вылезают принципиальные изменения.
Я таки (по дурному характеру) понастаиваю - ситуация с наличием некаталогизированных одноименных наборов на разных дисках есть несколько противоестественная и искусственная и сама по себе есть источник ошибок.
Не могу согласиться. Когда я на ЕСах работал, была нормальной ситуация, когда одновременно идет "производство" и рядом программисты чего-то девелопят для этой же задачи - а у них свой, "девелоперский" том, и библиотеки обозваны так же. Конечно, можно было организовать это и с разными именами... Но так оно сложилось до меня, что были одинаковые. Я совершил подвиг Геракла, внедрив префиксы имен для каждой задачи (а то задачи "дрались" за имена вроде "JOBS' , которые у них, естественно, пересекались ), так и эта эпопея растянулась месяца на 3... (В общем, НАВЕРНОЕ правильней было бы тестовые и эксплуатационные обозвать по-разному, но тут уже, ИМХО, затраты нервов всех участников процесса не окупались бы достигнутым результатом...)
О, а у меня разработческая и промышленные системы через VM разведены - от века повелось, еще с 370-систем с БОС и СВМ. И следов от разработческих дел в системе боевой нет - ни байта, туда девелоперы ходят только когда надо что-то потестировать или починить. У других моих коллег - близкое разделение реализовано LPAR-ами, хотя и не так гибко, как у нас с VM. А про цитированное - речь идет о современной OS-тенденции со всякими SMS и прочими закидонами. SMS-управляемый набор по определению не может быть некаталогизированный, И на SMS-управляемых томах нет некаталогизиованных наборов. А современные системы без SMS уже не бывают принципиально, и туда все больше компонент лезет. Так что у моего
Quote (akost)
ситуация с наличием некаталогизированных одноименных наборов на разных дисках есть несколько противоестественная и искусственная и сама по себе есть источник ошибок
не только личностная, но и техническая основа присутствует.
Мы создаем тесты, которые тестят репликации внутри Симметрикса. Тоесть мы пишем один том, он по миррору перетекает и на 2й том(естественно некаталигизированные наборы будут. Копия диск-диск). Далее попытка чтения приводит к верхним плачевным результатам. Приходится сначала снимать программу-писаку.
Тоесть грубо говоря высказывание, что мол копия сразу доступна для использования, мягко говоря некорректно. Надо тушить работу с исходником или в оффлайн его переводить и тд... Тоесть нельзя скопировать базу и спокойно выдать на нее запрос.
Хотя с другого LPAR запросто, если GRS не против. (даже один и тот же набор можно. Выживет последний F3.)
Ой как интересно, мамма-миа... IBM свои тома PPRC-копий сразу в оффлайн кидает и пишет на них совсем без меня. И проблемы разных наборов у меня не возникает, ибо чтобы взять том-копию в систему мне надо порвать PPRC-связь, отрубить основной том (или переименовать его) и только потом прицепить копию. И со стороны других LPAR, VM и прочих данные диски-копии недоступны - они в УУ выведены в оффлайн.
Да и другая дисциплина там использования. Вылетают основной дисковой массив - рву пары, перегружаюсь и работаю на резервных. Надо без перезагрузки - sysplex и GDPS, вот там hotswap есть. Или VM c hotswap для гостевых систем, например.
Ну значит здесь чутка гибче. При копировании я выбираю, менять метку тома или нет. Если менять - то диск уйдет в оффлайн. А могу и не менять и наборы использовать, если одноименные никто не трогает. Сейчас я говорю про SNAP, point-in-time копирование на одном массиве. Для непрерывного удаленного надо как минимум suspend на линк поставить(иначе данные каждую секунду идут же), а том держать в оффлайне не обязательно. Худая корова еще не газель!
Ага, я так понимаю, SNAP - это то, что flash-copy у IBM? Когда данные внутри моментально копируются за счет пересчета управляющих блоков в контроллере без реального физического копирования? Но там тоже - по flash-copy метки изменяются и копии вылетают в оффлайн.... Ну в общем ответ понятен, несмотря на желание производителей порождать собственные алгоритмы и торговые марки.. Хорошо, что EMC гибок. Страшненько, что эта гибкость может боком вылезти. А может и не вылезти.
Да, это близко от Флешкопи. Только копирование реальное. Смысл в том, что устройство доступно через секунду. Просто данные берутся либо из родных страничек, либо из страничек исходника, если они еще не перебежали. Боков здесь абсолютно нет никаких. Хочешь используй в режиме IBM, хочешь используй новые фишки с учетом особенностей системы. (выше системы не прыгнешь)
По моему мнению Симметрикс гибче и лучше ДС-ок... но у него нет никаких воможностей влиять на систему. Значит, если IBM со стороны хоста придумывает EAV диски, их поддержка какое-то время дорабатывается в симмах. Зато там где просто связь между массивами - в симмах хоть каскадно их соединяй, хоть звездой.
Вдруг подумал про SHR. Писака то открывает файлы по NEW у меня, но я ведь могу редизайн тесту сделать. В одном шаге создал, во втором открыл по SHR. Писаку правда все равно тушить надо, а то он помешает следующим тестам... но есть о чем подумать...
