What System z can do that Intel® can’t

[zVlad]

RTC, как один из продуктов который я сапортю на МФ, мне понравился.

Сыппортите, говорите? Какую вы версию поставили? 4.0.х? Пользователей в количестве больше 10-ти не пробовали запускать?
Про CLM у меня баек накопилось уже достаточно.
....
Удачи!

4.0.2 у нас. Мы только начали и начали очень по уродски в том смысле что наши программисты никогда никого ни о чем таком не просили. Это придумали наши гениальные манагеры чтобы можно было заявлять что наша оутсоурс фирма использует передовые технологии.
Еще смешно было то как решалось куда RTC ставить - на МФ или не на МФ. Хотелось конечно не на МФ нашему руководству, но когда сказали что для этого надо выделенный сервер, а в случае МФ нет, не надо, тоо выбор был сделан в пользу МФ.
И вот RTC на MF стоит и наши программисты что то пытаются из него извлечь. Но проблема в том что наши программисты это лишь небольшой сапорт приложения которое пишет вендор и вендор этот никакого RTC для сапорта не предполагал. Так что понятно уже что ничего хорошего из этого получится в принципе не может или наши должны отказаться от технологии вендора, но это слишком смелО будет для наших, хотя и правильно, и они на это точно никогда не пойдут. Поэтому будет очередной урод рождет, или просто, после отчета что RTC внедрен все вернется на то что было.

[zVlad]

....
В отличии от других кампаний ИБМ-у было что хоронить. Я например был очень обескуражен тем что был снят VisualAge for Smalltalk в угоду Java, ну и что теперь? умирать по Вашему надо.

А за OS/2 скорее надо не ИБМ винить, а больше Микрософт, как впрочем и за Lotus тоже. Надеюсь не надо обяснять почему.

я рад что айбием может себе позволить профукать два отменных продукта, и при этом найдутся фаны готовые оправдать айбиэм и свалить вину на конкурентов.

мне то от этого не легче

В отношении к OS/2 Микрософт не совсем конкурент был по началу, скорее партнер, и даже создатель. Партнер пославший лесом второго партнера (ИБМ) и действительно замечательный продукт, который иначе сделал бы ИТ совершенно другим чем сейчас.

Не знаю какое у этому можете иметь отношение Вы, объясните.

ну как какое, я ведь инвестирую время и деньги как свои так и клиентов в эти технически грамотные, _востребованные_ технологии. А в результате у айбиэм оказывается что собственная траектория развития противоречит выживаемости этих продуктов. Почему? фиг знает, логику не виду. И они не продают их, не опенсорсят, но тихой сапой хоронят.

В результате я потерял деньги, время и репутацию.

Зачем же мне в будущем поощрять такую компанию своим доверием? Fool me once...

Нисколько не оправдывая ИБМ за OS/2 я все таки должен рассказать Вам что будучи в аналогичной ситуации как ВЫ (много лет назад) я имел и использовал один и тот же набор продуктов ИБМ для некой ИТ в OS/2 и в Windows 95. T.e. иными словами, мои клиенты не могли пострадать от отказа ИБМ развивать OS/2. Кстати OS/2 не был убит в прямом смысле. Я не знаю что с ним сейчас, но довольно долгое время он поддерживался этузиацтами. Мог бы и доо сих поддерживаться, но видимо этузиастов оказалосьмало.
Тоже самое можно сказать и о SmallTalk.

[rzen]

Нисколько не оправдывая ИБМ за OS/2 я все таки должен рассказать Вам что будучи в аналогичной ситуации как ВЫ (много лет назад) я имел и использовал один и тот же набор продуктов ИБМ для некой ИТ в OS/2 и в Windows 95. T.e. иными словами, мои клиенты не могли пострадать от отказа ИБМ развивать OS/2.

как это не могли? Ваша очередь объясниться.

[zVlad]

