Комментарии 75
Я честно прочитал это, и оно было интересным, но есть фундаментальный вопрос: а зачем под это писать? Программисту понятно — за это ЗП платят. А зачем банку инвестировать в такую технологию? Неужели, для поддержки отечественного производителя волокуш?
Фундаментальный ответ — банк давным-давно инвестировал в инфраструктуру на основе IBM AS/400+DB2, и для того чтобы соскочить с этого надо… ну в общем в масштабе альфабанка проще будет банк закрыть и открыть новый с нуля. Потому что ЦБС — это основа всего.
Это самый простой ответ. Но на самом деле он требует разбора:
а) Инвестиции в железо и купленный так велики, что перекрывают все остальные инвестиции в банк?
б) Инвестиции в самописный софт…
… который не может портироваться ни подо что, от слова «вообще», и не может быть модифицирован? Вот этой части я не понимаю. Бизнес-логика же не должна быть завязана на особенности ОС.
Или я всё-таки что не понимаю в устройстве банковского софта?
а) Инвестиции в железо и купленный так велики, что перекрывают все остальные инвестиции в банк?
б) Инвестиции в самописный софт…
… который не может портироваться ни подо что, от слова «вообще», и не может быть модифицирован? Вот этой части я не понимаю. Бизнес-логика же не должна быть завязана на особенности ОС.
Или я всё-таки что не понимаю в устройстве банковского софта?
This is not specific to Banking systems, but those applications back then pursued performance and stability versus flexible business process, and expandability.
In my old workplace there was a system that counted monthly turnover and other stuff for various companies. the process hasn't changed for over 40 years. Thus there is no reason to change the system. Also things like bugs in code, if there are any, we would rather keep consistent error margin rather than risk having other unknown bugs affect the result.
With this kind of system you can't thing in terms of multiple applications, this is not a PC. This mainframe does, lets say plane ticket bookings, and this is all it will ever do. So you have to sacrifice everything for performance.
Sorry for the English, don't have a Russian keyboard on hand :)
In my old workplace there was a system that counted monthly turnover and other stuff for various companies. the process hasn't changed for over 40 years. Thus there is no reason to change the system. Also things like bugs in code, if there are any, we would rather keep consistent error margin rather than risk having other unknown bugs affect the result.
With this kind of system you can't thing in terms of multiple applications, this is not a PC. This mainframe does, lets say plane ticket bookings, and this is all it will ever do. So you have to sacrifice everything for performance.
Sorry for the English, don't have a Russian keyboard on hand :)
This is one approach: If it works, do not touch it. On another hand author in the original article pointed to 'java6 applicaiton'. I suspect, that many other components are getting old. Getting old means 'no upstream support'. No upstream support means no updates, including CVE.
I could guess that 'if you have access to this thing, than it's a gameover, close the bank', but vulnerabilities may arises from a rather unexpected sources, and system with no update has many known CVEs. I think, this puts system to a risk of another scale.
… And we even hadn't started to cound geo-political risks. How about sanction-induced revocation of the license for 'i'?
I could guess that 'if you have access to this thing, than it's a gameover, close the bank', but vulnerabilities may arises from a rather unexpected sources, and system with no update has many known CVEs. I think, this puts system to a risk of another scale.
… And we even hadn't started to cound geo-political risks. How about sanction-induced revocation of the license for 'i'?
Представьте себе, что компании, в которой вы работаете, предложили переехать с AIX@Power на, скажем, Minix@ARM. Компиляторы C и C++ дадут. Нет, про Go, Java и Python забудьте. Софт у вас самописный, придётся переписать. Основная база — Progress, заметная часть низкоуровневой логики живёт в хранимых процедурах. Миграция должна быть он-лайн; замедление или перерывы обслуживания не допускаются. Да, и часть сервисов должны обеспечивать соответствие PCI DSS. Руководство понимает, что переезд будет стоить как поддержка и развитие существующей инфраструктуры в течение следующих 30 лет, но всё равно решилось на такой шаг. Пойдёте отговаривать?
Если есть Си, будет и питон. В целом, «тупик и выхода нет» это всегда плохо, но из тупика может быть всегда выход в умершее железо, санкции и закрытие IBM'ом кусочка своего бизнеса (не важно по какой причине).
Мне очень грустно видеть, что кто-то свой бизнес настолько завязывает на одного вендора.
Мне очень грустно видеть, что кто-то свой бизнес настолько завязывает на одного вендора.
Мне очень грустно видеть, что кто-то свой бизнес настолько завязывает на одного вендора.А мне грустно видеть, что вы за деревьями не видите леса. Платформа вышла больше 30 лет назад. И всё что вы писали под неё всё это время — вы можете использовать и сегодня. Несмотря на несколько смен CPU и прочего.
А сколько других платформ, с множеством поставщиков, за это время появилось и умерло? Назовите вообще хоть одну другую платформу позволяющую использовать бинарники, созданные 30 лет назад без перекомпиляции! И не в режиме «запустим эмулятор X под эмулятором Y и там будем пускать ваш старый софт» (а новые модули кто и как к этому будет прикручивать?), а в режиме «купили железо, заменили — всё дальше продолжило работать»?
Преимущество Windows перед всякими бесплатными GNU/Linux'ами — в стабильности (на уровне ядра у Linux'а всё хорошо, но вот разработчики Desktop'а, со своим бессметрным CADT, казалось, все свои усилия много лет тратили на то, чтобы их разработками никто-никто не смог воспользоваться), но по сравнению с AS/400 Windows — это просто бабочка-однодневка.
Linux — это уже давно не Cascade of Attention-Deficit Teenagers. Сейчас ее развивают и поддерживают крупные корпорации, в том числе и IBM. Что касается «стабильности» винды — запустите что-нибудь из эпохи XP под десяткой. А прошло всего каких-то 15 лет.
Что касается «стабильности» винды — запустите что-нибудь из эпохи XP под десяткой.Что конкретно предлагается запустить? Delphi и MS Office работают, Visual Basic 6 — тоже. Чаще всего бывают неполадки с инсталляторами, но, в общем, преодолимые.
Кстати Windows XP вышла в 2001м году, так что прошло уже заметно больше 15 лет.
Сейчас ее развивают и поддерживают крупные корпорации, в том числе и IBM.У RHEL нет версии для десктопа, а Fedora — это как раз типичнейшый CADT и есть.
Если есть Си, будет и питонупс. Покажите мне Питон на STM32 под FreeRTOS, плиз…
Мне очень грустно видеть, что кто-то свой бизнес настолько завязывает на одного вендора.Особенно, если это IBM/PC. Что из написанного вами пойдет не на персоналках? Ну скажем на ту же AS/400 что перенести сумеете?
Большая ЭВМ — это не персоналка, там совсем иной подход. Решения с микроэвм на неё не переносятся.
Ну только STM32F4 вижу. И вроде не FreeRTOS, но портировать можно. 16К ОЗУ и 256К ПЗУ — довольно много, ПЗУ, конечно. Это ведь без пользовательского кода, только интерпретатор.
Тем не менее, питон для STM32, для FreeRTOS можно адаптировать (потому что на голом железе оно уже работает), а то, что интерпретатор жрет — мало кто ожидал что жрать будет не мегабайты.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
мало кто ожидал что жрать будет не мегабайты.Ну вот потому мне и не кажется верной фраза: Если есть Си, будет и питон
I'd quit before that happened. We were migrating AIX on Power8 to RHEL on x86 ingres databases, stored procedures, sqlca, some COBOL(don't ask). Can't drop service standard, all outputs require extensive regression testing over 6 months to prove the new system. Yeh, after 3 months they decided to kill that idea.
Это всё возможно. Если перераспределить деньги от зам. директора, радостно меняющего мерс amg на порш — к программистам.
Вот и мы так переезжаем. Маленькая компания, которая 30+ лет назад сделала систему, до сих пор самую популярную в нашем бизнесе. Изначальный стек: OS/400 COBOL/RPG (даже никакого C). Лет 15 назад компания начала всё переписывать на другой проприетарный язык Lansa. 3 года назад начали переписывать на Java. Последние User Facing приложения из GS мы переписали только в прошлом году. И сейчас система выглядит как Веб приложение в перемешку Lansa и совсременные компоненты. Но куча Batch Processing и Triggers, до сих пор живут как ни в чём не бывало (уже не счесть сколько раз я проклинал Triggers). И даже сама Lansa/Java (которая крутится тоже на Power8) пока делают нейтив вызовы к некоторым Legacy компонентам.
Проблема с которой столкнулась компания: у нас в городишке все кто умеет работать с Cobol/RPG уже на пенсии либо работают у нас и тоже скоро на пенсию. Учить это, а тем более писать на нём, никто в здравом уме не будет.
Ну а в сопуствие весь букет проблем связанных с legacy:
— деды которые ещё работали на оригинальном GS не понимают как работает современный веб и банальное перемещение поля из левого угла на 40 px ниже вызывает взрыв звонков в саппорте
— молодеж, которую кастомеры нанимают к себе, нужно учить к Legacy подходу для тех компонентов, которые пока не переписаны
— воспроизведение очевидных багов Legacy в новом коде, потому что 30 лет они доказывали что это «не баг, а фича»
Проблема с которой столкнулась компания: у нас в городишке все кто умеет работать с Cobol/RPG уже на пенсии либо работают у нас и тоже скоро на пенсию. Учить это, а тем более писать на нём, никто в здравом уме не будет.
Ну а в сопуствие весь букет проблем связанных с legacy:
— деды которые ещё работали на оригинальном GS не понимают как работает современный веб и банальное перемещение поля из левого угла на 40 px ниже вызывает взрыв звонков в саппорте
— молодеж, которую кастомеры нанимают к себе, нужно учить к Legacy подходу для тех компонентов, которые пока не переписаны
— воспроизведение очевидных багов Legacy в новом коде, потому что 30 лет они доказывали что это «не баг, а фича»
>Вот этой части я не понимаю. Бизнес-логика же не должна быть завязана на особенности ОС.
Бизнес-логика примерно такова:
Есть ЦБС, система в которой ведутся счета. Времена, когда ее могли написать на фокспро давно прошли, щас это должна быть аццкая транзакционная сотона которая оперирует миллионами счетов, логирует всё и не имеет права на ошибки. Это — основа банка, как фундамент — основа здания; разрабатывают такие системы не так уж много фирм, и выбрав одну — на что-то другое перескочить практически нереально, не останавливая банк — нереально практически совсем, в случае крупного банка — нереально ваааще, даже в подвиндовом мире, потому что вокруг конкретной ЦБС и ее особенностей накручивается со временем столько всего, что это всё проще закрасить чем отскребать. Это, кстати, работает в обе стороны, если с PC-шной ЦБС в уже сложившейся среде пытаться переехать на IBM — тоже получится исключительно трэш угар и содомия.
В случае инфраструктуры на AS/400 это усугубляется еще и тем что их система очень сильно заточена в производительность в режиме мультидоступа, и если например позаменять у всех операторов во всех филиалах большого банка старообрядный зеленый экран терминала с формами какого-нибудь Equation'а на современные модные воздушные material'ные вебинтерфейсы — то сети банка сильно поплохеет.
Таковы они, суровые реалии-с кровавого энтерпрайза, легаси и промышленных систем.
Бизнес-логика примерно такова:
Есть ЦБС, система в которой ведутся счета. Времена, когда ее могли написать на фокспро давно прошли, щас это должна быть аццкая транзакционная сотона которая оперирует миллионами счетов, логирует всё и не имеет права на ошибки. Это — основа банка, как фундамент — основа здания; разрабатывают такие системы не так уж много фирм, и выбрав одну — на что-то другое перескочить практически нереально, не останавливая банк — нереально практически совсем, в случае крупного банка — нереально ваааще, даже в подвиндовом мире, потому что вокруг конкретной ЦБС и ее особенностей накручивается со временем столько всего, что это всё проще закрасить чем отскребать. Это, кстати, работает в обе стороны, если с PC-шной ЦБС в уже сложившейся среде пытаться переехать на IBM — тоже получится исключительно трэш угар и содомия.
В случае инфраструктуры на AS/400 это усугубляется еще и тем что их система очень сильно заточена в производительность в режиме мультидоступа, и если например позаменять у всех операторов во всех филиалах большого банка старообрядный зеленый экран терминала с формами какого-нибудь Equation'а на современные модные воздушные material'ные вебинтерфейсы — то сети банка сильно поплохеет.
Таковы они, суровые реалии-с кровавого энтерпрайза, легаси и промышленных систем.
Плюс всякая политика внутренних отделов, IT против безопастников, Ильина Матвеевна — ведущий программист, писала систему аж с 74 года, вся документация у нее. И огромное количество очень дорогих контактов проплаченных на 5 -10 лет, и проблемы с нахождением альтернативы.
А кстати, Актиан (разрабы Ingres ) сделали сервис где на твой зелёный терминал нахлобучат этот ваш материал дизайн и все вроде даже заработает. За совершенно символическую плату. Ну так и зачем вам менять свой старый мейнфрейм? :) А Ирина Матвеевна может продолжить работать на глупом терминале.
Там еще, кроме софтверной части, есть железная часть. Отказоустойчивость внутри этого шкафа, возможность горячей замены процессоров, памяти, интерфейсных плат и т.п. без остановки бизнес-процессов или отключения пользователей.
Мелочи вроде LPAR, когда в одном шкафу могут жить 3-5 ОС, на которых работают бизнес-приложения, не мешая друг другу без возможности залезть из памяти Linux в память Windows Server в другой партиции.
Ну и еще, вспоминая дела давно минувших дней, был я как-то в 90-х на презентации IBM про тогда еще AS/400. Особенно запомнилась фраза презентующего: «Если на виндоус сервере у вас загрузка процессора больше 50% — у вас где-то есть проблемы и все страшно тормозит. Если на мэйнфрейме у вас загрузка процессора меньше 100% — где-то оборвался коммуникационный кабель.»
Мелочи вроде LPAR, когда в одном шкафу могут жить 3-5 ОС, на которых работают бизнес-приложения, не мешая друг другу без возможности залезть из памяти Linux в память Windows Server в другой партиции.
Ну и еще, вспоминая дела давно минувших дней, был я как-то в 90-х на презентации IBM про тогда еще AS/400. Особенно запомнилась фраза презентующего: «Если на виндоус сервере у вас загрузка процессора больше 50% — у вас где-то есть проблемы и все страшно тормозит. Если на мэйнфрейме у вас загрузка процессора меньше 100% — где-то оборвался коммуникационный кабель.»
До Equation у Альфа-Банка был… Clipper (на нём шкипер, а у шкипера триппер) под Novell. Размеры DBF файлов были под 2Гб, Computer Associates честно сказал, что на базы таких размеров их продукт не рассчитан. Если на такой базе падал индекс это было «ой». Процесс стопился. Процесс переиндексации занимал несколько часов, банк курил бамбук и вёл операции на бумаге. Потом парни написали тулзу, которая умела оперативно перестраивать только битую часть индексов, жить стало легче, жить стало веселей. И вся эта веселая хрень творилась с 92 по 99 год. А потом случился кризис 98 года, и банк в 99 году начал открывать филиалы, и тут выяснилось, что их хренопись собственной разработки под названием А-Банк, очень плохо подходит для филиальной сети. Что у банка кроме милых гафинских роликов Let my people go по большому счёту ничего нет. Раздалась вполне разумная критика с мест — что если один здоровенный файл со всеми проводками поделить хотя бы по годам, то А-Банк — сляпанный из совершенно разномастных, вырвиглазных приложений, будет падать не так часто и даже работать, не ломая индексы.
И это уже не говоря о том, что филиалами надо было самим писать ПО для расчетов через местные РКЦ ЦБ РФ. Я сам лично нашёл ошибку в функции расчёта контрольной цифры банковского счёта, которую 7 лет не могли найти программисты из ЦО. «Ну да, у нас иногда бывало такое, что некоторые заведённые у нас счета не проходили контроль в РПУ2» (по моему так называлось московское РКЦ, работавшее с крупными банками), «перезаводили такие счета в системе для частных вкладов (Esc/M), там всё получалось правильно». Вот такое было качество кода у АБС Альфа-Банка. Зато с какими сложными щщами ходили начальники отделов — это вам не весёлые и умные раздолбаи из «Российского Кредита», АБС у которых пахала на Sun Solaris и Oracle 7 («Симболино, сынок...» как мы ласково называли адаптированную Форс сингапурскую АБС Symbols. Офигенная штука, к которой мы дописали автоматическую систему резервирования, которая по-моему до сих пор работает в Авангарде. Веселые времена были.
Так что для Альфы внедрение Equation на OS/400 в конце двухтысячных было гигантским шагом вперёд. А иначе до сих пор бы сидели на Клиппере с его dBase4 DBF. Хотя не, потуги у ребят были. Они честно пытались наваять А-Банк на Informix. Informix был хорошей СУБД с отвратительными средствами разработки, которые были на голову хуже терминальной Oracle*Forms даже самой первой версии. Оконные интерфейсы на Информиксе надо было полностью писать вручную. Как я обрадовался, что IBM приобрел это чучело и прибило его, чтобы оно не болталось под ногами у DB2.
Веселые времена были.
И это уже не говоря о том, что филиалами надо было самим писать ПО для расчетов через местные РКЦ ЦБ РФ. Я сам лично нашёл ошибку в функции расчёта контрольной цифры банковского счёта, которую 7 лет не могли найти программисты из ЦО. «Ну да, у нас иногда бывало такое, что некоторые заведённые у нас счета не проходили контроль в РПУ2» (по моему так называлось московское РКЦ, работавшее с крупными банками), «перезаводили такие счета в системе для частных вкладов (Esc/M), там всё получалось правильно». Вот такое было качество кода у АБС Альфа-Банка. Зато с какими сложными щщами ходили начальники отделов — это вам не весёлые и умные раздолбаи из «Российского Кредита», АБС у которых пахала на Sun Solaris и Oracle 7 («Симболино, сынок...» как мы ласково называли адаптированную Форс сингапурскую АБС Symbols. Офигенная штука, к которой мы дописали автоматическую систему резервирования, которая по-моему до сих пор работает в Авангарде. Веселые времена были.
Так что для Альфы внедрение Equation на OS/400 в конце двухтысячных было гигантским шагом вперёд. А иначе до сих пор бы сидели на Клиппере с его dBase4 DBF. Хотя не, потуги у ребят были. Они честно пытались наваять А-Банк на Informix. Informix был хорошей СУБД с отвратительными средствами разработки, которые были на голову хуже терминальной Oracle*Forms даже самой первой версии. Оконные интерфейсы на Информиксе надо было полностью писать вручную. Как я обрадовался, что IBM приобрел это чучело и прибило его, чтобы оно не болталось под ногами у DB2.
Веселые времена были.
Наверное, не очень понимаете.
Банковский софт должен быть
а) Надежным
б) Еще раз надежным
в) И еще раз надежным.
Т.е. превыше всего надежность. Если тот софт, что пишется внутри банка собственными силами и/или вендорами можно оттестировать на надежность (а тестирование там проводится специально обученными людьми и не в один этап — компонентное, интеграционное, бизнес, нагрузочное...) то надежность платформы на которой все это крутится должна обеспечиваться ее производителем.
И данная платформа (IBM i) достаточно надежна ибо разрабатывалась не под бытовые нужды, а для высокопроизводительных коммерческих серверов.
Что касается собственно АБС (автоматизированной банковской системы). Данная АБС есть система реального времени. Т.е. пользовательские операции тут совершаются не «с 4-х утра до полуночи», а круглосуточно. Даже при том, что сведение баланса (ежемесячный кошмар бухгалтера) в банке происходит ежедневно.
Чего стоит это реальное время для системы… Об этом лучше не говорить ибо в двух словах не описать :-)
Ну и на самом деле бизнес-логика на особенности ОС никак не завязана. Завязана ее конкретная реализация. И не столько на особенности ОС, сколько на особенности используемой банков АБС. А та или иная АБС используется любым банком ибо написать все с нуля своими силами нереально. И ни о каком порте тут речи быть не может.
Ну а что касается темы статьи — тут речь идет не о бизнес-логике, а о том самом тестировании. Без которого ни одна поставка не уйдет в бой. И о посильной автоматизации этого тестирования. Ибо куда проще и спокойнее дорабатывать поставку с тестов, чем бросать все и кидаться срочно затыкать дефект боя (когда некорректная работа обнаруживается уже в промышленной эксплуатации и сказывается на клиентах, вызывая их негативную реакцию и ущерб репутации банка).
Банковский софт должен быть
а) Надежным
б) Еще раз надежным
в) И еще раз надежным.
Т.е. превыше всего надежность. Если тот софт, что пишется внутри банка собственными силами и/или вендорами можно оттестировать на надежность (а тестирование там проводится специально обученными людьми и не в один этап — компонентное, интеграционное, бизнес, нагрузочное...) то надежность платформы на которой все это крутится должна обеспечиваться ее производителем.
И данная платформа (IBM i) достаточно надежна ибо разрабатывалась не под бытовые нужды, а для высокопроизводительных коммерческих серверов.
Что касается собственно АБС (автоматизированной банковской системы). Данная АБС есть система реального времени. Т.е. пользовательские операции тут совершаются не «с 4-х утра до полуночи», а круглосуточно. Даже при том, что сведение баланса (ежемесячный кошмар бухгалтера) в банке происходит ежедневно.
Чего стоит это реальное время для системы… Об этом лучше не говорить ибо в двух словах не описать :-)
Ну и на самом деле бизнес-логика на особенности ОС никак не завязана. Завязана ее конкретная реализация. И не столько на особенности ОС, сколько на особенности используемой банков АБС. А та или иная АБС используется любым банком ибо написать все с нуля своими силами нереально. И ни о каком порте тут речи быть не может.
Ну а что касается темы статьи — тут речь идет не о бизнес-логике, а о том самом тестировании. Без которого ни одна поставка не уйдет в бой. И о посильной автоматизации этого тестирования. Ибо куда проще и спокойнее дорабатывать поставку с тестов, чем бросать все и кидаться срочно затыкать дефект боя (когда некорректная работа обнаруживается уже в промышленной эксплуатации и сказывается на клиентах, вызывая их негативную реакцию и ущерб репутации банка).
Ну еще банку надо оперативно реагировать на инструкции ЦБ, а если понять статью буквально, то получается там в Альфе есть команда разработчиков на каком-то AS/400, которая оперативно все имплементит, что ЦБ спускает. И, видимо, справляются.
Так надёжно, производительно и дёшево.
Про банки не скажу, но по своему опыту замены ERP это мероприятие:
1. Очень дорогое (реально хватит чтобы поддерживать legacy еще лет 20)
2. До ужаса рискованное (был случай когда из-за внедрения ERP разорилась крупная сеть аптек, я серьезно это даже в учебники вошло)
3. Очень длительное и требует параллельного допила в Legacy. Нельзя ж запереть 100 программистов в кабинете и через 4 года получить систему т.к к тому времени она тупо морально устареет. Компромиссом является постепенный перенос бизнес процессов и развитие их в новой системе, при этом появляется огромный пласт интеграции между системами.
4. Далеко не всегда приводит к выводу Legacy из эксплуатации. В лучшем случае (повторяю — это самый оптимистичный случай) Legacy система будет жить в полу замороженном состоянии с небольшими вынужденными (не приносящими бизнес профита) допилами.
1. Очень дорогое (реально хватит чтобы поддерживать legacy еще лет 20)
2. До ужаса рискованное (был случай когда из-за внедрения ERP разорилась крупная сеть аптек, я серьезно это даже в учебники вошло)
3. Очень длительное и требует параллельного допила в Legacy. Нельзя ж запереть 100 программистов в кабинете и через 4 года получить систему т.к к тому времени она тупо морально устареет. Компромиссом является постепенный перенос бизнес процессов и развитие их в новой системе, при этом появляется огромный пласт интеграции между системами.
4. Далеко не всегда приводит к выводу Legacy из эксплуатации. В лучшем случае (повторяю — это самый оптимистичный случай) Legacy система будет жить в полу замороженном состоянии с небольшими вынужденными (не приносящими бизнес профита) допилами.
Работал на фирме у которой Самая Важная База Данных крутилась именно на System i.
Как ни странно, но, помимо большого количества Legacy решений, были и другие причины оставаться верным зелёному экрану. IBM железо дорогое, но к нему не нужно докупать лицензии на базы данных — DB2 идёт из коробки. Скорость, надёжность, сложность администрирования — как у конкурентов или лучше. Отдельный важный плюс в хорошем саппорте. Софт и железо идут одним комплексом, что ускоряет и упрощает траблшутинг. Не возникает футбола, когда продавец бд посыдает к железячнику, а железячник клянётся мамой, что с их стороны всё хорошо, а глючит ПО.
Жирных минусов лично я вижу два. Первое это вендор лок. Второе, гораздо более важное, это недостаток профильных сисадминов (даже не программистов, программисты есть) на рынке. Имеющиеся специалисты стремительно приближаются к пенсионному возрасту, а молодёжь не торопится связывать свою карьеру с зелёным экраном. При чём руководство проблему видит и готово вкладываться в обучение джунов, но желающих всё равно не густо.
Как ни странно, но, помимо большого количества Legacy решений, были и другие причины оставаться верным зелёному экрану. IBM железо дорогое, но к нему не нужно докупать лицензии на базы данных — DB2 идёт из коробки. Скорость, надёжность, сложность администрирования — как у конкурентов или лучше. Отдельный важный плюс в хорошем саппорте. Софт и железо идут одним комплексом, что ускоряет и упрощает траблшутинг. Не возникает футбола, когда продавец бд посыдает к железячнику, а железячник клянётся мамой, что с их стороны всё хорошо, а глючит ПО.
Жирных минусов лично я вижу два. Первое это вендор лок. Второе, гораздо более важное, это недостаток профильных сисадминов (даже не программистов, программисты есть) на рынке. Имеющиеся специалисты стремительно приближаются к пенсионному возрасту, а молодёжь не торопится связывать свою карьеру с зелёным экраном. При чём руководство проблему видит и готово вкладываться в обучение джунов, но желающих всё равно не густо.
Такое во всем мире происходит. В той же США работают сервера 30 летний давности и никто их не берется менять или модернизировать ПО, поскольку оно и так прекрасно работает, а если уже и апать систему, то проще будет построить новую экономику, чем модернизировать текущее. Иными словами это нерентабельно для корпораций.
В хабра-хабровцев вселилиьсь бесы… Минусовать это?
Я однажды в самом начале 90-х подрабатывая типа гидом-переводчиком общался с буржуем. У него был успешный бизнес, который обеспечивал ему безбедную жизнь и возможность ездить по странам, которые ему были интересны. У него был один компьютер на весь его успешный бизнес. Кажется что-то типа PC-XT с хардом на 40 мегов. На мое удивление, он ответил, что его программа учета прекрасно работает. А что еще нужно? Я не осилил тогда ему вразумительно ответить, зечем нужно что-то более крутое. И сейчас бы я тоже, вряд ли бы смог дать однозначный ответ.
Я однажды в самом начале 90-х подрабатывая типа гидом-переводчиком общался с буржуем. У него был успешный бизнес, который обеспечивал ему безбедную жизнь и возможность ездить по странам, которые ему были интересны. У него был один компьютер на весь его успешный бизнес. Кажется что-то типа PC-XT с хардом на 40 мегов. На мое удивление, он ответил, что его программа учета прекрасно работает. А что еще нужно? Я не осилил тогда ему вразумительно ответить, зечем нужно что-то более крутое. И сейчас бы я тоже, вряд ли бы смог дать однозначный ответ.
Отличный рассказ про лютейший легаси! :) У меня похожая система была: Ingres ABF на IBM Aix. И очень не хватало инструментов для тестирования таких интерфейсов. Автор молодец!
Я конечно не настоящий сварщик (с), но в статье приводится пример успешной ит-некрофилии. Как бы не была красива бортпроводница, её стоит закопать.
/хмыкая/
Мир состоит не из одного вебдезаена, бизнес считает деньги, и подобные предложения встречает вопросом «а кто за это будет платить?» И таких стюардесс в мире реального успешного бизнеса — чуть менее чем дохрена.
Ну и эта, вы догадываетесь за чей счет будут похороны стюардессы если с AS/400 решит соскочить тот же, афаик, сбер?..
Мир состоит не из одного вебдезаена, бизнес считает деньги, и подобные предложения встречает вопросом «а кто за это будет платить?» И таких стюардесс в мире реального успешного бизнеса — чуть менее чем дохрена.
Ну и эта, вы догадываетесь за чей счет будут похороны стюардессы если с AS/400 решит соскочить тот же, афаик, сбер?..
Ну это вы здря.
Я не по наслышке знаю, что творится в альфе и в сбере. Ребят которые там работают иногда и пожалеть хочется, особенно эксплуатационников. Какую только древность не реанимируют ежедневно. Бывают дни когда вообще нет времени не то что чай попить или покурить, а и до белого друга добежать. В том же альфе огромная потребность в новых исправных решениях. Проблема в том, что новые решения не то чтоб не соответствуют специфике, новые решения вообще невозможно интегрировать ни в существующую систему ни в новую. Множество решений на рынке вообще малоприминимы ни в широком смысли ни в узком сегменте. Буквально десять заказчиков на весь земной шар.
Я не по наслышке знаю, что творится в альфе и в сбере. Ребят которые там работают иногда и пожалеть хочется, особенно эксплуатационников. Какую только древность не реанимируют ежедневно. Бывают дни когда вообще нет времени не то что чай попить или покурить, а и до белого друга добежать. В том же альфе огромная потребность в новых исправных решениях. Проблема в том, что новые решения не то чтоб не соответствуют специфике, новые решения вообще невозможно интегрировать ни в существующую систему ни в новую. Множество решений на рынке вообще малоприминимы ни в широком смысли ни в узком сегменте. Буквально десять заказчиков на весь земной шар.
Будете смеяться, но в Сбере нет ни одного приложения, заточенного на специфическую аппаратную платформу. Правда, там есть нагруженные БД, для которых не существует адекватной x86 машины, но с Aix на Solaris и обратно эти базы ездят легко.
Вы, вероятно, путаете некрофилию и некромантию. Здесь нет нездорового интереса, здесь циничная прагматика без модного пафоса. Если зомби послушны, не устают и не спят — зачем их заменять кем-то голодным, своенравным и состоящим в профсоюзе?
Удалено.
любой школьник может написать бот кликер для Eve Online.
а вот бот-кликер для эмулятора зеленеого терминала — ах это так сложно.
а вот бот-кликер для эмулятора зеленеого терминала — ах это так сложно.
Когда-то, в 99-ом, 2000-ом годах принимал участие в разработке банковского софта, который был портирован в т.ч. под ас/400. Может это оно… Помнится, тогда этот самый ас приехал и стоял недолго прям-таки в нашей комнате.
Тестирование зелёного экрана, кстати, ещё можно так делать: нужно всё взаимодействие с дисплейным файлом (exfmt, read, write, etc) делать строго с указанием ds-ок для ввода и вывода. Каждая ситуация, когда пользователю даётся шанс на взаимодействие с экраном, выносится в отдельную процедуру. При этом можно добавить if defined так, чтобы при компиляции с проставлением define'а в духе «TEST» вместо ввода-вывода через дисплейник вызывалась тестовая процедура (которая благодаря /if defined(TEST) в прод-версию вообще не попадёт). Что-то в таком духе (могут быть ошибки, пару лет зелёный экран в руки не брал):
Это не совсем то, что у вас, конечно, зато дико быстро. Если в дисплейнике какое-нибудь поле запротектить или функциональную клавишу запретить, то GUI сломается, однако такого сорта тесты будут продолжать проходить. Но логику с валидациями так можно отлично тестировать.
В духе на экране нужно указать счёт, БИК и сумму для перевода. В дисплейнике это, пусть, fooACC, fooBIK, fooAMT. В OUTPUT-рекорд формате будут все функциональные индикаторы и эти поля. Поэтому можно написать тесты для реакции на ответы с взведёнными *in03, *in12, разнообразным трешем в fooACC, fooBIK, fooAMT и т.д.
Если везде аккуратно ставить LikeRec и Like, а также не использовать явные координаты в структурах, то это всё отлично переживает и изменения структуры базы, и изменения в дисплейнике.
P GUI_FOO B
D GUI_FOO PI
D inDS LikeRec(DSPF.REC:INPUT)
D outDS LikeRec(DSPF.REC:OUTPUT)
/if not defined(TEST)
write DSPF.REC inDS;
read DSPF.REC outDS;
/else
outDS = Mock();
/endif
P GUI_FOO E
P Mock B
D Mock PI
D outDS LikeRec(DSPF.REC:OUTPUT)
outDS.in03 = *On;
outDS.fooACC = '47202810000000000000';
outDS.fooAMT = '123.123';
P Mock E
Это не совсем то, что у вас, конечно, зато дико быстро. Если в дисплейнике какое-нибудь поле запротектить или функциональную клавишу запретить, то GUI сломается, однако такого сорта тесты будут продолжать проходить. Но логику с валидациями так можно отлично тестировать.
В духе на экране нужно указать счёт, БИК и сумму для перевода. В дисплейнике это, пусть, fooACC, fooBIK, fooAMT. В OUTPUT-рекорд формате будут все функциональные индикаторы и эти поля. Поэтому можно написать тесты для реакции на ответы с взведёнными *in03, *in12, разнообразным трешем в fooACC, fooBIK, fooAMT и т.д.
Если везде аккуратно ставить LikeRec и Like, а также не использовать явные координаты в структурах, то это всё отлично переживает и изменения структуры базы, и изменения в дисплейнике.
А вообще мне безумно грустно за AS/400 и RPGLE. Крутейшая платформа, хороший язык. Только платформе не хватает какой-нибудь более разумной ценовой политики (а не вот это «вам нужно поменять CDROM, это будет стоить 1000$, плюс обязательно оплатить поддержку за последние 5 лет, то есть 30000$»).
А ещё платформе не хватает нормальных «разрешений» зелёного экрана: не 27x132, а 40×200, грубо говоря. Текстовые интерфейсы дико быстрые и удобные для операционистов. Все эти модные анимации, выпадушечки и т.п. из браузера для работы операциониста не нужны, а нужно 100% надёжная, быстрая и предсказуемая работа с клавиатуры…
А языку не хватает нормальной стандартной библиотеки.
А ещё платформе не хватает нормальных «разрешений» зелёного экрана: не 27x132, а 40×200, грубо говоря. Текстовые интерфейсы дико быстрые и удобные для операционистов. Все эти модные анимации, выпадушечки и т.п. из браузера для работы операциониста не нужны, а нужно 100% надёжная, быстрая и предсказуемая работа с клавиатуры…
А языку не хватает нормальной стандартной библиотеки.
Да, платформу убивают. Там пооставались одни пенсионеры. Бас фактор для ряда продуктов реально равен 1.
> А ещё платформе не хватает нормальных «разрешений» зелёного экрана: не 27x132, а 40×200, грубо говоря.
Как человек, который последние лет 10 предпочитает не работать с текстом более чем 25x80, не соглашусь.
Местами нужно впихивать много текста, да. Но основной интерфейс перегружать нельзя.
А лучше таки переходить на графику — не зря ведь её так долго и тщательно изобретали, начиная с бумажных бланков. Только продумать, а не свистелки-прыгалки накидывать.
> Текстовые интерфейсы дико быстрые и удобные для операционистов.
Эти свойства ортогональны текстовости. Современные массовые графические интерфейсы, да, не рассчитаны на гарантию быстрой и адекватной реакции; например, когда посреди набора поля всплывает окно «вам письмо» и забирает на себя фокус. Профессиональные интерфейсы не должны такого давать, но и не должны быть ограничены текстом.
Формат терминалов IBM, да, способствует тут нормальной работе — когда текст вводится в локальном поле и потом идёт сигнал в центр с готовым результатом, а не нажали клавишу и ждём, когда пройдёт через tty, его дисциплину, код libreadline и т.д. Но он соответственно и ограничен.
На сейчас можно было бы вполне сделать в самом терминале логику совмещения и оперативности и надёжности действий, и расширить её на любые графические объекты. Видимо, не было пока настолько платёжеспособного запроса.
Как человек, который последние лет 10 предпочитает не работать с текстом более чем 25x80, не соглашусь.
Местами нужно впихивать много текста, да. Но основной интерфейс перегружать нельзя.
А лучше таки переходить на графику — не зря ведь её так долго и тщательно изобретали, начиная с бумажных бланков. Только продумать, а не свистелки-прыгалки накидывать.
> Текстовые интерфейсы дико быстрые и удобные для операционистов.
Эти свойства ортогональны текстовости. Современные массовые графические интерфейсы, да, не рассчитаны на гарантию быстрой и адекватной реакции; например, когда посреди набора поля всплывает окно «вам письмо» и забирает на себя фокус. Профессиональные интерфейсы не должны такого давать, но и не должны быть ограничены текстом.
Формат терминалов IBM, да, способствует тут нормальной работе — когда текст вводится в локальном поле и потом идёт сигнал в центр с готовым результатом, а не нажали клавишу и ждём, когда пройдёт через tty, его дисциплину, код libreadline и т.д. Но он соответственно и ограничен.
На сейчас можно было бы вполне сделать в самом терминале логику совмещения и оперативности и надёжности действий, и расширить её на любые графические объекты. Видимо, не было пока настолько платёжеспособного запроса.
Текстовые интерфейсы дико быстрые и удобные для операционистов.Не скажу за операционистов, а саппорт рядом сидит. И от вида того, что они в этой консоли набирают — волосы дыбом встают в неожиданных местах и тайком крестишься, в надежде, что прям сейчас дьявола не вызовут.
НГДБР 211, РР, 25 DD5!, прости господи…
Такое чувство, что в Альфе вообще не осталось никого, кто профессионально работает на as400. Пришла какая-то комманда пионеров-хипстеров и начала «креативить».
На самом деле изобретали велосипед. В pcom есть библиотека, в которой с древних времен нв VB отлично пишутся любые экранные скрипты. Не нравится VB — можно через обертку на питоне, например. Не нравится вин — есть бесплатная опенсоурсная реализация tn5250, где опять же имеется API.
Если не нравиться jt400, есть отличная опенсоурсная альтернатива (опять же от IBM).
Вообще, лет 20 назад, мне предлагали работать в альфе как раз в команде as400. Но платили что-то не очень, так что не срослось. Интересно, там ведь еще остались люди, пишущие на RPG и все вот это вот? Или все уже на пенсии?
На самом деле изобретали велосипед. В pcom есть библиотека, в которой с древних времен нв VB отлично пишутся любые экранные скрипты. Не нравится VB — можно через обертку на питоне, например. Не нравится вин — есть бесплатная опенсоурсная реализация tn5250, где опять же имеется API.
Если не нравиться jt400, есть отличная опенсоурсная альтернатива (опять же от IBM).
Вообще, лет 20 назад, мне предлагали работать в альфе как раз в команде as400. Но платили что-то не очень, так что не срослось. Интересно, там ведь еще остались люди, пишущие на RPG и все вот это вот? Или все уже на пенсии?
vb работает просто ну дико нестабильно. Сам client access — ещё ничего, хотя, конечно, периодически падает. А вот vb в нём для долгих задач ну совсем нестабилен. Нам (не в Альфе) приходилось какие-то вещи так автоматизировать (в духе 10000 сделок в MIDAS ввести), так там половина кода были костыли на всевозможные случаи отказов vb.
Ну, так там vb — только чтобы быстрее попробовать. А писать то можно на чем угодно. Я вот VB не очень, на питоне делал.
Там с новым acs (реинкарнация client acess) и библиотекой pcom есть сложности. Библиотеки автоматизации просто нет.
Midas это райф и раньше юник. В Альфе Эквейжн
Из текста не совсем понятно, они вытащили java библиотеки HLLAPI из acs или hod. Я так понимаю, что из acs — там они должны быть, я думаю. А документацию читали из hod. Хоть бы описали процесс подробно, названия библиотек которые нужно брать… Пользы бы от статьи было больше.
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
Насчет того, почему в банках (и не только банках) до сих пор стоят «динозавры», я объяснил в другом комментарии.
Голубые гиганты не перестанут получать прибыль на «зеленых экранах» еще долго. Хотя, экраны уже давно могут быть не зелеными, а какими угодно.
Голубые гиганты не перестанут получать прибыль на «зеленых экранах» еще долго. Хотя, экраны уже давно могут быть не зелеными, а какими угодно.
А не расскажите, чем эта операционная система принципиально отличается? Я сам застал vax/vms и даже rsx-11m
Почитайте старую добрую книжечку по теме. Там все от «папы» подробно и доступно.
Спасибо! Было интересно почитать.
Да когда-то отсутствие штатного API у абс компенсировалось ком+ компонентой вколачивающей данные в эти экранные формы :)
Ещё одна альтернатива: IBM HATS/WebFacing — штатная вебизация зелёного экрана.
После запуска можно переключится на стандартный стек тестирования с selenium и xpath. Тут и автоматизация быстрее станет.
Более свежая версия конкурента абс Midas от Finastra (ex. Misys) уже лет 10 как ушла от зелёного экрана.
Хотя наверное более свежий Equation тоже с веб формами?
Помню, как оседский админ молился на AS/400. Восторженно говорил много умных слов. Я тогда мало что понимал и не запомнил кроме, что «ещё ни разу не взломали» и что-то о производительности и конечно же — про «вещь в себе». Но некий трепет — остался с того времени остался
А можно поинтересоваться, на какой IBM-овской платформе функционирует сама АБС в её современном виде? AS/400 и тем более System/38 уже давно мертвы…
Спасибо, интересно получилось. Я в другом банке наступал на те же грабли, но не для тестирования интерфейсов, а для малой автоматизации обычных процессов. Сначала через pcom, но он как сказали выше время от времени отваливался, плюс жрал ЦПУ. В итоге плюнул и за 2 месяца разобрал протокол tn5250, написал собственный эмулятор (от чего вы отказались :) ). Всё на коллбэках, поэтому когда возвращался ответ — программа не ждала(никаких sleep), а продолжала выполнять сценарий там, где остановилась. Для ускорения, я из одной программы запускал сразу несколько сессий tn5250, и она переключалась между ними, пока другие ждали ответ от сервера. Методом проб и ошибок выяснил, что больше 6 сессий держать бессмысленно — программа уже не успевала переключаться между потоками.
Скорость действительно запредельная — человек уже точно ничего не поймет, но этого и не надо, ведь вам же нужен результат — выполнено ли(терминал ввёл нужный текст), или нет. И если уж получено не то, что ожидали, то тогда уже поднимать логи.
Странно что вы принудительно ставите задержки, чтобы человек смотрел что там происходит, за 60мс ничего ведь не понять :)
Я сделал так, чтобы он каждые 3 секунды сохранял текст экрана в файлик, или в бд, чтобы можно было человеку посмотреть, почитать чем робот сейчас занят.
Ещё момент — мне кажется, вам тоже стоило заморочиться и свой чистый эмулятор написать, без всего лишнего, я сделал за 2 месяца в паре с wireshark, а вы возможно и того больше, возившись столько с разными вариантами готового ПО.
Кстати, возможно кому-то это покажется диким, но робот был написан на php, тогда ещё на версии 5.4 крутился. Памяти не жрал(всего около 8мбайт), не падал, работал чертовски стабильно. Это к слову тем, кто до сих пор презирает php, что он только для home page годится). Кстати, вот вам и ответ, fukkit на этот комментарий habr.com/ru/post/445380/#comment_19947386
Кстати, в самой Альфе люди даже не знают, что у них есть зелёные экраны. Даже некоторые топ-менеджеры думают, что у них всё работает на Pega )
Скорость действительно запредельная — человек уже точно ничего не поймет, но этого и не надо, ведь вам же нужен результат — выполнено ли(терминал ввёл нужный текст), или нет. И если уж получено не то, что ожидали, то тогда уже поднимать логи.
Странно что вы принудительно ставите задержки, чтобы человек смотрел что там происходит, за 60мс ничего ведь не понять :)
Я сделал так, чтобы он каждые 3 секунды сохранял текст экрана в файлик, или в бд, чтобы можно было человеку посмотреть, почитать чем робот сейчас занят.
Ещё момент — мне кажется, вам тоже стоило заморочиться и свой чистый эмулятор написать, без всего лишнего, я сделал за 2 месяца в паре с wireshark, а вы возможно и того больше, возившись столько с разными вариантами готового ПО.
Кстати, возможно кому-то это покажется диким, но робот был написан на php, тогда ещё на версии 5.4 крутился. Памяти не жрал(всего около 8мбайт), не падал, работал чертовски стабильно. Это к слову тем, кто до сих пор презирает php, что он только для home page годится). Кстати, вот вам и ответ, fukkit на этот комментарий habr.com/ru/post/445380/#comment_19947386
Кстати, в самой Альфе люди даже не знают, что у них есть зелёные экраны. Даже некоторые топ-менеджеры думают, что у них всё работает на Pega )
Работал в крупной корпорации, связавшейся в 70-х с AS/400, и могу сказать, что цена разработки в этой экосистеме запредельно высока не только из-за нехватки кадров, но и из-за устаревших на 50 лет методологий программирования. Решение одной и той же проблемы в современных стеках, даже не важно в каких — будет стоить на несколько порядков(!) меньше. Поэтому я с сомнением смотрю на слова вроде «полная переработка будет стоить как поддержка legacy еще 20 лет» — вряд ли. Нанять команду, например, джавистов, которые погрузятся в предметную область и за несколько лет вдумчиво построят ядро системы с нуля может быть дешевле, чем это же время содержать команду поддержки AS/400, которая будет просто разбираться с текучкой.
Нанять команду, например, джавистов, которые погрузятся в предметную область и за несколько лет вдумчиво построят ядро системы с нуля может быть дешевле, чем это же время содержать команду поддержки AS/400, которая будет просто разбираться с текучкой.Проблема в том, что вам всё равно потребуется поддерживать AS/400 в адекватном состоянии и, кроме того, нужно будет интегрироваться с «новыми, стильными, молодёжными» вещами.
Так что затраты у вас вырастут как раз на AS/400 программистов — и существенно.
Не будет стоить дешевле и тем более не на несколько порядков.
Наоборот, будет дороже и больнее. Стек RPG-DB2/400-OS/400 работает как часики, и писать бизнес логику в нем одно удовольствие. Вот переписывание на java займет действительно на порядки больше и времени и денег.
Поддержка as400 будет требовать меньше людей чем поддержка аналогичной функциональности на java.
Задумайтесь, ведь никто не запрещает писать на java для as400. Там есть отличная, оптимизированная JVM. Только не пишут особенно бизнес логику. А все потому, что на RPG проще и быстрее.
Наоборот, будет дороже и больнее. Стек RPG-DB2/400-OS/400 работает как часики, и писать бизнес логику в нем одно удовольствие. Вот переписывание на java займет действительно на порядки больше и времени и денег.
Поддержка as400 будет требовать меньше людей чем поддержка аналогичной функциональности на java.
Задумайтесь, ведь никто не запрещает писать на java для as400. Там есть отличная, оптимизированная JVM. Только не пишут особенно бизнес логику. А все потому, что на RPG проще и быстрее.
Почему-то тикет (для примера — вспоминается как вопиющий случай) на добавление текстового поля в печатной форме «расходная накладная» (существующего уже в источнике данных) приводил к:
— постановке в беклог на полгода;
— разработке в течение нескольких дней с постоянным общением с разработчиком;
— еще месяцу исправлений ошибок, вылезших в других местах.
Возможно, дело в низком качестве разработчиков (индийские фамилии попадались частенько), но у меня сложилось впечатление, что сам по себе язык RPG не может обеспечить достаточную изоляцию функционально не связанных кусков кода, что приводит к сильному усложнению процесса разработки.
В результате двух лет борьбы со связкой RPG+worldwriter была на коленке написана простенькая программа, вытягивавшая данные через ODBC и печатавшая все что нужно. Уже больше 10 лет там не работаю — программа, по слухам, так и работает — ничего лучше не придумали.
— постановке в беклог на полгода;
— разработке в течение нескольких дней с постоянным общением с разработчиком;
— еще месяцу исправлений ошибок, вылезших в других местах.
Возможно, дело в низком качестве разработчиков (индийские фамилии попадались частенько), но у меня сложилось впечатление, что сам по себе язык RPG не может обеспечить достаточную изоляцию функционально не связанных кусков кода, что приводит к сильному усложнению процесса разработки.
В результате двух лет борьбы со связкой RPG+worldwriter была на коленке написана простенькая программа, вытягивавшая данные через ODBC и печатавшая все что нужно. Уже больше 10 лет там не работаю — программа, по слухам, так и работает — ничего лучше не придумали.
НЛО прилетело и опубликовало эту надпись здесь
Когда стало понятно, что быстро сделать искусственный интеллект не получится, часть индустрии ПО занялась переписыванием одного и того же функционала под разными обертками, которые затем продаются доверчивым бизнесменам с обещаниями увеличения производительности на порядки. Причём каждый год появляется новейшая хайповая технология, если ты её не внедрил — ты не производителен и вообще динозавр. Это как рынок БАДов и прочей фигни, но для бизнеса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IBM System i (aka AS/400) — Как мы делали автотесты приложений зеленого экрана