Господа, традиционное извинение за серость... В каких средах под z/OS можно программить на Це ? Поятно, что в унихообразе можно. Но я так подозреваю, что боссов больше интересует MVS и CICS ... Там оно есть ?
я писал и выполнял C++-программы в TSO, в чистом пакете и в USS. Без проблем. И более того, у IBM есть вроде средства диалоговой разработки для C++.
А что такое "диалоговая разработка" ? Есть отличный отладчик WebSphere Debuger. (на персоналке по шагам, видя код и переменные) А вот, чтобы писать и тут же компилять, такого нормального ничего нету. Можно извращаться с копированием h-файлов на персоналку и по ftp кидать job на компиляцию, но это все равно не идеал.
Можно конечно обозвать этим ISPF редактор + панельки на вызов компиляции.
В любых. Почему-то распространено заблуждение, что USS есть нечто изолированное в z/OS, что-то особенное... Это вовсе не так - в TSO можно использовать вызовы USS, в USS можно использовать вызовы TSO и т.д. и т.п. ...
Сообщение отредактировал Gregory - Сб, 15.08.2009, 01:47
А это еще надо доказать. Покажите мне ссылку, где одновременно есть слова z/OS and visual development. Вот, что я вижу на сайте: XL C/C++ XL C/C++ is the follow-on successor to our VisualAge C++ compiler line, and is available in versions to support AIX, Linux, z/OS and z/VM.
- Provides an interactive workstation-based environment to help create, maintain and reuse applications for traditional processing or for inclusion in an SOA
- Provides quick and easy access to IBM z/OS datasets and UNIX System Services Hierarchical File System (HFS) / System z File System (zFS) files
- Helps create Assembler, COBOL, PL/I, C, and C++, and Java applications via:
Remote syntax check Content assist Visual BMS mapping and JCL generation capabilities Visual MFS editor Color coded editing
- Support for
CICS IMS Batch DB2 and DB2 stored procedures
- Create, maintain, and debug CICS and IMS system-based code, IMS and Structured Query Language (SQL) statements
- Remote compile generation, build and deployment support
- Integration with z/OS IBM Problem determination tools
File Manager Integration enables access to Keyed Sequence Data Set (KSDS) files from the IBM Rational Developer for System z workbench, including browsing and updating datasets from the workbench; supporting template-driven display of VSAM, PDS Member, and Sequential File data; and supporting large dataset display and edit Fault Analyzer Integration that allows users to browse Fault Analyzer ABEND reports on CICS, IMS, Batch, Java, WebSphere, and other runtimes; view dump selections relating to ABENDs; and annotate reports to share comments with other users who browse the same reports
Windows developmentWindows
-based development and mainframe-emulated development
IBM COBOL for Windows compiler supports development of IBM COBOL applications including compiling, testing, debugging, and deploying to Windows platforms. IBM PL/I for Windows compiler supports development of IBM PL/I applications including compiling, testing, debugging, and deploying to Windows platforms. IBM TXSeries provides CICS support for development of IBM PL/I and COBOL for Windows applications including translating, compiling, testing, and debugging. For deployment, IBM TXSeries for Multiplatforms must be purchased.
О как! Может, это поможет? Хотя чертовски сложно все.
И еще - почти не по теме. По общению с коллегами, активно пишущими, для мэйнфрейма перспективнее на Java или на COBOL. Причем на Java проще.
Круто. Есть надежда. Только у меня нет такого, а хотелось бы услышать очепользователя. Java не шибко шевелится на фреймах. Это если наверно докупить ЗААП (читай целый проц под нее одну), то может быть... Опять же, джава больше для бизнес-логики. А если нужны вещи доступные только в асм-макрах, то проще их в Си запаковывать. (PLX же наружу не дают) Худая корова еще не газель!
Жаба чудовищно медлительна и страшно прожорлива где бы она не жила от мобильного телефона до майнфрейма... Ну разве что ей целый процессор скормить... А если еще к этому добавить несовместимость жаб и наличие зависимости жабы от родного болота (зависимость от платформы на практике не только есть, но и довольно существенна!) то я бы советовал десять раз подумать прежде чем трогать этот террариум :-)
Так и С/С++ тоже дико медленный, я тут потранслировал чужую программу на этом языке. Причем в разных средах. Результат не впечатлил. Так что Ассемблер+Rexx, видимо, навсегда.
Следует знать, что в Си есть куча опций по оптимизации(корявого кода). Поддержка XPLINK(сомневаюсь, что рекс про него слышал). А также SPC - официально признанный годным для системного программирования(не требует LE). Кроме того из того, что я вижу, Си генерирует ассемблер ничуть не хуже чистого. (скажем сложение - это одна AHI и тд). Да, по определению, Си медленне асма, но... потому, что он создает код предусматривающий больше проверок на ошибки + доп возможности. При этом Си выигрывает вчистую в скорости написания программ, нахождения студентов-работников, читабельности кода и тд.
Единственное, что мне не хватает - это аналог trap в REXX, чтобы получать вывод TSO комманд. Как создать его на асме, я тоже не знаю. В итоге если запускать IKJEFT01, то он гад свои DD держит и никому не дает. А если запускать его из под Си, то это требует доп-авторизации самой Си проги + время на раскрутку ТСО на каждый вызов
Ой, забыл добавть, Си оперирует той же логикой, что и асм. Память, указатели. В Рексе - это постоянные переводы в STEM, невозможность мапить память и тд.
в Рексе я люблю только его парсинг...
Худая корова еще не газель!
Сообщение отредактировал XOpen - Вт, 18.08.2009, 13:27
Нет, конечно Rexx не быстрее C. Покажете, где я такое написал? Я вроде написал про связку assembler+Rexx говорил. Что касается оптимизации. Оптимизировано было все, что можно. Включены были XPLINK и поднята опция до O(2) (выше моя версия С не позволила). Все равно по сравнению с С в Линукс на той же платформе было медленнее почти в 2 раза. А кроме парсинга в Rexx есть безтиповые данные и псевдо-хеш за счет использования в массивах в качестве индексов любых символьных данных. В общем, кому что нравится.
Стоп. Разговор шел в пределах одной платформы. Если в z/Linux он быстрее - это круто и интересно, но это не значит, что Си в самом по себе z/OS медленный. (по сравнению с REXX, COBOL, PL и тд)
Могу пофантазировать, что в линуксе нет LE и скорее время теряется на его инициализацию. Нужно чтобы программа выполнялась долгое время. Ну и стандартные вопросы, а что в z/OS в это время работало? Приоритеты? Разрешено ли Си 100% цпу и тд...
А что хорошего в без-типовых данных, если асм имеет типовые. И нет механизма отображения этих данных в нужной мне форме. И надо писать монстров типа M4I=X2D(C2X(SUBSTR(DEVICE.1,25,4))) , тоесть фактически работать с данными как с типовыми.
Могу пофантазировать, что в линуксе нет LE и скорее время теряется на его инициализацию. Нужно чтобы программа выполнялась долгое время. Ну и стандартные вопросы, а что в z/OS в это время работало? Приоритеты? Разрешено ли Си 100% цпу и тд...
Да нет, тут как раз чисто. Все приоритеты в WLM были выставлены куда надо, система пустая, 4 CPU почти простаивает, а один из них под задачу используется на 100%. И про инициализацию LE можно только догадываться - задача идет почти полчаса, в пакете вызывается один модуль, вряд ли там многократно инициализируется что-то, хотя кто знает. Сравнивал С с Паскалем в OS/390 - но давно и не очень корректно. Тоже показалось, что C медленнее, но насколько - не помню. Можно считать злобным домыслом, но на мысль наводит.
Quote (XOpen)
А что хорошего в без-типовых данных, если асм имеет типовые. И нет механизма отображения этих данных в нужной мне форме. И надо писать монстров типа M4I=X2D(C2X(SUBSTR(DEVICE.1,25,4))) , тоесть фактически работать с данными как с типовыми.
А что это вы делаете? Вырезали строчку - и чего? Нафига символы в шестнацетеричный вид, потом - в десятичный? Это все зачем?
Покажите мне ссылку, где одновременно есть слова z/OS and visual development. Вот, что я вижу на сайте: 
Собака быстрее Си стал ? 
