× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'll definitely have a look at CommandGate, but I think my approach is still solid and performs well also and is easily teachable to IBM i developers. We'll see :-)

The best thing is it takes out the odd nature of trying to map out calls to Java types andmethods in an RPG program and loading only a single copy of the JVM in an RPG app. We had some programming we had done this was that fell apart at V7R1 so we removed RPG from the Java calling equation because it was not easily debuggable.

My approach typically uses Qshell and the 32-bit 1.5 or 1.6 JVM which smokes. I can run a simple submit remote command call to a remote system in 3-5 seconds, which includes JVM startup with JT400. Even faster without JT400.

Note: JT400 is not needed unless running remote commands, using data queues, building a NEP to perform intra-system program calls, etc.

I agree with your point on performance if I'm running thousands of these types of calls at a time, but most people aren't. If they are a pre-start approach or NEP app may be warranted as you suggested.

I have used this java calling technique in RJS commercial products for many years, so I'm pretty confident in recommending this approach to writing system commands with Java.

Also writing NEPS like you are describing would be pretty easy because the Java class just has to simply loop until some defined condition occurs. I'm guessing that's probably similar to how ArdGate works as you are describing it.

Java's not really too ugly if you build your own wrapper functions to provide standard functionality and creating simple fall-thru Java programs.

Good programmers learn from example. Maybe some of us can contribute some useful classes to this project.

I'll be opening up a Codeplex or GitHub site for the code once it's done, so any Java sample class or function sample donations will be appreciated and will get posted for people to share.

I'll make an honorable mention to check out ArdGate and CommandGate in my presentation so anyone interested can reach out and take a look as well.

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
------------------------------

message: 5
date: Sat, 7 Feb 2015 18:29:35 +0100
from: "D*B" <dieter.bender@xxxxxxxxxxxx>
subject: RE: Running java from CL was: RE: Java for RPG Programmers,
2nd edition still useful ?

Does CommandGate allow calls to feed response data back to the caller ?
it's running on a prestarted JVM ans as it running in a Multithreaded environment, you can't use System.out for this.

Your command gate component looks interesting, but it adds another
layer to worry about because it requires Tomcat or some other app
server container, correct ?
No, it doesn't need Tomcat. It's using its own server programm (a NEP), but this is rocksolid, it's the base layer of ArdGate which is running in production since its beginning without any problems.

My goal is to be able to create CL commands that don't necessarily
require RPG, but simply call a simple fall thru Java program to do
some action such as process a PDF with iText, Read/Write XML, etc
this was one of the starting points of CommandGate and this could be done without any programming, there are OpenSource (Java) solutions out there providing Java main programms, which don't need parms back, just a call to a Java main, providing the name of an input file and the name of an output file.

and allow parameters to be sent back from the Java CPP to the command
so that the CL commands are embeddable in a standard CL job stream and
can return parms via the CL command wrapper.
this could be don via AppServer4RPG. This base layer is extendable by a rather simple interface and you could define your in and out parameters as you need. ArdGate is implemented this way and it has to implement rather crude parameter structure going to and back.

An interesting by-product from my testing and using JT400 was the
simple ability to run a job on a remote system and bring back response
data without any special remote system setup. JT400 rocks for
inter-system IBMi communications and can now be used to easily perform
inter-system program calls without a lot of work.
the problem is arising, when you are starting multiple JVMS (worst case: one for every call). This is rather sloon server machines (as AS/400, but not
only) and doesn't scale well.

The secondary goal is to possibly move some RPG developers forward who
may have been previously afraid to touch Java. As you know it's not
that hard to use. It just gets roughed up a lot :)
That's not my experience; if they don't forget many things, they've learned for RPG, they are writing RPG logic in Java,, resulting in ugly code, which is hard to maintain (have a look to jt400, here you could see such code.

In today's world with the faster JVMs available and installed
natively, there's no reason not to consider Java to build command
processing programs that use the JVM directly.
On AS/400 CPU is rather expensive and the startup process of a JVM is much slower, than on other boxes. Running Java in a server manner: one prestarted JVM serves multiple clients in a multithreaded environment outperforms the direct call variants by far. Creating PDF from XHTML (without any programming needed) the runtime was cutdown from 10 to 20 seconds to subsecond (comparable to windows boxes). Just replacing RUNJVA with RUNJAVARUN this is happening and no classpath fiddling needed, just throw your needed jars to the lib directory of AppServer4RPG.

With my approach an RPG developer will hopefully be able to be writing
Java based fully callable/embeddable CL commands within a few hours
without any system setup beyond building a little CL program and
placing a small Java class in the appropriate IFS folder.
With a little extend to AppServer4RPG the interface could be extended for giving back parms as needed. The programmer would just write a Java class with a static method, "called" from RPG, or even direct from CL. This extend could be done easily and with a little bit of sponsoring I would make it open source (CommandGate was a similar joint venture.

Dieter

PS: if the discussion is getting to specific, feel free to contact me direct by eMail.



_______________


Confidentiality Notice: This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

________________

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.