А кто-нибудь может поделиться примерами удачных миграций на эмуляторы?
вообще говоря, переход на эмулятор - это всегда неудача, потому что компромисс и паллиатив. но если говорить о самых "удачных неудачах", то имеет смысл вспомнить миграцию следующей конфигурации:
IBM 4381 (!!!! модель не помню, два процессора, 32МБ ОП)
IBM DASD 3880/3380
MVS/XA
ADABAS
NATURAL
TSO
на самосборную ПЭВМ.
Получили выигрыш на единичных длинных пакетных заданиях раза в два по сравнению с 4381 и просадку процентов на 30 при запуске около 50 коротких пакетных заданий (была у них такая система, метала этот горох со страшной скоростью).
причем заметил, что явными узкими горлами являются переключение адресных пространств (видимо, эмулятору тяжеловато реализовывать эту операцию, чем больше заданий - тем явно линейно растут накладные расходы эмулятора), и ввод-вывод (когда количество операций превышает некий предел или количество виртуальных томов, к каким мы обращаемся, то производительность падает по экспоненте). однако заказчикам деваться было некуда, остались довольны.
после этого я проверил всю связку на топовом на тот момент сервере Intel IBM, модель не помню, стоял в моей организации на приемных нагрузочных испытаниях. выигрыша по сравнению с самосбором не получил вообще, за исключением того, что порог по вводу-выводу, когда производительность начинает падать экспоненциально, у него выше. остальное все вообще не имеет значения.
Явными узкими горлами являются переключение адресных пространств ...
У меня тоже было такое предположение. ... или же вообще работа с памятью там по архитектуре медленнее...? Однако, повезло как то пообщаться с разработчиками эмуляторов, они относятся к этому скептически. Хотя и объяснить такого поведения систем тоже не смогли. (либо просто я их не понял )...
и как это повлияло? я отношусь к этой идее несколько скептически, и вот почему: упаковка-распаковка треков "на лету", конечно, загружает процессор и память, но в то же время уменьшает объем ввода-вывода, а в Вашем случае, критическим ресурсом процессор не является (10%, как Вы пишете). Кстати, применяете ли Вы "shadow"-файлы?
Код
0A12 3390 Z11V01.cckd sf=z11V01_*.cckd
можно попробовать разместить shadow-файлы на виртуальном RAM-диске
можно попробовать разместить shadow-файлы на виртуальном RAM-диске
мы пробовали, и вообще эффекта не получилось заметного. а вот разжатые диски давали процентов 10 прирост производительности. и при этом (что важно!) на сжатых дисках несколько раз портились тома, а с несжатыми это не происходило. испытывали на актуальной тогда версии Геркулеса 3.01 и 2.17
на сжатых дисках несколько раз портились тома, а с несжатыми это не происходило.
портились необратимо? у меня было несколько раз неожиданное прекращение работы hercules (машина на smart UPS, я написал скрипт для завершения z/OS и hercules при потере питания, но то ли в скрипте ошибки какие-то, то ли он вызывается не всегда). chkcckd -2 успешно чинила образы.
Чинила, но не полностью. Образ открывался и монтировался, туча наборов данных пропадала. По закону подлости, самых нужных (хотя и без закона подлости понятно, что самые нужные - те, с которыми активно работают, и именно они попадают в зону риска в случае аварийного завершения). И пару раз было, что починенный образ был без VTOC. Совсем.
Кстати, применяете ли Вы "shadow"-файлы?Код 0A12 3390 Z11V01.cckd sf=z11V01_*.cckd
можно попробовать разместить shadow-файлы на виртуальном RAM-диске surprised
Если бы знали что это =) При разжатии образов дисков прироста производительности не почувствовали, а тесты кроме восстановления БД Adabas, не запускали...
shadow files Идея shadow files - моделировать образ диска несколькими файлами. Первый файл, содержащий образ диска, в процессе работы не изменяется (и может быть размещен на устройстве read-only), а изменения пишутся в shadow-файл. Эта конструкция вряд ли сильно улучшит производительность, но чрезычайно полезна для обслуживания: в любой момент возможна загрузка без shadow-файлов, то есть откат к предыдущему состоянию. Для одного образа диска поддерживается до 8 shadow-файлов.
в конфигурационном файле Hercules: 0A12 3390 Z11V01.cckd sf=z11V01_*.cckd shadow файлы будут иметь имена Z11V01_1.cckd, Z11V01_2.cckd и т.д. (либо команда sf= в консоли)
в консоли Hercules: sf+ активирует новый shadow-файл sf- { merge | nomerge } деактивирует активный shadow-файл, при этом можно объединить данные shadow-файла с основным образом.
люди добрые подскажите как специалисту который не сталкивался с данными устройствами до этого, есть образы дисков в форматах *.CPK и *.PKC, как мне их включить в Hercules.
продублирую свой коммент #6 отсюда здесь, как мне кажется, он будет уместен в этом топике...
Возможна прямая передача образа тома из Hercules в реальный MF или наооборот, осуществляется она почти одними только стандартными средствами. Общий принцип: - в системе 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.
задание для организации передачи данных между системами: //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
Схема применима для копирования из любого z/OS (OS/390) в z/OS (OS/390) где бы он не работал - под управлением любого эмулятора, в частности, Hercules, или на реальном MF.
Сообщение отредактировал Gregory - Пт, 16.10.2015, 23:12
описанная схема может быть применима для обмена данными двух любых программ, не обязательно dump/restore. требования к программам следующие: - программы должны использовать последовательный метод доступа - BSAM/QSAM; - программы должны открывать набор данных только для ввода или для вывода (INPUT или OUTPUT, INOUT нельзя); - программы не должны использовать позиционирование (NOTE/POINT). это основные требования, при выполнении которых вместо набора данных можно использовать файл fifo.
по идее, одной из сторон обмена может быть не z/OS, а *IX, в частности Linux, но ftp в этом случае должен быть запущен на стороне z/OS.
Интересно!!! Я бы попробовал использовать это для передачи изменений БД и синхронизации их между hercules и MF... Но если говорить о копировании дисков, то мне кажется , что вариант с mfnetdisc как то естественней выглядел: - сформатировал геркулесовский диск - выполнил на MF ADRDSSU copy full на этот диск - подключил его к hercules Конечно, есть там и свои недостатки и ограничения, но как то естественней...? Но IBMу-IBMово .... :)
)...
