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

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

Debug

Не знаю почему, но дебаг приложений на z/OS в 2021 происходит примерно так же как и лет 30 назад. Самый удобный/мощный дебагер который есть - это консольный XDC дебагер работающий на z/OS с доступом из ISPF панели. Он реально крутой, но вообще не user-friendly и его нельзя прикрутить к IDE, что заставляет большинство джунов использовать printf в первый год и избегать дебагер (но долго бегать не получится, рано или поздно придётся заглянуть в пасть льву).

Да, есть дебагер от IBM с собственной IDE, но лично моё мнение, что он подходит или для "Hello World!" проектов или для небольших карманных проектов.

Legacy код

Я не утверждаю, что другие платформы не сталкиваются с легаси, тут скорее даже проблема не в самом легаси коде, а в его возрасте: он может быть написан на старых языках программирования и с применением устаревших практик разработки. И в данном случаем ты даже не знаешь что хуже: разбирать код на HLASM (High Level Assembler) или пытаться понять код на C++, написанный с использованием большого числа глобальных переменных.

Т.е. код, который ты читаешь, может быть написан до публикации книги Clean Code (2008) ... да что уж там, даже до публикации Code Complete (1993).

Да и в целом найти человека, умеющего хотя бы читать HLASM или REXX, намного сложнее чем C, C++, PHP, Java разработчиков. Отсюда, кстати, вытекает следующая особенность.

Кадровый голод

Если у вас появляется свободная вакансия в команде, с большой долей вероятности, её место займёт человек, который о мейнфреймах слышал не более чем среднестатистический читатель этой статьи. Вам в любом случае нужно обучить человека тому, что человек будет слышать впервые в жизни: TSO, JCL, USS, ISPF, Datasets, JES, SDSF, SMP/E.

Как правило, первые полгода разработчик не будет приносить пользы, но на него будет требоваться время Техлида, Скрам-мастера, Менеджера и других членов команды.

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

Частота релизов и Quality First

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

Мы используем немного изменённый Scrum фреймворк в нашем процессе разработке и живём двухнедельными спринтами, в конце которых мы делаем релиз продукта с обязательным проходом всех юнит-тестов и полной регрессии. Звучит довольно стандартно, но у нас возникают следующие трудности:

1. Исторически мы можем поддерживать несколько версий продукта. Для нас это значит, что в конце спринта мы делаем релиз только для одной версии продукта. Как следствие, новые обновления для каждой версии выходят примерно раз в месяц. Также, по личным наблюдениям, мультиверсионность стоит нам примерно 20% времени команды - что очень много.

2. Даже с учётом ежемесячных обновлений, больше половины кастомеров обновляют продукты только если у них случилась проблема или пришло время ежегодного обновления (если так за год ничего критического не случилось). Из-за этого у нас бывают кастомерские проблемы, в которых решение было релизнуто год назад (клиенты на ещё более старой версии), и ты настаиваешь на установке самого свежего релиза, чтобы вновь не пытаться чинить то, что уже давно исправно работает.

Утечки общей памяти

Архитектурно z/OS имеет общую память, которая доступна для чтения/записи всем процессам. И исторически z/OS имеет 24, 31 и 64 битную адресацию, т.е. чисто теоретически память может утекать в мизерной 24-битной адресации, в уже нормальной 31-битной памяти или в бездонной 64-битной. Любое привилегированное приложение (Key 0, SUPER MODE) может аллоцировать память в общем пространстве.

Одним из примеров использования общей памяти может служить следующая ситуация: у нас есть продукт "A", который хочет получить данные о продукте "B", для этого "A" запрашивает общую память, кладёт туда код, который запустится в адресном пространстве продукта "B" (это называет schedule SRB - Service Request Block), пройдёт по нужным блокам памяти, заполнит нужную структуру и вернётся в "A" для дальнейшей обработки результатов и затем "A" очистит общую память.

Но что если "A" будет запрашивать общую память, скажем, каждые 15 минут, но чистить не будет? Размер общей памяти будет уменьшаться до тех пор, пока различные приложения не начнут падать (ABEND) из-за нехватки этой памяти. Фишка в том, что даже если убить "A" z/OS не вернёт неочищенную общую память (на то она общая, особенная и может быть использована только привилегированными приложениями). Т.к. этой памяти станет мало, придётся рестартовать LPAR, это процесс называется IPL.

