С каким кодом закончится этот синтаксически верный джоб? Известно, что VOL001 в онлайне и не содержит данный набор. Каталог чист. Все остальные политики не важны, здесь все имеется для ответа. Варианты:
вот так вот в лоб если - то я бы выбрал вариант нумер три. сперва, по-моему, делается аллокация того, что нужно в степе, потом запускается программа. аллокация навернётся, получим ошибку.
2 //NOWHERE EXEC PGM=IEFBR14 3 //SYSUT1 DD DISP=SHR,DSN=SPOSPEL.NOWHERE,UNIT=3390 IEF212I DRBLEZA NOWHERE SYSUT1 - DATA SET NOT FOUND
ух ты! а у меня в итоге прошло по нулям. проверил... всё зависит от того, указывать ли VOL=SER=VOL001,UNIT=3390 (с реальным диском). если и то, и другое есть - отрабатывает по нулям. если хотя бы одного нету - ошибка.
получается, всё зависит от того, нужно ли идти в каталог до того, как программа обращается к набору. если не нужно (т.е. есть всё необходимое) - отработает. если чего-то не хватает, и нужно залезть в каталог - схватит ошибку.
Сообщение отредактировал Bibizyan - Вт, 21.02.2012, 18:44
Ответ правильный, но логика неверна. Буду остальным задавать вопрос с примером PGM=MYPROG.
Хорошо Попробую с логикой. На этапе обработки DD-карт, для каждой из них строится блок управления файлом (JFCB) Заполняются там отнюдь не все поля, а некоторый минимальный перечень. В него как раз обязательно должны попасть данные из UCB (возможно там просто ссылка на живой UCB, не помню, смотреть надо). Вот почему если имя файла указано, а диск нет, то идет обращение к каталогу. Разумеется это для DISP=SHR,OLD и MOD. Далее, если будет выдан обычный OPEN произойдет непосредственное чтение DSCB и заполнение блоков DCB и DEB. Можно прочитать JFCB (макро RDJFCB), произвести там модификацию много чего и выдав OPEN TYPE=J читать затем совсем например другой файл. Этот прием широко использовался в древних версиях ОС, когда надо было в одной программе работать с большим количеством разных файлов, а DD - карты плодить не хотелось. Когда появилась DYNALLOC, все стало гораздо проще.
Имелось в виду в том смысле, что независимо от того есть open или нет, упасть по JCL error может еще до запуска программы (диск не указан или не доступен). Но, если это подразумевалось в вашем ответе и уточнялось, что 213 тоже не будет - то снимаю шляпу.
Можно прочитать JFCB (макро RDJFCB), произвести там модификацию много чего и выдав OPEN TYPE=J читать затем совсем например другой файл... Когда появилась DYNALLOC, все стало гораздо проще.
Вставлю пять копеек: между модификацией JFCB, что и сейчас возможно, и DYNALLOC принципиальная разница. "Можно прочитать JFCB произвести там модификацию много чего и выдав OPEN TYPE=J читать затем совсем например другой файл" но только на том же томе - распределение устройств уже выполнено. DYNALLOC же обеспечивает динамическое распределение устройств. В ранних OC динамическое распределение устройств тоже существовало (TSO DAIR), равно как и динамическое распределение памяти (SVC 32), но эти API не были открыты для пользователя и многие умельцы народные что только не выделывали для получения желаемого эффекта К вопросу о том, почему так сделано - я предполагаю, что причина этого - необходимость избежать deadlock (напомню, что ранние OC это системы пакетной обработки): задание A получает устройство U1, затем запрашивает U2, а в это время задание B получило устройство U2 и запрашивает U1... Для динамического распределения нужна намного более сложная логика планирования, что на машине с 256К памяти достаточно проблематично.
Сообщение отредактировал Gregory - Ср, 22.02.2012, 14:22
но эти API не были открыты для пользователя и многие умельцы народные что только не выделывали для получения желаемого эффекта
Эх!, я даже ретранслировал почти все модули SVC 32. что бы попытаться до конца понять что оно умеет делать. Помнится научился создавать простые файлы и завязал с этим из-за отсутствия на тот момент необходимостей.
//NOWHERE EXEC PGM=IEFBR14 //SYSUT1 DD ... последовательность действий такая: 1) вызов catalog management если в DD отсутствует VOL=SER и/или UNIT, а также если указано VOL=REF=dsname 2) распределение устройств (возможно, с запросом монтирования тома, еcли том не установлен и в UNIT не указан DEFER) 3) распределение памяти, если в DD указано или подразумевается DISP=NEW и UNIT определяет том прямого доступа
т.е. здесь еще еще один момент, который сейчас практически забыт - монтирование тома. Диски бывали съемными, а дисководы были дороги, и их было не так много, например, всего 4 штуки 5061 (29Мб) (сравните с ресурсами современного мобильного телефона ) Магнитные ленты (кассеты) и сейчас съемные носители.
Сообщение отредактировал Gregory - Чт, 23.02.2012, 10:54
Поправьте меня, если что. Но, по-моему, EAL-5 был навешен на оборудование, а не на систему. Гугль говорит о сервере z10 EC, в частности. А вот про систему - не встречал. Так что мой ответ - 2. Тут, кстати, интересное обсуждение по этому поводу.
Горькая правда такова, что EAL5 даже не у сервера, а у технологии LPAR. z/OS тоже имеет сертификат, но EAL4+
И если IBM маркетологи стараются мягко всё завуалировать и говорят у нас есть EAL5 в z Series, то следующая волна уже всё мешает в кучу. Такая же истории как с запуском Windows на мейнфрейме.
Ну и по ссылке видно, что EAL4+ есть и у Линуксов и Юниксов. То есть ничего сверх выдающегося в самом z/OS в плане безопасности нет.
Попробую с логикой. На этапе обработки DD-карт, для каждой из них строится блок управления файлом (JFCB) 
