Thanks Chuck. I'm going to pass this along in my PMR.
Interesting that you saw this with one column files. When I stripped my files down to just the BTN# field (VARCHAR), I didn't get the Format ID issue. But once I added another field (just so happens to be CUST# from the example) before the BTN# field, I had the issue again.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, February 01, 2012 4:28 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Format Level ID
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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
