В первую очередь хочу по-честному, без подколок, поблагодарить сотрудников российского IBM за очень удачное мероприятие. Вообще такой вот формат завтраков в центре города, когда можно быстро и качественно пообщаться с коллегами за пару часов и успеть на работу, мне очень нравится. Три доклада, приличная еда, знакомые лица, умные слова - что еще нужно техническим специалистам для того, чтобы вынести самые положительные впечатления о мероприятии и при этом не угробить окончательно день? В общем, молодцы. Отличная идея и прекрасная реализация.
О докладах. Все доклады были отличными, экономя силы читателей я не буду повторять это, говоря о каждом докладе отдельно, хотя это лучший из поводов для повторения. Отдельно замечу, что мне особенно нравится то, как уверенно было выдержано время. Я вот так не умею, и поэтому жутко завидую. Андрея Губенков рассказал про аппаратную платформу z13. На смену MCM пришли здоровенные блоки. Машина стала такой шустрой и жаркой, что теперь внутри обязательно имеет жидкостное охлаждение. Лично меня это не особенно радует, потому что в нашей стране если есть где возможность протечь, так обязательно протечет. А еще было забавно увидеть, что на SE теперь ставят не ноутбуки, а полноценные однослотовые сервера. Видимо, надежность ноутбуков уже не та)) или некуда стало девать пока еще IBM-овские сервера, решили утилизировать часть из них таким причудливым способом). Появились новые машинные команды, стало больше оперативной памяти, и вообще “быстрее, выше, сильнее”. Хорошая такая эволюционная корпоративная машинка.
Про программное обеспечение рассказывал Миша Егоров. Хорошо так рассказал, живенько. Вот что я лично вынес из его рассказа, так это то, что ОС уже не просто отстает от возможностей оборудования, а отстает ОЧЕНЬ СИЛЬНО. Мог ли я представить лет пять назад, что память, которую поддерживает zVM будет существенно (на два порядка, между прочим!) меньше базовых возможностей оборудования? А вот тут - на тебе, на машинке может быть террабайт 80 памяти, а zVM дальше террабайта не ходит. Вот не думал, что когда-нибудь такое увижу. Обычно пока новую машину ставили в серию, программисты успевали увеличить ограничения по поддерживаемому оборудованию так, что покрывали возможности оборудования полностью хотя бы по процессору, памяти и адресации ввода вывода. Потом уж могли возится с сетевыми адаптерами и прочим. Так что век живи - век удивляйся.
На сайте уже был анонс технического семинара по новой машине и программному обеспечению 26-27 марта. Там обещают все рассказать в подробностях, битах, байтах, метрах кабеля и количестве вентилей на кубический сантиметр. Приходите, если хочется подробностей.
Если темы первых двух докладов были традиционными, то третий доклад вполне может претендовать на “изюминку встречи”. Адилет Сабырбаев рассказывал о тестировании приложений на платформе z Systems. Им и его командной была сделано хорошая работа, никаких сомнений. И рассказ о ней был очень хорош и аргументирован, все было структурировано, аргументировано и качественно нарисовано. Так что “изюминка” явно состоялась. Но я не понял одну важную вещь: если была поставлена задача выполнить измерение производительности, какого черта разработчики в процессе измерения докручивали приложение и даже платформу этого приложения?... Ведь такие вещи возможны не в процессе эталонных измерений, а в процессе отладки, нагрузочного тестирования и так далее. А после того, как промышленное приложение сдано в работу, на нее написана документация, дальше никаких разработчиков на оценке производительности быть не должно, и приложение настраивают чужие сотрудники по штатной документации, иначе это все - чистой воды подгонка. Единственное, что можно принять во внимание - то, что речь шла о мигрированном приложении, штучном, которое будет устанавливаться и сопровождаться у заказчика теми же специалистами, что его и разрабатывали. Так что я бы скорее говорил не об измерении производительности приложений на z Systems, а о комплексном тестировании и процедуре глубокой отладки с привлечением специалистов IBM. Но, как бы то ни было, работа была сделана прекрасная, и она, безо всякого сомнения, пойдет на пользу и заказчику, и специалистам IBM, и разработчикам. Это ценнейший опыт, который не пропадет.
Со своей стороны не только отмечаю удачный формат встречи и познавательные доклады, но и доброжелательную непринужденную атмосферу, массу знакомых лиц и интересные разговоры в перерывах. Всемерно рекомендую к посещению всем заинтересованным лицам.
Категория: От AKost | Добавил: akost (28.02.2015)
| Автор: Костырко Александр
Без участия разработчика некоторые решения искались бы дольше. Разработчик лучше знает свой код и может пояснить откуда взялись, например, те или иные запросы к СУБД. Поэтому тут речь не о "замере производительности" как таковом, а об оптимизации производительности конкретного приложения на конкретной платформе без изменения прикладного кода этого приложения, т.е. только за счет настроек СУБД, сервера приложений, операционной системы и промежуточного ПО.
Для одного и того же прикладного приложения параллельно тестировались две конфигурации на одинаковом "железе" (т.е. та же физическая машина и дисковая стойка, одинаковый объем CPU и оперативной памяти). Это дало возможность получить сравнительные характеристики работы этого приложения под управлением разных ОС.
В итоге связка z/OS+DB2+WAS показала значительно лучший результат, хотя приложение изначально разрабатывалось и тестировалось на СУБД Oracle.
И основной "посыл" тут даже не в том, что "круче" z/OS или z/Linux, а о том, что комплексная оптимизация может радикально повысить производительность решения, и IBM обладает методиками, специалистами и мощностями для проведения подобных мероприятий.
не совсем верно, или совсем не верно - на выбор. не укладываясь в требования по производительности, разработчик пошёл на, скажем так, интересные нарушения архитектурных принципов, типа привязки ядра платёжной системы к внешним условиям, понимая и признавая, что если внешние условия изменятся, то всё коту под хвост. Так что приложение как раз тщательно допиливалось на предмет уложиться в требуемую производительность. И тем не менее, описанные результаты порождают кучу вопросов своей странностью, но тут лучше пусть art напишет. если захочет. достаточно просто проанализировать выданные результаты. а конечный результат совсем печальный. потом у как "фирменный стиль" поведения вендора заказчику надоел.
По второму тестированию в публичном доступе информации меньше, но я о нем знаю несколько больше, т.к. был одним из участников событий. Мой комментарий описывает только второй сценарий. И там все собственно так и было, естественно, с оговоркой "насколько мне известно".
Собственно, началось то всё намного (или немного) раньше, особенно переписка кода приложения, и тестирования были и до этих. В целом ничего особо не поменялось - на разных этапах выполнялись разные работы, проводились тестирования, для достижения общей цели для заказчика. если закачик другой у другого тестирования - то тогда надо смотреть, что там за задача ставилась, если же тот же что и для первого (и предыдущих) тестирований - то всё грустно. А других заказчиков небыло, да и этот перестал быть хотеть заказчиком, и все работы выполнялись не для него, а для себя.
Женя, как ты понимаешь, задача "повысить работоспособность" от задачи "измерение производительности" сильно отличается многим. В первую очередь - целью и процедурой достижения цели. Если задача стояла "подкрутить приложение, чтобы работало лучше, и померить, насколько хорошо это получилось" - это одно. Это, как мы понимаем, не бенчмаркинг. Но как бы то ни было, была сделана хорошая во всех отношениях работа, как ее ни называй.
Если даже не обращать внимание на замечания в комментариях к статье (некоторые вполне справедливые), то вывод не полный. Почему же не сравнивали сравнимое - cross-memory services не с сетевым, а со сравнимым IPC, в данном случае при использовании JDBC Type 2 это была бы shared memory для Linux? J2EE часто ставится отдельно от СУБД, что есть, то есть, не всегда, но часто (что не делает чести J2EE), но не для замеров времени ответа - глупо измерять время ответа в такой конфигурации. Ставят в такой конфигурации, когда время ответа не существенно с точки зрения бизнеса. Ничто не мешает на нормальном сервере system P, а уж тем более на мейнфрейме, поставить J2EE в ту же ОСь, что и СУБД, и выполнить замер, тем более таких конфигураций и в жизни хватает. Почему заставили ходить через сеть? Обоснования нормального нет.
В статье нет главного для вывода. Вот, например, в TPC важнейший параметр - стоимость выполнения транзакции. Взять да и посчитать лет на 5, или даже 10, если уж это платёжная система, да ещё для такой организации, тем более и организация срок не менее 10 лет эксплуатации отводит. Для конфигурации с z/OS, с zLinux, ну и пусть - с Intel. Ну нету денег на проведения теста на Интел (что странно, не правда ли?) чёрт с ним. Не потому ли, почему IBM не публикует результаты DB2 z/OS в TPC? Потому, что при сравнимой стоимости во всех случаях с неиспользованием z/OS в ту же цену влезет куда как больше железа, то есть стоимость выполнения транзакции в случае DB2 + WAS на z/OS получается самая высокая. Выгоднее окажется в три раза больше впихнуть IFL и сравнять производительность, ещё и экономия на ресурсах будет. Э
Ну уж пассаж про то, что MQ обычно ставится на отдельный сервер в распределённых системах - извините, ну это уже чёрт его знает что. Чаще всего MQ ставится именно в ту ОСь, где СУБД.
А учитывая, что этот тест это всё то же, что и другой, то и задачи корректного сравнения не ставилось, что и показывает конфигурация тестов.
Проблема в том, за каждую конфигурацию отвечала отдельная команда, и, командам нельзя было "подглядывать" в результаты друг друга. При этом у каждой команды была цель показать максимальные результаты на выбранной конфигурации. Почему команда, которая представляла решение "z/Linux+Oracle+WAS" решила разбить компоненты на две системы, тем самым добавив задержек в обработку - неизвестно. Но, это не было инициативой IBM. Да, было бы интереснее сравнительное тестирование в более "совместимых" условиях, командами, которые могли бы обмениваться полученной информацией, но видимо пока никто не заинтересован оплатить такой "банкет".
Разработчики прикладного ПО заявили, что результаты, полученные в связке "z/OS + DB2 + WAS" в настоящий момент являются абсолютным максимумом того, что они вообще получали на разных установках, поэтому, я полагаю "не все так грустно", платформа вполне конкурента. Да, возможно я наивен.
По поводу совокупной и долгосрочной стоимости - нужно считать. Причем не абстрактно, а под конкретную прикладную задачу. Причем только после профилирования (оптимизации) этой задачи на конкретной установке. Если нужно сравнение на нескольких установках - профилирование нужно выполнить на каждой.
Почему команда, которая представляла решение "z/Linux+Oracle+WAS" решила разбить компоненты на две системы, тем самым добавив задержек в обработку - неизвестно.
Ели заказчик был настолько некомпетентен, чтобы допустить такое сравнение... Но мы же знаем, что заказчик вообще ничего не заказывал и это была именно что инициатива IBM Ну хорошо, взяли два взаимодействующих приложения и один раз протестровали взаимодействие через память, второй раз через сеть. Допустим, заказчик так пожелал. Ну сделали, хорошо. Но согласись, выводы в статье надо делать корректнее.
Цитата
настоящий момент являются абсолютным максимумом того, что они вообще получали на разных установках
Это хорошо - максимальная производительность. Тогда - прямая дорога в TPC, то вот беда - там же полное раскрытие пути достижения результата, и подсчёт стоимости за транзакцию. И две эти проблемы как раз и закрывают путь IBM с этими продуктами дорогу к рекордам. Я к тому, что максимальная производительность это отлично, показывает, чего достигла индустрия в целом, но заказчики ориентируются в жизни на множество параметров, и стоимость транзакции не последний. Тем более, что по маркетинговым материалам system Z здесь есть чем похвастать. Ну а учитывая, что заказчик исследование и сравнение не заказывал от слова совсем, то в этом направлении как раз грустно, хотя платформа вполне себе конкурентна. Грустно потому, что заказчик не готов оплачивать 44 процессора system Z, вне зависимости от достигнутой максимальной производительности в тестах считая это чрезмерным. Заказчик задавал давно прямые вопросы, на которые не получил никакого вменяемого ответа, а только враньё и уход от ответов, и поставил точку. Был бы это единственный случай, было бы может и не грустно. Но после целого ряда подряд идущих случаев - это уже тенденция. Особенно в случае миграции POSIX приложения на z/OS в течении 6 месяцев с поразительным результатом в производительности в итоге.
Цитата
По поводу совокупной и долгосрочной стоимости - нужно считать. Причем не абстрактно, а под конкретную прикладную задачу
Тем не менее, тесты TPC или SAP вполне себе позволяют ориентироваться при выборе платформы под решение - если есть описание протестированной задачи, есть количество выполненной работы и стоимость единицы выполненной работы, уже можно прикинуть. Не так ли?
Судя по вышесказанному, мне известно меньше информации, т.е. я в курсе только маленького кусочка гораздо большей картины.
Насчет TPC (или SPEC) - я двумя руками ЗА то, чтобы были выложены результаты тестов System z в общем доступе, как это сделано для System p и System x систем. Вот только как этого добиться?
Никак. Тесты TPC на z/OS есть, и не только с ДБ2, но никогда не будут опубликованы. Считать там просто, даже очень просто, берётся стоимость по прайс-листу на 5 лет, включая поддержку. Да я не про то. Статьи написаны правильно в целом, статьи нужны для популяризации. Но надо аккуратнее с выводами.
Это ещё один важный аспект не затронули. "сопровождаемость". Ну если система расчитывается в эксплуатации больше, чем не десятилетие. За этот период точно сменятся программные и аппаратные платформы. Сколько в DB2 10 deprecated конструкций по сравнению с DB2 9, и и в 11 по сравнению с 10? Сколько в последней яве deprecated конструкций по сравнению с педпоследней? Этого TPC не учитывает. А заказчика достаточно спросить - у тебя какой .net? 3.5, хорошо, а текущий 4.5, и как мигрировать собираетесь? В ответ нецензурщина. А ведь обратная совместимость - одна из сильнейших сторон мейнфрейма, а не отражена от слова совсем. Ну и так далее.
Почему-то на практике специалисты по Linux так решения для промышленной эксплуатации не разворачивают
Можно заметить, что на практике в России платёжные системы на мейнфреймах не эксплуатируют.
И вообще, для такого вывода не нужна была СУБД с WAS, достаточно было сделать простенькое клиент-серверное приложение "echo", где клиент шлёт строку, а сервер возвращает её обратно, и протестировать в двух вариантах - на одной ОСи с взаимодействием через shared memory, и на двух ОСях с взаимодействием через сеть, и гордо всем демонстрировать разницу во времени отклика. Да и железо можно было по-дешевле взять.
Цитата
Тестируется не просто сферический конь в вакууме, а конфигурация, которая может удовлетворить заказчика. Заказчик естественно выбирает исходя из имеющихся лучших практик.
Ну, если учесть, что заказчик вообще ничего не заказывал, не выбирал, и не заказывал сравнительное тестирование, и не собирался смотреть его результаты, то.... Про "лучшую практику" в смысле разнесения СУБД и WAS - то же самое, притянуто за уши в отрыве от конкретных требований, обе конфигурации имеют место быть.
Ну, если учесть, что заказчик вообще ничего не заказывал, не выбирал, и не заказывал сравнительное тестирование, и не собирался смотреть его результаты, то....
Наверное и я обладаю меньшей информацией чем ты, хотя... как бы это сказать, я собственно и отвечал за организацию тестирования сидя в составе комиссии заказчика. Ты не допускаешь, что заказчик-таки заказывал сравнительное тестирование, регламентировал конфигурацию стенда, смотрел результаты в режиме Live, принимал отчёты, оценивал их, выбирал? Почему не выбрал - это вопрос не к нам.
Этот заказчик "послал" давно и далеко. Чему есть интересные документальные подтверждения. Приходи. А то, что вы там себе... нафантазировали..... А теперь твоё слово против моего - ты можешь делать вид, что это всё было заказано и оплачено заказчиком, я могу утверждать обратное... Давай погодим пару лет и посмотрим? Что заказчик внедрит? Или быстренько пробежимся по остальным "победам" и посмотрим, что внедрено и с каким успехом?
1. Для того, чтобы узнать, что заказчик внедрит не нужно ждать пару лет - анонс о выборе решения и его поставщика опубликован в интернете на сайте заказчика в декабре. Что в итоге внедрят - ну вот это мы посмотрим через перу лет. Мне тоже интересно. 2. Что заказывал заказчик я знаю лучше, но к сожалению не могу прислать тебе ни методики тестирования, ни запрос конфигураций ни отчёты о тестировании (NDA, помнишь слово такое?). Так что верь на слово. Да. и вот ещё, так на всякий случай - это не то решение, куда в своё время предлагалась IMS. Наверное ты говоришь всё ещё о том... Так показалось. :-)
Женя, кстати интересно как ты думаешь, помему статья про сравнение зета с линуксом вызвала гораздо больше внимания на том же хабре чем про тестирование распределенного сисплекса?
Да просто тема ближе и понятнее. Ибо что такое SYSPLEX знает только узкий круг "посвященных", при этом реально его "щупали" еще меньшее количество. И там нет никаких сравнений.
Ну а "DB2 круче Оракла" - это же практически "священная война".
Вот бы еще сравнить Apache Tomcat VS WebSphere Application Server Liberty на нескольких платформах и на каком-то реальном приложении или на популярном бенчмарке.
От комментариев сложилось ощущение, что нет доверия к IBM и его продуктам (в данном случае DB2, WebSphere Application Server, Java). И это ощущение появляется периодически, когда речь заходит про продукты IBM (в России). В основном посыл такой, утрирую, что "Все продукты IBM это дорогие, неповоротливые и глючные монстры, которые покупают только ради распила бюджета" и "Продукт X (бесплатный или опенсорсный или просто другой) с легкостью уделает вашего IBM YYY".
Приходится периодически доказывать, что эти убеждения не соответствуют действительности.
Справедливости ради замечу, что в России это касается не только IBM, а вообще любого вендорского софта, стоит вспомнить волну хейтерства к той же Microsoft. Ну и наша традиционная забава варить кашу из топора, когда: "какие EJB?! Да я такой крутой и уникальный да на сервлетах, на спринге, да я вам покажу! Что значит "двухфазные транзакции?", я этого не знаю, значит нинужно!" В Java мире просто открытых и бесплатных библиотек наверное больше, чем в других областях программирования, поэтому такое отношение особо заметно.
Может быть еще влияние инженерной школы конечно, в том смысле, что внедрять готовое - постыдно и убого, а вот создавать свое, пусть и велосипед, это достойно и значимо.
В точку. А зачастую ещё и применение продуктов не по назначению. Отсутствие архитекторов, знающих платформу, ПО под платформу, умеющих работать с аналитиками. Я могу вот легко устроить опрос, и вывалить сюда тонну ругательств от заказчика. И те факты, которыми они оперируют, действительно показывают, что в данной ситуации, в данном рекомендованом ИБМ порядке применения, продукты неповоротливые монстры, не сказать чего хуже...
Хотя, тебе могу адресовать мнение зам начальника ИПИ РАН, лауреата Государственной Премии, обладателя кучи регалий, в одиночку сделавшего для нашей страны больше, чем ваша команда в полном составе.
Цитата
Совершенно очевидно, что для платежной системы реляционные базы не нужны и даже вредны.
Хочешь возразить - пожалуйста, не мне, а ему. Ищи выход и возражай. Только не надо про условия тестирования, про заказчика. Хоть мне то этого не надо говорить.
В науке, насколько мне известно, не признаются ссылки на авторитеты. Какие бы регалии у тебя не были тезис надо обосновывать и доказывать. Бремя доказательства всегда лежит на выдвинувшем тезис, аргументация вида: " я сказал А, опровергайте" порочна по определению.
ещё раз для плохо умеющих читать по русски - хочешь возразить, иди автору и возражай.
А вообще всё это от отсутсвия базовых знаний курса CS, многократно уже убеждался. И это... у нас, вообще-то, ремесло, а не наука. А курс CS при том, что там этот вопрос тщательно разбирается. Пардон - раньше, до поколения пепси, разбирался.
Именно так. Я своего отношения к цитате не высказывал. мопед не мой. И это не совсем тезис. Это на-подумать, почему автор это сказал. Ещё раз - не надо со мной на эту тему спорить, ок? Без базовых знаний по предмету не надо пытаться чего-то ниспровергать. Если очень захочется - есть отдельное место, здесь на сайте есть обсуждение статьи по сравнению иерархической и реляционной базы от ИБМ, вот милости прошу, там и ниспровергай.
Я читал и переписки длинные в соответствующих темах тоже. Сейчас не вижу никаких аргументов кроме: "это - базовые знания, а если вы со мной не согласны, то вы просто CS не знаете, маленький еще из поколения пепси и вообще сперва добейся". Это все, кстати, после того как я пришел с вопросом, а не возражением. Я в IBM человек новый, но кажется начинаю понимать, почему продаж нереляционной СУБД не было.
О, а вот мне интересно мнение молодых сотрудников IBM, почему не было продаж нереляционных СУБД в России. Свежий взгляд зачастую помогает увидеть что-то новое. Не стесняйтесь, валяйте)).
О прочтении, после которого может появиться желание ниспровергнуть. http://s390soft.ru/publ/20-1-0-81 - ссылка на статью, которую обсуждают, не работает. может, выложил бы ее в pdf на гугл-докс или еще куда? или хоть сюда на сайт.
да выложить то я могу.. опубликуешь? тут и вторая часть на подходе - сравнение методов разработки и языки доступа к данным. А вот свежего взляда ты не дождёшься - троллизм, хамство, невежество, и желание впарить любой ценой, ничего не поменялось. Что придётся иметь в виду при планировании развития. Пусть ЛПР почитают, полезно будет. Ну что же, ожидаем результатов успешных продаж. Как pdf-ку выложить? Что прикольно - IBM менеджмент запрещал статью публиковать. С чего бы это, если технология нафиг никому не нужна
ну, во-первых, читать лучше это http://public.dhe.ibm.com/common....SEN.PDF Как я уже писал, ничего подобного от DB2/Z просто-напросто нету. На основе этого было желание сделать стенд для сравнения анализа. самой статьи сравнительного анализа небыло, потому... да собственно вот http://www.slideshare.net/geery/db2-vs-db1part1shortlink-34863741 Аннотации там нету, но нужна бы краткая. Статья была создана по заданию архитектора, которому надо было разобраться. Поэтому изобилует количеством ссылок на документацию, приведённых в качестве подтверждения тезисов. Содержит далеко не полный обзор "фишек" технологии. Архитектор попросил официального специалиста DB2 прокомментировать, но он мягко ушёл в сторону. Комментировали много разных специалистов лаборатории, сообщества. Была идея сравнительного нагрузочного тестирования, начался создаваться стенд... Но сперва запретили саму статью, а потом я получил слишком заманчивое предложение перейти на тёмную сторону силы заказчика, и поработать руками. В общем, сравнительное тестирование провести, в принципе, можно. Но ндо переделать структуру данных под RDBMS. Я могу сделать, но ведь обвинят в подыгрывании, потому лучше делать кому-то другому. Ну и главное - у меня абсолютная уверенность, что результаты нельзя будет легально, без нарушения лицензии, опубликовать. Или ошибаюсь?
Кстати, там, на slideshare есть вторая статья, описывающая реализацию архивного хранения оригиналов документа. Кратко была обсуждена с крутыми зарубежными специалистами, и очно даже с одним немцем. Как я понял по вытянутой физиономии, все попытки мэтра отнекаться, мол, это не мы придумали, не канают, за рубежом такой подход неведом, во всяком случае, я следов не обнаружил, потому авторство идея и практическая реализация принадлежат нашему мэтру. Я только записал, и приступил к воплощению. Мэтр, с благодарностью, http://www.slideshare.net/geery/doc-store-ext
в статейке по хранению оригиналов документов я позже добавил версионность документов на основе GDG... оказалось, что нам это может быть очень удобно. Но в сатье "на экспорт" на slideshare менять влом. Само понятие тривиальное. Наши мелкомягкие разработчики были зело впечатлены, и кинулись тестировать.
Мне кажется, общение в таком стиле - это "жёлтая карточка". Павел возражает очевидные вещи, ты его затыкаешь и приглашаешь для дальнейшего "мордобития" на поляну, где он точно тебе не соперник. У него не было столько времени и возможностей разобраться в иерархичеких БД, сколько его было у тебя. И мозгов у него не меньше, поверь. И Пепси здесь - не аргумент. Да, они не умеют писать Ассемблер - им просто это не надо. Поговори с ним о Java, например, если хочешь развлечься.
да хоть красная. лапшу только не надо вешать науши - это всех касается, и тебя тоже. За 10 лет уже достаточно надоело. Небыло времени разбираться - не надо выносить суждения. Надо разобраться. А врать, передёргивать, и подтасовывать факты - тут вы мастера. И повторю - я, давая цитату, предупредил, что мне претензии по ней предъявлять не надо. Цитата может не нравится по сути, но то, кто её автор, должно заставить задуматься. То, что базовых знаний нет - очевидно, вот у нас старые деды тут, ИТ-шники разлива СССР, влёт дают характеристики и области применимости иерархических и реляционных баз - ибо это учили в ВУЗе. Ныне - не учат. Это просто факт. А про яву мне незачем разговаривать, её у нас нет и не предвидится. Политика простая - всё, что может исполнятся не на мейнфрейме, должно исполнятся не на мейнфрейме, если не нарушается SLA. Из немейнфреймовских платформ у нас microsoft.
Ай-ай, а что ты так горячишься? Сюда люди ходят "черпать умных мыслей" (я по крайней мере). Кстати, если считаешь, что моя "лапша" будет интересна тем, кто ходит сюда за тем же, за чем я - опубликуй, пожалуйста.
Согласен, любви маловато в нас, это да, есть над чем работать. А вот дураками тут никто никого не называл, я слежу за переходом на личности. Павел - вменяемый специалист, и никто ему в этом не отказывает. Но то, что некоторых базовых знаний у нынешних специалистов маловато - так тут и спора нет, я 5 лет в Бауманке дипломы принимаю и программу обучения рецензирую, могу тебе по этому поводу петь долго. И да, пассаж про понимание того, почему в России не пошли нереляционные СУБД тоже был не очень уместен, особенно с учетом того, что тут таки есть люди, которые были вовлечены в этот процесс на протяжении всей его длительности и со стороны технарей (это я и мои подчиненные), и со стороны потенциальных заказчиков (мы и наши коллеги), и со стороны образователей, и со стороны IBM реального, а не дутого (российского) - тот же Женя Ляхович. (Про "дутость" российского IBM у меня есть подтверждение от самого российского IBM, на бумаге, бгггггггг). Григорий действительно не продавец, и на то, почему все не выстрелило, лучше, наверное, сначала спросить у тех, кто был активно задействован, ну чтобы хотя бы в фактической стороне не проколоться. И еще. Аргумент "ассемблер им не надо" в случае с мейнфреймами - это за гранью берегов. Ассемблер - это путь к пониманию архитектуры. Без понимания архитектуры на мейнфреймах, увы, делать нечего. Это как врачу не знать анатомию. Собственно, миллион раз убеждался - если тот, кто двигает мейнфрейм, не написал хотя бы одну программу на ассемблере с цепочкой ввода-вывода, то он архитектуры НЕ ЗНАЕТ, и рано или поздно, в крупном или мелком проколется. Собственно, у мейнфрейма-то кроме особенностей архитектуры нет плюсов, его надежность сильно преувеличена, такой же уровень надежности на любой платформе получить - не проблема. и софт долизать до уровня полупромышленного можно. а вот схему обработки прерываний на Интеле - хер изменишь, а это вообще меняет уровень аргументации, на этом тот же Шмид, например, все экономические метрики построил. Ну чо, объяснишь обработку прерываний Явовскому специалисту? Или ему это тоже не надо? В общем, есть всем над чем работать, критику принимаю, и призываю всех возлюбить друг друга, радоваться весне, укорачивающимся юбкам и набухающим почкам, которые на деревьях. Make love, not war!
Саш, говоря об Ассемблере - я не про Павла и мэйнфрейм, я про "поколение Пепси" вообще. Я на 100% согласен с тобой, причём не потому, что я бывший ассемблерщик. У меня лично не вызывает сомнения утверждение, что получить "бенефиты" от этой платформы можно только опираясь на его архитектурные "вкусняшки".
Почему IMS в России не пошёл? Да потому что не пошёл и всё. Несколько раз пытался к нему подъехать с разных сторон. Архаичен до безобразия, несмотря на всяческие прикручивания, типа SQL-доступа и доступа из Java. Та же DB2 гораздо удобнее, с точки зрения администрирования. например модификации структуры базы. И процесс этот, в IMS, ближе к программированию низкого уровня, чем в той же DB2. Нет сейчас необходимости пилить ножовкой дрова, когда есть бензопила, да впрочем и дрова сегодня никому не нужны. Adabas получил некоторое распостранение на МФ в России, благодаря советскому наследию и не наличию альтернатив в то время. DB2 - протекционизм IBM и командное управление тех кто начал пользоваться DB2. Единичные установки Oracle на МФ(знаю наличие двух, от силы трех заказчиков) - из-за его модности в России в момент принятия решения. Были еще попытки с IDMS, CA просто отдавало его даром, но забыли приложить к нему настоящих сварщиков.
ммм..... ну парочку утверждений я бы пообсуждал, если что. например, про архаичность, дрова и бензопилу. Ассемблер, да продлит Всевышний годы его, вполне архаичен. И что? значит ли это, что он нафиг не нужен? кому-то может и не нужен, а у меня вон кусочек задачки совсем недавно в интересах прикладников на ассемблере на мейнфрейме написали, оказалось, что понадобилось системный вызов подкрутить. так что низкоуровневость IMS - иногда минус, иногда плюс, это от массы параметро зависит. ну в аналогии с дровами - резьба по дереву бензопилой представляется странной, а вот резцом - да! потому что не дрова рублю, а создаю ТВОРЕНИЕ! так и с Адабасом. он был распространен и потому, что альтернатив было не дофига (но были!), и потому, что он шустр, прост в настройке, там есть Natural! И сейчас, в общем, тоже есть объективные технические достоинства, и уроды-продаваны, развалившие бизнес в стране. Но это, думаю, тема другой статьи и следующей пары сотен комментариев))
В IMS всё, включая описание данных (физическая и логическая структуры) задаётся через макросы (если не брать во внимание массово клепаемые в последнее время нашлёпки), в чём одна из сильных сторон, но сила с одной точки зрения является слабостью с другой, это диалектика. Но кто угодно, но чтобы широко известный AKonev жаловался на неудобство работы с макросами ассемблера?!? Пойду напьюсь кофе с бальзамом, прям с утра и с расстройства.....
И Linux задели, и Oracle DBA обидели, не зря вопросы про large page и прочие мульки пошли. Мне кажется, что основным плюсом двух данных экзерсисов была демонстрация "легчаешей' миграции с платфомы на платформу и вдобавок в другую базу. А что касается DBA-мулек, то их в запасе еще было и разогнать более чем в 3 раза не вопрос вовсе, а время, желание и необходимость...
вот опять верные слова - легчайшая миграция с платформы на платформу. Но у этого есть и оборотная сторона. Раз это легко - то это и будут делать. А учитывая возражения, изложенные мэтром в обсуждении статьи про консолидацию на z, то все эти вопросы первоначальных вложений капитала и прочее, невозможность планирования на длительные сроки, и ты-ды, и будут препятствовать широкому распространению платформы z. Если нету принципиальной разницы.... То пойдут по линии наименьшего сопротивления. Наличие именно что принципиальной разницы пока не просматривается из данных материалов. Нет основания тому же архитектору сделать вывод о необходимости применения именно платформы. Ни про линукс, ни про сисплекс. С появлением DB2 PureScale применимость сисплекса вооще под вопросом по всё тем же причинам, изложенным метром. Нужна принципиальная разница - финансовая, технологическая, функциональная - ну хоть что-то, но принципиальное для конкретного заказчика или отрасли.
Один и тот же прикладной код (принципиальная позиция). Разные среды исполнения. Явно видимая разница. Какие еще нужны аргументы? Если команда линуксоидов + ораклоидов не смогла сделать лучше, то это что - слабость команды или решения?
Здесь всё допущения. Допустим, что был заказан именно такой сценарий тестирования, и отсюда исходим. А аргументы - так заказчика надо спрашивать, почему ему не нужны ни результаты тестирования, ни платформа. Заказчик формулировал два простых и понятных вопроса 1) что мы будем использовать уникального при эксплуатации этой платформы 2) что мы получим принципиально отличающегося от того, что эксплуатируем. При отсутствии ответов на вопросы интерес угас. А данное испытания никак не отвечает на вопрос, почему должна быть именно платформа z - такое условие сравнения. Даже абстрагируясь от конкретного заказчика - данное исследование никак не сможет оказать помощь другим потенциальным заказчикам. Что, собственно, и видно из комментариев.
Ещё раз напомню, что тех, кого интересует разница в сетевом доступе и доступе через память, могут сравнить и менее затратным способом. А суть теста именно в этом - безотносительно силы или слабости какой-то команды. Есть архитектор, он будет сравнивать сравнимое. Если он архитектор. В данных условиях тестирования, кем бы и чем бы они не обуславливались, архитектору смотреть не на что.
Ну вот, теперь будем педалировать JDBC 2 vs JDBC 4, большинство "архитекторов" не ведают о существовании этой разницы и опять же, если они не смогли выстроить правильную конфигурацию, кто в этом виноват?
а если попробовать не говорить о тех, кто не смог. а говорить о применимости данной работы. если не искать виноватых, а посмотреть, как можно использовать. то получается, что никак. Кстати, про архитекторов. Конкретный архитектор может не знать конкретной технологии. Но он будет сравнивать сравнимое, а не килограммы с километрами, и в этом плане ему, возможно, придётся выяснить, что существуют разные типы взаимодейтствия. (курс computer scienece). В принципе, конкретному архитектору можно навешать лапшу на уши. Но зачем? Это что, цель? Раз ты, архитектор, не понимаешь, то сейчас мы тебя разведём? Ну и ок. Тогда исключительно полезный материал с этой точки зрения - раз вы не понимаете, то мы вам говорим - мейнфрейм круче, вот, в три раза быстрее, всё. Жаль, что мифические "они" не догадались связь по модему 2400 организовать, а то бы описали, и сделали однозначный вывод - ну и дерьмо же ваш линукс, а мы что, виноваты, что они тупые, не смогли ethernet прокинуть. Это я утрирую, чтобы было понятнее - не важно, как накосячили "они", важно, как можно использовать результат
Здесь как раз и там и там мейнфрейм и сравниваются яблоки с яблоками.В частности - это ответ тем, кто без всякого основания заявляет о том. что что-то круче другого. И совсем уж нереальный материал для тех, кто в угаре "импортозамещения" грозится переделать работающие мф-приложения на шароварный софт и x86 железо.
здесь сравнивается сетевое взаимодейтсвие с взаимодействиеми через память. И как раз в данном конкретном случае, в этом приложении, как раз вполне мейнфрейм заменяем без особых проблем. Яблоки с яблоками показали разницу в 25% не подскажете разницу в стоимости процессоров и лицензий? Это мы ещё альтернативу в виде того же DB2 на Linux не смогли посмотреть результаты. воткнули бы модем на 2400 и сравнение мейнфрейма с мейнфреймом выглядело бы вообще чудесно! А главное аргумент есть - кто же виноват, что у "них" слабая команда.
Следует обратить внимание на время выполнения многостороннего взаимозачета без учета работы с СУБД, т.е. время выполнения только расчетной части. На z/OS данное время оказалось на 25% меньше, чем на Linux.
Вот единственное, на что можно посмотреть. То есть кричащий заголовок "как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle" можно выбросить, и скромно написать, как z/OS + DB2 оказалась на 25% быстрее Linux + Oracle, тоже утрируя. но здесь хоть сравнивается сравнимое. В обеих случаях работает код в одинаковых условиях. И дальше уже каждый заказчик будет решать, для него принципиальна разница в 25% производительности, если это порядки разнице в цене?
На тему сравнения System z VS x86 наткнулся на такой вот тред: zLinux vs x86 Costs
Там длинная дискуссия, но, вроде как, есть успешные кейсы по переходу на zLinux, в результате которых сильно сэкономили на стоимости лицензий (упоминается Oracle), на объеме машинного зала, и на сопутствующих расходах (охлаждение, электроэнергия, коммутация и т.п.) И те кто совершил переход, утверждают, что все работает, весьма стабильно и быстро. Причем это речь еще про z10!
Позиция компании IBM по поводу консолидации Linux-приложений на zLinux мне известна и понятна. Да, и в указанной ветке речь шла именно об этом. Но, в блоге на LinkedIn вроде как отвечали не сотрудники IBM (не только они), но и те, кто выполнил такую миграцию и получил реальные профиты от этого. Я не имею в виду, что "нет доверия к IBM", но позиция вендора и клиента в подсчете профитов могут сильно отличаться, поэтому мнение конечных пользователей решения очень и очень ценно.
в этой области переносимых решений долговечного чего-то не будет, всё будет определятся ценовой политикой и ценовыми войнами. На это ещё наш мэтр говорил - выгодно сегодня гонять нагрузку на мейнфрейме, будем гонять на мейнфрейме, завтра станет выгодно на блейдах, будем гонять на блейдах. Примерно так, я своими словами. Решение переносимое, само понятие "выгодно" может отличаться и во времени, и от заказчика к заказчику. Было бы в этой сфере однозначное лидерство ИБМ - небыло бы такого засилья VMWare со-товарищи.
В этом месте хочется вспомнить компанию Apple. Технологическое преимущество у них есть не всегда, много "наступающих на пятки" и предлагающих аналогичные решения, причем зачастую гораздо дешевле. Но, они создали программно-аппаратную инфраструктуру, в которую смогли привлечь (и успешно в ней удерживать) платежеспособную аудиторию. Хейтеров у компании очень много, каждый день появляется новый "убийца iPhone", через день заявляется что "Андройд круче всех и имеет максимум инсталляций". Но, при этом, компания в очень хорошей прибыли и радует дальнейшей интеграцией своих решений в единое целое. Компания умеет договариваться с другими игроками рынка о продвижении совместных решений. Мигрировать с iPhone на Android (или с MacOS на Linux/Windows) тоже несложно, но, те кто пользуются, как то не спешат этого делать (насколько я знаю), т.к. чаще всего на этой платформе вполне "тепло и уютно".
Это я к чему. IBM как то неправильно (ИМХО) продвигает платформу. Понятно, что у платформы своя аудитория (платежеспособная). Но, как то нужно избавляться от бейджика "тяжелое, неудобное и динозавр". IBM вроде бы делает шаги в эту сторону (OpenStack, WebSphere AS Liberty, Eclipse Tools for WebSphere, zExplorer и т.д.). Однако, популяризации платформе явно не хватает, особенно в России.
Как вариант, поднять у российского облачного хостера "облако" на основе System z, и, если z/VM+z/Linux действительно в этом так хороши, то по идее хостер может получить совокупный профит и, при этом, предоставлять клиенту облачные серверы дешевле, чем аналогичные на x86, причем с указанием, что это System z. Типа "Win-Win" для всех участников процесса.
В принципе, соглашусь, хорошее сравнение. Могу только добавить к сравнению политику работы Apple с разработчиками, их успех во многом зависит от того, как они смогли заинтресовать разработчиков, создать их сообщество, возглавить его, подпитывать его... Разработчикам действительно очень удобно и уютно разрабатывать под Apple. Тем же путём пошло и Microsoft. Таким же, или схожим путём, шла и ИБМ, в эпоху становления и развития мейнфреймов - на фоне всего остального программирование под мейнфрейм было прорывом. ИМХО, без создания сообщества разработчиков платформа обречена на нишевое существование. Вот навскидку, попробуйте найти готовых решений к развёртыванию в z/OS в какой-либо индустрии... Просто чтобы посмотреть количество. Ясно, что в лоб тут не сравнишь - мейнфрейм и смартфон используются немного для разных вещей. Но сравните хотя бы с рынком готовых приложений для as/400. Да один Equation чего стоит! Ниша пользователей и разработчиков под Equation в чём-то схожа с пользователями/разработчиками Apple. Было бы, например... Ну вот в бизнес-приложениях такой же выбор, ну хоть примерно, как с утилитами на cbttape. А то ведь ну вообще не из чего выбрать, а то, что есть - невозможно получить на предмет посмотреть/пощщупать/оценить.
Компания Apple абсолютно никак не управляет сообществом разработчиков. Они просто создали выгодный рынок для них. И заинтересовали они разработчиков просто баблом и возможностью из нуля стать большой компанией. Про "удобство" написания кода на Objective-C уже слагают легенды, но на это всем пофиг, пока оно приносит бабло.
Ты знаешь, про кошмар отслеживания изменений в Equation тоже слагают легенды... Так и хочется сказать.... мышки плакали, кололись, но продолжали... Возможно, это только вопрос бабла. Но факт наличия сообщества есть. А процессор многоядерный, который ИБМ создавала в содружестве с Soni, затух как раз по причине того, что под платформу никто не стал разрабатывать. Если не будет рынка решений под z/OS, z/VM, а будет только набор "переносимых технологий"... То этим новых заказчиков соблазнишь с трудом, они как наш хитрый мэтр будут рассчётливо думать - сегодня на мейнфрейме, завтра на блейдах, и не делайте мне нервы. Согласись, рынок мейнфреймов во всём мире держится не на этом, не на переносимых технологиях. Что может быть легко перенесено - будет перенесено. При малейших колебаниях ценовых политик.
Господа, давайте будет реалистами. Рынок решений под мейнфрейм начал как custom-разработка, не заметил переход к стандартным решениям, и продолжает оставаться разработкой под конкретного заказчика. Никакое сообщество, которое бы делало решения под мейнфреймы с целью продажи это кучи заказчикам просто не нужно.
Большая часть успешных и эффективных решений под эту платформу сделали заказчики сами себе. Та же VISA. Не IBM и никакая другая фирма не сделала VISA, это VISA сделала саму себя, своей внутренней мощнейшей разработкой. И то же самое про кучу других заказчиков. Бизнес модель была такая - делаем сами. Потом сменилась модель на "оутсорсим разработку", но это совпало с переходом на распределенную платформу, core остался тем же, так же поддерживается внутренне.
Компании-разрботчику невыгодно иметь спец. отдел и спец. решения с унимальными характеристиками, так как в их головах (и совершенно справедливо) это не позволит бизнесу расти, так как сужает потенциальную клиентуру до 1-2 заказов. Только в рамках эксклюизвной договоренности с очень большим кошельком. Да и то, все равно будут пытаться сократить затраты, так как у них мотивация принципиально различается с целью заказчика. Это заказчику надо дешево, масштабируемо, надежно и т.д. А компании-разработчику надо чтобы было дешево по затратам, маржа побольше, и подписали акт сдачи-приемки. В таких условиях люди и ищут разные варианты в виде той же Java, получая в итоге компромиссное решение.
О! Ты первый, у кого хватило смелости и честности. Ты понимаешь, что этим заявлением ты ставишь крест на всех переносимых технологиях? В том смысле, что они могут и быть на мейнфрейме. А могут и не быть. И небыть на нём они будут чаще, чем быть, пока не изменится ценовая политика, а она не видно, чтобы поменялась. А чтобы заказчик стал лояльным - ему нужна кастомная разработка, где кастомер имеет уникальных специалистов, которые создают на уникальной платформе уникальное решение. В таком случае всё остальное (переносимые решения на мейнфреймах) попадают под категорию, которую IBM однажды красиво обозвало как-то типа, "Интеграция на z/OS. Почему нет?". Если это можно сделать и не на z/OS, То найдётся куча причин, по которым это не захотят делать на z/OS, и мало причин, по которым захотят. Нужны будут реально критичные требования, чтобы переносимое решение занести на мейнфрейм, и, как я вижу, это скорее всего в том случае, когда у компании на мейнфрейме уже есть непереносимое решение. Тогда с целью унификации ли, уменьшения времени отклика ли, или по другой причине, но можно будет рядом с непереносимым решением воткнуть переносимое, согласившись на изрядные издержки, которые частично нивелируются уже имеющейся командой, наработанным опытом, регламентом, и так далее. А брать с нуля решение на переносимых (или открытых) технологиях, и продвигать его в компанию, у которой вся инфраструктура распределённая.... Таких случаев будет, но по сравнению с классическими - на уровне статистической погрешности. Разве не это мы и наблюдаем?
могу апелировать к нашему мэтру. учитывая всю гнусность поведения вендора он бы может и слез с мейнфрейма... и пробует... регулярно... но "не выходит каменный цветок"
Компания Apple продает не продукты, она продает user experience. Когда ты торгуешь ощущениями от взаимодействия с вещью, то даже функционал отходит на второй план. И они кстати не особо не скрывают этого. Люди, покупающие ощущения это апприори не нищие люди, так как люди с малым достатком оценивают не удобства, а именно функционал. Поэтому они покупают именно это и зачастую даже дороже чем тот же продукт Apple, зато надежнее и гибче по применению.
Компании IBM нет особо смысла убирать бейджик "тяжелое и неудобное" с мейнфрейма, так как от этого ничего не изменится. Много лет пытаются продавать мейнфрейм с налетом эксклюзива и не особо получается. Потому что ценность то его не в этом, ценность его как раз в функционале и надежности. А разработчики? Ну кинут на 10-15% больше зп за разработку на мейнфрейме чем под другую платформу и переманишь. Ну придется человеку пару-тройку месяцев сначала немного поучиться, это ничто по сравнению с горизонтом планирования для решений на мейнфрейме.
Это всё так, но когда встаёт вопрос о миграции на мейнфрейм, остаётся один путь - полностью домашняя разработка (почти один путь, есть варианты, но катастрофически мало).
Цитата
Ну придется человеку пару-тройку месяцев сначала немного поучиться, это ничто по сравнению с горизонтом планирования для решений на мейнфрейме.
А вот здесь как раз и начинается интересное - тот же вопрос сопровождаемости, и прочее. Как только появляется горизонт планирования, в который явно войдут смены поколений софта и аппаратуры (если такой горизонт в наших условиях и появляется, явно не у всех заказчиков), то в полный рост встаёт вопрос - нафиг мне учить разработчиков три месяца под эту платформу, когда через год опять всё переделывать, пусть с таким же успехом работают на том, что умеют. Что я хочу сказать - зачем тратится, что это даст, чем это будет отличаться принципиально и кардинально? Где легендарное "написано однажды, работает всегда" применительно к данному тестированию? Если бы этот принцип соблюдался, этим сильно можно зацепить заказчика. Фиг с ним, я круто переплачу за железо, но 30 лет не буду иметь геммороя с обновлением софтовой и аппаратной платформы - а ведь такая ситуация имеет место быть, и именно такая ситуация сильно удерживает заказчиков. Вложились однажды, и с небольшими накладными расходами сменили кучу поколений аппаратуры и ПО
Вот я тоже когда-то писал программы Написанное мной в начале восьмидесятых, разумеется на мейнфрейме, до сих пор весьма успешно работает без меня, но заказчик, начитавшись заголовков из компьютерных газет, этого никак не ценит. И планирует сделать что-то, неизвестно на чём, главный принцип - что бы никому ничего не платить, включая собственных сотрудников.
да пусть планирует, фиг с ним! Вона, мэтр наш, тоже планирует... Без толку Обещать не значит жениться. Вот мы затронули одну из сильнейших сторон... Мы, а не IBM.
А что, нет ли ностальгии и желании немного сделать чего полезного со своей командой?
Эмм, как обладатель нескольких Apple-гаджетов могу сказать, что пока ни один конкурент не предлагает лучшей интеграции своих продуктов, особенно это заметно с выходом Mac OS X (Yosemite) и iOS 8.
Эти устройства легко интегрируются между собой и дают доп.функционал, которого (ИМХО) нет у конкурентов. Из последнего - прием сотовых звонков и СМС на другом соседнем устройстве (планшете или ноутбуке). Из более раннего - сквозное редактирование документов при смене устройства. Т.е. начал на планшете, продолжил на компе, и т.д. Из еще более раннего - AirPlay (Apple TV), благодаря которому можно в одно-два движения выдавать на большой экран аудио,видео, фото с любого устройства и любого приложения.
Да, с одной стороны это "ощущения", с другой стороны - это самый что ни есть "функционал", который (ИМХО) на голову выше конкурентов.
Насчет мейнфреймов - пока платформа будет мало популярна и под нее будет мало специалистов - это дополнительный риск ее приобретения. Про надежность вроде все знают (?), а вот производительность таки остается под вопросом, поэтому публичные результаты бенчмарков были бы весьма показательны. Т.е. получается что мейнфрейм это такой дикий, неизвестный и редкий зверь, к которому непонятно как подойти. А укротителей мало.
Поэтому, превращение (в умах ИТ-сообщества) мейнфрейма из "динозавра" в "послушную лошадь-тяжеловоз" - ИМХО очень и очень желательно.
превращение (в умах ИТ-сообщества) мейнфрейма из "динозавра" в "послушную лошадь-тяжеловоз"
Вот эту фразу надо бы попросить мэтра сделать девизом форума. Превращаем динозавров во владимирских тяжеловозов... А лет через -цать - в крестьянскую лошадку.... даёшь лошадку в каждый двор! Только как это реализовать.
Про надёжность знают все, даже кто мейнфрейма не имеет. Но отвечают - ну нафиг, уж лучше мы будем серваки чаще менять, да и вообще, хоть склад запасными серваками забьём... Тут ведь парадокс какой.... Вот сидят горячие поклонники на as/400, и любую попытку предложить мейнфрейм отвергают: - а ну как ваш мейнфрейм сломается?! - а ну как ваша as/400 сломается? - ты аэску не трогай, это святое! Вот он, раздел. Но не просто так же аэска заняла это место. Большую роль сыграл софт, и концепция разработки... Именно концепция.
А тут за три года куча вышедших из строя дисков в DS8800, цену подсказать? И ведь один диск не продадут, только линейкой... Надёжность.... При всей надёжности у заказчиков убеждение - дело с IBM иметь нельзя, самый ненадёжный поставщик! И сколько угодно топ менеджерам можно показывать результаты тестов...
да куда же идти, когда стойки уже жужжат!! в эту $%#& стойку ничего же от конкурентов не воткнёшь!!! Если бы это только одна попаболь была, фиг бы с ним, так у меня и уже.... От Голубых тоже ничего не воткнёшь! Не дают %$&#&!!!! И вообще.... слов нет, такие ужасы творяцца... я тут art немного рассказал... что его компания творит...
Не только видел, но и регулярно пользуюсь. И то, и другое по степени интеграции уступает комплекту приложений Apple iWorks + iCloud. "Дьявол кроется в деталях".
Однако DropBox - это файлы. Это не офисный комплект. А GoogleDocs без интернета превращаются в "тыкву". Да и я не помню, чтобы запуская в браузере на другой машине GoogleDocs я сразу попадал в ту же точку документа, на которой остановился в существующем на другой машине активном сеансе.
В Apple iWorks (Pages, Numbers, Keynote), Mail, iBooks и т.п. я, открывая соотв. приложение, попадаю в ту же точку. Например с тем же iBooks (читалка книг), читая книгу на смартфоне и, потом, открыв ее на ноутбуке или планшете, я попаду ровно на то же место, где остановился. При этом, приложения сохраняют работоспособность без интернета и синхронизируются по мере возможности. Если недоступны нативные приложения (комп с конкурирующей ОС например) - то остается веб-интерфейс iCloud, в котором есть веб-версии тех же самых приложений.
Сейчас тем же путем идет Microsoft с пакетом Microsoft Office 365.
я, открывая соотв. приложение, попадаю в ту же точку. Например с тем же iBooks (читалка книг), читая книгу на смартфоне и, потом, открыв ее на ноутбуке или планшете, я попаду ровно на то же место, где остановился.
Прям как я - каждый вечер убиваю на работе 3270, запускаю дома, и попадаю в ту же точку
Вот поддержу, как не фанат, но просто пользователь MAC OS X (исключительно для обработки фото) - лучше чем MAC для конечного пользователя нет ничего, и никакие ваши предложения не катят. Именно что дьявол в деталях, а Apple создал целую идеологию/концепцию.
к тому же комплексы на линуксах переносить с железа на железо больших проблем не доставляет. чуть тяжелее между разными юниксами и линуксами, но если в предлах одного дистра линукса, и меняется только аппаратура, то реально можно двигать часто. К тому же по функционалу z/VM давно не впереди планеты всей, и непонятно, когда догонит.
Какая интересная дискуссия получилась! Я почитывал краем глаза, и на конференции по управлению ИТ-активами, где имел честь и грустную необходимость делиться опытом (ненавижу доклады, очень от них устаю, и слушать, и говорить). Что имею сказать по существу написанного выше. 1) Я рад, что прозвучал тезис о первостепенной значимости для мейнфрейма приложений, разработанных именно с учетом особенностей, сильных и слабых сторон архитектуры. Да, не переносимость (которая сама по себе - дело неплохое), а именно архитектурные особенности оправдывают высокую цену и высокий порог вхождения платформы. Поэтому продвижение платформы, основанное на цене или привлекательности для переноса приложений, не сработает. Оно, собственно, и не работает, как мы все видим. Почему так странно продвигают платформу - не знаю. Я, может, подумаю, и набросаю свои соображения в Колонке, или, если не удастся изложить более-менее внятно, в Блоге. Но, повторю, мысль о том, что выживание мейнфрейма как платформы зависит от возможности создавать и поддерживать бизнес-значимые приложения, спроектированные именно для него, за приемлемые деньги и в допустимые сроки, считаю стопроцентно верной. 2) О переносимых приложениях. Тут тоже все нелинейно. Вот, например, я чисто теоретически могу столкнуть свой основной программный комплекс с мейнфрейма. Это потребует денег, времени, но если прижмут - могу. Однако не сталкиваю, потому что сейчас на мейнфрейме получаю прямые технические преимущества - быстрее, надежнее, больше срок эксплуатации, консолидация, и все такое. Что может, кроме скотского отношения производителя, меня при таком раскладе столкнуть с этой платформы? Только политика. Потому что кроме эффективности начинает играть и результативность, а независимость от скотски ведущего себя производителя - это значимый для бизнеса результат, он снижает принципиально важные риски. Понимаете, о чем я? А я о простом - не только экономика и техника имеют значение, политика - тоже воздействует. Хотя все связано, как вы все понимаете. 3) О проделанной работе. Вот Миша Егоров правильно на самом событии сказал: по уму такие вот изменения в приложения, чтобы заставить его работать лучше на конкретной архитектуре, нужно делать в процессе проектирования и разработки. Это вообще хорошо - учитывать особенности того, на чем будет крутиться софт, даже если софт с претензией на межплатформенность. Так что мне бы хотелось все-таки отметить инженеров, задействованных в проекте: они молодцы. Да, выводы иногда грешат. Да, сами тесты и конфигурации не бесспорны. Да, решалась иногда не та задача, которая озвучивалась в условии. Но были и достижения, и опыт, и предмет обсуждения. Так что хлопцам определенно жирный "плюс" в инженерную карму и хороший опыт в подмогу. 4) По поводу реляционных и нереляционных баз в платежых системах. Была у нас небольшая дискуссия по этой теме - http://s390soft.ru/publ/20-1-0-81 - но увы, вроде как начальный документ удалили, а жаль. Там, в документе, и в дискуссии, вполне вменяемые слова есть, как минимум на уровне здравого смысла. У меня по этому поводу есть дилетантское мнение, но, поскольку я не очень глубоко плаваю в этом предмете, то просто повторяю то услышанное, чему больше верю. Так вот, у реляционных СУБД, как у любого технического решения, есть свои плюсы, минусы и ограничения. И для многих интересных задач нереляционки ведут себя лучше - эффективнее, проще в сопровождении, легче в эксплуатации.
а вот же, мы обсуждаем как раз пример продвижения платформы. всё, что мы обсуждаем, этим примером и есть. Очень просто - заказчик эксплуатирует систему, разработанную разработчиком, и недоволен - по ряду параметров. IBM предлагает решение - мы допилим, и пропихнём, не смотря на недовольство заказчика. Кто-то умный, кажется, art, задал вопрос - господа, вы оцениваете риски, мы кладём все яйца в одну корзину, делаем ставку на одного партнёра-разработчика, которым недоволен заказчик. Но ничего, два IBMer'а отвечают - зато этот партнёр управляемый, нажмём и сделает что надо. Они "взяли на себя ответственность", но в ИБМ это пустой звук - никто не анализирует причин провалов. А ситуация и на рынке, и в стране поменялась, рынок переформатировался, и бесцельно выбрасывать деньги уже никто не готов. Несмотря на все старания, заказчик отвёрг разработчика - он не видел для себя ничего нового и не понимал, почему это приложение должно работать именно на мейнфрейме. И никто на эти вопросы внятно не ответил - то, что отвечали.. да лучше не надо о грустном. Но IBM продолжило биться лбом в стену - все испытания чисто по инициативе ИБМ, уже после того, как заказчик сказал - спасибо, не надо, и документик заберите, мы читать не будем. Ну и сейчас бьются лбом в стену, не пытаясь изменить подход. Ответ на всё один - заказчик должен платить больше, точка. Вот и все принципы продвижения платформы. Подтасовки и недомолвки Но в случае очередной неудачи в серии неудач никто ни в чём не будет разбираться и делать выводы. Так заведено. Ведь этот же заказчик уже уводит часть задач с платформы... Не понимая, как они вообще на мейнфрейм попали...
а вот же, мы обсуждаем как раз пример продвижения платформы. всё, что мы обсуждаем, этим примером и есть.
Ну мне это как раз понятно. Я вот причину, почему именно так, понять хочу. Ну не глупее ж нас люди в IBM сидят. Масса опытнейших граждан, вот как тот же Гонзалес. И таких вот умных и опытных в IBM есть таки некоторое количество. Почему же тогда такую фигню творят? Вот что у них в голове?... Я как-то писал статью про то, как IBM гробит мейнфреймы. Так вот, ничего не изменилось, а для России стало даже хуже. Единственное положительное изменение - это то, что в последней поставке изготовление было без таких ярких огрех, что было раньше: не было забитых в раму молотком шурупов, неряшливо запиханных проводов и так далее. В остальном - идем туда же, бодрым шагом. Ниша съеживается просто на глазах, и, как я понимаю, вполне заслуженно. И причина этого мне не понятна.
Гонзалес с коллегами фигню не творят, они делом заняты. Сервисники они. Но есть ещё продажники. С коими мы и вынуждены иметь дело. И их большинство. пусть art, как почти дипломированный экономист, опишет ситуацию рынка мейнфрейма - стадия снятия сливок, вкладывать не надо только собирай урожай, как-то так примерно.
Я предлагаю не трогать здесь тему этого конкретного заказчика и этого конкретного тестирования (ты ведь его опять в качестве примера используешь), ибо: 1. Ты не владеешь всей информацией о ситуации, особенно в части политической, где технические аргументы имеют минимальный вес. 2. Те, кто обладает этой информацией никогда не обнародуют её и не поделятся ей с тобой даже в привате - ты это также знаешь. Так что не жди контраргументов.
Так здесь всё обсуждение посвящено конкретному тестированию. Предлагаю поправить статью о результатах тестирования, и проблем не будет. Да там обе статьи надо править. Заодно убрать ключевые фразы, однозначно идентифицирующие заказчика. Я не владею ситуацией с вашей стороны. Но сторон много, и я владею ситуацией совсем с неожиданной для вас стороны. Ну а если технические аргументы имеют минимальный вес, а политические максимальный, то - зачем писать "технические" маркетинговые материалы - это называется не политика, а коррупция. ИБМ этим не может заниматься, на верю!
По поводу предмета обсуждения я писал - см. мой пост №19. Ты (и твои информаторы) имеют в виду другое решение, от другого разработчика. То, о чём написана статья про "в три раза быстрее" - совсем другая тема, которую (извини, повторюсь) здесь никто не будет обсуждать (NDA). А по поводу статей: я честно надеялся, что придут люди и скажут - мы сделали (руками) систему, которая построена на <имя любой платформы> и показывает в кластере на 100 км вот такие результаты на продуктивной системе, к которой предъявлены вот такие требования. Это нормальный, профессиональный разговор. Здесь люди взяли требования, сделали руками систему в соответствии с этими требованиями, протестили её и поделились. Что такого, что так обидело уважаемое сообщество? Если кто-то сделает что-нибудь подобное, то вне зависимости от того, какие сертификаты указаны у них в профайле - мне это интересно и я искренне за них порадуюсь. Может быть потому, что я в этих вопросах лох и не понимаю "драматизма", но мой жизненный опыт говорит, что человек - это не то, что он говорит, а то, что он делает.
Претензии не к сделанному - претензии к выводам. Две статьи. В одной числа не бьют, не сходятся, во второй ... тоже. Ещё раз по русски - претензии не к сделанному. Претензии к презентации сделанного. Если не получилось нормального сравнения DB2/Z vs Oracle/zLinux - по независящим причинам, то не надо делать вывод от троекратном превосходстве. Ибо то, что сравнить можно, показывает 25% превосходство. Так же и по линейной масштабируемости в другой статье. Так понятнее стало? Ты опять уводишь в сторону, когда я тебе в который раз говорю - претензии не к статьям, а к выводам. По поводу NDA - можешь не темнить, ибо абсолютно прозрачно, что за приложение и чей разработки тестировали, и куда оно позиционировалось. Это из статьи всё читается, потому и говорю - ключевые слова надо бы убрать. А то ещё неизвестно, как заказчик отреагирует на подобные маркетинговые материалы, случись что. Так понятнее? По поводу сисплекс на 100 км... Понимаешь, нам это не надо от слова совсем.... И вот заказчики, к которым я имею доступ, рассуждают схожим образом. Для нас максимум - сисплекс в пределах одной машины. И асинхронное копирование на удалённый датацентр. Смысла в разнесённом кластере для нас никакого, одни накладные расходы. Такова специфика. Могу добавить, что асинхронное копирование с очень мягкими требованиями... Даже неделя допустима.
А что у нас конкретно в первой статье не сходится? А то на Хабрахабре был только один комментатор - XOpen, он и здесь на сайте есть, да и тот понял статью как-то по-своему. Может мне писательского таланта не хватает, конечно, хотелось бы понять.
Паша, ну название провокационное, в этом нет сомнения. Но это было ожидаемо. Надо было хоть знак вопроса поставить в конце. Не знаю, возможно это или нет постфактум.
Я про первую статью, где мы как раз про Sysplex рассказывали. Не понятно, какие именно числа там не бьются и не сходятся, вроде бы все четко, масштабируемость наглядно так показана.
1. Ну, про "нужность" сисплекса на 100 км я согласен, конечно. Я таких не видел... кроме того, вокруг которого сыр-бор. :-) 2. Решения всё-таки разные, но позиционировались для одного и того же, да. 3. А вот для задач заказчиков, "к которым ты имеешь доступ", иерархическая модель - это просто сказка! А они всё на сиквелах "блякаются". Я так понимаю, ты там не случайно, и скоро у нас будет шанс увидеть чудо? Помнишь, ведь говорили про это, когда ты был "по эту сторону"? 4. Зашёл бы, кофейку на набережной попить? (Кстати, мне доложили, что ты был здесь и не "доложился". Я вообще-то обиделся)
1. более того, необходимость актив-актив сильно преувеличена. Имеет место быть, но место надо выбирать аккуратно, не суя везде. Мощности отдельного мейнфрейма за глаза, это не аргумент, высокая доступность - дык для этого не надо 16 узлов, очевидно, и она имеет чётко оформленные параметры. В нашем случае, когда данные рождаются не у нас, а к нам копируются, и срок хранения в месте зарождения очень значительный... плюс остальные нефункциональные требования (в ИБМ ещё помнят, что это такое?). Место для кластера Актив-Актив просто нету. Скорее всего эксперименты будут, не могу даже сказать, когда. Ибо приоритет низкий.
3. Ты не поверишь, какие разные у меня заказчики. Чуда не будет, будет кропотливая работа - архитектурная в том числе, разработческая, программистская, включая системное и прикладное программирование. Могу сказать, чего не будет. Не будет референсов, но какая-то часть материалов будет публично доступна, не всё, очевидно. Не будет закупки чего-попало из списка ИБМ. Да и вообще, закупки будут после окончания этапа разработки. В принципе концепция развития понятна, тут ты угадал, в целом утверждена, нужен конкретный документ - детали, сроки, ресурсы. Часть описана в документе "СХОД", ссылка была, это одна часть, вторая - поисковая.... Если данные имеют от природы развитую иерархическую структуру, что ты мне, как архитектор архитектору, посоветуешь в качестве СУБД под мейнфрейм? Под минимум три десятка лет эксплуатации со всеми вытекающими затратами на сопровождение (новые версии явы и т.д.). Отсюда реализация логики архитектурного уровня доступа к данным - уже не на яве. Что на мейнфрейме понятно, иначе огромные накладные расходы - на межпроцессные взаимодействия, сериализацию, и прочее - процессов на писюках, это уже попробовали и впечатлились. Типы нагрузки - типичная OLTP и типичная пакетная (batch). Вариантов не много, вернее он один. Вот его и будет выбирать. Общий принцип тот же - всё, что может исполнятся не на мейнфрейме без потери качества - будет исполнятся не на мейнфрейме. Никаких "... почему не на z?" Патамушта гладиолус (дорого). Кесарю - кесарево, слесарю - слесарево. Остаётся вопрос по аналитике которая верчение кубов (не путать с регламентной отчётностью), но по ряду признаков скорее всего уедет на писюки. Ибо нет аргументов против - непонятно из требований, почему оно должно быть на мейнфрейме. Всё это ИМХО - а жизнь покажет.
4. В планах зайти есть, когда не могу сказать. Работы очень много и вся интересная. Зато точно теперь уверен, что все требования по регламентной отчётности покрываются без всякого Cognos старым добрым DFSORT/ICETOOL, это в копилку к тому, чего не будет Может, ничего не будет, жизнь она такая. Ишь что в мире творится.
А вот, кстати, что плохого в новых версиях Java? Да, язык развивается, хотя и не так бытро как C#, например, какие-то методы и приемы становятся @Deprecated, но я не помню ни одного класса или метода, который был бы удален или запрещен к использованию с течением времени, кроме некоторых из com.sun.*, которые вообщем-то заранее были нерекомендованы к использованию, да и те не удалены, просто при их использовании нужно при компиляции передать ключик. 30 лет Java'е еще конечно нет, есть 20 (в этом году), что сопоставимо. В угоду обратной совместимости некоторые вещи впрочем сделаны не самым эффективным образом, например Generic'и.
Эти какие-то - около пятисот в версии 1.7 Что это значит для нас - затраты на тестирование каждый раз при желании сменить версию, сопровождаемые, возможно, затратами на до-переработку. Для сравнения, у КОБОЛа, которы с 1956 года существует, около 20 deprecated конструкций (или восьми, запамятовал), и последняя случилась до исторического материализма. Но платформа активно развивается, новый компилятор выходит 27 апреля, но это не значит, что надо хоть что-то менять, меняются опции компилятора в основном. Захочется воспользоваться - да, перекомпилить и протестировать, но очевидно - не надо ничего трогать в исходном коде. Имея в виду, что затраты на сопровождения складываются из многих составляющих, в которые входит и затраты на изменение сырцов или тестирование комплекса ПО. Что-то менять или тестировать надо или при смене версии платформы, или при смене бизнес-требований. Отказываясь от Явы мы оставляем только случаи, связанные с бизнес-требованиями, избавляясь от остальных. Это так, очень кратко. Без затрагивания более проблемных мест, то, что на поверхности. С этой точки зрения ряд задач, модулей, вполне будут себе реализовываться на HLASM, те, которые не будут подвержены изменениям в связи с бизнес-требованиями. И тогда их можно будет вообще не трогать. PROFIT. Найм тестировщиков - это отдельная головная боль. Их не хватает (как и разработчиков) под текущие задачи, в которые не входят смена версий платформ ПО. Ну и я уже писал - стандарт для презентационного архитектурного уровня microsoft, ибо сертифицировано. Уровень доступа к данным, который будет на мейнфрейме, имеет строгие SLA включая real time, нету места для явы. На писюках вместо неё уже .net, который для меня не отличается от явы принципиальным образом, так что в этой сфере я не готов переубеждать мелкомягких, есть много других тем для срача с ними
Ну если метод помечен как @Deprecated - кто-то все равно запрещает его использовать? Если разработчики КОБОЛа добавляют в язык новые функции, но старые не помечают как Deprecated, то это значит только, что у них другой подход, это не значит, что Java хуже, а может наоборот, честнее что-ли.
Опять же, по поводу надо или нет что-то менять в языке, если в языке не появляется новых конструкций, то значит он не развивается, хорошо это или плохо, судить конечно тем, кто им пользуется, в данном случае - вам.
Я не оперировал понятиями хуже/лучше и зрелость платформы. Я оперировал одним понятием стоимость сопровождения. Появление deprecated повышает стоимость сопровождения. Так понятнее? Мда... Тут бы на производстве поработать... Сразу бы категории "хуже/лучше" ушли бы... С точки зрения эксплуатации - идеал когда ничего не меняется, изменения - зло.
Сопровождение это же не только эксплуатация, это еще и разработка. Как говорится, если к вашей системе нет претензий, значит ею никто не пользуется. Я на КОБОЛ не писал, может быть это идеальный язык, в котором не к чему придраться, но не думаю. В Java же как языке программирования придраться много к чему можно, отсюда и новые функции "try-with-resources", лябды, аннотации, дженерики и т.д. Разработчикам хочется писать проще, чтобы кода было меньше и он был понятнее. Думаю, тут я имею право говорить, т.к. я и есть такой разработчик.
Меньше кода, кстати, значит меньше вероятность возникновения ошибок, а значит, опа, меньше затраты на то самое сопровождение. Ну и сколько на рынке Java-разработчиков и сколько КОБОЛ и какова их цена. Не хотят люди в массе своей писать на языке, который не развивается, отсюда и стоимость.
Т.е. сопровождение - это не только вопрос того, сколько @Deprecated методов в новой версии языка, ну это даже на мой взгляд, может кто-то и будет спорить по этому поводу.
Про "лучше/хуже" - справедливое замечание, сам себя ловил на этом.
1. Сопровождение и разработка из разных эпархий. Разработка комплекса не имеет отношения к сопровождению, кроме особо выделенных мною случаев, двух, изменение версии платформы, ведущее к необходимости изменения исходного кода, хотя бы даже его верификации, и изменения бизнес требований. Всё остальное - мимо, ибо это вот основное не было прочитано.
2. Меньше кода меньше вероятность ошибки - неправда, С с перлом и соревнованиями на самый запутанный код в помощь. Очередное заблуждение в ряду
Если ты не будешь читать написанного - я перестану писать рано или поздно. Какой смысл?
По поводу разработчиков - наличие ресурсов хороший вопрос. Но позиция проста. Если человек программист, то две недели на ознакомление с синтаксисом языка и он начинает работать под присмотром. Если нет - он не нужен. Выбирать платформу на десятилетия руководствуясь количеством явистов... Глупо. Лучше потратить время на аккуратное и полноценное документирование, на архитектуру. Это скажется на стоимости сопровождения, а количество явистов - нет. Надо выбирать не натасканного на инструмент - а Инженера. Распространённая ошибка. Я освоил кучу языков, многие из которых нужны были только на время, многие уже забыл - но я не являюсь программистом. Я просто пример того, что не в синтаксисе языка дело. И я берусь утверждать, что программирование на КОБОЛЕ во многих вопросах безопаснее в плане ошибок чем на яве, и проще, в некоторой степени, но это субъективно уже.
Я думаю лет 20-30-40 назад точно так же выбирали платформы, руководствуясь наличием КОБОЛистов и бизнес таки-можно понять. Гений-Инженер (даже с большой буквы), это хорошо конечно, но на всех не хватает, увы.
Подход вида "я выучил 20 языков программирования и написал на них хелоуворды, значит любого программиста можно посадить и он через 2 недели будет кодирующей обезъяной под присмотром" конечно имеет право на жизнь, но он порочный. Почему порочный? Потому что во-первых надо найти этого, который будет присматривать, что не всегда особенно в случае того же КОБОЛа возможно. Во-вторых, повторю ка я твой агрессивный аргумент, тут надо поработать тимлидером, чтобы это понять, присматривать за хотя бы 7-ю такими обезьянами - работа не из легких и на нее тоже тратится и время и, значит, деньги, а если не уследишь, то они такого понапишут. При этом во многом эти "они" - грамотные люди, не дикари, обезьянами их называю так, не со зла, просто выражение "coder monkey", просто для них технология новая, а то опять скажешь, что не все читаю. В-третьих, помимо синтаксиса языка, есть такие понятия как парадигма программирования и библиотеки/фреймворки: переход с явы/кобола/С++ на Лисп - это не только смена синтаксиса, это во многом смена мышления, а изучение правильного (повторю, эффективного, правильного) использования фреймворков/библиотек да даже той же Java - дело далеко не двух недель. Но чтобы это все понять надо хотя бы несколько лет попрограммировать не хелоу-ворды, да и желательно в команде.
Ну а меряться у кого сколько заблуждений - не буду, скучно, просто проигнорирую. Просто для участников, мертвые системы никому не нужны. Система без развития - мертва. Хотя ее замечательно сопровождать, да вот только не нужна никому, а лет через N и разрабатывать некому будет, что мы и наблюдаем.
Ну и на тему стоимости ресурсов возражений не поступило. Предположим даже наняли кого-то и за 2 недели они начали выдавать код, убогий, кривой, но зато легко сопровождать. Дак они через год-два-четыре или за границу уедут со своими сакральными знаниями, или зарплату потребуют раза в 2 больше чем Java'исты.
1. Нам на всех не надо. Мы за всех отвечать не будем. 2. Знакомый подход - про хелоуворды. Знаю от кого. Ну да фиг с ним. Да и с тобой, если ты сам эту глупость придумал Это - нормальный подход, апробированный десятилетиями, в том числе и за рубежом. Специалист, Ведущий специалист, Главный специалист, и так далее. И архитектор. Специалист может вырасти в Ведущего, может не вырасти. Про Тимлидера... Ты бы помолчал, а? Под моим управлением были не одна сотня людей, с совсем другими сферами ответственности. Не лезь в эту сферу, дабы не сесть в лужу со своими "7 человек". 3. Синтаксис, парадигма, мышление, фреймворк - всё верно. Ведущий знает больше специалиста и учится у Главного, главный больше чем ведущий, и так далее. Да, это уже не две недели - дык какие проблемы? Чем выше уровень - тем меньше таких людей надо. 4. Мёртвые системы? Мы это наблюдаем? Бред и мания величия Система без развития? невежество Полное отсутствие знаний. В коболе есть встроенная функция расчёта величины аннуитентного платежа ипотеки, что ему ещё надо, как общему языку бизнес программирования? и в языке и в платформе есть уже всё, но платформа продолжает активно развиваться - язык дошёл до совершенства в своей сфере. 4. Стоимость ресурсов - а что возражать? Ты просто не можешь осознать, что не надт программистов под z/OS в таком же количестве, как и под Java. Банально - не надо. Опять - убегут, опять - зарплату потребуют... Это - обсуждалось уже не однократно, но извини - у тебя такие пробелы, особенно в вопросах найма и управления людьми... Я даже не знаю, на каком уровне тебе возражать... Одни косяки... Вот сколько стоит сисадмин z/OS и где их брать? Их много? А ведь задача решается, и не сложно. Мы решаем. Также будем решать и с разработчиками. Просто надо с людьми работать, это не HR, это работа с людьми, этому тоже раньше учились.
Давай так - я понимаю, что ты соглашаться не хочешь. Так же понимаю, что весь твой жизненный опыт пока не даёт осознать многие вещи. Они к тебе придут позже - возможно, но не факт. Если не просто балаболить и не просто возражать из принципа - есть вопросы, отвечу, мне ликбезом не впервой заниматься, да ты в курсе, и мне приятно, что хоть что-то ваша маленькая команда усвоила А просто возражать из принципа, что ява лучше, что фреймворк надо учить, что редкие специалисты дороже, не надо. И про хелоуворд тоже не надо Потому что смешно. "Нам тут проект надо собрать, только взрослый, а не хелоуворд" - а оказывается, что понятия как собираются проекты нет от слова вообще И поинтересуйся жизненным циклом ПО. Оно сравнимо с жизнью человека. Рождается (разрабатывается), взрослеет (тестируется и проходит этап опытной эксплуатации), выходит в жизнь (промышленная эксплуатация), и умирает (снимается с эксплуатации). Так вот разработка - это слишком малый период по сравнению с эксплуатацией, и надо экономить не на разработке, а на эксплуатации. А так - да, стоимость специалистов Ладно, молодость не вечна, это не недостаток. Хамство и глупость, подлость, лживость - вот недостатки.
В тебе очень силён синдром ниспровергателя. Но ты его применяешь к сферам, в которых плаваешь. И которые многократно уже обсуждались, и часть из которых не имеют однозначного решения, а решаются по месту и зависят от множества факторов. Вот и получается балабольство, переливаем из пустого в порожнее избитые вещи
Моя любимая референсная компания. Референс дурацкий, как все ренференсы в ИБМ. https://devopsenterprisesystems.wordpress.com/2015....elopers Но тем не менее, немцы вопрос решают, а у них это, наверное, сложнее, чем у нас. У нас даже ИБМ предлагает набрать 10 студентосов, загрузить их проектом, при активной помощи ИБМ в обучении, и через пол года оставить двоих. Пока обошлись без студентов, но в уме вариант остаётся, возможно, и применим. По словам правильного ИБМ - один специалист со знанием платформы и группа студентов - уже можно браться за проект. А это говорил ИБМер, у которого студентосы Бауманки на третий день начинали писать программы на ассемблере, пусть как обезьянки - но писали! Пусть из всех пришедших десятков на ассемблер пробило только пятерых, включая сына мэтра... Но этого вполне достаточно.
Вот в тебе щас тоже любви к Вселенной мало. Ну скажи на милость, Миша, кто тут у нас профилями меряется? Кто тут у нас прям такой вот бездельник-разбездельник, который ничего не делает?... конкретно по работе - есть объективные замечания, они озвучены, мной в том числе в комментариях и в тексте самой статьи, я думаю, хотя и субъективно, но вполне в конструктивном ключе. Не согласен? У Григория мнение другое, и он его темпераментно высказывает, иногда на грани фола. Ну что ж, такое тоже имеет право на жизнь. Единственное объективное и существенное замечание к Грише - это замечание про реляционные базы и мопед. Ссылка на авторитеты уместна в религиозной беседе, в научной и инженерной лучше бы воспроизвести хотя бы парой фраз суть, но есть топик, где этот вопрос очень живо и глубоко обсуждается.
ок, допустим, ссылка на авторитет лишняя. Ок, она провокация. Но, когда я вижу, что моё мнение отличается от мнения предыдущих поколений, сперва стараюсь разобраться, что я сделал не так. Ибо если 55 лет народ работал... Всю Одессу удовлетворяет... А меня не удовлетворяет... Ты вспомни, сколько мы с тобой по поводу HLASM vs COBOL срались дискутировали. Но я, разобравшись, признал правоту предыдущих поколений - нет замены HLASMу в ряде областей. То есть это не провокация - это повод задуматься. Что не так? почему вокруг меня одни гвозди? может, потому, что у меня из инструментов один молоток? может, мне разнообразить инструментарий? Но потом может оказаться, что предыдущие поколения ошибались. Такое может быть. Но для этого надо ведь разобраться. А не заявлять про непризнание авторитетов. Да и пусть их, авторитетов. Но согласись, не мы с нашими гениальными ниспровергателями впереди планеты всей в области платёжных систем в частности и транзакционной обработки вообще. Нам бы на олимпиадах победить.... А работать... пусть трактор работает, он железный.
Не могу ответить на 79, нет кнопки "ответить". Если коротко -'человеческий фактор'. В принципе сейчас на рынке 1001 NoSQL СУБД, каждая из которых заточена на свое применение, среди молодых да ранних это уже скорее модный тренд засунуть какую-нибудь MongoDB, ибо "круто". В принципе обсуждения той же IMS на данном сайте меня как специалиста заинтересовали, действительно необычно, рекордно и т.д., даже коллеги подкалывают, мол про IMS читаешь, но мне не понятно, как человек, который ее продавал мог что-нибудь продать. Яйца курицу не учат конечно, но как минимум культура ведения дискуссии та еще.
Ошибка я никогда ничего не продавал. Да, именно так. От слова совсем. Чаще наоборот - мой разговор с заказчиком включал "это вам не надо" гораздо чаще, чем "это вам надо", в смысле купить. Но суть понятна - у нас в стране нереляционые СУБД не присутсвуют из-за меня - не смог продать. Ну чо, красивая версия А главное - простая, доказывать ничего не надо, аргументов не надо Зато какой стиль ведения дискуссии
Во! Григуар! запомни: ты теперь в ответе за IMS! все из-за тебя! провалил всю работу, и был уволен за провалы! да что там IMS, ты и мейнфреймы не продавал вовсе, вообще работу завалил! вот ответь честно, сколько ты за годы работы в IBM продал мейнфреймов, а? тунеядец, однозначно. я думаю, картина мира стала простой и по-своему привлекательной.
какой же тут троллинг - просто доведено до логического завершения. часовню тоже я. а "суровый" да ещё "специалист" не может быть трусливым по определению, так шта не испугается.
Кстати, о часовне. В ответ на это (не могу ответить непосредственно под постом, простите - до освоения "троллосферы" никак не дойдут руки): Была идея сравнительного нагрузочного тестирования, начался создаваться стенд... Но сперва запретили саму статью, а потом я получил слишком заманчивое предложение перейти на тёмную сторону силы заказчика, и поработать руками. В общем, сравнительное тестирование провести, в принципе, можно. Но ндо переделать структуру данных под RDBMS. Я могу сделать, но ведь обвинят в подыгрывании, потому лучше делать кому-то другому. Как автор "идеи сравнительного тестирования в целях прекращения многомесячного теоретического мордобоя" хочу спросить: А то, что ты всё это время делал на стенде (работая руками) не было разве компонентом платёжки, прототип которой в варианте WS/DB2 тогда уже был протестирован вчерне? Структура данных, требования, готовый генератор нагрузки, стенд с готовым прототипом на DB2 - всё было доступно. Да, прошу не бросаться каштанами - я просто интересуюсь, зачем что-то сейчас выдумывать? :-)
Кратко - небыло. Готовился к разворачиванию стенд, на котором SWL показала 117К транзакций в секунду. Идею с реализацией платёжной системы умертвили силами Суворова, Молодцовой, Сабирбаева, и кто там ещё причастен был к решению, как не соответствующей духу партии. Сейчас я ничего не выдумываю. Сравнительное тестирование провести можно, но при чём тут платёжная система на извращённом ядре, не понимаю.
гениальней всего высказался архитектор один, который уже давно ушёл. "хуле думать?! вебсфера плюс дб2 и вперёд!" кратко, ёмко, понятно, обосновано - вот образец архитектурного решения. Применяемого в ИБМ. А ещё был интересный архитектор, распечатывал страницу сайта русскоязычного - иерархические базы представляют чисто исторический интерес. Мэтр, а ты со своим САГом ваще вне-исторический интерес
Дык ясное дело: я вообще реликт! На одной из ИТ-конференций некий важный супер-грамотный дядя из большой интеграторской конторы, вроде даже партнера IBM, убеждал, что Software AG (те, которые ADABAS и прочее), и SAP SE (те, которые SAP) - это одна и та же фирма, а ADABAS и Natural - это кусок SAPа. А его коллеги стояли рядом, и поддакивали, хотя было видно, что они не врубаются в происходящее и, похоже, обе аббревиатуры слышат впервые. Я был так очарован его обаянием и харизмой, что немедленно и с энтузиазмом согласился))! Вот что значит магнетизм личности! Благодаря неустанным усилиям талантливейших российских продажников за последние годы доля Software AG в части мейнфреймовского софта съежилась во много раз, так что продавцы от IBM на их фоне выглядят просто образцами здравомыслия. Я даже пару раз ставил им IBM-овских в пример. Теперь ставить некому, адабасно-натуральные продавцы и сопровожденцы, похоже, вымерли, как птицы дронт. А до этого рынок, на котором доля Software AG оценивалась в 82-86%, был радостно слит до уровня в 5-7% немецкими талантами. Так что и зарубежным, и местным продаванам есть к чему стремиться.
Ну что коллеги, хорошо так позавтракали :-) Больше сотни комментариев! Я вот подумал, что если бы мы чаще встречались и обсуждали то, что кажется насущным (и интересным всем) - было бы лучше. На завтраке, кстати, это тестирование представлял человек, которому и можно было бы задавать вопросы. Жаль, что не все участники дискуссии были там.
Максимум профита технического можно получить только с ассемблера. Именно поэтому у меня десятки ассемблерщиков и всего пара джавистов(без сферы). В заметке профит скорее экономический. Просто IBM готова дать скидку на джава, а на простой проц нет. И так купят, куда денутся. Падение рынка - маленькие проценты от миллиардов. И в запасе опция "скидка на CP". Именно поэтому я смотрю уверенно в будущее мейнфрейма.
зы: другое дело что с умом и заботой о пользователях рынок можно было бы и поднять...
Законы торговли - скидку дают на то, что плохо берут. ИБМ скидку даёт на Яву и на ДБ2. И изо всех сил убеждает пользовать одно и другое.
С Асмом она беда, как и с z/OS в целом... Это вопрос исследования на предмет того, что оно делает то, что должно делать. Ну не сертифицирована z/OS нашими органами... Вопрос решаемый тематическими исследованиями комплекса. Но блин... Масштаб бедствия в случае с исследованиями кода на АСМе... пугает. Но это надо пройти один раз.
Что вот я вчерась подумал... Имея АСМовский код и Principle of operations можно в ходе тематических исследований доказать (кому положено), что код выполняет именно то, что заявлено, где надо - вставляет, где надо - меняет, где не надо не удаляет и не искажает. В принципе, можно такое и с АСМовским листингом от кобольной компиляции провернуть. Вот с Java фиг его знает... пока не соображу.
С Явой тоже можно, но сложнее. Кто положено описывает такую последовательность функционального анализа: 1) сертификация и функциональный анализ отладчиков, компиляторов и Ява-машины 2) анализ исходников и построение тестов 3) функциональный анализ с применением сертифицированных компилятора, отладчика, ява-машины и тестов. Естественно, в реальной жизни это.. мягко сказано... затруднительно.
It's impossible. В свое время пытался постичь глубокий смысл трех следующих подряд ASM-команд. XR 1,0 XR 0,1 XR 1,0 Пока побитно не расписал, ничего не понял. А вы говорите смотри туда, не знаю куда и ищи то, не знаю что. Хотя, наверное, если знать что искать, найти всегда можно.
Какое-то SVC, изучал всякие недокументированные или не совсем документированные функции с помощью дисассемблера. В данном случае обмен регистров значениями, в условиях дефицита этих регистров и памяти.
С ява-приложением, может быть в чем-то проще, декомпилировал, получил вполне приличный код. Далее можно прогнать через доступные, как грязь, отладчики. Опять же, если знать что искать. А если задача абстрактная, найти абстрактную вредность ну крайне затруднительно. Был еще у меня такой прецедент, зная место, имея код (ретранслированный), не имея отладчика, зная что в результате должно получиться - ничего не смог понять в алгоритме реализации. Просто функциональные команды были размазаны по всему модулю и густо пересыпаны ничего не значащими. Долго бился с этим, проблему решил, просто обнулив проверку после вызова.
Скомпилированный байт-код по сути является "машинным кодом" для Java-машины. На Java-машину существует формальная спецификация (аналог Principles of Operation). Байт-код замечательно(однозначно) "декомпилируется" в JVM-ассемблер, и, более-менее декомпилируется в исходный Java-код.
Отдельная тема - это реализация самой JVM, которая занимается исполнением Java-кода на конкретной платформе.
Т.е. задача по сути раскладывается на две: 1. Проверка корректности байт-кода. 2. Проверка корректности реализации Java-машины на конкретной платформе.
В IMS всё, включая описание данных (физическая и логическая структуры) задаётся через макросы (если не брать во внимание массово клепаемые в последнее время нашлёпки), в чём одна из сильных сторон, но сила с одной точки зрения является слабостью с другой, это диалектика. Но кто угодно, но чтобы широко известный AKonev жаловался на неудобство работы с макросами ассемблера?!? Пойду напьюсь кофе с бальзамом, прям с утра и с расстройства.....
Я не сказал, что плохо и неудобно
Не запал я на IMS, наверное потому, что предпочитаю хороший чай и коньяк к нему А ассемблер - это просто самый понятный и предсказуемый язык программирования, а если ещё и писать структурно, то ....
не, не чай тому причина, факт. есть у меня догадки, почему, но... догадки есть догадки А про ассемблер - возражений нету. Так вот IMS - это своего рода ассемблер. Я во второй части подробно сравниваю процесс разработки под РДБМС и под ИМС, но суть та же, если грубо, на пальцах - как ассемблер и, к примеру, какой-нить 3GL язык. Под современный мощный объектный язык можно очень быстро "сгавнякать" (с) Бреус некое поделие. Под ассемблер надо сперва думать, планировать, готовиться, структурировать, прикидывать... Так же и под РДБМС - "сгавнякать" структурку, запросиков - любой может. С ИМС придётся сперва думать, планировать, готовиться... Ну а на этапе исполнения... в РДБМС начали работать, начали расти данные, начались проблемы.... Начали искать проблемы и возвращаться к этапу планирования и разрабтки - структуры менять, запросы менять, приложения менять. И так практически в бесконечном цикле, если не в идеале, а в реальной жизни. А ведь стоимость разработки на фоне всего жизненного цикла комплекса очень мала. Уж лучше вложиться в разработку, и не трогать больше десятилетия. А если и трогать, то только потому, что бизнес требования изменились - атрибутный состав, и т.д. Есть у IMS свои трудности, продолжение её сильных сторон, в том числе с изменением структуры данных. Но я как-то уже здесь выкладывал (или нет) последовательность работ на производстве по изменению структуры данных в СУБД комплекса. Так вот на собственно ALTER TABLE или что-то там уходит исчезающе малое время, по сравнению с кучей согласований, проверок, выверок, тестирования, и так далее, включая безопасность и прочее. И если будет не три, допустим, часа, на ALTER TABLE (с перегрузкой данных), а день на написание программы перегрузки из старой структуры в новую.... плюс час-два на перегруз самих данных... Всё одно ещё не все причастные успеют документацию прочитать. То, что телодвижений больше - факт. Ну так и результат по итогам стоит того. А по факту, Рик Лонг, австралиец, создал структуру и асм код по загрузке данных в неё из поставки наш КЛАДР в такой срок, что я немного был офигевший. Это был ещё один аргумент в пользу асма в нашем с мэтром споре. Такое впечатление, что человек на АСМе думает.
кстати, про КЛАДР вспомнилось, если кто его ещё помнит. Немало на форумах sql.ru было копий сломано по поводу оптимального отображения КЛАДР в реляционке. в ИМС получилось на удивление просто и красиво, если провести аналогию - то одна таблица, ссылающаяся на саму себя (хоть таблиц в ИМС и нету), это на физическом уровне, а на логическом - развёрнутая КЛАДРовская иерархия. И если такое же повторить в РДБМС, то производительность будет... Мягко говоря, не сравнимая с ИМС, ну оно и понятно. В принципе, можно поднять исходник и на примере разобрать, как построена та структура, если интересно. В каком-нить пивбаре (ок, согласен на чайно-коньячную).
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
Ибо что такое SYSPLEX знает только узкий круг "посвященных", при этом реально его "щупали" еще меньшее количество. И там нет никаких сравнений. 
