|
Why don't u use stored procedures to do that. I am not sure if there is any issue or not. I think they are the best and easiest solution for communication b/w Java and RPG program. -----Original Message----- From: Chanh_Le@countrywide.com [mailto:Chanh_Le@countrywide.com] Sent: Friday, August 10, 2001 11:01 AM To: JAVA400-L@midrange.com Subject: RE: Communicating between java & rpg? I have some questions related to MQSeries. I appreciate very much for all inputs 1/ Besides String, is there anything else which MQSeries can transport like objects? 2/ If MQSeries can only transfer String, when placing XML through MQSeries, should we place as a serialized XML object or XML text file? 3/ Do you remember which MQSeries document shows how to set a Java program as a MQSeries trigger to process new arrival messages? Thanks. CL "DUCRET Gilles (GVA)" <Gilles.DUCRET@LloydsBank.ch>@midrange.com on 08/10/2001 12:23:33 AM Please respond to JAVA400-L@midrange.com Sent by: owner-java400-l@midrange.com To: "'JAVA400-L@midrange.com'" <JAVA400-L@midrange.com> cc: Subject: RE: Communicating between java & rpg? We use MQSeries and XML to enable communication between Java and RPG in a given application. I don't think that this is less work than data queues, since you have to write listeners, data exchange protocol, a framework to handle the queries. Should be the same work, but with another technology (MQ instead of data queues). In a recent redbook about java and iseries, there is several chapter about java interoperability on the as400. My suggestion would be: don't use something specific to the AS400. So, as Even said, MQ would be preferable. Gilles -----Original Message----- From: Evan Harris [mailto:spanner@ihug.co.nz] Sent: jeudi, 9. août 2001 21:47 To: JAVA400-L@midrange.com Subject: Re: Communicating between java & rpg? David Given that the processes will be on separate systems have you thought about MQ ? What you are describing sounds like a good scenario for MQ rather than trying to deal with all the process etc issues yourself. regards Evan Harris >Folks: > >We've got a project brewing where we have to communicate between java & rpg. >The java program is not necessarily going to be running on the 400 (in fact, >probably won't be). > >We're planning on using the Toolkit (probably JTOpen, but not 100% sure yet) >to implement remote data queue listeners. > >I'm curious if anyone knows of a "Recommended" way of using data queues for >inter system communication? > >Also, does anyone know of a way to handle "Process Death" on either side of >the connection? If I were using TCP, I would just look for a closed socket. >With a dataqueue, the potential exists for the remote process (the one that >feeds the data queue) to die and the local process (the one that eats the >data queue) to just wait forever. > >Thanks! > >david +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +--- ********************************************************************** This E-mail and any files transmitted with it are confidential and intended for the exclusive use of the addressee(s) only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender immediately. ********************************************************************** +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
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.