×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 01-Feb-2012 12:03 , Kurt Anderson wrote:
I changed the varchar to char for a test, and the format level IDs
came out the same.
From a dump of the database file I determined the problematic bit
appears to be at the offset 0027,4 in the "field definition" [kwd
wddffld] which is similar to, but not the same as, Qddffld. I could not
correlate that to any specific bit in the FILD0200 format of the
QDBRTVFD API, because [on v5r3] that API suggests the fields in that
format [including the reserved fields] match for that column
irrespective of SQL or DDS.
So digging a little deeper, I compared the v5r4 doc for the API to
the v7r1 docs. Seems the /bit/ of interest is likely Qddffvln which is
the "proper" varlen\varchar indicator for a non-query record format.
The Qddffvar is off for both the DDS and the DDL versions of the column
according to the API [on v5r3]; a bit in the "reserved" section, the bit
at offset 4 of Qddffldst2 [Field status byte 2, located just after the
Qddfjref bin-2] is set on.
Oddly that misuse of the "variable length" information seems very
familiar to me. I think I made a PTF at one time to expose the Qddffvar
with the value of Qddffvln or some such. Hmm, researching that also, I
came up with APAR SE24623 "OSP-DB-INCORROUT QDDFFVAR OF QDDFFLDST2 FIELD
API QDBRTVFD" which was obviously of my doing:
http://www.ibm.com/support/docview.wss?uid=nas2b27048757cfc5e798625712000421f47
I am guessing that the problem is that a bit WDDFFVLN offset 0027,4
of WDDFFLD is being used in the hash, but that the DDS compiler does not
set that bit for the files created using CRTPF from DDS source; neither
for a REFFLD from an SQL TABLE, nor for a source-only creation [on
v5r3]. Not sure about IBM i 7.1, but my RcdFmtLvlId results were a
match to the given re-creates.
Anyhow, the differences for such indicators [either correctly
included in the hash but different between SQL and DDS, or incorrectly
included in the hash while different between SQL and DDS] is effectively
the same origin for some past defects with the RcdFmt Level Identifier.
That indicator\bit does not appear to be an attribute which is
restricted to the SQL DDL, so I infer the difference is very likely a
[¿not-previously-identified?; I did not perform a search for existing
APAR|PTF] defect :-(
FWiW the above research was performed narrowly, pared down to three
one-column files; one DDL, one DDS with REF to the DDL, and one DDS with
no REFerence. My non-reference version of the DDS for the full file had
more differences I have not yet investigated.
Regards, Chuck
midrange.com