.... Пользователей в количестве больше 10-ти не пробовали запускать?
Про CLM у меня баек накопилось уже достаточно.
Хотите, например, расскажу как устанавливаются патчи на данный продукт (например, с х.х.х.0 на х.х.х.1)? Сокращенный вариант (реальные инструкуции занимают несколько страниц):
1. Задеплоить новую "instance" продукта версии х.х.х.1
2. Скопировать конфигурацию каждого приложения (только для RTC - это 2 приложения, всего в CLM - 4) из "instance" х.х.х.0 в "instance" х.х.х.1 - этот процесс выполняется наполовину в ручную (копирование и правка конфигурационных файлов), наполовину с помощью скриптов.
3. Накатить update на базы данных (новые таблицы и/или новые поля - это для пача!!!). Только для RTC - это 3 базы, всего в CLM - 4) .
4. Убедиться, что все работает и снести "старый" instance приложения (для WAS это возможно только при наличии дополнительного instance application server. Иначе частичный uninstall надо делать после шага №1).

Это я к тому, что такой подход возможен, когда речь идет о каком-либо in-house приложении (которое надо установить только 3 раза - в TEST, PROD, and DR), или даже не о продукте, а прототипе разработки стартапа на этапе поиска финансирования.
Но когда это уже 4-й major release продукта от IBM, который на рынке уже пять лет, и ориентирован на корпоративных клинетов, то это наталкивает на определенные мысли.
....Удачи!

Я пока не делал патчи - мы только только установили RTC. Но я все равно не понимаю Ваших возмущений. Работа по установке патчей и переходов на новые версии всегда с одной стороны не тривиальна, а с другой не бином Ньютона и как правило описана вендором и им же протестированна. Мне приходилось это делать несчетное количество раз для z/OS, DB2 for z/OS и других продуктов и я никогда не возмущался тем чтоо этот процесс не происходит сам сабой, а надо прикладывать к этому и руки и мозги.

Много лет я поддерживаю свой, in-house, продукт для DB2. С каждой новой версией DB2 мне приходится засучать рукова и копаться в том что написано пусть мной, но много лет назад. Это наша работа. Как можно от нее открещиваться. Тоже примерно самое, только проще, когда продукт написан не тобой а кем то другим. Выполнил формальные процедуры акуратно и установил патч или новуы версию. Если Вы хотите чтобы упгрэды RTC проходили так же как upgrade Adobe Acrobat, или Media Player, то Вы похоже недопонимаете чего то, уж извините за рескость.

Кстати у меня RTC посажен в WebSphere в конфигурации Deployment Manager, так что с AS мне проще будет управляться. Придет патч я обязательно учту Ваш опыт и постораюсь что-нибудь сделать иначе (есть идеи, но пока рано) и расскажу Вам, если конечно до патчей дело дойдет.

[zVlad]

Нисколько не оправдывая ИБМ за OS/2 я все таки должен рассказать Вам что будучи в аналогичной ситуации как ВЫ (много лет назад) я имел и использовал один и тот же набор продуктов ИБМ для некой ИТ в OS/2 и в Windows 95. T.e. иными словами, мои клиенты не могли пострадать от отказа ИБМ развивать OS/2.

как это не могли? Ваша очередь объясниться.

Очень просто - все что я им написал легко транспортировалось в Windows. Более того, тогда у меня было два клиента и один из них имел только Windows. Я писал код обоим сидя в ОS/2. На VigualAge for SmallTalk и DB2.
Вы драматизируете или делали что то уникальноe в OS/2.

[uncle_Pasha]

Много лет я поддерживаю свой, in-house, продукт для DB2. С каждой новой версией DB2 мне приходится засучать рукова и копаться в том что написано пусть мной, но много лет назад. Это наша работа. Как можно от нее открещиваться. Тоже примерно самое, только проще, когда продукт написан не тобой а кем то другим. Выполнил формальные процедуры акуратно и установил патч или новуы версию.

Вы, похоже, действительно не понимаете, либо не либо невнимательно читаете.
Проблемы в данном случае по меньшей мере две:

