On 27 Aug 2013 08:32, James H. H. Lampert wrote:
Hmm. Would whatever caused the index to not have a member also cause
it to return the aforementioned large negative number as its join
spec array displacement in QDBRTVFD?
I had ignored the claim that the "QDBRTVFD returns a large negative
number as the displacement to the join-spec array," presuming that the
origin was probably just a coding error. It is possible however, that
the coded assumptions in the IBM code, in general, manage to overlook an
effective corruption of the file definition. Yet it seems unlikely that
all of the restore, the *DBXREF, and the DSPFD would all fail to exhibit
some negative symptoms, if the offset to the join information was
incorrect; i.e. I doubt all of that IBM code verifies that either
Qdbfjoin=*ON or Qdbfsqli=*ON before trying to navigate to the join
information by use of a non-zero value for the Qdbfoj in the Logical
File Specific Attributes (Qdb_Qdbflogl) as addressed by Qdblfof when
Qdbfhfpl=*ON, in order to find the Qdbfj for its offset to the Join
Specifications (Qdbfjnho). Debug or DMPOBJ of the file headers for the
two SQL INDEX files could be compared; possibly also comparison with a
file created from the newly created INDEX using a RSTOBJ RSTLIB(QTEMP)
FILEMBR((*ALL *NONE)) after a SAVOBJ of that newly created INDEX.
Is there any way that transferring it from one box to another might
have caused this mangled condition?
Restore Object (RSTOBJ) is the primary [supported] means to effect a
SQL database *FILE either having more than the maximum of one members or
having zero members, in conflict with the assumption that every
[non-partitioned] SQL database file has just one member. IIRC the
CRTDUPOBJ can effect zero members; there may be others. As Mark alluded
in an earlier reply, explicit requests to remove the one member (RMVM),
are specifically prevented.
<<SNIP JDE ref>>
Whatever is an effect, is irrespective of JDE.