Поэтому нам, как разработчикам, нужно быть очень внимательными с общей памятью и пытаться чистить её даже в случае ненормального (kill) завершения приложения.

Нестабильность системы

"В смысле мейнфреймы нестабильны?". Тут суть в том что конфигурация боевых мейнфреймов и наших девелоперских мейнфреймов - это совершенно разные подходы к отказоустойчивости и администрированию. Как разработчик, я могу отключать диски(DASD), менять каталоги, смотреть информацию по системе, менять приоритет процессов (джобов) и многое другое, что в реальной жизни даже не всем администраторам мейнфреймов позволено делать. Всё это нужно, чтобы разработчики больше времени тратили на разработку, а не на ожидание получения доступов и разрешений.

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

Или кто-то включил PRIMEPSA, которая не занулит всю запрашиваемую вашим приложением память, а, например, всё заполнит байтом 0xAA. Тем самым ваш продукт начинает падать с ABENDами в разных модулях потому, что проверки на NULL теперь пропускают то, что обычно было NULL.

Или кто-то стал делать нагрузочное тестирование на том же LPAR что и вы. В итоге у вашего приложения CPU голодание, и вам нужно переезжать на другой LPAR или другой мейнфрейм.

Всё это приводит к перезагрузке (IPL) LPARов раз в 1-2 недели, когда как на боевых мейнфреймах это происходит 1-2 раза в год.

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

Google не поможет

И Stack Overflow тоже. Очень часто сталкиваешься с тем, что при гуглении вопроса или ключевого слова находится всего несколько результатов поискового запроса. Более того, это могут быть форумы на которых человек задавал тот же самый вопрос что и вы ... лет 10 назад ... на него так никто и не ответил. Такое происходит не всегда, но чаще приходится скачивать и читать документации чтобы самому ответить на собственный вопрос.

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

Поэтому, у нас есть свои собственные wiki, где ответ найти намного проще, чем в интернете. В любом случае, всегда найдётся ответ на свой вопрос или человек, который тебе поможет.

Кастомеры

Как и все, мы пишем продукты, которые используются кем-то, в нашем случае это кастомерами по всему миру. Основная цель наших продуктов - решать бизнес-процессы кастомеров, мониторить системы, упрощать им жизнь, выявлять потенциальные проблемы на ранних стадиях и т.д. Фишка в том, что разные бизнесы имеют свои особенности, в них работают люди с разным мышлением и они пытаются решать разные проблемы с помощью наших продуктов. Как следствие, в продуктах существует множество как задокументированных, так и незадокументирумых фич.

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

Например, один из бразильских кастомеров имеет много баз данных Adabas на z/OS и им критически было важно мониторить информацию о том, как эти базы используют хранилище данных. Собственно, нам пришлось это реализовывать в наш продукт за короткий промежуток времени. В итоге это фича доступна всем, хотя ценность приносит только малому числу кастомеров.

Азиатские кастомеры, как ABC или CCB, очень дотошны, они пытаются разобраться во всём. Если они найдут незначительный баг, то будут требовать объяснения о причинах этого бага и того, как он был пофикшен. В итоге разработчик может тратить несколько часов на объяснения техподержке, менеджеру, кастомеру вместо выполнения реальной работы.

Есть принципиальные кастомеры, которым нужно, чтобы всё было готово вчера, есть понимающие, с которыми можно обсудить примерные сроки, или которым можно подготовить тест-фикс для проверки решения (особенно если на своих системах проблема не воспроизводится).

Заключение

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

В целом, если зайти в офис (после того как их откроют, разумеется) к мейнфрейм разработчикам, вы не увидите сильных различий: тот же scrum, те же сопутствующие митинги, всем знакомые IDE, автоматизация на том же Python, какие-то web UI, те же тикеты в Jira и много чего ещё узнаваемого. Думаю, глобализация и желание всех компаний работать эффективно делает всё везде похожим.