1. Я упомянул об изменениях структуры базы при выпуске минорного патча. Это, вообще говоря, по меньшей мере questionable release management practice. И уж тем более, странно видеть это у команды разрабатывающей линейку продуктов, которая предназначена для application lifecycle management.
Тоже самое происходит у них и с поддержкой:
- ребята, у вас тут бага...
- Да? Действительно... Но для фикса вам надо будет проапгрейдиться на следующий major release...

2. В упомянутом списке процедур нет ничего, что нельзя было бы автоматизировать (и на самом деле автоматизируется, но уже клиентами). Почему для данного продукта это не сделано IBM?

Если Вы хотите чтобы упгрэды RTC проходили так же как upgrade Adobe Acrobat, или Media Player, то Вы похоже недопонимаете чего то, уж извините за рескость.

Да, я этого хочу, и не вижу никаких тому препятствий.
Тем более, если вы заметили, в данном случае речь шла не об upgrade, а о минорных патчах.
Исторически, тот же Rational такого себе никогда не позволял (точнее, подобное было лишь единожды при 7.0->7.1, ввиду перехода на IBM Installation Manager), хотя продукты у них были, пожалуй, посложнее RTC.

Удачи!

[rzen]

Нисколько не оправдывая ИБМ за OS/2 я все таки должен рассказать Вам что будучи в аналогичной ситуации как ВЫ (много лет назад) я имел и использовал один и тот же набор продуктов ИБМ для некой ИТ в OS/2 и в Windows 95. T.e. иными словами, мои клиенты не могли пострадать от отказа ИБМ развивать OS/2.

как это не могли? Ваша очередь объясниться.

Очень просто - все что я им написал легко транспортировалось в Windows. Более того, тогда у меня было два клиента и один из них имел только Windows. Я писал код обоим сидя в ОS/2. На VigualAge for SmallTalk и DB2.
Вы драматизируете или делали что то уникальноe в OS/2.

ничего уникального не требуется, много бизнесов закупились os/2 и остались без поддержки и без будущего, как вы точно сказали на голом энтузиазме.

ещё хуже дело с лотус нотусом. люди инвестировали массу времени, вышли на уровень экспертов, компании вложили массу сил и средств в создание инфраструктуры и в конце концов вынужденны выбросить down the drain.

драматизирую? i dont think so..

[zVlad]

Много лет я поддерживаю свой, in-house, продукт для DB2. С каждой новой версией DB2 мне приходится засучать рукова и копаться в том что написано пусть мной, но много лет назад. Это наша работа. Как можно от нее открещиваться. Тоже примерно самое, только проще, когда продукт написан не тобой а кем то другим. Выполнил формальные процедуры акуратно и установил патч или новуы версию.

Вы, похоже, действительно не понимаете, либо не либо невнимательно читаете.
Проблемы в данном случае по меньшей мере две:

1. Я упомянул об изменениях структуры базы при выпуске минорного патча. Это, вообще говоря, по меньшей мере questionable release management practice. И уж тем более, странно видеть это у команды разрабатывающей линейку продуктов, которая предназначена для application lifecycle management.
Тоже самое происходит у них и с поддержкой:
- ребята, у вас тут бага...
- Да? Действительно... Но для фикса вам надо будет проапгрейдиться на следующий major release...

2. В упомянутом списке процедур нет ничего, что нельзя было бы автоматизировать (и на самом деле автоматизируется, но уже клиентами). Почему для данного продукта это не сделано IBM?

......

Удачи!

Я не знаю таких понятий "минорный" патч и "major release". Для меня есть просто патчи и релизы, которые в свою очередь состоят из патчей. Так у нас в z/OS это устроено. Если кроме того чтобы патч был внедрен нужно что-нибудь поделать руками или подумать и поделать или не делать ничего, то такой патч идет в состоянии "задержан" и я прежде чем его внедрять читаю сопроводиловку к нему и решаю что мне делать или ничего делать не надо. Если там будет написано что надо что-то поменять (например в структуре БД, или новые фолдеры создать в файловой структуре), то просто меняю и создаю.

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

