Из MF нужно картриджи, в которых хранятся DUMPы группы файлов, перенести в Hercules. Я думала, что можно будет сбросить, без RESTORE, на ps файл и далее по аналогии дисков.
можно, при условии что данные правильно переданы. не должно происходить ни преобразований, ни искажений структуры записей (усечение записей, изменение длины, потери границ записей).
Цитата
У меня не проходят ни COPY, ни COPYDUMP в ADRDSSU. ADR331E (001)-CPYD (01), OUTPUT BLKSIZE 58786 FOR DATA SET ON DDNAME OUT IS SMALLER THAN INPUT BLKSIZE 65520
опишите подробнее процесс переноса. на устройстве какого типа были расположены наборы данных, дампы которых Вы пытаетесь загружать? как выглядит задание на восстановление ADRDSSU? как выглядело задание, которым эти наборы данных были выгружены на картриджи (если это возможно, конечно)
Сообщение отредактировал Gregory - Пт, 17.06.2016, 18:09
фалы сбрасываются на ленту группой с помощь программы, которая на самом деле вызывает ADRDSSU Dump
понятно. В результате выполнения выгрузки на ленте Вы получаете наборы данных RECFM=U. Как Вы загружаете их на диск и как переносите полученный набор данных на PC? Диски у Вас все 3390?
Сообщение отредактировал Gregory - Пн, 20.06.2016, 11:40
Здравствуйте. Обычно их восстанавливают программой , тоже вызывается обычный restore ADRDSSU. Повторяюсь, мне нужно без восстановления ленту перенести в Геркулес. Попытка загрузить на диск с помощью COPYDUMP из ADRDSSU не увенчался успехом. Ругается на blksize, а на выходе в Dummy "копирует". диски 3390-9 на PC я обычно через blueZone скачиваю в binary режиме.
Добавлено (20.06.2016, 14:11) --------------------------------------------- ADR006I (001)-STEND(01), 2016.172 14:07:31 EXECUTION BEGINS ADR331E (001)-CPYD (01), OUTPUT BLKSIZE 58786 FOR DATA SET ON DDNAME OUT IS SMALLER THAN INPUT BLKSIZE 65520 ADR324E (001)-CPYD (01), THE VOLUME/DATA SET SPECIFIED BY DDNAME OUT HAS BECOME UNUSABLE
откуда он берет 65520, если на входе описано 32000, не пойму? почему с таким blksize пытается копировать?
Добавлено (20.06.2016, 14:54) --------------------------------------------- HOMEP ИMЯ HAБOPA DAHHЫX KOЛ_BO DЛИHA DЛИHA ФOPMAT D A T A ПPИЗHAK * ПOKOЛEHИЯ * TOM HOMEP HAБOPA БЛOKOB БЛOKA ЗAПИCИ БЛOKИP COЗД. ГOДH. ЗAЩИTЫ HOMEP BEPCИЯ HAЧAЛA TOMA .0001...G0213130 ..003902..00000..00000..U. ...014349.000000...0.... ... ....................
Добавлено (20.06.2016, 14:55) --------------------------------------------- задала в IN LABEL=(1,BPL), закончился кодом 24: ADR006I (001)-STEND(01), 2016.172 14:47:46 EXECUTION BEGINS ADR351E (001)-MIO (01), UNEXPECTED END OF FILE ON DDNAME IN
на PC я обычно через blueZone скачиваю в binary режиме.
если можно, подробнее. Если Вы скачиваете набор данных в файл, то при этом происходит потеря границ записей, а это необратимое искажение данных. Выгрузите набор данных TRANSMIT (XMIT) или AMATERSE, перенесите полученный набор в файл, а затем восстановите оригинальный набор данных.
Цитатаmentor ()
откуда он берет 65520, если на входе описано 32000, не пойму? почему с таким blksize пытается копировать?
полагаю, это результат некорректного переноса данных...
мне нужно получить м\л на геркулесе, так же, как и диски. Если диски сначала Dumpируем, потом преобразуем в aws формат, затем в геркулесе восстанавливаем restore, то как быть с м\л, в которые сброшена информация с DUMP, и в таком виде мне нужно их получить в Геркулесе? у меня дело до передачи м\л в ПК не доходит еще.
а, так это Вы пытаетесь с реального картриджа на диск восстановить на реальной машине? хорошо бы на задание посмотреть, потому что вызывает вопросы не только значение 65520, но значение 58786, ведь справка говорит о размере блока 14349.
Цитатаmentor ()
задала в IN LABEL=(1,BPL), закончился кодом 24:
если это лента со стандартными метками (SL), то (1,BLP) это как раз метки (VOL1+HDR1+HDR2), тогда уж (2,BLP). Принципиально возможно и IEBGENER скопировать набор данных с ленты на диск, но интересно выяснить почему COPYDUMP не дает желаемый результат.
Сообщение отредактировал Gregory - Пн, 20.06.2016, 17:25
Gregory, мой опыт общения с МФ мне подсказывает, что собака может быть зарыта совсем в другом месте, а не в blksize. Зачастую сообщения вообще не соответствуют действительности. однажды, система ругалась непонятно на что, оказалось, что на диске места не хватает. Когда сделала многотомный набор, все сообщения пропали. мое задание:
//DASDDUMP JOB // SET HLQ=HERCULES // SET DHLQ=HERCULES.DUMP // SET TAPE=02131C // EXEC PGM=ADRDSSU
//** КОПИРОВАНИЕ ЛЕНТ //SYSPRINT DD SYSOUT=* //IN DD DSN=G0213130, // DISP=(OLD,KEEP), // UNIT=3480,VOL=SER=&TAPE, // LABEL=(2,BLP),DCB=(BLKSIZE=32000) //*UT DD DUMMY //OUT DD DSN=&HLQ..W&TAPE,UNIT=SYSDA, // DISP=(NEW,KEEP),VOL=SER=HERCUL, // SPACE=(TRK,(20000,10000)) //SYSIN DD * COPYDUMP INDD(IN) OUTDD(OUT) /* // Я уже пробовала н\д создать предварительно c BLKSIZE 32760. Результат тот же.
Добавлено (21.06.2016, 11:19) --------------------------------------------- ранее я копировала задания, как наборы дампируются на м\л.
Добавлено (21.06.2016, 11:21) --------------------------------------------- результат выполнения: ADR331E (001)-CPYD (01), OUTPUT BLKSIZE 58786 FOR DATA SET ON DDNAME OUT IS SMALLER THAN INPUT BLKSIZE 65520 ADR324E (001)-CPYD (01), THE VOLUME/DATA SET SPECIFIED BY DDNAME OUT HAS BECOME UNUSABLE ADR006I (001)-STEND(02), 2016.173 08:16:05 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2016.173 08:16:05 TASK COMPLETED WITH RETURN CODE 0016
Теперь когда я, наконец-то, понял что Вы хотите сделать, могу сказать что так у Вас не получится... Я считаю, реальный размер блока на картридже 65520, такой размер блока ADRDSSU использует для лент. А размер блока 12349, сообщаемый здесь 0001 G0213130 003902 00000 00000 U 014349 000000 0 K020202A/S1 вряд ли соответствует действительности.
58786 это максимальный блок, который можно записать на том 3390 (если записывать блок как r0, если как r1, то 56664 - константа, которая объявлена в документации IBM). Так что сообщение ADRDSSU совершенно точно описывает происходящее и с помощью COPYDUMP дамп нельзя скопировать на диск. COPYDUMP не позволяет изменить размер блокаю так что ничего не получится. Нельзя также скопировать этот набор данных с помощью ICEGENER и других утилит, так как все они используют методы доступа для чтения ленты, а в таком случае размер блока ограничен 32767.
Вам нужно использовать программу VTT2DISK (файл 533 CBT). Эта программа читает блоки размером 64K и более, преобразуя данные в последовательный набор, моделирующий ленту (AWS). Полученный последовательный набор копируете на PC как binary любым доступным способом (ftp) и описываете как картридж для hercules: 0290 3490 DSSUDUMP.AWS
Сообщение отредактировал Gregory - Вт, 21.06.2016, 13:29
58786 это максимальный блок, который можно записать на том 3390 (если записывать блок как r0, если как r1, то 56664 - константа, которая объявлена в документации IBM).
вот и странно. На самом деле дампирована лента с blksize=32000
потому что при восстановлении такой BLKSIZE задают.
неубедительно. ADRDSSU, скорее всего, его игнорирует.
Цитата
да, с кодом 0
тем не менее я думаю, что результат этого копирования непригоден для восстановления, несмотря на код 0.
Цитатаmentor ()
а формат команды можете написать?
hetinit файл volser
hetinit -h покажет формат команды
P.S. Поясню, почему я так считаю. В отличие от Вашей точки зрения я считаю, что любая стандартная программа z/OS и собственно сам z/OS априори функционируют правильно. Поэтому сообщение ADR331E (001)-CPYD (01), OUTPUT BLKSIZE 58786 FOR DATA SET ON DDNAME OUT IS SMALLER THAN INPUT BLKSIZE 65520 и содержащиеся в нем значения являются для меня более убедительными, нежели все остальное. Следовательно, на этой ленте блоки размером 65520 (> 32K), и программа IEBGENER, как и любая другая программа, использующая методы доступа, скопировать их без усечения не сможет.
Сообщение отредактировал Gregory - Вт, 21.06.2016, 16:39