RE: ASCII to EBCDIC

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