RTC- это приложение юниксовское и ве нем воплащены юниксовые подходы. Юниксовские подходы это отсутствие каких либо стандартных подходов вообще. Каждый вендор лепит что-нибудь свое. По другому обстоят дела у того же ИБМ, но, например, в z/OS. Поэтому Ваши претензии не к ИБМ (я их вовсе не выгораживаю), а к тем юнисксовским разработчикам которые работают в ИБМ и их манагерам естественно. Я за годы работы и в Юниск и в MVS (оба - это z/OS) это прекрасно понял и не ожидаю от юниксовского приложения многого кто бы ни был его создателем, IBM ли, Ventyx ли или кто еще. Но как уже говорил RTC для меня пока приемлен без особых претензий, в плане установки и кастомизации.

[uncle_Pasha]

RTC- это приложение юниксовское и ве нем воплащены юниксовые подходы. Юниксовские подходы это отсутствие каких либо стандартных подходов вообще. Каждый вендор лепит что-нибудь свое.

К вашему сведению: серверная часть RTC - это Web container + backend database. К UNIX это не имеет никакого отношения. Т.е. абсолютно.
Эта команда вышла из OTI - канадские студенты, в свое время переписывавшие VisualAge со Smalltalk на Java (aka VisualAge Micro Edition), впоследствии легший в основу Eclipse.
Эта команда уже сумела похоронить несколько продуктов доставшихся IBM по наследству.

Удачи!

[zVlad]

RTC- это приложение юниксовское и ве нем воплащены юниксовые подходы. Юниксовские подходы это отсутствие каких либо стандартных подходов вообще. Каждый вендор лепит что-нибудь свое.

К вашему сведению: серверная часть RTC - это Web container + backend database. К UNIX это не имеет никакого отношения. Т.е. абсолютно.
...
Удачи!

A Web container то в воздухе что ли висит? В какой по-Вашему операционной среде он исполняется? Или Вы скажите что это Java? Тоже самое я отвечу и по поводу Java.
backend database тоже может быть и DB2 for z/OS и DB2 LUW. Не так ли?

[flip_flop]

..... А давайте наоборот, я не буду приводить ссылки от божественного Интела, а Вы не будете приводить ссылки от обожествляемого ИБМ, ок? ....

А давайте не будем давайте. Давайте ... давайте ... Давайте ... давайте ... И давайте ... Давайте ... Давайте?

Давайте не будем "давайте не будем ... И давайте (N раз) ". Черт, опять звучит как "давайте". Ок, не давайте. Снова не то. Чудна логика. Вообщем, "я больше НЕ БУДУУУ!!!" (ушел в угол)

..... Если есть общепризнанные тесты - давайте обсудим их, если нет - аналитиков от не-ИБМ. Еще бы лучше своими словами на основе данных от независимых источников. Или без данных от ИБМ никак?

А что этого мало было здесь приведено мной? А что разве кого-нибудь хоть как-нибудь поколебал мой более чем 30-ти летний опыт работы на МФ. Разве мало было рассказано мною о том как один наш клиент ушел с МФ и что из этого получилось. Я описывавал это прямо из того места где это происходило, без каких-либо посредников. Хоть как-то те мои данные Вас лично поколебали? Я думаю что никак.
Т.е. остается вывод Вам и без данных "все ясно". А вот это вот хуже, гораздо хуше, чем пресловутое и много раз объясненное отсутствие "данных от независимых источников".

Одиночные факты не убеждают. Декларация большого опыта сама по себе не убеждает, она лишь привлекает больше внимания к словам, типа - "встречают по одежке". Нужны аргументы независимые от личности их приводящего. Интересно, что аргументы в пользу МФ от Вас и от независимых аналитиков действительно меняют мнения. Например я изменил в лучшую сторону вопрос надежности МФ, несмотя на очень печальный практический опыт работы на наших отечественных аналогах. Так что аргументы убеждают. Но всё таки независимые данные тоже нужны, "в числа мы верим". Впрочем, это многократное дежа-вю.

