I'm restoring an old d3/aix file-save tape to d3/nt 7.5.1

a) I wanted to warn that account names spelled with "/" are
no longer tolerated. RESTORE-ACCOUNTS prints a
clear description of this and then drops back to TCL prompt
when one is found. I recall that really old d3/nt releases
accepted this spelling, though... So get along with ye and
migrate your exotically-spelled files & accounts today, instead
of waiting until your boss tells you "guess what, we're migrating
from *nix to windows!"
[If I ruled the world, that verb would have
just skipped over the offending accounts, instead of abending...]

b) If I'm handed a FILE-SAVE tape and asked to show what
accounts are on it, I just pop it in and do an
ACCOUNT-RESTORE of, say, the BOZO account {which isn't
an expected account} and watch the list of accounts scroll by.
But how can I tell which of those accounts are from the FSI:
versus the VME? I'd hate to guess wrong and fill up my VME...

c) In D3, do SSELECT MDS before your FILE-SAVE
and your tape will bear the accounts {other than DM, which
gets pushed to front or rear, I forget which} in alpha. order.
In case you appreciate that sort of thing...

"Frank Winans" wrote:

I'm sort of not surprised that this is the case, especially in the FSI
where account and file names are really Windows directories. That
said, D3NT does have a file in accounts called _ConvertName which
allows us to create files with reserved characters. It's curious that
isn't applied to the mds as well.

Agreed. If that's a regression, file a report with RD.


I understand the question, and it's a reasonable one for which I don't
have an answer outside of writing a little code. But I don't quite
get why this is a real-world issue either.

You pop in the tape and look at the accounts with a dummy restore as
you said. Now if you want to restore an account into the FSI you use:
account-restore FSI:acctname
If you don't want to restore it, it doesn't matter what format it is
on tape.

If you want all accounts to restore to the FSI, you use:
restore-accounts (r

Are you saying you might want to restore only FSI accounts? I might
go to the back of the save, retrieve the file-of-files dump, then use
that to determine which is which.

Or you can "sel-restore tempfile * (n" using file #2. That will
return all of the Q and QS pointers along with other items. Then use
this to tell you which items are your FSI files:
sort only tempfile with a1 q] a1

Any help?

The file-save was specifically enhanced to pull DM up to the front of
the tape. The problem that needed to be solved was that some systems
would have a problem doing a full restore from a bad tape. If your
filesave couldn't restore a base environment then you had no platform
from which you could start poking the tape for anything else. With DM
up front, even with a corrupted save tape, it's possible to create
this base.

SSELECT of all MDS items or specific MDS items will work with
File-save but DM will still get bubbled up to the top for the above
reason. Looking at the code I see they aren't putting FSIDM up at the
top which is a bug because if your D3NT filesave is bad then you still
can't get a base environment and the whole purpose of that enhancement
is lost. If anyone cares about this, report it to RD. The
alternative is to restore a base system using the original VME or
install pseudo, then do what you need from there.

HTH
T

"Tony Gravagno" wrote
surprises. I had sometimes wondered if doing a
simple restore of an old tape from another d3/nt
server would fill up my VME {or my whole FSI, for that
matter.} You're right, there _is_ a t-dump of the FOF file
after all those account-saves on the tape, and with some
effort I can retrieve it and do a modified LIST-FILE-STATS
on that new 'foo' file. And yes, it would also be nice to
pull back just the FSI accounts en mass; even nicer if
that also left me a memo somewhere about what accounts
had been restored, what accts had been skipped {and why
each was skipped -- due to my 'skip vme flag' or due to my
not doing an '(O'verwrite flag} Again, my biggest bushwacked
situation is accidently pulling back an account that I hadn't
realized was in the VME, or one that I knew was in the VME
but hadn't realized was rather large. As ever, not knowing
the originating installation's frame size or ABS patch level is
good for a painful laugh, too. And as long as I'm "Wishing
it would rain beer," a step-by-step description of pulling the
MDS qpointers from tape using SEL-RESTORE to ask for file
numbered 2 on the tape would make a very nice reference
document for newbie sysadmins, who never even suspect
this is something they should have been worried about...

"Frank Winans" wrote:

The file-save and related restore processes were designed to get the
data off of the system and provide one of at least four means of
getting it back: account-restore when you know the accounts, full
restore for everything, restore-accounts, and sel-restore. Outside of
those functions, you're on your own. Once again this is where I say
the vendors have provided us with tools, now we need to use them,
rather than asking the vendors to build an application above that
layer, one that we can simply do ourselves. If you can't do it then
you need to take some more time, do some more reading, be a little
more creative, or cough up some bucks to pay someone else who has
invested the time to do these things for you.

As far as precedent, you're not going to find utilities from IBM that
convert the file types and flavors of backups on the fly so that you
can restore them to something different than their original. Nor will
you find this with any MV vendor because the demand for such things is
so small that it's left to the third-party market to create the
solution if it's required.

One solution to the problem you present is to create an item in the dm
account or somewhere else in a common place on systems that you
support, a simple document of information that you think is important,
like system version, default frame size, production accounts vs junk
accounts, and a list of settings that you like to tweak after a fresh
restore (those should be in macros anyway). When you have a mystery
tape, sel-restore that one item, get the facts, and move on.
Absolutely everyone in our market could do this today if they had any
interest. After 30 years of this software in this market, why aren't
people doing this sort of thing in dynamic environments? Probably
because it's not really such a big deal, and that's why the DBMS
vendors haven't built anything around this as part of their base
offering. With that one simple non-technical solution, all of these
problems would go away.

Regarding new sysadmins who never suspect things, this is where
education and product support come in. Someone who is responsible for
system administration should maybe take a class to learn something
about the environment they've accepted the responsibility for
supporting, and a company that relies on data integrity should have a
valid Support contract with the DBMS provider, and perhaps someone
they can call on for adhoc information, insight, and assistance as
required. Your questions could have easily and quickly been answered
by RD Support, which is where most people get their technical
information, or in the RD web forum for D3NT.

All that said, I don't disagree with your basic frustration that the
file-save tape doesn't have some information up-front that we could
use. When we look at a new tape at a new site, we have no clue what's
on it. This was a fault that started in the VERY beginning when all
we got up front was an 80 byte header. There should be an entire file
of config data which is ignored by a full-restore, but it's too late
to change history and putting this in now would break lots of
processes already in the field. I've commented on the frame size
issue in the RD forum and I believe an enhancement request was filed -
you can't very well restore using (r2000 if you don't know the save
was created on a system with 2000 byte frames. Then again, back in
the old days we actually used paper labels on tapes to specify this
sort of information for racks of 1/2" 9tracks.

Don't just complain about inconveniences and let it drop, seek real
solutions from vendors or from the open market using proper business
channels.

T

Frank Winans wrote:
Like Tony, I'm not suprised by this one ... the same warning could also
be applied to filenames
If the file-save came from anything OTHER than D3/NT, then all of the
accounts are VME style accounts (currently D3/NT is the only platform
with an FSI account structure (and provided the *nix platforms don't
suddenly get forced to use FSI for databases over 2Gb, all will remain
"good" on the *nix platforms.

Anyway, in terms of restoring from this backup, a simple
RESTORE-ACCOUNTS will drop the FSI accounts into the FSI, and the VME
accounts in the VME (and if you try & load the FSI accounts under *NIX
you will get an error unloess they were saved with an A option

My biggest gripe with D3/NT is that it STILL doesn't index "properly"
(and even that is assuming you agree that VME indexing is
"proper"/enough/sufficient) and it keeps making retrograde steps (like
no longer supporting exploding within [BOM style] sorts in FSI
accounts/files