Прямая передача данных возможна, и более того, осуществляется почти одними только стандартными средствами - идея с named pipes реализуема. Общий принцип:
- в системе A создаем named pipe: mkfifo /u/ibmuser/pipe_A
- в системе B создаем named pipe: mkfifo /u/ibmuser/pipe_B
- в системе A выполняем выгрузку образа диска в /u/ubmuser/pipe_A
- в системе B выполняем загрузку образа диска из /u/ibmuser/pipe_B
- связываем pipe_A системы A с pipe_B системы B завершая построение канала передачи данных.

для практической реализации требуется
- программа dump/restore, которая использовала бы QSAM/BSAM для записи и чтения дампа, чтобы для размещения образа можно было использовать файл. К сожалению, ADRDSSU без модификаций (подробнее об этом ниже) не позволяет использовать файл для размещения образа диска. Я использовал программу OFFLINDR (File # 719 Offline DASD Dump/Restore Program from Greg Smith)
- для передачи данных между системами A и B используем ftp.

Итак:
задание для выгрузки:
//DUMP JOB
//DUMP    EXEC PGM=OFFLINDR,PARM='DUMP,cuuA'
//STEPLIB  DD DISP=SHR,DSN=CPAC.LINKLIB
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD PATH='/u/ibmuser/pipe_A',
//            PATHOPTS=(ORDWR),PATHDISP=(KEEP,KEEP),
//            FILEDATA=(BINARY),BLKSIZE=32700,RECFM=U
//

задание для загрузки:
//RESTORE JOB
//RESTORE    EXEC PGM=OFFLINDR,PARM='RESTORE,cuuB'
//STEPLIB  DD DISP=SHR,DSN=CPAC.LINKLIB
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD  PATH='/u/ibmuser/pipe_B',
//             PATHOPTS=(ORDONLY),PATHDISP=(KEEP,KEEP),
//             FILEDATA=(BINARY),BLKSIZE=32700,RECFM=U
//

задание для организации передачи данных между системами:
//TRANSMIT JOB
// EXEC PGM=FTP,PARM='ip_address'
//SYSPRINT DD SYSOUT=*
//NETRC    DD  *
machine ip_address login userid password password
//INPUT    DD  *
lcd /u/ibmuser
cd /u/ibmuser
quote site unixfiletype=fifo
locsite unixfiletype=fifo
get pipe_A pipe_B
//

RESTORE и TRANSMIT стартуем в системе B, DUMP - в системе A

По-видимому, можно использовать и ADRDSSU, если использовать user exit отсюда
File # 880 Extension of ADRDSSU to manage dumps in a network

Схема применима для копирования из любого z/OS (OS/390) в z/OS (OS/390) где бы он не работал - под управлением любого эмулятора, в частности, Hercules, или на реальном MF.

Отличная статья, респект и спасибо автору. Добавлю 3 копейки)
- при описании эмулируемых DASD полезно указывать модель контроллера:
0A00    3390    sysres.cckd cu=3990-6
это необходимо, чобы получать наборы с EF-EA, что, в свою очередь, требуется для DB2 10.

- рекомендую очень компактный freeware эмулятор 3270 wc3270. Не поддерживает графику (GDDM, QMF), но зато поддерживает все остальное а из уникальных функций поддерживает сохранение образа экрана в html, что позволяет получить полностью идентичные оригиналу образы в виде текста, а не графики и тем самым позволяет в разы уменьшить размеры документов с многочисленными образами экранов

-если аварийное завершение все же произошло (например, отключение питания), то перед повторной загрузкой необходимо выполнить проверку и исправление ошибок для всех образов дисков CCKDCDSK:
cckdcdsk -f -2 sysres.cckd

А в заключение вопрос:
А нельзя ли обойтись без дампа диска при переносе томов с реальных 3390 на эмулируемые?
принципиально это возможно - одна программа (автономная или в среде операционный системы) на реальном MF читает дорожку и передает образ дорожки (TCP/IP) другой программе в Hercules, которая этот образ пишет. Для реализации можно было бы попробовать модифицировать IBCDMPRS, например, но более интересной идеей было бы применение чего-либо вроде этого mfnetdisk
Еще одна идея - z/OS FTP поддерживает named pipe (FIFO файл), может быть с этим можно что-то выкрутить и построить pipe для прямой передачи данных?
Никто не пробовал?

   
особенность утилиты такова, что если вы используете shadow files, то их надо проверять ею отдельно, непосредственно указывая в параметрах именно shadow file, сама она их не проверяет, и указать ей в параметрах и основной и shadow невозможно. Ну или я не нашёл.
Я проверяю отдельно. Потому как при использовании shadow ошибки как раз наиболее вероятны именно в них (с ними ведь вся работа идёт).

не затронут вопрос эмуляции ленточных библиотек па TS3500
у меня пока не получилось.
С отдельными лентами проблем нету, но вот чтобы робота...
Возможно, такое в нынешнем дистрибутиве геркулеса просто не поддерживается.

Гриша, думаю, что библиотека - это слишком жирно. это ж надо подхватывать в DFSMS состояние библиотеки по порту управления. почему-то мне кажется, что требует проприетарной, не описанной в Принципах, информации... но может быть я и ошибаюсь...

эх, раньше бы... а то уже своим умишком пришлось
хотя - обходя разложенные грабли вы лишаете себя бесценного опыта!