|
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-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.