| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2553.1 | | QUIVER::CHILDS | Ed Childs | Thu Mar 12 1992 11:02 | 7 |
| --> We're also using a local namespace.
That's why. The installation procedure created a new MIR for you. If
you were using DNS you wouldn't have this problem.
Perhaps it's possible to restore some old MIR files and get back
everything?
|
| 2553.2 | Ick! | TOMLIN::ROMBERG | some assembly required... | Thu Mar 12 1992 11:56 | 7 |
| Isn't this a little unfriendly? Maybe a question in the installation asking if
I want my namespace reinitialized (with a default of NO), or at least a
warning that it's going to be reinitialized so that I can stop the installation
and try to find the right files to save so that I can put them back later.
I may remember now, but what about the next person...It isn't obvious to the
novice that this 'feature' exists when you use a local namespace.
|
| 2553.3 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Mar 12 1992 13:03 | 15 |
| This is field test software. Among all the other constraints in doing
the zillion things we need to get these products finished, we just
don't have the time to provide migration tools between each
incompatible intermediate baselevel. And we *have* to be able to make
such changes now because once we ship, we will take upward
compatibility very seriously. Any time we ship an incompatible update
to a storage structure we will most definitely give the user a way to
not lose his old data. So we are trying to shake out file structure
changes at the expense of the field test sites for the sake of not
having to do it after we ship.
I know this is not great for FT users, but that's part of the downside
of using FT software, Hopefully you'll bear with us.
Thanks
|
| 2553.4 | | TOMLIN::ROMBERG | some assembly required... | Thu Mar 12 1992 13:23 | 8 |
| Ok, now that I know I'm likely to lose my environment with a new baselevel,
are there any tools/magic commands that I can use dump out my mir and/or create
a command file that will reregister/recreate everything that I have, or do I
get to learn the FCL the hard way ;^) ?
(I've been working on the managEE side of the wire, rather than the managER,
so I've been using the IMPM for registration/creation cuz it was easier and the
examples in the BMS guide were clearer.)
|
| 2553.5 | use local copy | COOKIE::KITTELL | Richard - Enterprise Storage Mgmt | Fri Mar 13 1992 10:52 | 14 |
|
Copy the MIR database to a local directory, then add that directory to the
MCC_SYSTEM searchlist. Then, even if future baselevels put a new (empty)
namespace MIR in MCC_COMMON, the one in the local directory will still get
used.
But remember, if one of those future baselevels changes the namespace MIR
format, your local copy won't work anymore.
The files that make up the namespace MIR are
MCC_DNS_ATT.DAT
MCC_DNS_ENT.DAT
|
| 2553.6 | Will saving those files work for me now? | SGWS::SID | Sid Gordon @ISO | Sun Mar 15 1992 07:36 | 9 |
| >But remember, if one of those future baselevels changes the namespace MIR
>format, your local copy won't work anymore.
Can someone say whether in upgrading from T.1.2.4 to bl15 the MIR format
has changed? Or if I make sure to save MCC_DNS_ATT.DAT and MCC_DNS_ENT.DAT
and then copy them back will my domains and maps look like they did before?
Tnks,
Sid
|
| 2553.7 | Here are some tools to help | TOOK::R_SPENCE | Nets don't fail me now... | Mon Mar 16 1992 16:49 | 13 |
| Copy MCC_DUMP_DNS.COM (if you are running VMS) from
NETS::USER$NETS:[MCC011.S-KIT]MCC_DUMP_DNS.COM
and use it to save your instance data. Then use
NETS::USER$NETS:[MCC011.S-KIT]MCC_MOVE_MAPS.COM
to normalize the filenames of the map files (name them in the
transportable non-UID format).
Then you can blow away your local namespace and restor it from
command files.
s/rob
|
| 2553.8 | | TOOK::R_SPENCE | Nets don't fail me now... | Mon Mar 16 1992 17:03 | 5 |
| Oh, I haven't actually tested this with a local namespace so feedback
is definately welcome. I have, however tested it moving from one
dns namespace to another one.
s/rob
|
| 2553.9 | What about Ultrix??? | PJWL::LAMB | Peter Lamb - GSG Santa Clara MAIL=MUTTON::LAMB | Tue Mar 17 1992 22:48 | 16 |
| Hi,
Is there a similar procedure for Ultrix?? I will shortly
be moving from 1.2.4 to a newer baselevel will just coping
the files listed below to another directory prior to installing
work?
/usr/var/mcc/mcc_dns_ent.pag
/usr/var/mcc/mcc_dns_ent.dir
/usr/var/mcc/mcc_dns_att.pag
/usr/var/mcc/mcc_dns_att.dir
Thanks!
Peter
|
| 2553.10 | Post T1.2.4 MIRs are different | TOOK::MINTZ | Erik Mintz, DECmcc Development, dtn 226-5033 | Wed Mar 18 1992 07:33 | 18 |
| Unfortunately, copying MIR files on ULTRIX will not work.
First off, these are sparse files. If you just copy them,
the holes will fill in, and they may take up a lot of
unnecessary space on your disk.
But more importantly, the MIR file format has changed, so that the MIR
files are incompatible anyway. Once a newer baselevel is available
on ULTRIX, all old MIR files will have to be removed (or very
confusing error messages will start to appear).
We understand the inconvenience of such incompatibilities, but this one
was unavoidable (and had to be done during field test, because once
we ship to customers, it is critical to preserve compatibility).
I don't know about a .csh version of this command file.
-- Erik
|
| 2553.11 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Mar 19 1992 10:12 | 5 |
| Just a nit on the previous not, due to ndbm changes in 1.2.18 and
following, the "sparseness" of the mir .pag files has been greatly
reduced. You will not lose significant space on a copy unless the
files are *very* large (>1MB).
|
| 2553.12 | | TOOK::R_SPENCE | Nets don't fail me now... | Mon Mar 23 1992 11:23 | 9 |
| First, we do hope to convert the files to csh versions however we
have a time crunch on the people converting them. Any volunteers to
convert a couple?
Second, at least for V1.2 we expect the majority of the users of the
conversion files to be VMS V1.1 users who either want to move to a
VMS Local namespace, or to an ULTRIX system.
s/rob
|