Миграция RPG на Java на IBM iSeries

Моя компания также пытается перейти на Java из RPG.

1. Мы не пытаемся использовать JRE на тонком клиенте, мы переходим к веб-приложениям, доставляемым через браузер. Это может повлечь за собой (в конечном итоге) замену наших старых POS-сканеров некоторыми из более новых сканеров на базе ПК.
2. Мне сообщили (от архитекторов компании), что JVM в ОС iSeries действительно имеет некоторые проблемы с производительностью. Я лично не знаю, что это за ограничения. В нашем случае миграция включала в себя выделение ресурса AIX, что должно быть намного лучше — поговорите со своим представителем IBM о том, нужно ли вам просто приобрести лицензию на ОС (я просто программирую на этом, я не вмешиваюсь в процесс). аппаратное обеспечение).
3. См. ответ на вопрос 1. В более широком контексте, когда вы пытаетесь обновить браузер (или любой другой ресурс), это обычно решается наличием корпоративных лицензий. , удаленные обновления.

Некоторые другие примечания:

• Вы должны иметь возможность перейти только к использованию .NET, хотя для запуска среды вам может потребоваться другое оборудование/разделы. По крайней мере, так можно разговаривать с DB2. Единственное преимущество Java заключается в том, что он будет работать на той же ОС/аппаратном обеспечении, что и база данных.
• Я видел здесь приложение для очистки экрана (оно было в VB.NET, но я уверен, что пример применим). Очистка экрана выполнялась путем получения / размещения символов в определенных позициях на экранах (эквивалент substring()). Это может быть просто API, который мы использовали — я думаю, что слышал о решениях, которые могли читать имена полей. Тем не менее, он также полагался на программный поток RPG для своей логики, и в остальном его нельзя было поддерживать.
• Большинство RPG-программ, которые я видел и писал, имеют тенденцию нарушать MVC, а это означает, что вы не можете делать ничего меньшего, чем интеграционное тестирование — история и архитектура самого языка (и некоторые разработчики) предпочитают, чтобы все (доступ к файлам для отображения на экране) находиться в одном файле. Это также сделает практически невозможной попытку обернуть RPG для удаленного вызова. ЕСЛИ вы правильно разделили все на служебные программы, вы должны иметь возможность аккуратно их обернуть (почти как эквивалент вызова нативного метода) - к сожалению, я не не видел здесь ничего, что не полагалось бы на один или несколько трюков, которые не подходят для типичного использования в Интернете (например, использование файла в QTEMP для управления выполнением программы — сеанс на iSeries фактически исчезает каждый раз, когда запрашивается новая страница...).
• Java как язык имеет тенденцию способствовать лучшему разделению кода (обратите внимание, что его можно использовать не по назначению), поскольку он не имеет истории RPG. В общем, может быть полезно думать о Java как о языке, в котором все является служебной программой, где все параметры передаются с установленным VALUE, OPTIONS(*nopass : *omit) не разрешено, CONST обычно рекомендуется, а большинство параметров имеют тип DS (структура данных — это является отдельным типом в RPG) и передается по указателю. Параметры уровня модуля не одобряются, если они предпочитают инкапсулировать все либо в переданных структурах данных, либо в самих процедурах служебной программы. STATIC используется в Java несколько иначе, делая переменную глобальной и недоступной внутри процедур.
• RPG is quite a bit more simple than Java, generally, and OO-programming is quite a different paradigm. Here are some things that are likely to trip up developers migrating to Java:
  1. Arrays in RPG start at 1. Arrays in Java start at 0.
  2. В Java нет выходных параметров, и все примитивные типы передаются по значению (копируются). Это означает, что редактирование целого числа не будет видно при вызове методов.
  3. В Java нет упакованной/подписанной кодировки, поэтому перевод в/из чисел/строк более сложен. Тип Date в Java также имеет некоторые серьезные проблемы (в том числе и время), и его гораздо сложнее осмысленно изменить на/из символьного представления.
  4. Читать/записывать файлы на Java сложнее, даже при использовании SQL (и забудьте об использовании собственного ввода-вывода непосредственно с Java) - однако это можно несколько смягчить с помощью хорошей структуры.
  5. В Java нет операторов ENDxx, везде используются скобки ({}) для указания начала/конца блоков.
  6. В Java все находится в свободном формате, и нет никаких колоночных спецификаций (хотя сигнатуры процедур по-прежнему требуются). Жестких ограничений на длину строки нет, хотя по-прежнему рекомендуется ~80 символов. Инструменты (даже бесплатные) лучше, точка, и, как правило, намного полезнее (хотя тем, кто подвергается SEU, может потребоваться некоторое время, чтобы привыкнуть к ним). Существуют также огромные бесплатные библиотеки, доступные для скачивания.
  7. Знак = не является контекстно-зависимым в Java, как в RPG, он всегда используется для присваивания. Используйте оператор двойного равенства == для сравнения значений в Java.
  8. Объекты (структуры данных) нельзя осмысленно сравнивать с == — вместо этого вам часто потребуется реализовать метод с именем equals().
  9. Строки не изменяемы, их нельзя изменить. Все операции, выполняемые со строками (либо в самом классе/структуре данных, либо из внешних библиотек), возвращают совершенно новые ссылки. И да, строки считаются структурами данных, а не типами значений, поэтому их также нельзя сравнивать с ==.
  10. Встроенных эквивалентов директив прекомпилятора /copy нет. Попытка реализовать их означает неправильное использование Java. Поскольку они обычно используются для работы с «шаблонным» кодом (определения переменных или общий код), лучше иметь дело с этим в архитектуре. Определения переменных (на самом деле ВСЕ D-спецификации) будут обрабатываться с помощью операторов import или import static, в то время как варианты общего кода обычно обрабатываются фреймворком или определением нового класса.

Я уверен, что есть ряд других вещей, дайте мне знать, если у вас есть другие вопросы.

Распространение и управление толстым клиентом было бы абсолютным кошмаром.

Идеальным решением является веб-приложение на основе Java, размещенное на iSeries. Рабочие станции получают доступ к вашим приложениям через веб-браузер, как и в ASP.NET.

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

Когда IBM говорит, что вы должны перейти на Java/J2EE, вам, вероятно, следует переместить свои приложения в веб-приложения, такие как веб-приложения asp.net. Вероятно, вам следует использовать многофункциональный интерфейс, такой как JSF или GWT.

Веб-приложениям не нужно беспокоиться о проблемах с JRE, поскольку вам нужен только стандартный браузер.

Однако я не знаю RPG и не знаю предлагаемой стратегии миграции.

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

В дополнение к веб-сайтам на основе Java EE вы, вероятно, можете использовать веб-сервисы на основе jax-ws, которые предоставляют услуги для различных плоских и сетчатых экранов.

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