В этом посте я расскажу вам о том, что такое приложения зеленого экрана, зачем они нужны и как мы делали для них автотесты, написав для этого собственное решение, которое позволило нам ускорить автотесты в 11 раз.
Платформа AS/400 (Application System/400) появилась на свет в 1988 году. Первой ОС для данной платформы является OS/400, позже переименованная в i5/OS и еще позже в IBM i. Не так давно она отметила свое тридцатилетие.
Погружаясь в мир разработки под операционной системой IBM i, понимаешь, что это никакой на самом деле не «legacy» в классическом понимании этого слова. Это другая, совершенно иная среда, которая мало схожа с привычными Windows или Unix-системами. Главная задача этой ОС — быть максимально производительной на аппаратуре, с которой работает, а не быть удобной пользователю.
ИМХО, эта ОС может свести с ума от того, насколько привычные подходы к написанию кода на С++ неэффективны на ней (до десятков раз потери CPU), что некоторые демонстрируемые в учебниках антипаттерны являются best-practice эффективного кода, а исходники с датой написания за 1978 год не просто собираются без проблем, но и работают как было спроектировано! Все это заставляет по-новому взглянуть на современные подходы к разработке ПО.
Введение
Вопрос повышения качества разрабатываемого программного обеспечения волнует умы каждой команды разработки. Не обошел данный момент и одну из наших кредитных команд, чья задача состоит в разработке и развития Back части модуля для автоматизированной банковской системы Misys Equation. Особенность этой АБС в том, что:
- первые версии АБС работали под предшественником AS/400 – платформой IBM System/38 (появилась в 1978 году) под ОС CPF – «Control Program Facility»;
- она разрабатывается с 70-х годов двадцатого века, и вы можете встретить код, написанный до вашего рождения (очень много старого кода);
- особенности работы с АБС обусловлены тесной интеграцией с IBM i, причем из-за колоссальной обратной совместимости последней кажется, что ты работаешь археологом на раскопках Великой пирамиды.
IBM i (логотип)
Разработку приложений для данной АБС (опций АБС) мы ведем в соответствии со стандартом пакета разработчика Misys ITP – Integrator’s Technical Package, в котором регламентируется, что опция должна состоять из интерактивной программы для терминального взаимодействия с конечным пользователем и реализовывать API по установленному интерфейсу для фонового выполнения.
Такие интерактивные программы, разрабатываемые под операционной системой IBM i, исторически называются приложениями зеленого экрана и являются единственным UI, с которым взаимодействует пользователь данной АБС.
Что такое приложение зеленого экрана?
Простой ответ — это приложение, которое выглядит следующим образом:
Или так:
Зачем нужны приложения зеленого экрана?
Исторически единственными интерактивными приложениями, выполняющихся на low и mid-range системах семейства AS/400 и других меинфреймах IBM, и которые позволяли запрашивать какой-либо пользовательский ввод, являются приложения зеленого экрана. Инсталляция, администрирование, конфигурирование и разработка на операционной системе IBM i (и ее предшественниках i5/OS и AS400) велись (а где-то до сих пор ведутся) исключительно с помощью приложений зеленого экрана.
Изображение приложений зеленого экрана имеет два размера – 24x80 и 27x132 символов и 16 возможных цветов. В пределах данных масштабов выполняется большая часть работы разработчиков и пользователей данной операционной системы.
Такие размеры экранов являются результатом эволюции «рабочих станций», которые подключались к прародителям AS400 из low-end и mid-range сегмента бизнес — компьютеров IBM System/32, System/34, System/36 и System/38. Эти рабочие станции назывались терминалами и представляли из себя экран в металлическом корпусе с клавиатурой и дополнительным оборудованием в виде светового пера. Изначально поддерживалось только два цвета экрана – это зеленый и ярко-зеленый, отчего пошло устоявшееся словосочетание «приложение зеленого экрана» (green screen application в англоязычной литературе). В 1970-х годах количество поддерживаемых цветов увеличилось до 16.
5251 Display Station Model 11
Самыми распространенными вариантами терминалов являлись 5251 Display Station Model 1 (960 символов на экране) и Model 11 (1920 символов на экране) с габаритами Ширина/Глубина/Высота равными 530/400/400 мм соответственно и весом в 34 кг. Разрешение экрана Model 1 было 12x80, Model 11 – 24x80. Подключение терминала выполнялось напрямую к хостовой системе.
Также были достаточно распространены терминалы 5251 Display Station Model 2 (960 символов на экране) и Model 12 (1920 символов на экране) с большими габаритами и весом в 45 кг. Их отличает от Model 1 и Model 11 наличие возможности «проброса» upstream-соединения через себя к хостовой машине от более дешевых клиентов в виде терминалов Model 1 (или 11) с настольными принтерами или отдельно напольного принтера. Таким образом, модели 2 и 12 выступали в роли хаба, проксирующего соединение до хоста от устройств, требующих прямого подключения к хостовой машине, и стоили существенно дороже.
Необычным современному обывателю покажутся также терминалы серии 5252 Dual Display Station.
Рекламное изображение из брошюры IBM System/38 Equipment and Programs (5252 Dual Display Station)
Цена одного комплекта терминала с подключаемым к нему принтером могла достигать нескольких тысяч долларов США.
Подключение терминалов выполнялось по твинаксиальному кабелю до хостовой машины с топологией по типу «шина» в полудуплексом режиме со скоростью передачи до 1 Мбит/с. Максимально по твинаксиалу поддерживается подключение до 6 терминалов, причем максимально удаленный от хоста терминал должен располагаться на расстоянии не более 1500 метров.
Номер каждого терминала задается при его установке тремя переключателями, так определяется уникальный адрес в пределах шины. При наличии существующей коаксиальной сети возможно использование переходников с твинаксиального кабеля на коаксиальный кабель и соответствующий набор концевиков для кабелей под обжим. При такой схеме возможно было подключить на шине только два устройства с максимальной протяженностью сегмента до 30 метров. Общее количество подключаемых устройств варьировалось в зависимости от модели от дюжины до нескольких десятков.
По мере развития Desktop-систем и сетей доступа громоздкие терминалы вытеснялись рабочими станциями, где в качестве средств доступа к хостовой машине использовались различные платы расширения сторонних компаний, поддерживающие непосредственное подключение через твинаксиал. После разработки IBM технологии Token Ring в 1984 году появились программные решения доступа к машине в том числе через данный интерфейс.
Адаптер 5250 на шину ISA (производитель неизвестен)
Blackbox 5250 Adapter Cards (PC470C, PC471C, PC472C, PC473C, PC478C)
Появляются эмуляторы под MS-DOS и MS Windows как от IBM, так и от сторонних производителей, в том числе и OpenSource-реализации (например, tn5250j.sourceforge.net).В середине 90-х годов стек TCP/IP приходит в мир mid-range и low-end бизнес-машин. Для поддержки доступа к хостовым машинам по новому протоколу IBM разрабатывает программные эмуляторы терминалов серий 5250.
С целью создания протокола обмена с хостовой системой, IBM разрабатывает
расширения Telnet-протокола (RFC 854, RFC 855, RFC 856, RFC 860, RFC 885, RFC 1091, RFC 1205, RFC 1572, RFC 2877), в совокупности обозначающиеся как Telnet5250 (TN5250), в которых описывается процесс приема и передачи потоков данных 5250 (5250 data streams) поверх стандартного Telnet-протокола.
Инсталлятор IBM Client Access/400 for Windows 3.1
Что особенного в IBM 5250?
Особенностью терминалов IBM 5250 (и соответственно протокола TN5250) является его блочноориентированность в отличие от привычных *nix-терминалов, которые являются символьноориентированными. Это означает, что потоки данных 5250, которыми хост общается с терминалом, передаются блоками данных, и отдельно стоящий символ в нем без контекста передаваемого блока не имеет смысла.
Например, хостовая машина передает терминалу блок данных в котором находится выводимая статическая информация на экран вместе с атрибутами и координатами полей ввода и указанием смещения в данном блоке, куда записать результат пользовательского ввода в поля. После этого хостовая машина ожидает сообщения от терминала и более в процессе пользовательского ввода не участвует.
Экран входа на IBM i хостера RZKH.de (pub400.com)
Далее задача эмулятора терминала в том, чтобы интерпретировать блок данных от машины и сформировать пользователю экран ввода, где в разрешенные поля ему предоставляется возможность ввести какую-либо информацию. Также в задачи эмулятора терминала входит реакция на пользовательские действия. Клавиши F1-F24 (F13-F24 имитируются через SHIFT+Fx), Enter, Home, End, PageUp, PageDn и некоторые другие специальные клавиши, отсутствующие на современных клавиатурах, считаются хостовыми клавишами. Это значит, что по нажатию данной клавиши буфер потока с информацией из полей ввода и позицией курсора на экране, предварительно заполненный эмулятором терминала, будет отправлен хосту на обработку.
WIreshark 5250 Data Stream дамп попытки входа в систему на pub400.com
Хост получает буфер, разбирает его, и результат ввода передается программе, запросившей реакции пользователя, для дальнейшей валидации данных и продолжения работы приложения, при этом приложению передается код нажатой хостовой клавиши.
Зачем вообще здесь автотестирование
Мы задумались над автоматизацией ручного тестирования приложений зеленого экрана, когда столкнулись с необходимостью тестирования сотен экранов разрабатываемого модуля, где на один экран могло приходиться до восьмидесяти различных бизнес-проверок (валидаций).
Особой болью, с которой столкнулась команда, было практически полное отсутствие на 2017 год средств автотестирования зеленых экранов, кроме проприетарного решения UIPath. Даже сегодня подобных решений не так много, автору известны Automate от HelpSystems и расширение JMeter для BlazeMeter (буду рад информации о других аналогичных продуктах).
Первые исследования по задаче
Штатным эмулятором терминала TN5250, установленного на рабочих местах в банке, является решение IBM Personal Communications for Windows 6.0 (PCOMM 6.0). Коллеги обнаружили, что данный продукт имеет штатные средства автоматизации управления им в виде разнообразного API, а именно:
- High-level Language Application Program Interface (HLLAPI);
- Enhanced HLLAPI;
- Windows HLLAPI;
- Host Access Client Library (HACL).
Первые три интерфейса являются наиболее старыми и поддерживаются со времен DOS-а и 16-разрядных версий Windows. Работа по интерфейсу EHLLAPI реализуется через вызов одной единственной функции по следующему прототипу:
long hllapi (LPWORD, LPSTR, LPWORD, LPWORD);где первый параметр есть указатель на числовой номер выполняемой функции, два остальных – контекстно-зависимые от вызываемой функции ее аргументы, а последний – результат работы функции. То есть, чтобы запросить статус соединения ‘A’ (сессии в эмуляторе нумеруются латинской буквой диапазона от ‘A’ до ‘Z’), необходимо выполнить следующий код (взят из документации IBM):
#include "hapi_c.h"
struct HLDQuerySessionStatus QueryData;
int Func, Len, Rc;
long Rc;
memset(QueryData, 0, sizeof(QueryData)); // Init buffer
QueryData.qsst_shortname = 'A'; // Session to query
Func = HA_QUERY_SESSION_STATUS; // Function number
Len = sizeof(QueryData); // Len of buffer
Rc = 0; // Unused on input
hllapi(&Func, (char *)&QueryData, &Len, &Rc); // Call EHLLAPI
if (Rc != 0) { // Check return code
// ...Error handling
}
Количество доступных подобным образом функций для вызова — около 60.
Интерфейс WinHLLAPI немного расширяет данный функционал несколькими дополнительными функциями, позволяющих регистрировать callback-функции для асинхронного вызова с целью уведомления о событиях установления соединения с хостом, отключения от хоста, изменения данных на экране терминала и др.
Интерфейс Host Access Client Library (HACL) показался более дружелюбным для работы, потому что, в отличие от вызова «функции одного имени», предоставлялся вариант объектно-ориентированной иерархии классов, позволяющих полностью имитировать любое пользовательское действие.
Иерархия классов Emulator Class Library из состава HACL (C++)
Имеются реализации HACL для С++, Java, LotusScript и сервера автоматизации COM для Windows (удобно для Visual Basic и .NET).
Первый прототип
Из-за огромной сложности в протоколе потока данных 5250 и крайне скудной информации о его внутреннем устройстве с отсылками на закрытую платную литературу от IBM стало очевидно, что разработка собственного эмулятора — дело крайне нетривиальное и затратное по времени. В связи с этим возникла идея использовать middleware-слой, который позволит управлять эмулятором терминала в рамках минимально требуемого функционала, в частности «ввести в поле значение», «сверить часть экрана с эталоном» или «нажать хостовую клавишу F22».
Коллеги, использовавшие ранее интерфейсы HACL, утверждали (а поиск по StackOverflow подтвердил), что COM-объект имеет проблемы со стабильностью и мог зависать после выполнения определенного количества команд. Помогал только перезапуск процесса сервера автоматизации. Беглый анализ Java-версии показал, что используется Wrapper над интерфейсом C++ через JNI. Поэтому выбор пал на интерфейс С++. Соответствующие заголовочные файлы и .lib файлы оказались в наличии в установочном каталоге самого Personal Communications For Windows.
Первый прототип базировался на Qt5, где была возможность выполнить JavaScript-код через QtScript. В окружении исполняемого скрипта выполнялась регистрация объекта с небольшим количеством методов, позволяющих выполнять команды в эмуляторе терминала так, будто бы их выполняет человек (ввод в поле, нажатие хостовых клавиш, ожидание появления строки на экране). Мы продемонстрировали живое «демо», где скриптовали пользовательский кейс по запуску приложения зеленого экрана из АБС Equation с проверкой реакции приложения на некорректный ввод в поля. Демонстрация показала, что прототип успешен и можно двигаться дальше.
Появление соседа
Одновременно с демонстрацией первого прототипа коллеги из другого отдела собрали связку Ruby + Cucumber + Quick3270 + Ruby module (cheeze/te3270). В предлагаемом варианте используется Ruby-модуль, который взаимодействует с эмулятором терминала Quick3270 от DN-Computing через его специализированные COM-объекты (несовместимы по интерфейсам с HACL). Это было полноценное решение для автотестирования приложений зеленого экрана в стиле BDD, с небольшим количеством предварительно описанных шагов. Однако в предлагаемом решении нас настораживало следующее:
- Использовался сторонний платный эмулятор не от IBM (все эмуляторы работают немного по-разному, а нам нужно проверять работу именно на штатно используемых в банке, цена ошибки невероятно высока);
- Реализации шагов Cucumber-а для Quick3270 использовали большое количество sleep-ов для ожидания ответа от машины;
- Очень низкая производительность работы Quick3270 через интерфейс автоматизации (работа с HACL в прототипе через С++ интерфейс выглядела куда более динамичной).
Эмулятор терминала Quick3270
Мы решили на основе прототипа попробовать реализовать собственный сервер автоматизации, чтобы соединить Cucumber с Personal Communications for Windows и разработать шаги таким образом, чтобы время простоя между действиями на экране эмулятора было минимальным.
Лирическое отступление. Несмотря на тот факт, что вокруг якобы «legacy» IBM существует огромное количество технических задач, которые, казалось бы, уже должны были быть решены для систем уровня среднего и enterprise-бизнеса, актуальность адаптации и переноса существующих технических решений очень высока попросту из-за их отсутствия на платформе. Зачастую отсутствие связано с самими особенностями работы этой ОС, которая в корне отличается от современных *nix, Windows или MacOS X, что требует значимой оптимизации софта для данного стека.
Собственное решение
В качестве собственного решения мы создали сервер автоматизации как развитие ранее демонстрируемого прототипа. Данный сервер выполняет команды по автоматизации взаимодействия от потребителей через RPC сервер (Qt5 WebSocket). Он взаимодействует с Personal Communications for Windows, входящим в образ корпоративной ОС Windows, и позволяет:
- запускать/останавливать сессии эмулятора терминала;
- выполнять Screen Scraping зеленого экрана;
- искать поля ввода на экране;
- управлять курсором и имитировать нажатия клавиш (в т.ч. хостовых);
- и др.
Запуск сервера автоматизации
Однако при всех достоинствах HACL API, у него есть один недостаток – он совершенно не умеет работать со встроенной в ОС СУБД DB2 for i и не позволяет выполнять команды, которые жизненно необходимы для построения mock-окружения, где бы выполнялся тестовый сценарий. Если DB2-клиент для Ruby существует от IBM, то клиент для сервера удаленного выполнения команд «Remote command and distributed program call server» есть только для Java в виде библиотеки JTOpen: The Open Source Version of the IBM Toolbox for Java (также известная как jt400). Решение данной проблемы мы «подсмотрели» у самого IBM путем анализа поведения его продуктов со схожей функциональностью (в частности, Personal Communications for Windows Data Transfer, iSeries to PC / PC to iSeries Transfer и др). Оказалось, что эти продукты по своей реализации запускают IBM JRE 6 или 8, в зависимости от версии приложения, и используют библиотеку jt400.
Для сервера автоматизации мы решили поступить аналогичным образом. Через JNI запускается IBM JVM, поставляемая вместе с Personal Communications for Windows. Используя специальные методы-обертки, исполняются приходящие извне команды RPC-сервера с помощью их проксирования в вызовы необходимого функционала jt400. Так как последний также содержит JDBC-драйвер для DB2, решено было использовать его же для доступа к СУБД на IBM i.
Важно отметить, что при использовании HACL нельзя использовать Oracle JVM. Если вы запустили сессию эмулятора терминала, то попытка создать экземпляр виртуальной машины приведет к падению. Аналогично, если запустить Oracle JVM в адресном пространстве процесса, взаимодействующего с HACL, то последний зависает без объяснения причин.
Со временем решение внедрялось на все большее количество рабочих мест. Оно работало быстрее решения с Quick3270. Популярность возрастала, как и количество автотестов. Однако в процессе эксплуатации возникли дополнительные сложности:
- Эпизодические зависания терминала;
- Невозможность работы на регрессионном стенде вследствие того, что эмулятор терминала отказывался запускаться, если рабочий стол пользователя, под которым запускается эмулятор, заблокирован или неактивна его RDP-сессия;
- Windows-only;
- Сложная процедура установки, настройки и обновления инструментария (через msi-пакет);
- Наш цикл регресса на 130 автотестов (около 4000 шагов) стал занимать 7-8 часов.
Нужно что-то делать…
Путем анализа журналов трассировок многочисленных запусков автотестов, поиска узких мест в производительности выполнения часто используемых шагов, общее время выполнения регресса удалось снизить до 4-5 часов. Но было понятно, что использование middleware-слоя в виде RPC-сервера автоматизации совместно с интерфейсом HACL, который в том числе имеет «плавающие» ошибки, накапливаемые с продолжительностью работы всей системы, не поможет в улучшении характеристик решения.
С другой стороны, в качестве альтернативы IBM Personal Communications for Windows вендор предоставляет кроссплатформенное решение под названием IBM i Access — Client Solutions.
IBM i Access — Client Solutions
Анализ его внутреннего устройства по субботним и воскресным утрам за чашками кофе показал, что его кодовая база построена на базе другого продукта от IBM, который называется IBM Host on-Demand (IBM HOD). Это полноценное решение для доступа к IBM i, разработанное на Java 6, которое не только имеет в себе полную реализацию разнообразных протоколов коммуникаций, используемых в машинах IBM (TN3270, TN5250, VTxxx и др), но и высокоуровневые java-swing UI-компоненты, используемые для построения собственных эмуляторов терминалов в виде конструктора, который можно собрать по скудной документации IBM. Более детальное изучение IBM HOD показало, что UI-компоненты построены на базе Java-реализации интерфейса HACL, чья документация открыта. Их поведение совпадает лишь с небольшими отличиями от С++ HACL-документации.
IBM Host On-Demand (логотип)
Далее мы создали Java-библиотеку для внутреннего пользования, в которой реализуется такой же интерфейс как у С++ RPC-сервера автоматизации, но внутри полностью использующий IBM HOD. Для уменьшения накладных расходов при выполнении шагов автотеста мы мигрировали с Ruby Cucumber на cucumber-jvm с реимплементацией всех шагов аналогично Ruby-вариантам. При наличии схожего с RPC-сервером программного интерфейса это не составило большого труда, особенно с учетом того, что мы старались сдерживать бесконтрольный рост числа самих шагов и у нас это значение находилось в районе 30 единиц.
Что в итоге
В результате мы добились работоспособности всех автотестов без их изменения, а скорость работы стала столь велика, что пришлось вводить искусственную задержку между шагами, чтобы при разработке автотеста можно было наблюдать за его работой, иначе UI не успевал отрисовывать до конца экран.
Уже существующие 180 автотестов с более чем 16000 шагов при установленной задержке в 60 мс между шагами стали выполняться порядка 30 минут против 5 часов 30 минут, что соответствует одиннадцатикратному увеличению производительности регрессионного стенда.
Результаты превзошли все ожидания. Мы вплотную подошли к физическим пределам протокола TN5250.
На сегодняшний день решение опубликовано на весь банк, а к совершенствованию подключились коллеги из других городов. Из последних изменений коллеги выполняют интеграцию решения с Jenkins-ом, в тестовом варианте завершена апробация запуска на Linux-сервере с Xvfb и начинается стадия пилотной эксплуатации запуска автотестов на нем.
Спасибо, что дочитали до конца!
Всем успехов!
P.S. В декабре 2018 года состоялась очередная Конференция разработчиков IBMi, на которой в том числе был сделан доклад на тему этой статьи.
До сих пор мы ежегодно проводили Конференцию только для сотрудников Банка. С 2019 года мы будем приглашать участников из других компаний. Очень интересно расширить круг профессионального и личного общения, поделиться эмоциями, знаниями и опытом.
Комментарии (65)
Bazilbrush
02.04.2019 15:39Отличный рассказ про лютейший легаси! :) У меня похожая система была: Ingres ABF на IBM Aix. И очень не хватало инструментов для тестирования таких интерфейсов. Автор молодец!
Mykola_Von_Raybokobylko
02.04.2019 17:57Я конечно не настоящий сварщик (с), но в статье приводится пример успешной ит-некрофилии. Как бы не была красива бортпроводница, её стоит закопать.
jrthwk
02.04.2019 18:52+4/хмыкая/
Мир состоит не из одного вебдезаена, бизнес считает деньги, и подобные предложения встречает вопросом «а кто за это будет платить?» И таких стюардесс в мире реального успешного бизнеса — чуть менее чем дохрена.
Ну и эта, вы догадываетесь за чей счет будут похороны стюардессы если с AS/400 решит соскочить тот же, афаик, сбер?..
Mykola_Von_Raybokobylko
03.04.2019 09:33Ну это вы здря.
Я не по наслышке знаю, что творится в альфе и в сбере. Ребят которые там работают иногда и пожалеть хочется, особенно эксплуатационников. Какую только древность не реанимируют ежедневно. Бывают дни когда вообще нет времени не то что чай попить или покурить, а и до белого друга добежать. В том же альфе огромная потребность в новых исправных решениях. Проблема в том, что новые решения не то чтоб не соответствуют специфике, новые решения вообще невозможно интегрировать ни в существующую систему ни в новую. Множество решений на рынке вообще малоприминимы ни в широком смысли ни в узком сегменте. Буквально десять заказчиков на весь земной шар.mikhailidi
03.04.2019 15:30Я вам, как человек имеющий боевой опыт работы в банке, скажу так: В любом банке творится ад и гоморра, вне зависимости от АБС. И чем крупнее банк тем пекло жарче.
hard_sign
03.04.2019 18:47Будете смеяться, но в Сбере нет ни одного приложения, заточенного на специфическую аппаратную платформу. Правда, там есть нагруженные БД, для которых не существует адекватной x86 машины, но с Aix на Solaris и обратно эти базы ездят легко.
Danik-ik
02.04.2019 22:28+2Вы, вероятно, путаете некрофилию и некромантию. Здесь нет нездорового интереса, здесь циничная прагматика без модного пафоса. Если зомби послушны, не устают и не спят — зачем их заменять кем-то голодным, своенравным и состоящим в профсоюзе?
rezdm
02.04.2019 17:47Когда-то, в 99-ом, 2000-ом годах принимал участие в разработке банковского софта, который был портирован в т.ч. под ас/400. Может это оно… Помнится, тогда этот самый ас приехал и стоял недолго прям-таки в нашей комнате.
ShashkovS
02.04.2019 22:02Тестирование зелёного экрана, кстати, ещё можно так делать: нужно всё взаимодействие с дисплейным файлом (exfmt, read, write, etc) делать строго с указанием ds-ок для ввода и вывода. Каждая ситуация, когда пользователю даётся шанс на взаимодействие с экраном, выносится в отдельную процедуру. При этом можно добавить if defined так, чтобы при компиляции с проставлением define'а в духе «TEST» вместо ввода-вывода через дисплейник вызывалась тестовая процедура (которая благодаря /if defined(TEST) в прод-версию вообще не попадёт). Что-то в таком духе (могут быть ошибки, пару лет зелёный экран в руки не брал):
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, а также не использовать явные координаты в структурах, то это всё отлично переживает и изменения структуры базы, и изменения в дисплейнике.ShashkovS
02.04.2019 22:12А вообще мне безумно грустно за AS/400 и RPGLE. Крутейшая платформа, хороший язык. Только платформе не хватает какой-нибудь более разумной ценовой политики (а не вот это «вам нужно поменять CDROM, это будет стоить 1000$, плюс обязательно оплатить поддержку за последние 5 лет, то есть 30000$»).
А ещё платформе не хватает нормальных «разрешений» зелёного экрана: не 27x132, а 40?200, грубо говоря. Текстовые интерфейсы дико быстрые и удобные для операционистов. Все эти модные анимации, выпадушечки и т.п. из браузера для работы операциониста не нужны, а нужно 100% надёжная, быстрая и предсказуемая работа с клавиатуры…
А языку не хватает нормальной стандартной библиотеки.vlsinitsyn
02.04.2019 23:41Да, платформу убивают. Там пооставались одни пенсионеры. Бас фактор для ряда продуктов реально равен 1.
netch80
05.04.2019 07:15> А ещё платформе не хватает нормальных «разрешений» зелёного экрана: не 27x132, а 40?200, грубо говоря.
Как человек, который последние лет 10 предпочитает не работать с текстом более чем 25x80, не соглашусь.
Местами нужно впихивать много текста, да. Но основной интерфейс перегружать нельзя.
А лучше таки переходить на графику — не зря ведь её так долго и тщательно изобретали, начиная с бумажных бланков. Только продумать, а не свистелки-прыгалки накидывать.
> Текстовые интерфейсы дико быстрые и удобные для операционистов.
Эти свойства ортогональны текстовости. Современные массовые графические интерфейсы, да, не рассчитаны на гарантию быстрой и адекватной реакции; например, когда посреди набора поля всплывает окно «вам письмо» и забирает на себя фокус. Профессиональные интерфейсы не должны такого давать, но и не должны быть ограничены текстом.
Формат терминалов IBM, да, способствует тут нормальной работе — когда текст вводится в локальном поле и потом идёт сигнал в центр с готовым результатом, а не нажали клавишу и ждём, когда пройдёт через tty, его дисциплину, код libreadline и т.д. Но он соответственно и ограничен.
На сейчас можно было бы вполне сделать в самом терминале логику совмещения и оперативности и надёжности действий, и расширить её на любые графические объекты. Видимо, не было пока настолько платёжеспособного запроса.
rjhdby
05.04.2019 22:24Текстовые интерфейсы дико быстрые и удобные для операционистов.
Не скажу за операционистов, а саппорт рядом сидит. И от вида того, что они в этой консоли набирают — волосы дыбом встают в неожиданных местах и тайком крестишься, в надежде, что прям сейчас дьявола не вызовут.
НГДБР 211, РР, 25 DD5!, прости господи…Igor_O
05.04.2019 23:32Проще — застрелиться. Русскоязычные интерфейсы командной строки — это взрыв мозга термоядерным зарядом! Всмоминается знаменитый цензурный вариант нецензурного перевода классического ДОСовского «Abort, Retry, Ignore»: «нафиг, нефиг, пофиг»…
vlsinitsyn
02.04.2019 22:11Такое чувство, что в Альфе вообще не осталось никого, кто профессионально работает на as400. Пришла какая-то комманда пионеров-хипстеров и начала «креативить».
На самом деле изобретали велосипед. В pcom есть библиотека, в которой с древних времен нв VB отлично пишутся любые экранные скрипты. Не нравится VB — можно через обертку на питоне, например. Не нравится вин — есть бесплатная опенсоурсная реализация tn5250, где опять же имеется API.
Если не нравиться jt400, есть отличная опенсоурсная альтернатива (опять же от IBM).
Вообще, лет 20 назад, мне предлагали работать в альфе как раз в команде as400. Но платили что-то не очень, так что не срослось. Интересно, там ведь еще остались люди, пишущие на RPG и все вот это вот? Или все уже на пенсии?ShashkovS
02.04.2019 22:17+1vb работает просто ну дико нестабильно. Сам client access — ещё ничего, хотя, конечно, периодически падает. А вот vb в нём для долгих задач ну совсем нестабилен. Нам (не в Альфе) приходилось какие-то вещи так автоматизировать (в духе 10000 сделок в MIDAS ввести), так там половина кода были костыли на всевозможные случаи отказов vb.
vlsinitsyn
02.04.2019 22:25Ну, так там vb — только чтобы быстрее попробовать. А писать то можно на чем угодно. Я вот VB не очень, на питоне делал.
vlsinitsyn
02.04.2019 22:22Насчет того, почему в банках (и не только банках) до сих пор стоят «динозавры», я объяснил в другом комментарии.
Голубые гиганты не перестанут получать прибыль на «зеленых экранах» еще долго. Хотя, экраны уже давно могут быть не зелеными, а какими угодно.
Tzimie
02.04.2019 22:31А не расскажите, чем эта операционная система принципиально отличается? Я сам застал vax/vms и даже rsx-11m
vlsinitsyn
02.04.2019 22:48+1Почитайте старую добрую книжечку по теме. Там все от «папы» подробно и доступно.
Rampage
03.04.2019 00:01Спасибо! Было интересно почитать.
Да когда-то отсутствие штатного API у абс компенсировалось ком+ компонентой вколачивающей данные в эти экранные формы :)
Ещё одна альтернатива: IBM HATS/WebFacing — штатная вебизация зелёного экрана.
После запуска можно переключится на стандартный стек тестирования с selenium и xpath. Тут и автоматизация быстрее станет.
Более свежая версия конкурента абс Midas от Finastra (ex. Misys) уже лет 10 как ушла от зелёного экрана.
Хотя наверное более свежий Equation тоже с веб формами?
sim2q
03.04.2019 01:16Помню, как оседский админ молился на AS/400. Восторженно говорил много умных слов. Я тогда мало что понимал и не запомнил кроме, что «ещё ни разу не взломали» и что-то о производительности и конечно же — про «вещь в себе». Но некий трепет — остался с того времени остался
TimsTims
03.04.2019 11:15+2Спасибо, интересно получилось. Я в другом банке наступал на те же грабли, но не для тестирования интерфейсов, а для малой автоматизации обычных процессов. Сначала через 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 )
Sunny-s
03.04.2019 18:31Работал в крупной корпорации, связавшейся в 70-х с AS/400, и могу сказать, что цена разработки в этой экосистеме запредельно высока не только из-за нехватки кадров, но и из-за устаревших на 50 лет методологий программирования. Решение одной и той же проблемы в современных стеках, даже не важно в каких — будет стоить на несколько порядков(!) меньше. Поэтому я с сомнением смотрю на слова вроде «полная переработка будет стоить как поддержка legacy еще 20 лет» — вряд ли. Нанять команду, например, джавистов, которые погрузятся в предметную область и за несколько лет вдумчиво построят ядро системы с нуля может быть дешевле, чем это же время содержать команду поддержки AS/400, которая будет просто разбираться с текучкой.
khim
03.04.2019 20:29Нанять команду, например, джавистов, которые погрузятся в предметную область и за несколько лет вдумчиво построят ядро системы с нуля может быть дешевле, чем это же время содержать команду поддержки AS/400, которая будет просто разбираться с текучкой.
Проблема в том, что вам всё равно потребуется поддерживать AS/400 в адекватном состоянии и, кроме того, нужно будет интегрироваться с «новыми, стильными, молодёжными» вещами.
Так что затраты у вас вырастут как раз на AS/400 программистов — и существенно.
vlsinitsyn
03.04.2019 20:59Не будет стоить дешевле и тем более не на несколько порядков.
Наоборот, будет дороже и больнее. Стек RPG-DB2/400-OS/400 работает как часики, и писать бизнес логику в нем одно удовольствие. Вот переписывание на java займет действительно на порядки больше и времени и денег.
Поддержка as400 будет требовать меньше людей чем поддержка аналогичной функциональности на java.
Задумайтесь, ведь никто не запрещает писать на java для as400. Там есть отличная, оптимизированная JVM. Только не пишут особенно бизнес логику. А все потому, что на RPG проще и быстрее.
amarao
Я честно прочитал это, и оно было интересным, но есть фундаментальный вопрос: а зачем под это писать? Программисту понятно — за это ЗП платят. А зачем банку инвестировать в такую технологию? Неужели, для поддержки отечественного производителя волокуш?
jrthwk
Фундаментальный ответ — банк давным-давно инвестировал в инфраструктуру на основе IBM AS/400+DB2, и для того чтобы соскочить с этого надо… ну в общем в масштабе альфабанка проще будет банк закрыть и открыть новый с нуля. Потому что ЦБС — это основа всего.
amarao
Это самый простой ответ. Но на самом деле он требует разбора:
а) Инвестиции в железо и купленный так велики, что перекрывают все остальные инвестиции в банк?
б) Инвестиции в самописный софт…
… который не может портироваться ни подо что, от слова «вообще», и не может быть модифицирован? Вот этой части я не понимаю. Бизнес-логика же не должна быть завязана на особенности ОС.
Или я всё-таки что не понимаю в устройстве банковского софта?
Bazilbrush
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 :)
amarao
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'?
mikhailidi
Don't mind the JVM 6. It's not Sun JVM nor Oracle's one. It's proprietary IBM port, and it has all the modern perks. AS400 is a very stable and quite secure system where application security completely relays on OS features enforced by the hardware.
Gutt
Представьте себе, что компании, в которой вы работаете, предложили переехать с AIX@Power на, скажем, Minix@ARM. Компиляторы C и C++ дадут. Нет, про Go, Java и Python забудьте. Софт у вас самописный, придётся переписать. Основная база — Progress, заметная часть низкоуровневой логики живёт в хранимых процедурах. Миграция должна быть он-лайн; замедление или перерывы обслуживания не допускаются. Да, и часть сервисов должны обеспечивать соответствие PCI DSS. Руководство понимает, что переезд будет стоить как поддержка и развитие существующей инфраструктуры в течение следующих 30 лет, но всё равно решилось на такой шаг. Пойдёте отговаривать?
amarao
Если есть Си, будет и питон. В целом, «тупик и выхода нет» это всегда плохо, но из тупика может быть всегда выход в умершее железо, санкции и закрытие IBM'ом кусочка своего бизнеса (не важно по какой причине).
Мне очень грустно видеть, что кто-то свой бизнес настолько завязывает на одного вендора.
khim
А сколько других платформ, с множеством поставщиков, за это время появилось и умерло? Назовите вообще хоть одну другую платформу позволяющую использовать бинарники, созданные 30 лет назад без перекомпиляции! И не в режиме «запустим эмулятор X под эмулятором Y и там будем пускать ваш старый софт» (а новые модули кто и как к этому будет прикручивать?), а в режиме «купили железо, заменили — всё дальше продолжило работать»?
Преимущество Windows перед всякими бесплатными GNU/Linux'ами — в стабильности (на уровне ядра у Linux'а всё хорошо, но вот разработчики Desktop'а, со своим бессметрным CADT, казалось, все свои усилия много лет тратили на то, чтобы их разработками никто-никто не смог воспользоваться), но по сравнению с AS/400 Windows — это просто бабочка-однодневка.
CrashLogger
Linux — это уже давно не Cascade of Attention-Deficit Teenagers. Сейчас ее развивают и поддерживают крупные корпорации, в том числе и IBM. Что касается «стабильности» винды — запустите что-нибудь из эпохи XP под десяткой. А прошло всего каких-то 15 лет.
khim
Кстати Windows XP вышла в 2001м году, так что прошло уже заметно больше 15 лет.
У RHEL нет версии для десктопа, а Fedora — это как раз типичнейшый CADT и есть.
Jef239
Особенно, если это IBM/PC. Что из написанного вами пойдет не на персоналках? Ну скажем на ту же AS/400 что перенести сумеете?
Большая ЭВМ — это не персоналка, там совсем иной подход. Решения с микроэвм на неё не переносятся.
CodeRush
micropython.org
Jef239
Ну только STM32F4 вижу. И вроде не FreeRTOS, но портировать можно. 16К ОЗУ и 256К ПЗУ — довольно много, ПЗУ, конечно. Это ведь без пользовательского кода, только интерпретатор.
CodeRush
Тем не менее, питон для STM32, для FreeRTOS можно адаптировать (потому что на голом железе оно уже работает), а то, что интерпретатор жрет — мало кто ожидал что жрать будет не мегабайты.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
Jef239
Bazilbrush
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.
YetAnotherSlava
Это всё возможно. Если перераспределить деньги от зам. директора, радостно меняющего мерс amg на порш — к программистам.
Zeitung
Вот и мы так переезжаем. Маленькая компания, которая 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 лет они доказывали что это «не баг, а фича»
jrthwk
>Вот этой части я не понимаю. Бизнес-логика же не должна быть завязана на особенности ОС.
Бизнес-логика примерно такова:
Есть ЦБС, система в которой ведутся счета. Времена, когда ее могли написать на фокспро давно прошли, щас это должна быть аццкая транзакционная сотона которая оперирует миллионами счетов, логирует всё и не имеет права на ошибки. Это — основа банка, как фундамент — основа здания; разрабатывают такие системы не так уж много фирм, и выбрав одну — на что-то другое перескочить практически нереально, не останавливая банк — нереально практически совсем, в случае крупного банка — нереально ваааще, даже в подвиндовом мире, потому что вокруг конкретной ЦБС и ее особенностей накручивается со временем столько всего, что это всё проще закрасить чем отскребать. Это, кстати, работает в обе стороны, если с PC-шной ЦБС в уже сложившейся среде пытаться переехать на IBM — тоже получится исключительно трэш угар и содомия.
В случае инфраструктуры на AS/400 это усугубляется еще и тем что их система очень сильно заточена в производительность в режиме мультидоступа, и если например позаменять у всех операторов во всех филиалах большого банка старообрядный зеленый экран терминала с формами какого-нибудь Equation'а на современные модные воздушные material'ные вебинтерфейсы — то сети банка сильно поплохеет.
Таковы они, суровые реалии-с кровавого энтерпрайза, легаси и промышленных систем.
Bazilbrush
Плюс всякая политика внутренних отделов, IT против безопастников, Ильина Матвеевна — ведущий программист, писала систему аж с 74 года, вся документация у нее. И огромное количество очень дорогих контактов проплаченных на 5 -10 лет, и проблемы с нахождением альтернативы.
А кстати, Актиан (разрабы Ingres ) сделали сервис где на твой зелёный терминал нахлобучат этот ваш материал дизайн и все вроде даже заработает. За совершенно символическую плату. Ну так и зачем вам менять свой старый мейнфрейм? :) А Ирина Матвеевна может продолжить работать на глупом терминале.
jrthwk
>А Ирина Матвеевна может продолжить работать на глупом терминале.
… и это правильно, потому что она должна работать, а не терять время и творить косяки потому что дизайнер по модной тенденции в очередной раз перепахал интерфейс.
Igor_O
Там еще, кроме софтверной части, есть железная часть. Отказоустойчивость внутри этого шкафа, возможность горячей замены процессоров, памяти, интерфейсных плат и т.п. без остановки бизнес-процессов или отключения пользователей.
Мелочи вроде LPAR, когда в одном шкафу могут жить 3-5 ОС, на которых работают бизнес-приложения, не мешая друг другу без возможности залезть из памяти Linux в память Windows Server в другой партиции.
Ну и еще, вспоминая дела давно минувших дней, был я как-то в 90-х на презентации IBM про тогда еще AS/400. Особенно запомнилась фраза презентующего: «Если на виндоус сервере у вас загрузка процессора больше 50% — у вас где-то есть проблемы и все страшно тормозит. Если на мэйнфрейме у вас загрузка процессора меньше 100% — где-то оборвался коммуникационный кабель.»
jrthwk
Я какбы в курсе.
Был участником неудачной попытки миграции ЦБС банка на IBM, потому в курсе этой техники и в курсе какой это треш, угар и содомия — устоявшуюся среду пытаться мигрить.
SpiderEkb
Наверное, не очень понимаете.
Банковский софт должен быть
а) Надежным
б) Еще раз надежным
в) И еще раз надежным.
Т.е. превыше всего надежность. Если тот софт, что пишется внутри банка собственными силами и/или вендорами можно оттестировать на надежность (а тестирование там проводится специально обученными людьми и не в один этап — компонентное, интеграционное, бизнес, нагрузочное...) то надежность платформы на которой все это крутится должна обеспечиваться ее производителем.
И данная платформа (IBM i) достаточно надежна ибо разрабатывалась не под бытовые нужды, а для высокопроизводительных коммерческих серверов.
Что касается собственно АБС (автоматизированной банковской системы). Данная АБС есть система реального времени. Т.е. пользовательские операции тут совершаются не «с 4-х утра до полуночи», а круглосуточно. Даже при том, что сведение баланса (ежемесячный кошмар бухгалтера) в банке происходит ежедневно.
Чего стоит это реальное время для системы… Об этом лучше не говорить ибо в двух словах не описать :-)
Ну и на самом деле бизнес-логика на особенности ОС никак не завязана. Завязана ее конкретная реализация. И не столько на особенности ОС, сколько на особенности используемой банков АБС. А та или иная АБС используется любым банком ибо написать все с нуля своими силами нереально. И ни о каком порте тут речи быть не может.
Ну а что касается темы статьи — тут речь идет не о бизнес-логике, а о том самом тестировании. Без которого ни одна поставка не уйдет в бой. И о посильной автоматизации этого тестирования. Ибо куда проще и спокойнее дорабатывать поставку с тестов, чем бросать все и кидаться срочно затыкать дефект боя (когда некорректная работа обнаруживается уже в промышленной эксплуатации и сказывается на клиентах, вызывая их негативную реакцию и ущерб репутации банка).
klvov
Ну еще банку надо оперативно реагировать на инструкции ЦБ, а если понять статью буквально, то получается там в Альфе есть команда разработчиков на каком-то AS/400, которая оперативно все имплементит, что ЦБ спускает. И, видимо, справляются.
rjhdby
Кстати вот да. Не ту организацию прозвали «бешеный принтер», ох не ту…
spqr_voldi
Так надёжно, производительно и дёшево.
valis
Про банки не скажу, но по своему опыту замены ERP это мероприятие:
1. Очень дорогое (реально хватит чтобы поддерживать legacy еще лет 20)
2. До ужаса рискованное (был случай когда из-за внедрения ERP разорилась крупная сеть аптек, я серьезно это даже в учебники вошло)
3. Очень длительное и требует параллельного допила в Legacy. Нельзя ж запереть 100 программистов в кабинете и через 4 года получить систему т.к к тому времени она тупо морально устареет. Компромиссом является постепенный перенос бизнес процессов и развитие их в новой системе, при этом появляется огромный пласт интеграции между системами.
4. Далеко не всегда приводит к выводу Legacy из эксплуатации. В лучшем случае (повторяю — это самый оптимистичный случай) Legacy система будет жить в полу замороженном состоянии с небольшими вынужденными (не приносящими бизнес профита) допилами.
RedTalon
Работал на фирме у которой Самая Важная База Данных крутилась именно на System i.
Как ни странно, но, помимо большого количества Legacy решений, были и другие причины оставаться верным зелёному экрану. IBM железо дорогое, но к нему не нужно докупать лицензии на базы данных — DB2 идёт из коробки. Скорость, надёжность, сложность администрирования — как у конкурентов или лучше. Отдельный важный плюс в хорошем саппорте. Софт и железо идут одним комплексом, что ускоряет и упрощает траблшутинг. Не возникает футбола, когда продавец бд посыдает к железячнику, а железячник клянётся мамой, что с их стороны всё хорошо, а глючит ПО.
Жирных минусов лично я вижу два. Первое это вендор лок. Второе, гораздо более важное, это недостаток профильных сисадминов (даже не программистов, программисты есть) на рынке. Имеющиеся специалисты стремительно приближаются к пенсионному возрасту, а молодёжь не торопится связывать свою карьеру с зелёным экраном. При чём руководство проблему видит и готово вкладываться в обучение джунов, но желающих всё равно не густо.
NickSin
Такое во всем мире происходит. В той же США работают сервера 30 летний давности и никто их не берется менять или модернизировать ПО, поскольку оно и так прекрасно работает, а если уже и апать систему, то проще будет построить новую экономику, чем модернизировать текущее. Иными словами это нерентабельно для корпораций.
Igor_O
В хабра-хабровцев вселилиьсь бесы… Минусовать это?
Я однажды в самом начале 90-х подрабатывая типа гидом-переводчиком общался с буржуем. У него был успешный бизнес, который обеспечивал ему безбедную жизнь и возможность ездить по странам, которые ему были интересны. У него был один компьютер на весь его успешный бизнес. Кажется что-то типа PC-XT с хардом на 40 мегов. На мое удивление, он ответил, что его программа учета прекрасно работает. А что еще нужно? Я не осилил тогда ему вразумительно ответить, зечем нужно что-то более крутое. И сейчас бы я тоже, вряд ли бы смог дать однозначный ответ.