× 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 13-Feb-2014 14:32 -0800, Briggs, Trevor (TBriggs2) wrote:
I'm sure that changing something in a file will change its <ed:
record format level> identifier, but I'm not sure the reverse is
true. I.e. the file may not change but the identifier might. This was
true, I seem to recall (but many moons ago), that some actions, such
as a save/restore or recreating a file on a different OS release
could cause the identifier to change even though the file, for all
practical purposes, was identical.


The record format level identifier should never change once set... except as corrective for past defects in its generation. Even so, such a correction would be discouraged, as the effects are quite negative. However...

There were some defects for database record format level identifiers, for which some fixes were delivered, and SQL TABLE objects were allowed to have a changed RcdFmt LvlId value because the SQL does not utilize them; i.e. there is no such thing as LvlChk in the SQL run-time, because its effect is casting to properly map data rather than using fixed\aligned-buffers. Thus anyone who had changed to use SQL DDL to replace DDS, before having changed applications to use DML to replace RLA, likely would have applications that were adversely affected by those potentially changing\corrected [by regenerating of] the level identifiers.

Other past defects with the hashing algorithm were left unchanged, i.e. the defect became the function, specifically to avoid any ill-effects from a changing value. It was only the concept that the SQL cares not, for which a decision allowing the changing record format level identifiers [of the SQL *FILE objects] was deemed acceptable. FWiW: For many releases every SQL VIEW had all blanks [not even a valid value] as its record format level Id, and over several more releases after first assigning a value, some more corrections had been made for those SQL *FILE object, because the nuances of both the query record format and when the final format was produced were impacting the ability of the generation of the proper hash.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.