Paul, I don't know about reimporting to the same system, but when I exported nodes to a new server, I found the same situation. I had to define the old, invalid stgpools referenced by the invalid mgmtc on the new machine. Diskpools were easy enough to jigger, but tapepools only got easy with the "move node" in V5R1.
At 11:31 PM 10/9/2002 -0400, you wrote: >I have some filespaces that have part of their files that got stored in the >wrong storage pools, apparently because of a copy group definition error. >The question I have now is, will the following fix/do what I want. We do >not have V5 installed, we are at 4.2.2.12. > > Export the Node (This leaves the data on the server, right?) > Delete the broken filespace (not the whole node) > Import the filespace that was deleted for the node > >Can you even do this without deleting the whole node? > >How does the IMPORT know where to stick the data? I presume it tries to >match the management class to a management class in the node that is defined >on the server, or does it use the information exported, essentially putting >the data back based on the management class definitions on the export tape. >That is OK because the policy domain is correct now. > >Or, does it somehow save the bit file object information at the same time >and try to put it back to the same storage pools? > >If the management class is not defined, where does the data go, what does it >use to determine the target management class? I would think it would use >the default management class. > >Thanks for all responses, especially those that have done this before. > >Paul D. Seay, Jr. >Technical Specialist >Naptheon Inc. >757-688-8180
