Procedure to unregister a blade?

IDS 12.10.FC12 Solaris 10 1/13 I performed the following to unregister the BTS blade: informix@ifmx-prod-jnu>blademgr prodjnu2tli>list acoms DataBlade modules registered in database acoms: excompat.1.0 bts.3.11 prodjnu2tli>unregister bts.3.11 acoms Unregister module bts.3.11 out of database acoms? [Y/n]y DataBlade bts.3.11 was successfully unregistered from Database acoms. prodjnu2tli>list acoms DataBlade modules registered in database acoms: excompat.1.0 bts.3.11 prodjnu2tli>quit Disconnecting... Note that the 'list' command (above) still shows bts.3.11 as registered, despite the immediately preceding command indicating it was "successfully unregistered". I then double-checked it by (again) running blademgr: informix@ifmx-prod-jnu>blademgr prodjnu2tli>list acoms DataBlade modules registered in database acoms: excompat.1.0 bts.3.11 prodjnu2tli>quit Disconnecting... Why does blademgr continue to report bts.3.11 as being registered, and what is the proper procedure to unregister a blade? Thank you. DG

You seem to have followed the correct procedure for unregistering the blade. However, see my note on your other thread: sometimes all of the Blade tables aren't removed. Look for sysbld* tables and delete them. Then see if the 'list' still shows it as registered. BTW, you mentioned some processes not working with the blade registered. Do they work with it "partially" unregistered? Might want to try before deleting the system tables. Michael Hoffman

Thank you, Michael. There are about 6 sysbld* tables left, but I also have another blade installed, so am reluctant to delete them. One of the tables looks particularly interesting to me: sysbldregistered. I examined it, and it has only a single column. It is "bld_id". There are only two rows. The first row contains the bld_id for the other blade I have installed: "excompat.1.0". The second row contains the bld_id "bts.3.11", which is the blade I tried to unregister, and that "blademgr" reported "was successfully unregistered", yet it still appears as a row in "sysbldregistered". I guess I could try deleting that row. But, I am a Nervous Nellie, and am leery of directly editing system catalog tables. I have opened a tech support case. DG P.S. Any processes I previously referred to as being problematic, with regard to this BTS thing, were unrelated to the actual operation of the blade, but involved trying to get "myimport" to run without error. There were a bunch of errors related to BTS and various routines not being able to be resolved. I have not worked with blades before, and I am finding them difficult, confusing, and a great time sink.

My apologies, David. While I was typing my response, there was something niggling in the back of my brain - you have 2 blades registered. So, yeah, you cannot delete the tables. We only work with BTS, so deleting the tables didn't cause us any issues. Opening the support case is a good idea - they should address this issue. I don't know if it's an issue with blademgr or BTS. Please let us know what you learn. The BTS blade has being a great timeserver when it comes to doing searches, and a lot easier to maintain than Excaliber was (even though Excaliber runs on top of BTS). But BTS is not perfect - the C-Lucene underside has some 'interesting' quirks in searching, and the index can get corrupted and need a rebuild from time to time.

The "sysbldregistered" table is named like a system catalog table. But, it isn't in the system catalog. So, I guess it isn't really part of the catalog, right? DG

OK, I just tried manually DELETEing the bts.3.11 row from sysbldregistered. THen I did a 'list' to confirm that blademgr didn't 'see" it. So far, so good. Then, I tried to re-register it. It failed, saying that the "begin_scan" routine already existed. Presumable that was only the first one, and likely all of them were still present. So, "blademgr" really did lie when it reported successful deregistration. I guess the tech support case continues. I have heard nothing today. DG

Still have heard nothing from tech support (except that they said they were going to try to replicate the symptoms.) In the mean time, I tried blowing the whole instance away (working on a disposable test/development box) and did a cold restore from ontape backup. Now, I was successfully able to unregister the BTS blade! My plan now is to unregister the other blade I have installed (excompat.1.0) and (with a "pure" Informix) try exporting and importing with both dbexport/dbimport and myexport/myimport. (It was problems with import that lead me to discover that the blademgr 'unregister' command was failing, despite it reporting that the unregister operation had succeeded-- which it clearly had NOT. [BTS still showed up in the 'list' command as a registered blade, and the sysbldobjects table still had many BTS entries after the (allegedly) successful unregistering.]) DG

Closing this out. Tech Support's response was that they were sorry they couldn't replicate the problem, and posited that it may have been the result of our database being in a strange state. Fortunately, it was a test database on a test server, so I could just blow it away with a cold restore from an ontape archive. The upside is the problem no longer exists. The downside is we don't know what the problem was-- nor how it could have been fixed. Had this been production, it would have been a huge problem. DG