Доступ к RPG в iSeries из Java

Question

Кто-нибудь имел хороший опыт непосредственного общения с программами RPG, работающими на компьютере V5R4 iSeries с Java? Если да, то каковы рекомендации сообщества и каких ловушек мне следует избегать?

Из различных литературных и всплесковых решений, которые я пробовал, похоже, что мы можем использовать ProgramCallBeans (через PCML или xPCML), общаться с DataQueues (для асинхронных коммуникаций) или даже JNI.

Я ищу что-то надежное, производительное, быстрое в разработке, простое в обслуживании и простое в тестировании (не так ли?!!).

Answer 1

Я предлагаю использовать Java Toolbox для Java от IBM. Поместите JT400.jar в ваш classpath (или JT400Ntv.jar, если Java работает на iSeries). Я использовал как класс ProgramCall, так и классы CommandCall.

Класс com.ibm.as400.access.CommandCall прост в использовании. Он имеет простой конструктор, которому вы передаете класс com.ibm.as400.access.AS400. Затем просто используйте метод run, как этот:

CommandCall command = new CommandCall(as400);
command.run("CPYF FROMFILE(BLAH) TOFILE(BLAHBLAH) CRTFILE(*YES)");

Конечно, вы бы не использовали эту конкретную команду CL, но вы поняли идею. При использовании класса CommandCall всегда полезно обрабатывать любые сообщения, поступившие от команды. В одной программе, для которой я использую это, я отображаю сообщения пользователю в текстовом поле на их экране следующим образом:

AS400Message[] messageList = command.getMessageList();
for (int i=0;i < messageList.length;i++) {
String sMessageText = messageList[i].getText();
    sMessage+=sMessageText + "\n";
}

Класс com.ibm.as400.access.ProgramCall требует больше работы, но позволяет получить доступ к возвращаемым параметрам. Я использую это чаще, потому что я обычно вызываю существующие рабочие программы RPG, которые возвращают значения. Для этого определите массив com.ibm.as400.access.ProgramParameter. При передаче параметров в программу из Java не забудьте преобразовать их в дружественные для AS / 400 значения, используя класс, такой как com.ibm.as400.access.AS400Text. Детали команды ProgramCall лучше изучены с использованием документации IBM: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahh/page1.htm

Answer 2

Вы должны посмотреть на JTOpen . Это довольно легко использовать, чтобы делать то, что вы хотите сделать. Вот пример, который собрал:

Answer 3

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

PCML позволяет несколько прозрачно передавать типы данных Java в программу rpg в качестве параметра. Недостатком является то, что XML в документе PCML становится статическим интерфейсом и должен обновляться, если программа когда-либо обновляется. С правильными инструментами сборки может быть довольно просто автоматизировать обновление pcml xml, но сейчас я делаю это вручную.

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

В случае, когда логический поток контролировался программой rpg, я использовал очереди данных как для синхронных, так и для асинхронных вызовов java. Это потребовало написания значительного количества кода для стандартизации того, как читать и писать в очереди данных скоординированным образом из разных языков программирования

Answer 4

Довольно просто вызывать java-методы прямо из RPG. Я не уверен, что именно вы пытаетесь сделать, я несколько раз обращался напрямую к java-методам.

Для примера того, как это делается. Взгляните на RPGMail . Вы можете посмотреть на источник и увидеть, как Аарон использовал RPG для подключения к JavaMail.

Answer 5

Мы просто используем JDBC и хранимые процедуры. Хранимая процедура вызывает RPG вместо запуска SQL. Я не программист RPG, но кажется, что это очень простой интерфейс. DataQueues в порядке, но они не такие надежные, как JMS (без гарантированной доставки).

Answer 6

Хм, я новичок здесь и проголосовал бы за ответ KC Baltz, но пока не могу. Хранимые процедуры - путь. Я использовал JT open для непосредственного вызова программ и нашел проблемы с количеством передаваемых параметров, проблемами с типами данных и т. Д. После того, как у вас есть программа-оболочка SQL-процедуры вокруг вашей программы, вы обнаружите, что поддержка Java для SQL быть намного лучше, чем поддержка Java для нативных 400 вызовов.