Re: JT400 Record-level access problem

In DDS, I am not so sure. That is because the most desirable data type spec would be B=Binary [though actually signed Integer], but there is only signed binary support. DDS does not really have an equivalent type to BINARY in SQL, only the "shifted type" which is implemented with the H=Hexadecimal data type (position 35) declaration. The "Notes:" specific to the Hexadecimal data type do not give me great confidence that [shifted] type might not have the same issue per "most cases", even though I have that expectation: "Specify an H (hexadecimal) in position 35 to indicate a field whose contents are not interpreted by the system. In most cases, hexadecimal fields are treated as character fields, except that the contents of a hexadecimal field are not translated to any character set or code page."

Assuming H data type is functional for use of a DDS keyed database file, then CHGPF SRCFILE() issued after modifying the A data type specification in the source member to instead have the H data type specification [and removing any incompatible keyword modifiers such as CCSID(37)] will implement an effective ALTER TABLE to change the data type of the existing field.

In SQL the data type declaration is established with column data-type specification of BINARY(8) or the column modified using ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE BINARY(8)

Regards, Chuck

On 19 Oct 2012 11:05, Dan Kimmel wrote:

So it sounds like you're suggesting I somehow change the declaration
of the field in my files to BINARY. Can I do that in the DDS? Can I
do it with some sort of a CHG or ALTER TABLE?

CRPence on Friday, October 19, 2012 10:54 AM wrote:

On 19 Oct 2012 10:46, CRPence wrote:

I suppose a likely problem origin is for use of CCSID 37 instead
of FOR BIT DATA; the collation [Sort Sequence] would be moot for
the kind of issue I am thinking of.<<SNIP>>

Actually the use of CHAR, even with FOR BIT DATA, would likely
suffer the same type of problem I alluded. That is to suggest,
even the declaration of CHAR FOR BIT DATA is still
"character-string" data for which the blank-pad character changes
between encoding choices ASCII vs EBCDIC. Thus I presume the data
type to support 8-byte unsigned integer *must* be BINARY... which I
expect the database key processing *must* *never* infer any
pad-character to be used for comparisons.