Новый ГодОтличия во всём и кардинальные. начиная с SQL ( на z/OS он запаздывает ) и кончая администрированием ( это связано с тем что z/OS кардинально отличается от Unix ).

и писать приложения тоже совсем по разному.

например чтобы прочитать сообщение из MQ и записать в DB2
на z/OS придётся использовать Resouce Recovery Service , на Unix -- XA Compilant transaction coordinator


если нет skills в z/OS, то наверно и в db2 for z/OS соваться не следует.
Ну все не так страшно :)
На C/C++(Embedded SQL и ODBC) и на Java(JDBC и SQLJ) можно писать вполне кроссплатформенные программы. Да, компиляция и сборка будет отличаться (для C/C++), ну тут уж специфика системы, никуда не денешься.
Касательно SQL есть книжка, в которой описано что и как использовать в языке SQL, чтобы он работал и там и там.
The SQL Reference for Cross-Platform Development

Если работать с DB2 for z/OS удаленно, как разработчику запросов и удаленных приложений, то о специфике z/OS можно не знать почти ничего.
Если создавать базы данных, то придется немного познакомиться со спецификой использования дискового пространства и файловой системы (STORAGE GROUP, SMS, VSAM, SPACE ALLOCATION и т.п.).
Если же нужно администрирование и прикладное программирование в среде z/OS, тут нужно будет окунуться в мир z/OS "с головой".

Dr. BlezПродолжу...

Можно ли поступить так: поставить на wintel WebSphere, MQ, DB2, что-то там еще... Сваять аппликуху, а потом взять и перетащить все это на system z...

Или так: фронтенды оставить на ASP.NET, а базу перенести на DB2 LUW, потом на DB2 z/OS

На что наступлю?? т.е. как красиво разложить грабли??

Websphere Application Server версии 6.1 и выше для z/OS и MP совпадают практически 100%. Если писать веб-приложение в соответствии со стандартами, то работать будет и там и там.

Websphere MQ версии 6.0 и выше для z/OS и MP тоже во многом совпадают. Отличия могут быть в реализации двухфазных транзакций и допустимых опциях. Внимательно читать руководство по программированию для MQ, избегать опций, специфичных для MP.

DB2 - а вот тут сложнее. Какой версии будет DB2 для z/OS? Будут отличия в SQL, поэтому средства проектирования базы лучше иметь такое, которое сможет сделать общую логическую модель базы и сможет построить SQL-операторы для DB2 for LUW и для DB2 for z/OS, DDL операторы будут отличаться! Ну и при SQL-программировании не забывать консультироваться с книжкой "SQL Reference for Cross-Platform Development".

Вообще базу лучше бы сразу утащить на z/OS. Во избежание лишнего этапа миграции и тестирования. С миграцией MQ и WAS проблем обычно меньше, или нет вообще.

Dr. BlezЧто такое "МР"?
Multiplatform, читай LUW

Новый ГодC MQ проблем есть потому что RRS придётся использовать. И еще в в 6.0 появился на z/OS PCF, только там команды ESCAPE нет. А её очень нужно. Так что можно считать что интерфейс администрирования MQ на z/OS и LUW/iSeries также кардинально различается.
Про RRS:
Можно при сборке компилируемого приложения выбрать модуль линковки CSQBRRSI, чтобы функции MQ (MQCMIT, MQBACK) автоматически транслировались в соотв. функции RRS (SRRCMIT, SRRBACK), что применимо в части приложений.Тогда специально RRS-функции вызывать не нужно. И при этом будут работать двухфазные транзакции.
В общем:
Конечно конкретика будет зависеть от логики приложения. Но, базовые приложения MQ работают боле-менее одинаково. Администрирование в рассмотрение не беру, ибо администрирование и прикладное программирование таки разные задачи.
А если позволяет задача, то почему бы не уйти на более абстрактный уровень, Standalone java -приложение реализовать, или сделать приложение под сервер приложений и пользоваться его сервисами, транзакционностью в том числе.
Не подумайте что рекламирую Java-приложения, но при создании кроссплатформенных приложений Java уже не один раз выручала. Конечно применять ее нужно вдумчиво!

Dr. BlezА вот еще вопросец... Java-приложения на спец. процессоре - это быстро?
Т.е. можно прикладуху на z/OS ваять на Java и не париться?
Спец. проц это тот же центральный проц, только иначе сконфигурированный.
Так что сомневаюсь что на спец. проце Java будет работать шустрее, чем на аналогичном центральном. Но это ИМХО, ибо пока не видел вживую машины с zAAP-процессором.

Прикладные на Java ваять можно. Но! Оптимизировать и еще раз оптимизировать.
И тестировать на производительность регулярно.
Есть целая книжка от IBM по Standalone Java-приложениям.

Насколько будет хватать производительности - будет зависеть от алгоритма программы.
Из опыта эксплуатации, хранимые процедуры на Java работают как минимум не медленнее, а иногда и шустрее, чем аналогичные хранимые написанные на языке SQL. Но это не аксиома. Может быть и наоборот. Еще раз повторю, зависит от алгоритмов!