Re: What exactly is a "Binary Character" field?

On 16-Jun-2015 13:55 -0600, James H. H. Lampert wrote:

On 6/16/15 12:21 PM, CRPence wrote:

On 16-Jun-2015 12:19 -0600, James H. H. Lampert wrote:

It sounds oxymoronic.

What exactly is a "Binary Character" field?
"5" instead of "A" in the DDS;

AFaIK: In DDS specification, I believe that would be: "H" instead
of "A". Probably also the same effect [a Binary Character field] is
seen for a field defined with the [resolved] field-level keyword of
CCSID and the specification of 65535 [or possibly the special-value
*HEX, if supported].

The Ignorance Center (and empirical data) say "Binary Character" is
"5" in both DDS and QUSLFLD, and that "H" is "Hexadecimal."

<http://www.ibm.com/support/knowledgecenter/ssw_i5_54/rzakb/ldata.htm>


But that still doesn't say what in blazes "Binary Character" IS.
Whether it's some new kind of shift (wouldn't that be a keyword,
rather than a data type?), or whatever.

I did just run a test, creating a file from
A R FOO
A BAR 85
A BAZ 8A

and got this in DSPFFD:

Data Field Buffer Buffer
Field Type Length Length Position
BAR BINCHAR 8 8 1
Keyboard shift . . . . . . . . . . . . . : B
Coded Character Set Identifier . . . . . : 65535
BAZ CHAR 8 8 9
Coded Character Set Identifier . . . . . : 37

I muddled a bit of BINCHAR and HEX, although they are essentially identical; DDS Data-type code of 'H' has shift value of 'H' but that does not manifest in the DSPFFD whereas the Data-type code of '5' has shift value 'B' that is manifest on DSPFFD. I had forgotten that the DDS had not simply extended the existing concept of H=Hexadecimal, and instead added a new\separate DataType code of '5' to match the /new/ [new at that time] SQL data type of BINARY; presumably so the *DBXREF could continue to record the Field Type as CHAR for H=Hex for compatibility while storing the new Field Type as BINARY, though the differing shift-values should have already been capable of enabling that.

At first glance I had no idea why the Display File Field Descriptions (DSPFFD) feature chose to manifest the data type as BINCHAR instead of using the SQL naming of BINARY, figuring that was their prerogative. However upon further review, I am reminded with a test that BINARY was already being used for the B=Binary (aka Integer) data type. I suppose given the old BINARY appeared only in [displayed] spooled output, they could have /corrected/ that original SNAFU-naming instead, and renamed that to something like BIN2INT and BIN4INT :-)

As has been noted a few times [in the prior thread and again in this thread], the /Binary Character/ (BINCHAR) designation is just an indication that the shifted character-data-type is not translated per the implicit attribute of CCSID(65535) [aka CCSID(*HEX)]; hence the data is considered /binary/ [aka /image/ in FTP terminology].