[uncle_Pasha]

RTC- это приложение юниксовское и ве нем воплащены юниксовые подходы. Юниксовские подходы это отсутствие каких либо стандартных подходов вообще. Каждый вендор лепит что-нибудь свое.

К вашему сведению: серверная часть RTC - это Web container + backend database. К UNIX это не имеет никакого отношения. Т.е. абсолютно.

A Web container то в воздухе что ли висит? В какой по-Вашему операционной среде он исполняется? Или Вы скажите что это Java? Тоже самое я отвечу и по поводу Java.
backend database тоже может быть и DB2 for z/OS и DB2 LUW. Не так ли?

Казалось бы, при чем здесь UNIX?

Удачи!

[zVlad]

Казалось бы, при чем здесь UNIX?

Удачи!

Причем здесь тогда вообще операционные системы, так что ли?

[uncle_Pasha]

Казалось бы, при чем здесь UNIX

Причем здесь тогда вообще операционные системы, так что ли?

Тогда уж вните МФ - вы же джаву на нем запускаете, не так ли? Значит, по вашей же логике, в RTC воплощены мейнфреймные подходы.

Удачи!

[zVlad]

Казалось бы, при чем здесь UNIX

Причем здесь тогда вообще операционные системы, так что ли?

Тогда уж вните МФ - вы же джаву на нем запускаете, не так ли? Значит, по вашей же логике, в RTC воплощены мейнфреймные подходы.

Удачи!

Нет у меня такой логики. Да и не виню я ничего. Я лишь констатирую сложившиеся отбстоятельства согласно которым есть юниксовские подходы, воплощенные в том числе и на МФ, и есть классические МФ подходы, по недоумию ставшие "немодными".

[Мальчик-Одуванчик]

у IBM были неплохие лаптопы и жесткие диски
просрали

[Epi]

Интересно вас все же читать! Сначала:

Они еще много чего прикупили с той же целью. Например, Rational.

А что не так с Rational? Я как раз недавно закончил установку RTC на МФ и им только начали пользоваться.
С той же целью значит похоронить, так по-Вашему?

На следующей странице:

Поэтому будет очередной урод рождет, или просто, после отчета что RTC внедрен все вернется на то что было.

[zVlad]

Интересно вас все же читать! Сначала:

Они еще много чего прикупили с той же целью. Например, Rational.

А что не так с Rational? Я как раз недавно закончил установку RTC на МФ и им только начали пользоваться.
С той же целью значит похоронить, так по-Вашему?

На следующей странице:

Поэтому будет очередной урод рождет, или просто, после отчета что RTC внедрен все вернется на то что было.

Вы хотите сказать что нашли противоречие? На самом деле его нет. Если Вы прочитаете еще раз внимательно то поймете что в первый раз речь идет о собственно продукте, а второй раз о его внедрении в нашей фирме. Вот об этом самом внедрении я и говорил "урод". Продукт здесь вовсе не причем.

[zVlad]

Сегодня говорил с колегами по команде которые работают на другого клиента - крупная фирма по распределению электоэнергии. Клиент этот переводит приложение с МФ на Юникс/Оракл. МФ был двухпроцессорным z9 N02 s 214 MIPS-ами под production i z9 A01 s 26 MIPS-ами под ДР и development.
Спрашиваю на какие сервера переходят. Отвечают, не знаем, нам не говорят, но проект дилжен был закончится в октябре 2012 и по ходу тестирования выяснелось что начальные параметры серверов были занижены и пришлось их докупать. Было сказано что вместо 110 активных юсеров на тех серверах могли потынуть только 10. Предположение теам леад-а который хорошо знает клиента это 6-8 многопроцессорных AIX серверов

[rzen]

