d3vme /fileload does not build indexes for FSI accounts

I recently discovered that d3vme /fileload on D3 Windows does NOT build indexes in the FSI accounts. VME accounts only. This was discovered when working with someone who was using d3vme /fileload on D3 Linux 10.4, since entering d3 from a Linux prompt then taking the F option is no longer the way to restore the system.

The problem was further masked by the fact that list-index DOES show all of the index references even though the indexes never got built. This is because the index references in a file's D-pointer (file-defining item) get restored when the file is restored, but no further action is taken.

The way around this is to run indexer from TCL in the DM account after the file-load is complete. Indexer reads all of the index references in the D-pointers and builds the indexes accordingly.

As of now, we are treating this as a documentation issue since this has always behaved this way and the work-around is quite simple. I would appreciate any comments from anyone who uses d3vme /fileload as a save/restore mechanism to handle resizing, defragmentation, whatever. Thanks in advance for your input.

Hi Brian,

My experience is 99.9% with d3/Windows; and my recollection is that a reload did not automatically rebuild indexes.

That said, I think at some stage it started to do so, or I may be confusing with an account-restore.

Never-no-mind as in practice I always remember to perform an "indexer" when doing any kind of full system maintenance. Apart from time, there is no harm in doing so, even if it rebuilds what has already been rebuilt. Those on much larger systems may disagree!

Cheers,

I recently discovered that d3vme /fileload on D3 Windows does NOT build indexes in the FSI accounts. VME accounts only. This was discovered when working with someone who was using d3vme /fileload on D3 Linux 10.4, since entering d3 from a Linux prompt then taking the F option is no longer the way to restore the system.

The problem was further masked by the fact that list-index DOES show all of the index references even though the indexes never got built. This is because the index references in a file's D-pointer (file-defining item) get restored when the file is restored, but no further action is taken.

The way around this is to run indexer from TCL in the DM account after the file-load is complete. Indexer reads all of the index references in the D-pointers and builds the indexes accordingly.

As of now, we are treating this as a documentation issue since this has always behaved this way and the work-around is quite simple. I would appreciate any comments from anyone who uses d3vme /fileload as a save/restore mechanism to handle resizing, defragmentation, whatever. Thanks in advance for your input.

Hey Cram,

This issue is something that I originally reported on D3/Windows v10.2.0 and then again on the D3/Linux 10.4.0 BETA, (Engineering Action Item, jira Tickets D3-64197 and D3-69778 respectively).  So, you might want to check on those.
Thanks.

I did check on those. They reported as "fixed", but their test was to do a d3vme /fileload then list-index. Of course it looked like it worked because the D-pointer of the data file was loaded with A8 populated with index references, but they were references only. I told them my test was:

d3vme /fileload

select sql,tables, with a1 = "tables"

if they get a 404 instead of a 4041, the indexes are not there

Those two Jiras are being updated and linked to the documentation issue that warns that you must run indexer after /fileload is complete.

I recently discovered that d3vme /fileload on D3 Windows does NOT build indexes in the FSI accounts. VME accounts only. This was discovered when working with someone who was using d3vme /fileload on D3 Linux 10.4, since entering d3 from a Linux prompt then taking the F option is no longer the way to restore the system.

The problem was further masked by the fact that list-index DOES show all of the index references even though the indexes never got built. This is because the index references in a file's D-pointer (file-defining item) get restored when the file is restored, but no further action is taken.

The way around this is to run indexer from TCL in the DM account after the file-load is complete. Indexer reads all of the index references in the D-pointers and builds the indexes accordingly.

As of now, we are treating this as a documentation issue since this has always behaved this way and the work-around is quite simple. I would appreciate any comments from anyone who uses d3vme /fileload as a save/restore mechanism to handle resizing, defragmentation, whatever. Thanks in advance for your input.

Does the (B option for file-save (which saves the indexes as well) negate the issue by removing the need to rebuild indexes in this instance?