Help! Need to change chunk's device filename.

Note, this is in relation to Informix Online 7.23 on SGI Irix 6.4 Help! Due to reasons too complex to go into in this message, the device file names for some of our raw chunks have changed. Now our Informix database won't work since the chunks' device files have been renamed. The problem is that I can't find a way to re-name the chunks. There is no facility I could see to do that. I can add a chunk, or drop a chunk, but not change its device-file's name in-place. Incedentally, before anyone chastises me for not setting up a link to the device file like the manual suggests, let me say that I know I was supposed to do that. On Irix 6.4 it can't be done because the /dev directory and the /hw directory are not the same filesystem (can't hardlink), and Informix won't accept a symlink for chunks, and I can't put the hardlink in the /hw directory either since /hw gets dynamically re-created on each boot. Anyway, here's a list of what I've alredy tried, that didn't work: 1 - Make a symlink pointing from the old filename to the new name: - Failed: Informix doesn't accept symlinks here. 2 - Make a real link pointing from the old filename to the new one: - Failed: Irix can't allow hardlinks between filesystems. 2.5 - Fake a hardlink by making a new device filename with mknod, giving it the same major/minor numbers as the file I want to link to. This is not a permanent solution since Irix dynamically assigns its major/minor numbers to devices on each reboot, but it would have gotten me far enough along to fix the rest had it worked. But it did not. I don't know why (it works for one of the other chunks, but not the one I'm having trouble with.) Because I have the ability to programatically re-populate the entire database from files, I don't mind completely destroying it and starting over, if I can do that. These next solutions were attempts to do that: 3 - Run "oninit -i" and re-make the database from scratch, remaking the dbspaces from scratch too. - Failed: Got this message: oninit: Fatal error in shared memory creation (Not a useful message because it *always* says that for any sort of error the prevents oninit from running. I've seen that message before when the error had nothing to do with shared memory.) 4 - Use onspaces to drop the dbspace that uses the moved filename, then remake it. - Failed: Gives internal error. (Probably due to the chunk file not being accessable.) 5 - Use onspaces to drop just the one chunk from the dbspace, then add it under the new name. - Failed: Informix doesn't let you drop the first chunk from a dbspace, only subsequent ones. This dbspace just has the one chunk. 6 - Make an entirely new system from scratch by making a new onconfig.[dbname] file, using a new partition for rootdbs, and issuing "oninit -i", and building things up from there. - Failed: oninit -i returns: oninit: Fatal error in shared memory creation (I checked and triple-checked the systune parameters against the onconfig file parameters. I even set the shared memory footprint absurdly small and that still gave the same error.) I'm at a loss for how to continue. -- -- ------------------------------------------------------------------ Steven L. Mading at BioMagResBank (BMRB). UW-Madison Programmer/Analyst/(acting SysAdmin) mailto:madings@bmrb.wisc.edu B1108C, Biochem Addition / 433 Babcock Dr / Madison, WI 53706-1544

A follow-up to my previous message. I found the error now. Thanks to all who helped me via e-mail. The problem, as it turns out, is that while the user 'informix' exists, and the group 'informix' exists, and user informix is a member of group informix, the *primary* default group for user informix was not group informix, but instead was "users". This confused some of the install scripts, which made some of the informix executables setgid to the wrong group. (Instead of being setuid root and setgid informix, they were setuid root and setgid "users".) This led to a slew of other problems. I wouldn't have discovered it except that ipcs -am was showing me that the shared memory being created by oninit was owned by root:user, which seemed worth investigating. I suspect that the fact that it was not owned by the right group was preventing parts of the engine from connecting to it, hence the "failed to initialize shared memory" messages. The group problem was also the reason the symbolic links were not working. /dev/informix[0-5] were owned by informix:informix as the error message told me they should be, but the oninit program was not setgid informix, so it didn't have permissions to open them. Anyway, the problem is fixed now, and thanks again to all who helped. -- -- ------------------------------------------------------------------ Steven L. Mading at BioMagResBank (BMRB). UW-Madison Programmer/Analyst/(acting SysAdmin) mailto:madings@bmrb.wisc.edu B1108C, Biochem Addition / 433 Babcock Dr / Madison, WI 53706-1544