[cdt-core-dev] DataStore communication layer unicode requirement

[dmcknigh@xxxxxxxxxx]

The DataStore communication layer sends bytes with PrintWriter and receives
bytes by casting to String.  It makes the assumption that the encodings are
the same, which might not be true.  As a result, when communicating from a
Linux or Windows client to a 390 server, the communication layer fails.

The resolution that I think makes the most sense is to change the
communication layer to be pure UTF8 at least for transferring DataElements
(not sure about file transfer).  This should be fairly straight-forward as
we only need to change the Readers in the XML layer to be ones that support
unicode.  I've opened a defect to address this issue - 10433.



Here is a summary of a thread notes that have been passed around regarding
the DataStore communication layer:

------------------------------------------------------------------------------------------------------------------
Don Yantzi to David McKnight:


It looks like we have found another problem with running the datastore in
an EBCDIC environment.  My understanding is on zOS the JVM actually runs in
EBCDIC (as opposed to the iSeries where the JVM does actually run as ASCII
but all input and output is EBCDIC) so when we are running the DataStore
there, the XML Parser is expecting EBCDIC from the client!!!

I think as part of the initial connect handshaking we should exchange the
default file.encoding system value and have either the client or server use
this when sending and receiving information to the other end via the XML
Parser or Generator.

------------------------------------------------------------------------------------------------------------------
Eric Simpson to Don Yantzi:

The file.encoding is Cp1047.

Should we do something more or should we now get the DataStore team
involved?

------------------------------------------------------------------------------------------------------------------
Gabe Czobel to Eric Simpson:

Here's the output of your sysproperties:

-- listing properties --
java.assistive=ON
platform.notASCII=true
java.runtime.name=Java(TM) 2 Runtime Environment, Stand...
sun.boot.library.path=/usr/lpp/java/IBM/J1.3/bin
java.vm.version=1.3.1
java.vm.vendor=IBM Corporation
java.vendor.url=http://www.ibm.com/
path.separator=:
java.vm.name=Classic VM
file.encoding.pkg=sun.io
java.vm.specification.name=Java Virtual Machine Specification
user.dir=/u/ts64498/java/rseserver
java.runtime.version=1.3.1
java.fullversion=J2RE 1.3.1 IBM OS/390 Persistent Reus...
java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
os.arch=390
java.io.tmpdir=/tmp
line.separator=

java.vm.specification.vendor=Sun Microsystems Inc.
java.awt.fonts=
os.name=z/OS
java.library.path=/usr/lpp/java/IBM/J1.3/bin/:/usr/lpp/...
java.specification.name=Java Platform API Specification
java.class.version=46.0
invokedviajava=
os.version=01.02.00
user.home=/u/ts64498
user.timezone=EST
java.awt.printerjob=sun.awt.motif.PSPrinterJob
file.encoding=Cp1047
java.specification.version=1.3
user.name=TS64498
java.class.path=.
java.vm.specification.version=1.0
java.home=/usr/lpp/java/IBM/J1.3
java.specification.vendor=Sun Microsystems Inc.
user.language=en
java.vm.info=J2RE 1.3.1 IBM OS/390 Persistent Reus...
java.version=1.3.1
java.ext.dirs=/usr/lpp/java/IBM/J1.3/lib/ext
sun.boot.class.path=/usr/lpp/java/IBM/J1.3/lib/rt.jar:/us...
java.vendor=IBM Corporation
file.separator=/
java.vendor.url.bug=
java.compiler=jitc
sun.io.unicode.encoding=UnicodeBig

------------------------------------------------------------------------------------------------------------------
Eric Simpson to Gabe Czobel:

Not sure what is causing this.  It could be related to running in EBCDIC.
Could you try running a .class file I am sending?  It just displays all the
system properties.  That could help us understand what is going on.

You can run the class just with 'java sysproperties'.


------------------------------------------------------------------------------------------------------------------
Gabe Czobel to Eric Simpson:

I've gotten to the point with the server that the RSE client thinks there
is a connection. No error message pops up in RSE when I click on connect
for a subsystem and the log shows:

   Fri Feb 22 14:57:58 EST 2002
   INFO com.ibm.etools.systems.core  Connected to TOROLABB on port 8000
   --------------------------------------------

But the server on the host fails as soon as I attempt the connection. On
the host, the following messages (in blue) appear right after trying to
connect:

   Server Started Successfully
   8000
   Server running on: TOROLABB
   java.lang.NullPointerException
           at
   com.ibm.dstore.core.util.XMLparser.parseDocument(XMLparser.java:241)
           at
   com.ibm.dstore.core.util.Receiver.handleInput(Receiver.java:81)
           at com.ibm.dstore.core.util.Receiver.run(Receiver.java:64)
   java.lang.NullPointerException
   java.lang.NullPointerException
           at
   com.ibm.dstore.core.server.ServerReceiver.handleError(ServerReceiver.
   java:53)
           at
   com.ibm.dstore.core.util.Receiver.handleInput(Receiver.java:95)
           at com.ibm.dstore.core.util.Receiver.run(Receiver.java:64)
   Server Finished

When I actually try to expand the filters in the subsystem in RSE , I get
an exception because the server has already died. Are you familiar with the
server code and what these messages mean?

------------------------------------------------------------------------------------------------------------------


____________________________________
David McKnight
Linux AD, CDT Development
Phone:   905-413-3902 , T/L:  969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail:       D2/ 329/8200/TOR
____________________________________