сервер не потянул 10 юзеров?! не верю. детали в студию. никакой современный комп (вообще любой, включая телефоны) не сможет подавиться десятью юзерами. либо у них там _серьёзные_ проблемы с архитектурой софта.

[uncle_Pasha]

Предположение теам леад-а который хорошо знает клиента это 6-8 многопроцессорных AIX серверов

У меня есть подозрение, что когда какое-то приложение мигрируют с МФ, то имеется ввиду, что на самом деле создается новое приложение - такое все из себя с Web развесистыми сервисами и пр, и проблемы производительности в данном случае к платформе не имеют никакого отношения.
С другой стороны, я вам уже рассказывал о попытке мигрировать приложение на WAS на zOS - идея провалилась именно ввиду проблем с производительностью. Но там миграция была 1:1 - с той же версии WAS только на UNIX.
Каковы могут быть причины использовать AIX - это для меня загадка (точнее, понятно, что IBM опять впарили менеджменту очередное абсолютно неконкурентноспособное г). Если ползти в сторону UNIX, то имеет смысл либо на Linux, либо на Sparc Solaris, IMHO.

Удачи!

[zVlad]

сервер не потянул 10 юзеров?! не верю. детали в студию. никакой современный комп (вообще любой, включая телефоны) не сможет подавиться десятью юзерами. либо у них там _серьёзные_ проблемы с архитектурой софта.

Это то что мне сказали вполне вменяемые люди. И еще раз - новая конфигурация хранится в секрете по крайней мере от МФ-ков. Те МФ-ки на самом деле канадцы и им по барабану - это я любопытный .

[rzen]

Согласен с пашей, кто то кому то что то впаривает. Железо тут ни при чем.

[zVlad]

Предположение теам леад-а который хорошо знает клиента это 6-8 многопроцессорных AIX серверов

У меня есть подозрение, что когда какое-то приложение мигрируют с МФ, то имеется ввиду, что на самом деле создается новое приложение - такое все из себя с Web развесистыми сервисами и пр, и проблемы производительности в данном случае к платформе не имеют никакого отношения.
С другой стороны, я вам уже рассказывал о попытке мигрировать приложение на WAS на zOS - идея провалилась именно ввиду проблем с производительностью. Но там миграция была 1:1 - с той же версии WAS только на UNIX.
Каковы могут быть причины использовать AIX - это для меня загадка (точнее, понятно, что IBM опять впарили менеджменту очередное абсолютно неконкурентноспособное г). Если ползти в сторону UNIX, то имеет смысл либо на Linux, либо на Sparc Solaris, IMHO.

Удачи!

В данном случае о котором я сказал сегодня это так - новое приложение развернуто и данные мигрируются с МФ на тута.

О я рассказывал и о другом клиенте который мигрировал одно и тоже приложение с МФ на АИХ сервера с Оракл. Количество серверов в том случае не было секретом и я о них докладывал здесь. Их тоже было слишком много.

Интересно, удалось ли понять почему в Вашем примере случилась неудача? какими были параметры сервера на Юникс и какие были у МФ на который делался перенос. Без этого невозможно ничего сказать.

[Alexander Troyansky]

сервер не потянул 10 юзеров?! не верю. детали в студию. никакой современный комп (вообще любой, включая телефоны) не сможет подавиться десятью юзерами. либо у них там _серьёзные_ проблемы с архитектурой софта.

Вы зря не верите. Я в своей лабе частенько провожу нечеловеческие эксперименты -- по работе приходится нагружать системы не по-детски. Так вот у меня довольно-таки неплохо получается парой-тройкой тяжелых тестовых процессов опрокинуть пару AIX вёдер с болтами (сервер приходится перегружать). Такие фокусы даже с HPUX IA не проходят, не говоря уже про всякую шваль типа Винды, Солярки и Линуха.

Я было попросил память увеличить на одной AIX, ну 8 GB добавить. ИТ наш посмотрел на цену:
8GB Kit (4GBx2)
• Part #: CT788754 - $1425.99

и естественно жестоко меня послал.