× 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 17-Oct-2017 19:53 -0600, Troy Hyde wrote:
I've got a handful of DDS physical files, some that have existed
since the late 80s, that I'm converting to DDL. I'm generating the
DDL using QSQGNDDL and creating the new SQL tables.

It's important that the record format level does not change between
the existing physical file and the new SQL table because of the
number of RPG programs compiled against the existing level of file.

I have done this countless times in the past but am running into a
snag tonight. Fields defined as varlen in the DDS, and as varchar in
the SQL are resulting in a record format level change. I have been
able to prove that it's the varlen/varchar fields by removing those
fields from both the DDS and DDL and the resulting levels match.
However, any time I add one or more varchar, the levels change.

<<SNIP>>

The record lengths match between the file and the table. The record
format names match. The field names/positions/lengths/attributes all
match.

Using DSPFFD, the DDS file shows the variable length field like this:

SVMODL CHAR 40 42 147 Both SVMODL
Field text . . . . . . . . . . . . . . . : VEHICLE MODEL
Variable length field -- Allocated length : None
Coded Character Set Identifier . . . . . : 37

while the table looks like this:

SVMODL CHAR 40 42 147 Both SVMODL
Field text . . . . . . . . . . . . . . . : VEHICLE MODEL
Variable length field -- Allocated length : None
Default value . . . . . . . . . . . . . . :
''
Coded Character Set Identifier . . . . . : 37

<<SNIP>>

Any thoughts or suggestions?
<<SNIP>>

The same issue was reported several years ago, but not pursued [aggressively "enough"], not really pushed, at all, by anyone; i.e. no APAR was ever produced to document, nor anyone escalating that [lack of an APAR as the proper] response. And with no APAR, there is definitely no PTF. Here are a couple links, to specific replies in a thread that could be perused for the additional messages that did not stray too far off that topic like some of those in this {found in Oct2017 archives} thread:

[format level different with dds/SQL](https://archive.midrange.com/midrange-l/201206/msg00211.html)
[format level different with dds/SQL](https://archive.midrange.com/midrange-l/201206/msg00215.html)

An additional, but tangential, reference to the defect:
[convert LF's to SQL - LF's have Select/Omit](https://archive.midrange.com/midrange-l/201304/msg00853.html)

And after more research, I finally found where I gave a technical description for the origin of the defect; i.e. an attribute difference in setting for the /creation/ of a database *FILE object, between SQL and DDS, and notably, an attribute that is included as details for the generated hash value used for the Level Check Identifier (LVLID):

[Format Level ID](https://archive.midrange.com/rpg400-l/201202/msg00051.html)

added kwds: rcdfmt rcdfmtlvlid fmtlvlid lvlchk msg cpf4131


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.