db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: DRDA confusion
Date Thu, 01 Nov 2007 13:54:21 GMT
Dyre.Tjeldvoll@Sun.COM writes:

> Dyre.Tjeldvoll@Sun.COM writes:
>
>> Hi,
>>
>> I'm trying to understand how the DRDA spec is implemented in the
>> client driver and on the server. Specifically how to write and parse
>> an SQLSTT command.
>>
>> The implementation of NetPackageRequest.buildSQLSTTcommandData(String)
>> inserts an SQLSTT code point into the message, but the encoding of the
>> bytes that follow does not match the specification in the DRDA
>> manual. It states (Vol 3, page 825) that SQLSTT takes an instance of
>> BYTESTRDR (len, 0x044, ... bytes ...). But
>> buildSQLSTTcommandData(String) ends up calling buildNOCMorNOCS(String
>> string) which seems to encode the SQLSTT value as either
>>
>> (0x00, len, ... bytes ..., 0xff) 
>> or
>> (0xff, 0x00, len, ... bytes ...)
>
> After some more reading it seems like the value of an SQLSTT is "a
> sequence og bytes" but it does not have to start with the 0x44 code
> point. It seems like the rules governing what a legal value is
> determined by the FD:OCA descriptor... 
>
> But I still don't understand where the DRDA spec defines the two
> formats that can be used... Does anyone have the chapter and verse
> which descibes this? 

I don't know where it is defined, or whether it's defined at all. But as
I read the code, the byte sequences should be read like this:

>> (0x00, len, ... bytes ..., 0xff) 

First byte is a null indicator for a mixed-byte character string. Since
it is different from 0xff (which is the null-marker), it is followed by
the string length in bytes and the string encoded in a mixed-byte format
(UTF-8, I would guess, but it is negotiable, see for instance setting of
ccsid[SDM]BCEncoding in DRDAConnThread.parseTYPDEFOVR()). The last byte
(0xff) is a null indicator for a single-byte character string. Nothing
follows it since it marks that the single-byte character string is null.

>> (0xff, 0x00, len, ... bytes ...)

First byte indicates that the mixed-byte character string is null,
second byte indicates that the single-byte character string is not
null. Then follows length in bytes, and the string encoded as
single-byte per character.

Only one of the null indicators can be different from 0xff (otherwise
the string would be encoded twice). (0xff, 0xff) indicates that the
string is null.

-- 
Knut Anders

Mime
View raw message