Перенос RPG на Java на IBM iSeries

Question

Наша компания использует IBM iSeries для большей части нашей обработки данных. Все наши внутренние приложения написаны в RPG. Согласно дорожной карте IBM, IBM предлагает компаниям перейти на Java/J2EE. Мы стремимся модернизировать наши внутренние приложения к более GUI-интерфейсу. Мы предоставляем внешнее присутствие в Интернете с помощью веб-сайтов Asp.Net, хотя, возможно, проектами с новыми проектами могут быть Java. Один из вариантов - использовать приложение скриншота экрана, оставаясь на RPG, но я думаю, что может быть лучше медленно идти по пути дорожной карты IBM и перейти на Java. Наша цель - перейти к интерфейсу графического интерфейса и быть в соответствии с дорожной картой IBM.

Были ли вы связаны с переносом RPG на Java, даже если только проекты с зеленым полем были Java, а проекты с коричневыми полями остались RPG?

Мой менеджмент боится, что:

1) обновление JRE на рабочих станциях, особенно тонкие клиенты, может привести к административному кошмару (Наша компания использует 80% тонкие клиентов и 20% ПК) и

2) Java требует слишком много накладных расходов на рабочую станцию ​​для эффективной работы

3) Несовместимость между клиентами JRE по мере обновления, потенциально нарушая работу других приложений, требующих JRE.

Можете ли вы пролить свет на это? Есть ли огромные преимущества? Какие-то огромные пропасти?

ПОДТВЕРЖДЕНИЕ: меня интересует только переход на Java. Каков уровень сложности и я что-то теряю при переходе с RPG на Java? Являются ли экраны очень отзывчивыми при переносе на Java?

Answer 1

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

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

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

• Вы должны быть в состоянии двигаться только с помощью .NET, хотя вы, возможно, потребуется различные аппаратные/разделов для запуска среды. По крайней мере, вы можете поговорить с DB2. Единственное преимущество Java заключается в том, что он будет работать на той же ОС/аппаратном обеспечении, что и база данных.
• Я видел приложение screencraper здесь (оно было в VB.NET, но я уверен, что пример применим). Скребок экрана выполнялся путем ввода/размещения символов в определенных положениях на экранах (эквивалент substring()). Это может быть просто API, который мы использовали - я думаю, что слышал о решениях, которые могли читать имена полей. Однако он также полагался на поток программы RPG для своей логики и в остальном не поддерживался.
• Большинство программ RPG, которые я видел и писал, как правило, являются нарушением MVC, а это означает, что вы не можете сделать ничего, кроме интеграции - история и архитектура самого языка (и некоторых разработчиков) предпочитают, чтобы все (доступ к экрану экрана) в одном файле. Это также сделает попытку обернуть RPG для удаленного доступа к невозможности. IF Вы правильно разделили все на Сервисные программы, вы должны были бы их обернуть (как эквивалент нативного метода вызова, почти) аккуратно - к сожалению, я ничего здесь не видел, полагаться на один или несколько трюков, которые не задерживались бы при обычном использовании в Интернете (например, используя файл в QTEMP для управления выполнением программы - сеанс на iSeries эффективно исчезает каждый раз, когда запрашивается новая страница ...).
• Java как язык имеет тенденцию способствовать улучшению разделения кода (обратите внимание, что его можно неправильно использовать так же плохо), поскольку он не имеет достаточно истории RPG. В целом, может быть полезно подумать о Java как о языке, где все является сервисной программой, где все параметры переданы с набором VALUE, OPTIONS(*nopass : *omit) запрещен, обычно рекомендуется CONST, и большинство параметров имеют тип DS (структура данных - это является отдельным типом в RPG) и передается по указателю. Параметры уровня модуля не одобряются, если они предпочитают инкапсулировать все либо в переданные структуры данных, либо сами процедуры сервисной программы. STATIC имеет несколько иное применение в Java, делая переменную глобальную и недоступно внутри процедур.
• RPG довольно прост, чем Java, как правило, и OO-программирование - совершенно другая парадигма. Вот некоторые вещи, которые, вероятно, подножку разработчикам мигрирующие на Java:
  1. Массивы в RPG начинаются с 1. Массивы в Java начинаются с 0.
  2. Java не имеет параметры «Ouput», и все примитивные типы передаются по значению (скопированы). Это означает, что редактирование целого числа не будет отображаться в методах вызова.
  3. Java не имеет упакованного/подписанного кодирования, и поэтому перевод с/на номера/строки более активно. Тип Date в Java также имеет некоторые серьезные проблемы (включая время, вроде), и гораздо сложнее существенно изменить представление/символ.
  4. Сложнее читать и записывать файлы на Java, даже при использовании SQL (и забыть об использовании собственного ввода-вывода непосредственно с Java). Однако это может быть смягчено с помощью хорошей структуры.
  5. В Java нет операторов ENDxx, все использует скобки ({}), чтобы указать начало/конец блоков.
  6. Все в Java находится в формате freeformat, и нет никаких спецификаций столбцов любого типа (хотя сигнатуры процедур по-прежнему требуются). На длине линии нет жесткости, хотя по-прежнему рекомендуется ~ 80 символов. Инструменты (бесплатно) даже лучше, срок и в целом гораздо полезнее (хотя они могут привыкнуть к тем, кто подвергается воздействию SEU). Существуют также огромные бесплатные библиотеки, доступные для скачивания.
  7. Значок = не является контекстно-зависимым в Java так, как он есть в RPG, это всегда используется для присвоений. Используйте оператор double-equals, == для сравнения значений в Java.
  8. Объекты (datastructures) не могут быть значимо по сравнению с == - вам часто понадобится реализовать метод под названием equals().
  9. Строки не изменяются, их нельзя изменить. Все операции, выполняемые над строками (либо самим классом/datastructure, либо из внешних библиотек), возвращают новые ссылки. И да, строки считаются datastructures, а не типами значений, поэтому вы не можете сравнивать их с ==.
  10. Нет никаких встроенных эквивалентов предписывающих компиляторов . Попытка реализовать их неправильно использует Java. Поскольку они обычно используются для обработки кода «шаблона» (определения переменных или общего кода), лучше иметь дело с этим в архитеку. Переменные (ALL D-specs, фактически) definitons будут обрабатываться операторами import или import static, в то время как варианты с общим кодом обычно обрабатываются каркасом или определяют новый класс.

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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