RE: UniData memresize for dynamic files

2004-01-27 Thread Doug Miller


You should check out the new commands for handling dynamic parts. 

mvpart
The system-level mvpart command
moves one or more part files of a
dynamic file to a different location. mvpart sets or resets symbolic
links, if
needed, and creates or updates a prefix table (.fil_prefix_tbl) at
the
destination location, if needed. Using mvpart ensures that the links,
file
locations, and prefix tables remain synchronized.
Note: You must stop the UniData daemons (with stopud) before
executing mvpart.
When you are done, you can run the "auditor"
command to make sure everything is in it's place.
http://publibfi.boulder.ibm.com/epubs/pdf/9101.pdf
I only say this as it is safer to use database commands to manipulate the
files.  The main reason why I would recommend this is if IBM decided
to change the rules on how parts are stored in the dynamic files without
your knowledge, the commands should be updated to handle this. 
Otherwise, manually manipulating the pieces in future releases, could
break the files.
Doug
Strategy 7
At 07:07 PM 1/26/2004, you wrote:
If
you are on UNIX, you can symbolically link the parts of a file so they
actually take the space of another file system. This is how I have gotten
around memresizing a 30 gig file. I moved the parts to a different file
system or file systemes. Then I symbolically linked them under the
directory where the VOC pointer says they live to the place where they
physically reside. The memresize then make a rszxx directory where
the VOC pointer says it lives. This rszx directory (where the x
is some uniqueness that Unidata comes up with a resize time), then only
needs 30 gig of free space in the file system, not 60. The memresize will
clean up all the space used by the symbolic links when it is thru. It is
a pain, but I have used it successfully many times. -
Rod

___
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


RE: UniData memresize for dynamic files

2004-01-26 Thread Baakkonen, Rodney



If you 
are on UNIX, you can symbolically link the parts of a file so they actually take 
the space of another file system. This is how I have gotten around memresizing a 
30 gig file. I moved the parts to a different file system or file systemes. Then 
I symbolically linked them under the directory where the VOC pointer says they 
live to the place where they physically reside. The memresize then make a 
rszxx directory where the VOC pointer says it lives. This rszx directory 
(where the x is some uniqueness that Unidata comes up with a resize time), 
then only needs 30 gig of free space in the file system, not 60. The memresize 
will clean up all the space used by the symbolic links when it is thru. It is a 
pain, but I have used it successfully many times. - Rod

  -Original Message-From: Jeff Fitzgerald 
  [mailto:[EMAIL PROTECTED]Sent: Monday, January 26, 2004 4:01 
  PMTo: 'U2 Users Discussion List'Subject: UniData 
  memresize for dynamic files
  This question 
  relates to resizing UniData dynamic files using memresize.  The file is 
  far larger than the amount of memory available to memresize so a temp file on 
  disk must be used.  It is my understanding that the temp file for 
  memresize of dynamic files will be placed in the same directory as the file 
  being resized.  This is in contrast to static files, where the temp file 
  may be placed on another filesystem according to udtconfig TMP setting, 
  etc.
   
  So, if a 20GB 
  dynamic file lives on a filesystem with 10GB of available space, a memresize 
  of that file will fail even if another filesystem has 50GB of available 
  space.
   
  Can anyone 
  confirm that my understanding is correct, or correct my 
  misunderstanding?
   
  Thanks in 
  advance!
   
  Jeff 
  Fitzgerald
  Fitzgerald & 
  Long, Inc.
___
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users