Re: Weird situation with a customer's SQL INDEX

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.