Миграция RPG на Java в IBM iSeries - PullRequest
12 голосов
/ 22 ноября 2011

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

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

Мое руководство опасается, что:

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

2) Java требует слишком много служебной нагрузки для эффективной работы

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

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

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

Ответы [ 4 ]

14 голосов
/ 22 ноября 2011

Моя компания также пытается перейти на 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, в общем, немного проще, чем Java, и ОО-программирование - это совсем другая парадигма.Вот некоторые вещи, которые могут сбить с толку разработчиков, переходящих на Java:
    1. Массивы в RPG начинаются с 1. Массивы в Java начинаются с 0.
    2. В Java нет параметров 'ouput'и все примитивные типы передаются по значению (копируются).Это означает, что редактирование целого числа не будет видно в вызывающих методах.
    3. В Java нет упакованной / подписанной кодировки, поэтому перевод в / из чисел / строк более сложен.Тип Date в Java также имеет некоторые серьезные проблемы (в том числе время, в некотором роде), и его гораздо труднее осмысленно изменить на / из символьного представления.
    4. Труднее читать / записывать файлы в Java,даже при использовании SQL (и забудьте об использовании нативного ввода-вывода напрямую с Java) - это может быть несколько смягчено с помощью хорошей среды, однако.
    5. В Java нет операторов ENDxx, все использует скобки ({}) для указания начала / конца блоков.
    6. Все в Java находится в свободном формате, и нет никаких колоночных спецификаций какого-либо рода (хотя подписи процедур все еще требуются).Нет жестких ограничений на длину строки, хотя до сих пор рекомендуется ~ 80 символов.Инструменты (даже free даже лучше), точнее, и, как правило, гораздо более полезны (хотя они могут потребовать некоторого привыкания для тех, кто подвергается воздействию SEU).Также доступны для скачивания огромные бесплатные библиотеки.
    7. Знак = не является контекстно-зависимым в Java, как в RPG, он всегда используется для назначений.Используйте оператор двойного равенства == для сравнения значений в Java.
    8. Объекты (структуры данных) не могут быть осмысленно сопоставлены с == - вместо этого вам часто потребуется реализовать метод с именем equals().
    9. Строки не являются изменяемыми, их нельзя изменить.Все операции, выполняемые над строками (либо над самой структурой класса / данных, либо из внешних библиотек), возвращают новые ссылки.И да, строки считаются структурами данных , а не типами значений, поэтому их также нельзя сравнивать с ==.
    10. Нет встроенных эквивалентов для /copy preдирективы компилятора.Попытка реализовать их неправильно использует Java.Поскольку они обычно используются для работы с «стандартным» кодом (определения переменных или общий код), лучше разобраться с этим в архитектуре.Определения переменных (ВСЕ D-спецификации, фактически) будут обрабатываться с помощью операторов import или import static, в то время как варианты общего кода обычно обрабатываются каркасом или определяют новый класс.

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

3 голосов
/ 22 ноября 2011

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

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

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

2 голосов
/ 22 ноября 2011

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

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

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

0 голосов
/ 06 января 2012

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

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

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

...