I was wondering if some could help with my problem.
NT and D3 714, over 32K files
I have been saving to a pseudo file the backup of over 50 accounts that
contain roughly 2000 files each. All the accounts have the same named
files in them.
I made a full save and ran a /fileload to start reloading only the
active accounts and defrag while I was at it. I've reloaded
approximately 15 accounts and then no more accounts can be reloaded.
But after a point in the backup all the accounts and files that I'm
trying to reload all scrolls down the screen with the error in the
following format:

Fsi:AccountX > filenameXXX 0,1
'filenameXXX' is not a file name

I can go to these accounts and t-read and see the data is there.
I've heard that the problem had something to do with this version
being able to keep indexes for files numbering greater than 32K, and
was fixed in a later version. But I need the steps to get a specific
account restored.
Any and all help is greatly appreciated, thanks.

To restore a specific account try:

ACCOUNT-RESTORE FSI:<myaccount>
Account name on tape: <myaccount>

but, somehow I don't think is the real question?!?

Obvious question is "was the backup verified"

This happened before and were able to get accounts back that they
wanted when this issue first appeared a good while back, and we took
steps to reduce the number of accounts the system is loaded with. I'm
trying to recover an account from long ago, and was told before of a
way to get the accounts back, but this was many lost brain cells ago.
And all the notes that were taken on this project are lost.
I tried to position the backup at the beginning of the data portion of
the account and used the (a option and it does the same thing, it
scrolls thru every file, listing the dict and data filenames, it shows
the first modulo of zero and the second at some prime #, but says each
" is not a file name ".
The reason stated was that Pick (that version) could not track greater
than 32,000 files and that the indexes or something like that got
trashed, and needed to be regenerated. If this helps.

do NOT use the A option .... sounds like you have a FSI account, which
is why I suggested using FSI: prefix explicitly .....

"Matt J." wrote
.... {doing restore on d3/nt}...
tape on a d3/linux box -- d3/linux doesn't have an fsi: 'feature', so the
misleading error messages about 'not a file name' are really due to the
account mentioned not existing on hard disk, which frustrates the creation
of the current file found on the tape. Maybe you too are really having a
\no such account\ bottleneck in your restore effort. The (F option would
prevent some of the more advanced features from kicking in, like pulling
the old index tables off the tape, by the way. (F is handy when sucking
tapes from releases of D3 older than what you're now running.

Matt,

I would suggest the following:

1. In Windows delete all the contents of your ...\D3Database folder.
2. Get to the console, cd ...\D3Programs, d3fsi /mds.
3. Then try d3vme /restore, use your saved pseudo.

HTH
Nick

"Matt J." <mjircik (AT) vantagemed (DOT) com> wrote

Got it! The account was and FSI: account and using the (f option did
nothing when restoring to the FSI: but it worked when restoring to the
VME. Thanks for everyone's help!

Matt:

If you want to restore an FSI save into the FSI user "restore-accounts (r".
This makes sure everything on the backup, not already on the D3 system, is
restored into the FSI.

Hope this helps.

Bill

"Matt J." <mjircik (AT) vantagemed (DOT) com> wrote