|
It would kind of surprise me if there wasn't something built into the socket APIs to handle the conversion. Although I've not done socket programming in RPG, IBM usually supports conversion at the communication level. The Client Access APIs are a good example. If not, then you might try the QDXLATE API. Its documented in the System API Reference. Nathan Andelin. -----Original Message----- From: mtanveer@friedmancorp.com [mailto:mtanveer@friedmancorp.com] Sent: Wednesday, January 12, 2000 3:04 PM To: JAVA400-L@midrange.com Subject: 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.