|
You can use iconv api in AS/400 to do it but I think that is better option
that you send EBCDIC data to the AS/400 instead ASCII, you release AS/400 to
do this task.
you can use toolbox AS400Text do it . The next its my client class code, you
can adaptate it.
import java.net.*;
import java.io.*;
public class clientJAVA {
private Socket socket = null;
private BufferedInputStream reader = null;
private BufferedWriter writer = null;
private DataOutputStream os = null;
private DataInputStream is = null;
private ConexionClienteJAVA() {
super();
}
public cientJAVA(String serverStr, int port) throws Exception {
super();
InetAddress serverAddress = InetAddress.getByName(serverStr);
socket = new Socket(serverAddress, port);
socket.setSoTimeout(10000);
os = new DataOutputStream(socket.getOutputStream());
is = new DataInputStream(socket.getInputStream());
}
public void close() throws Exception {
socket.close();
}
public void write(String linea) throws Exception {
com.ibm.as400.access.AS400Text textConverter = new
com.ibm.as400.access.AS400Text(linea.length());
String aux;
byte[] ebcdicStr = textConverter.toBytes(linea);
os.write(ebcdicStr);
aux = leer();
}
public String read() throws Exception {
int textLength = 100;
String linea = null;
com.ibm.as400.access.AS400Text textConverter = new
com.ibm.as400.access.AS400Text(textLength);
byte[] data = new byte[textLength];
int length = is.read(data, 0, textLength);
linea = ((String) textConverter.toObject(data)).substring(0,
length);
return linea;
}
public static void main(String args[]) {
try{
clientJAVA c = new clientJAVA( "AS400M", 3771 );
c.write( "Hola ");
}catch( Exception e ){
System.err.println( "Error: "+ e );
}
}
}
----- Mensaje original -----
De: <mtanveer@friedmancorp.com>
Para: <JAVA400-L@midrange.com>
Enviado: miércoles 12 de enero de 2000 23:04
Asunto: ASCII to EBCDIC
> how can i translate data from ASCII to EBCDIC. I am doing some socket
> programing usin RPG/ILE. The only problem I am having is that PC is
sending
> me ASCII data on my port. I can read it but its not in EBCDIC.
>
> Please help
> Thanks
>
> -----Original Message-----
> From: owner-java400-l@midrange.com
> [mailto:owner-java400-l@midrange.com]On Behalf Of
> Andrew_Goodspeed@lbss.com
> Sent: Wednesday, January 12, 2000 9:43 AM
> To: JAVA400-L@midrange.com
> Cc: John_Jones@lbss.com; Zheng_Lee@lbss.com; Gary_Sun@lbss.com
> Subject: Re: jdbc-IBM Connection Manager-Servlets and sql handles
>
>
>
>
> Here is a little more information on why at least one person thinks that
> this is
> a good thing (a feature, not a bug).
>
> I am not sure what you are getting at in your reply, Gary. I gather that
> there
> is a persistent connection, and the problem (if it is a problem) is in
> closing
> the connection without closing the statements.
>
> I am curious how other implementations handle this. Are the connection
and
> the
> statement synchronized? And what about Netscape's Suitespot server?
>
>
>
>
>
> "Luther Ananda Miller" <luther.miller@HYPERE.COM> on 01/12/2000 09:49:00
AM
>
> Please respond to JAVA400-L@midrange.com
>
> To: JAVA400-L@midrange.com
> cc: (bcc: Andrew Goodspeed/Atlanta/LBSS)
>
> Subject: Re: jdbc-IBM Connection Manager-Servlets and sql handles
>
>
>
> > Do you see a downside to asking IBM to enhance the
> > releaseIBMConnection() method to call Statement.close() on any open
> > statements?
>
> Yes! releaseIBMConnection() just puts the connection back in the pool--
the
> connection is not necessarily closed at this point. It is very reasonable
to
> assume that some applicatoins might create a connection pool where
> statements within the connections within the pool could be used more than
> once. I am not sure how it would be implemented-- e.g., how would the
second
> user of a connection know that the statements have already been allocated?
> One way might be to subclass the Connection and add some functionality for
> application-specific statement management to the subclass, and let the
pool
> be instances of the subclass.. depending on the application at hand, this
> could be a real performance booster.
>
> Regarding the original problem of closing statements that will no longer
be
> used, be sure to do something like this:
>
> // [statement opened]
> try {
> // [use statement]
> } finally {
> stmt.close();
> }
>
> to ensure that it will ALWAYS be closed no matter what might go wrong in
> between..
>
> Luther
>
> > > Alex Garrison wrote:
> > > We sent a sql cli trace to IBM and found out that we were running out
> > > of free sql handles. Long story short: You must call the
> > > Statement.close() method when you are finished with a statement. If
>
>
> +---
> | 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 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 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 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-2025 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.