Dbsapce pathname change

T'other day, I reorganised my partitions (SCO Openserver 5.0.5) including the basename for the Informix server's (IDS 7.30 Workgroup) soft links. To expand, the soft links for the dbspaces were at /app1/informix/dev/whatever, and I changed the partitions so that the soft links now reside in /apps/informix/dev/whatever. Fine so far. I reinitialized rootdbs with the new paths, remade the other dbspaces with the new paths and restored from ontape. As I feared, the dbspaces would not come back until I remade them under their old pathnames. Even rootdbs, which was specifically initialised with the new paths, was finally restored, but I had to keep the old pathname. The ironic thing is that I've always kept soft links for the chunks in case of a physical partition change, and it's never been used. Now I go and change the path for the symbolic links (the actual chunk names did not change) and I can't find an elegant way to fix the problem. :| Is there a way around this other than dbexporting, and starting the reconfiguration from scratch? Judicious use of a hex editor is fine by me if that's the answer. I'm currently running fine with symbolic links for the paths, but it grates against my sense of neatness. Anal, I know, but that's me, I'm afraid. TIA Bryan Tonnet bryan@printman.com.au

> T'other day, I reorganised my partitions (SCO Openserver 5.0.5) > including the basename for the Informix server's (IDS 7.30 Workgroup) > soft links. > Is there a way around this other than dbexporting, and starting the > reconfiguration from scratch? Judicious use of a hex editor is fine by > me if that's the answer. I'm currently running fine with symbolic links > for the paths, but it grates against my sense of neatness. Anal, I > know, but that's me, I'm afraid. Never mind, I found the relevant bytes with the aforementioned hex editor and changed them. The instance came up fine and seems to report the correct (changed) configuration. I found two occasions of the pathname of the dbspaces mentioned in rootdbs, and none anywhere else. If someone can confirm or deny that is all that is expected, I would appreciate it, otherwise I'll run with what I've got. TIA Bryan Tonnet

>> Is there a way around this other than dbexporting, and starting the >> reconfiguration from scratch? No. It's a major flaw in the IDS product set. >Never mind, I found the relevant bytes with the aforementioned hex >editor and changed them "Rolling,Rolling, Rolling/Though the streams are swollen/Keep them doggies rolling/Rawhide"! Neil

Bryan Tonnet wrote: > > T'other day, I reorganised my partitions (SCO Openserver 5.0.5) > > including the basename for the Informix server's (IDS 7.30 Workgroup) > > soft links. > > > Is there a way around this other than dbexporting, and starting the > > reconfiguration from scratch? Judicious use of a hex editor is fine by > > me if that's the answer. I'm currently running fine with symbolic links > > for the paths, but it grates against my sense of neatness. Anal, I > > know, but that's me, I'm afraid. > > Never mind, I found the relevant bytes with the aforementioned hex > editor and changed them. The instance came up fine and seems to report > the correct (changed) configuration. I found two occasions of the > pathname of the dbspaces mentioned in rootdbs, and none anywhere else. > If someone can confirm or deny that is all that is expected, I would > appreciate it, otherwise I'll run with what I've got. You've got it. There will be two copies of the chunk table page (if you have more than 40 or so chunks the remaining chunk paths will be on extended pages though) on reserved pages 6 & 7 and the mirror chunks table page on reserved pages 8 & 9. You will have to update both copies (one is current the other a backup which will normally be one modification behind and they alternate). If you have any Informix mirrors you have to update both copies of the mirror chunk table as well. If the 5th word of the page header is non-zero it contains the page address of a block of contiguous pages containing the next section of the chunk/mirror chunk table (either the current table or the back up table). If you have too many chunks to fit on that second block the last page will also have a pointer in word 5 to a third block of pages. The initial chunk table page is always a single page. Note that this is dangerous work and if you s**w it up tech support will disavow your server's existence. They are still mad at me for writing such an app myself (and no I cannot share it, I promised in exchange for help debugging it ;-). I had to shrink our chunk names in our OL5.xx servers (which ONLY have the first chunk table page and no extension block) so we could survive until 7.21 came out and was stable enough to use as we had filled the old 5.xx chunk table and could not add any chunks. Art S. Kagel > > > TIA > > Bryan Tonnet

> You've got it. Thank you kindly. >There will be two copies of the chunk table page (if you have > more > than 40 or so chunks the remaining chunk paths will be on extended pages > though) > on reserved pages 6 & 7 and the mirror chunks table page on reserved pages 8 & > > 9. You will have to update both copies (one is current the other a backup > which > will normally be one modification behind and they alternate). If you have any > > Informix mirrors you have to update both copies of the mirror chunk table as > well. > If the 5th word of the page header is non-zero it contains the page address of > a > block of contiguous pages containing the next section of the chunk/mirror > chunk > table (either the current table or the back up table). If you have too many > chunks to > fit on that second block the last page will also have a pointer in word 5 to a > third > block of pages. The initial chunk table page is always a single page. Whoa! Too much information :) > Note that this is dangerous work and if you s**w it up tech support will > disavow > your server's existence. They are still mad at me for writing such an app > myself > (and no I cannot share it, I promised in exchange for help debugging it ;-). Interesting. If this is a weakness in the Informix product set, as a previous poster suggested, why would Informix not want to take your [debugged] application on board as a standard utility? Seems to me like a nice bonus for all and sundry. Bryan Tonnet