Уважаемые господа, нужны Ваша коллективная компетенция и аргументы "за или против" ОС zVM, по сравнению с zOS, для реализации крупного Проекта. Начну с плюсов zVM: IFLs не требует оплаты, более удобная среда для проектирования софта, проект хорошо декомпозицируется на VM's, удобный Linuх... Из минусов: - фактически нет VSAM, VM - однозадачная среда, ... Среди вопросов: - как работает и полный ли функционал у DB2/IMS на VM? Как реализовать полный мультидоступ к БДs на VM? Хорошо бы выслушать аргументы как адептов использования VM (если такие есть), так и противников VM (например, услышать Давида) как, почти, полноценной ОС (с гипервизором всё понятно) в Проектах.
Здравствуйте. Мне не совсем понятно что именно Вы предлагаете сравнивать. zVM - гипервизор, и его можно сравнивать с PR/SM (поддержка LPAR), и существует множество статей, сравнивающих zVM и PR/SM, но использовать только zVM для разработки проекта Вы не можете, нужна операционная система. Какая? CMS? GCS? zLinux? z/OS? Если Вы рассматриваете z/OS или zLinux, то zVM для Вас совершенно не принципиален, это просто более удобная среда разработки, для эксплуатации Вы можете обходится и без него. Если же рассматривать CMS vs. z/OS или CMS vs. Linux, то, IMHO это все же разные весовые категории. Да, существуют проекты, реализованные в CMS, как и существуют модификации CMS в сторону мультизадачности, и можно рассматривать GCS, но все же как мне кажется, это, прежде всего инструментальные среды разработки. Возможно, я не прав. Мне всегда очень нравился и сейчас очень нравится zVM/CMS, но рассматривать zVM/CMS как производственную среду я бы все же не стал, а вот использовать CMS для разработки проекта в z/OS мне представляется очень даже удобным. Во всяком случае, CMS в качестве среды разработки выглядит куда как лучше, чем какие-нибудь zowe или RDz. Разработка в подобных средах, по-моему, не что иное, как футбол в инвалидных колясках, уж просите меня за отсутствие политкорректности...
Сообщение отредактировал Gregory - Чт, 06.08.2020, 21:10
Возможно, я нахожусь в терминологическом "плену", но говоря о zVM я, конечно, имел ввиду CMS (но не о CP же говорить). Говоря о CMS, меня (да я, думаю, не только меня) всегда преследовало неявное убеждение о некой её "ущербности" перед zOS/MVS, хотя опыт работы на ранних версиях CMS говорил об обратном. Скажу даже так, не столько CMS удобная среда, сколько тяжеловесна и непрактична zOS (где JCL - вершина маразма(сразу извиняюсь за свою"неполиткорректность")) в сравнении с CMS. Собственно, поэтому и возник вопрос, а почему в нашем сознании укоренилось мнение об ущербности CMS? Да, мы все знаем, что zVM тестируется хуже, а разработкой занимаются наши с индийцами, что, конечно, не приносит ей "лишних очков", тем не менее, отбросив собственные ощущения, хочу спросить - в чем конкретно zVM не дотягивает до zOS? Однозадачность CMS - не очень большая проблема, её обойти можно архитектурой проекта, ощибок в ZVM не сильно больше, чем zOS. Конечно, наработок в сети под CMS сильно меньше, чем под zOS, зато и разработка в CMS, по-моему мнению, процентов на 30-40 быстрее, даже HLASM в CMS проще и менее строг к разработчику. По моему мнению, такой прием, как запуск zVM под zVM открывает интересные возможности для разработчика и ничего похожего в zOS нет. Кстати, с двумя последними Вашими предложениями я полностью согласен. Жду "убийственных" аргументов против zVM/CMS (если они есть).
не столько CMS удобная среда, сколько тяжеловесна и непрактична zOS (где JCL - вершина маразма)
полностью согласен с Вами. Конечно, z/OS и прежде всего, JCL связаны совместимостью, и JCL все-таки развивается - и 50 лет не прошло, как появилась подстановка параметров в данные) но, тем не менее, монстрообразность имеет место быть. Как вариант, Вы можете рассматривать z/OS как некий Unix, и вести разработку, как в Unix, использовать telnet и ничего не знать ни о tn3270, ни о JCL, ни о TSO. А "убийственных" аргументов против zVM/CMS от меня Вы не получите, потому что я их не вижу) Как Вы, наверное, знаете, VM никогда не являлся флагманской OC у IBM не по техническим, а по политическим соображениям.
Сообщение отредактировал Gregory - Сб, 08.08.2020, 21:55
Gregory, да, вспоминаю программы на ASM по примитивной обработки параметров в JCL..., а предложенный Вами вариант использования zOS, как Unix для меня несколько экзотичен (надо подумать!), но пока душа лежит к CMS (если не получу от сообщества серьезных противопоказаний) и, возможно, придется использовать zOS и RHEL. И, конечно, использование zOS хотелось бы минимизировать до "нуля". А политику IBM, мне кажется, сама IBM, вряд-ли, до конца сможет объяснить.
Добавлено (10.08.2020, 00:13) --------------------------------------------- AKonev, скажем так, сам проект связан с мониторингом различного транспорта на больших территориях. Большего сказать не могу, так как проект до конца еще не согласован.
Сообщение отредактировал Maint - Пн, 10.08.2020, 00:15
сам проект связан с мониторингом различного транспорта
Получается, что нужна БД и судя по всему немалых размеров и реактивная. Так что дорога в zVM/CMS вам противопоказана будет. Или DB2 в z/OS или любая по вкусу в zLinux
Сообщение отредактировал AKonev - Пн, 10.08.2020, 22:42
AKonev, первый аргумент против zVM. Вопросы: - что конкретно мне мешает использовать DB2 под zVM? -ограниченный функционал DB2 под zVM? -DB2 не поддерживается сейчас под zVM? В конце концов, если всё окажется так плохо, под zVM я смогу использовать связку zOS/DB2 или zLinux/DB2 (правда, не самые лучшие варианты - архитектурно). Более того, очень не хотелось бы использовать в Проекте zLinux в любой форме напрямую или как СУБД (только для вспомогательных целей и сервисов). Прокомментируйте меня плиз.
Сообщение отредактировал Maint - Вт, 11.08.2020, 04:41
Bibizyan, z/VSE существует для поддержания совместимости со старым софтом (S360), что-то новое делать на VSE несколько "стремно" (не смог подобрать более точное слово), тем более среда VSE весьма отличается от z/OS, можно "на автомате" сильно накосячить, а потом придется разбираться с кодом. Так в чем, конкретно, проблемы с z/VM? Уходить в прошлый век в буквальном смысле тоже не хочется. Какие реальные плюсы у z/VSE, она, даже, VSAM только "старый" поддерживает, хотя, конечно, по сравнению, с z/VM это плюс, а не единственный ли это плюс z/VSE?
Сообщение отредактировал Maint - Ср, 12.08.2020, 17:21
z/VSE - вполне себе полноценна и самодостаточная система. У вас не совсем точная, устаревшая информация. Как по мне - если речь о цене, то более чем достойный вариант. Я на VM только как пользователь по большому счёту, поэтому именно про неё мало что посоветую. А вот с z/VSE уже какое-то время работаю, и успел оценить. Про "только поддерживать старый код" - полная ерунда. Накосячить можно всюду. Наш код вполне себе без особых проблем запускался и до сих пор запускается под z/OS. Понятно, что на уровне макро есть отличия, но это легко решается. А так, на 99% - тот же код. Всё, что сегодня пишется под z/OS, спокойно пишется и под z/VSE. Хоть на ассемблере, хоть на Коболе, хоть на PL/1, хоть на Си, всё в рамках LE. Есть REXX, есть CICS, есть TCP/IP, есть поддержка шифрования как данных, так и протоколов. Я не знаю, что такое "устаревший VSAM". Каких опций вам там не хватает? Не устраивает VSAM - можно купить DB2, всё вопрос цены. Мы, к примеру, вполне себе VSAMом обходимся, что намного дешевле. Большие файлы поддерживаются, диски модели 54 поддерживаются. "Что ещё надо, чтобы достойно встретить старость?!" (с)
Сообщение отредактировал Bibizyan - Ср, 12.08.2020, 23:13
Bibizyan, По z/VSE аргументированная позиция, беру таймаут. Про VSAM долго и нудно объяснять, некоторые исторические отличия с MVS были, вполне возможно, что сейчас это не так. Очень хочется еще услышать мнения адептов z/VM.
а предложенный Вами вариант использования zOS, как Unix
Я знаю, как минимум, один достаточно большой проект, реализованный именно таким образом. Ни один из разработчиков никогда не видел эмулятор 3270 с TSO/ISPF.
Рассмотреть z/VSE, как предлагает Bibizyan, вполне имеет смысл. Кстати, VSAM в CMS именно оттуда, но, насколько мне известно, он не транзакционный - в VSAM z/OS есть поддержка транзакций (в виде дополнительного продукта). Вообще к идее использовать VSAM вместо реляционной СУБД я отношусь как к очень разумной. Имеет смысл также задуматься над использованием CICS или IMS.
Я сейчас, наверное, тривиальную вещь напишу - определяющим фактором при выборе среды все же должна быть специфика проекта, как, например, при покупке автомобиля. Если машина используется, чтобы по выходным ездить на дачу, то для этого не нужен Linkoln Navigator и уж тем более не нужен автобус...
Сообщение отредактировал Gregory - Пт, 14.08.2020, 23:22
