RE: UniData memresize for dynamic files
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: Migrating U2 data
IBM actually has documentation on this. http://publibfi.boulder.ibm.com/epubs/pdf/9155.pdf It's in the first chapter. You just need to copy the data files through the network and use the convdata convcode tools. I would recommend a complete rebuild of indexes as opposed to using convidx. The main issues you will find is things that were coded to interact with the OS. HTH, Doug At 02:23 PM 2/4/2004, you wrote: Any pointers on what document explains how to move data from an old old UNIX U2 system to a new 10.0 Windows system? Thanks. Cyndi -- -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: Migrating U2 data
Ah, silly me. My brain combined (U2 data = ""> Missed the give away clue of the release being version 10. Disregard my suggestions as they were UniData specific. As I crawl back under my rock... At 05:21 PM 2/4/2004, you wrote: Well, Universe is the RDMS (no?). I just need the data (Unidata, yes?) We have an very old 7.3.1.1 version of UniVerse running on SCO 3.2. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: [UV] How much do you pay for support each year?
At 07:46 PM 2/22/2004, you wrote: I have had clients that have taken the cheap way out only to pay more when they needed it. Not to mention the cost of time lost. Another point mentioning is that if you go off support, you are no longer entitled to any upgrades. You are then typically locked into that version of the OS as well. Eventually the OS will no longer be supported and you are playing with fire then. The only way to get back on support to receive upgrades is to rebuy your license. That is unless IBM had some type of amnesty program going on. (They do now but I bet this won't be forever) This is often the biggest part of support that is overlooked. Doug Miller [EMAIL PROTECTED] Manager of Technical Services Strategy 7Dallas TX -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Help required on SEARCH
At 02:58 PM 2/23/2004, you wrote: I remembered this thread and I thought I could use it someday. I created a VOC entry as described but I received the following error: :ESEARCH MFD STRING : 94067-004 STRING : Error when creating a shared memory segment (size=76288000), errno=22 U_shmalloc() failed ESEARCH is intended to traverse a hashed file at the record level looking for a string. I suspect your MFD pointer is pointing to an account as a directory or something along that line. This would explain why you cannot attach enough shared memory. Look at using grep at the unix level to look for strings at a directory level. HTH, Doug -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
Re: CLEANUP problem
At 09:13 AM 3/16/2004, you wrote: Marco, We just had this happen on Monday on Unidata 6.0.8 on AIX 5.1, we were told to run udtdiag to colloect data about the state of Unidata and stop and restart Unidata. There is no other way. Here is what Unidata support told us: I have seen this at a few sites myself... In addition to this, you should stop UniData and move the cleanupd.d in place of cleanupd when it is convenient. Make sure you rename the original to cleanupd.orig or something like this so you know what you can go back to. The .d of the executables in the $UDTBIN are nonstripped. What this means is they carry a heck of a lot more debugging information in any core files that come from them. Performance overhead in running these is usually undetectable and is definitely useful in a case of a failure. Also, as a last step before stopud, do a kill -11 on cleanupd. This will give IBM more tracing information on what it was doing when it hung up. You will most likely need to run a debug stack trace on the core as well to give to IBM. Get with your support provider as the instructions vary on different platforms and the purchase of a C compiler may be needed. Doug Miller [EMAIL PROTECTED] Manager of Technical Services Strategy 7Dallas TX -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
