Obviously I wasn't very clear in my response. First to say "even a
Windows based MSVC++ program can read..." just isn't true as you show by
continuing on to say "the drivers do all the translations." My response
was that he
needed to use a driver that converts or else do his own. Secondly and more
importantly, rather than encouraging platform specific questions, I was
asking that posters be very clear about it when that is what they are doing.
If that still isn't very clear or you don't like it, flame away. Otherwise,
when one is trying to avoid a waste of the time and effort of people who
sincerely want to help, you should stay out of their face.
Last, IBM's prompt, rather than being "brainless" actually saves some
custom work in most circumstances. The real problem, as is often the case
and a lesson to us all, is a lack of clear documentation on their intent and
how it works.
Joe Sam
-----Original Message-----
From: Thomas Moore <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, April 15, 1999 5:56 PM
Subject: Re: Urgent: Need to get int value
>Joe writes:
>> As you can see from your previous login question ( regarding an
>> AS/400 ToolBox for Java issue ) and this one, if I understand it
correctly,
>> people get confused here because they expect to answer it in a platform
>> independent way. This wastes their time and doesn't help you.
>[EBCDIC translation stuff deleted]
><flame mode="Java Evangelist" temp=mild>
> One of the key points to writing software in Java is doing away
with
>platform dependent issues like character encoding. However, even a
>Windows based MSVC++ program can read AS400 data without worrying about
>this sort of thing. The drivers (ODBC/JDBC) make all the translations,
>freeing the application programmer of that sort of concern.
> I also work with the AS400 Toolkit. I will grant that the AWT
login
>prompt default was a brainless move on IBM's part, but the rest of the
>questions should *not* be answered in a platform specific way. In the
>case of the login exception, that was a toolkit issue, not really a
>platform issue as such.
> My point is that this list is not for resolving platform specific
JDBC
>issues. I do think that it isn't a great sin to post questions that are
>only marginally related to servlets (like the tons of generic JDBC
>questions) because they are issues being faced by a lot of people right
>now. However, to recommend that people deliberately ask or answer
>platform specific issues is only going to decrease the signal to noise
>ratio...
></flame>
>--
>Within C++ is a smaller, cleaner language
>struggling to get out.
>It's called Java.
>
>Thomas Moore
>[EMAIL PROTECTED] Home Account
>Software.Engineer [EMAIL PROTECTED]
>phone://732.462.1880:268 NJ Patterns Group Home Page
>employer://Celwave, RF http://members.home.net/twmoore/cjpg
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
