L.S.,

When reconfiguring a table after adjusting it, error 113 ("Drop original table") occurs. We are using a BISAM-environment on this server.
There is only one way to solve this problem, until now: remove the table using tbase6.1 (inluding all data), create the table again and then reconfigure.

When altering the tabledefinitions, the misery starts all over again.

Does anyone have a proper, structural solution for this problem?


Henk.

Error 113 indicates that the table is locked.
I am sure that removing the table removes the lock as well, but as you say, there has to be a better way.

You need to find out what is locking your table. Since you indicat e that this happens during the reconfigure process, Maybe Baan has a problem writing to the DD. Check for ownership and permissions on the OS level.
The problem may also be caused by running out of TMP space come to think of it.

Franscesco,

The permissions on the used filesystems (directories) are alright, so that's not the problem.

Ofcourse we have been looking for a lock of some kind of the table. Unfortunately, there is nothing to find!
Still, the only solution so far, is the one I described above :mad: .

BGS has been working on this problem for three (!) months now, and only have come up with the suggestion that the bdbreconfig-file is not working properly. I am willing to believe so, but what then? And how is it possible that such a problem suddenly appears?

Mind you: we did install the latest portingset prior to the occurrence of this problem. So perhaps it's got something to do with that. But how to solve it?


Henk.

ok, ok ;)
But as a note to all, if you want to get the right answer, you need to ask the right question.
Of course a wise man once said that in order to ask the right question, you need to know most of the answer already.

Let's not get too phylosophical here. What I mean to say is please be as detailed as you can when describing a problem or be prepared to receive solutions you have already tried (which is not necesarily a bad thing, sometimes you just overlook the simple things, right?).

Anyway..

Can you give us the full picture of your system, Henk? OS, Baan version, porting set, etc, etc.

I remember a particular version of bdbreconfig being messed up, where it had to be replaced by the version in an older porting set. But if Baan support has been working on this case, then I am sure they would have had full details on this.

Francesco,

To get things straight: I absolutely did not mean to "blame" you for suggesting solutions we already tried. It's just that we're getting pretty desperate. And ofcourse we appreciate the thinking of all who visit the BaanBoard. It's not a problem if someone (like you) suggests things we already tried or asks for more information. In my opinion it just shows interest!

Oké, that concludes the inter-human part of this message. Now the information you are asking for:

The Baan-version where the problem occurs, is B40_c4. Our OS is HP-UX9000_PA_8000 (version 10_20) and we are working with a BISAM-database. Our portingset is 6.1c.06.04.
The problem occurs every time we alter a table: be it a domain, an index or insert/delete a tablefield. And when the error occurs, Baan treats the table as not-accessible: it can't be reached through ttaad4500/4100 and also can't be removed through session ttaad4231m000 (because it is locked, according to Baan).
Removing the table with "tbase6.1 R z $i" (if needed after making a sequential dump from the table) and creating the table again in Baan is the only workaround we have found so far (jeez, we even wrote a Unix-script to do it for us!). Then the "new" table (mind you, the datadefintion file is not deleted, so the adjustments to the table are shown after creating the table) can be reconfigured. (After that, the struggle begins to insert the "old" data into the "new" table. You can imagine the fun we have...)

Hopefully this brings you any further. If needed, please don't hesitate to ask for more information. Any help is more than welcome!


Henk.

My remark wasn't directed at you either, Henk. Just a general comment.

Let me see if I can assess the situation here and do a little 'out-loud' thinking:

- Your DD entries are made correctly.
- Baan does not see the actual table.
Can you locate the table by browsing your filesystem?
- Tbase _does_ see the table
Proving that the table _does_ exist. The fact that Baan doesn't see it, might indicate a problem in the package combination.
- You can make a sequential dump of the table.
Very odd, since you say Baan does not recognize the table in table management. Again this pushes my suspicions towards the package combination. Is the table maybe created in company 000?

Exactly at what point in the table-rebuild process does the error occur? Does the table reconfigure process even start?

What is the connection with the 113 error? Why would it say a table is _locked_ if it can't find it in the first place? Or is this one of those mismatched error messages that are put in to confuse us administrators and make our miserable lifes a little more interesting?

Francesco,

Regarding your suggestions the following remarks:


It is possible to locate the table on the filesystem in the DD. Yet, when you try to reach the table in Baan, error 512 occurs (in ttaad4500, for example).
Tbase sees the table. It is possible to use tbase6.1 to maintain the registration-file and to delete the table.
The problem occurs in every package combination and in every company. That indicates a structural problem with a central file or session, that's used by all companies and all PC's. (The suggestion of Baan Support that it could be something with the bdbreconfig-file doesn't seem quite that odd, seen in this light. But what goes wrong? And: how to solve it? Baan Support is very silent about that, till now.)
The fact that a sequential dump of the specific table can be made is very odd indeed: Baan doesn't recognize the table, yet can make an export of its data (?). It's one of the inexplainable ways in wich Baan works, I guess. I don't really have an explanation for this fact, but am very glad that at least this part is still functioning. Imagine building up a table's data from scratch every time you modified it...
So, the tables are not created or modified in company 000, but in different companies. And therefore also in many different package combinations.
The point at what the error occurs is the actual reconfiguration of the table. The screen turns to the terminal emulator en the following error is displayed:

tppdm600104 * 111 Drop original table error 113
Undo .... 111 Adding indexes ...
Error 113 for create index 9999.

Mind you, the error does not occur when the parameter "Reconfigure Tables" is set to "No" in sessions ttadv5215m000 and ttadv5210m000.

In short: indeed very interesting, but also very annoying. And still we don't have a clue what goes wrong exactly, and, more important: what to do about it.

Hopefully this additional information can boggle your mind a little further in the right direction. I am very curious what you think of all this.


Henk.

Looks like after dumping the table, Baan is leaving a lock that cannot be deleted when tries to re-import it.

If this only happened after the installation of the latest portingset and normal operations seem not to be affected (youy can add/delete, see records), I bet that there's a bug somewhere within the binaries...

Oké Victor,

But how to find it, so it can be fixed? Do you have any thoughts on that?

By the way: enjoy your holiday!


Henk.

sighs...I remember my time of 34 paid vacation days, but noooo I had to move to the US. 10 days....10....THAT'S what's wrong with this country!

Henk, it sounds to me that BGS is not giving this issue the attention it deserves, specially since this now appears to be related to SP10 installation.

Have you scanned the SP10 release notes for anything that might cause this defect (I think we can safely call it that now)?

Was the porting set part of SP10???

The 512 error indicates a corrupted DD. Have you tried rebuilding it yet?
It appears that the error (whatever the exact error is) is already present before bdbreconfig comes in to play. You may however still want to attempt renaming bdbreconfig and restoring your SP9 back-up just for the h*** of it.

Francesco,

The SP10-connection sprung into mind after reading another thread on this God-sent Board: http://www.baanboard.com/baanboard/showthread.php?s=&threadid=5980

The release-notes that came with SP10 don't indicate a solution for this problem. There is nothing in there (i.e., there doesn't appear to be anything in there...) that could cause this problem.

The DD has been totally rebuilt, but the problem still occurred. We even went as far as registering all our tables again in tbase, just to find out that that also did not solve the problem.

The portingset did not come with the SP, but BaaN highly recommended installing the latest portingset-version (as would I, if I worked there...) together with the installation of SP10. And so we did (and the rest is BaanBoard-history...).
After installation of the portingset, we got an error on the bdbreconfig6.1 when making a RDD. BGS advised us to put the "old" bdbreconfig-file back in its place, and the problem was solved. Ergo: the old bdbreconfig-file already has taken the place of the new one! So, unfortunately: this also was not the proper solution.


Henk.


P.S.: By the way: I don't think transportation by mule is a nice way to spend a holiday. So let's forget about Portugal...

I love Portugal though.

Henk, it sounds like you are up that infamous creek and your outboard is splashing.

Unless there is a strict dependency, it is never a good policy to do multiple upgrades at the same time.
This situation also shows the value of having a test box, but I know very well that that does not always fit in the budget, leave alone that there is time or are resources to perform proper testing.

After three months in production it is probably too late to back out SP10 (backing out Service Packs is everybody's favorite weeken activity, right?), but you might consider a restore of the porting set just to eliminate one of the two possible culprits.

Francesco,

I looked into things a bit closer, and I have to revoke some of the facts I mentioned earlier:


The error occurred for the first time in december 2001. I did not install SP10 until march 2002. So there goed that thread down the drain...
The latest portingset (6.1c.06.04) is installed as late as the 10th of July of 2002. So, also...


Sometimes time plays tricks on the minds of people, as it did in this case. It seemed to me I installed SP10 a lot earlier.

So, still no solution... (or even a hint).


Henk.

Henk,

Just before doing the actual reconfig, did you ever tried to check if the table was actual locked? I don't have a bisam system on hand but its one of the tbase6.1 P options with which you can check with locks are being make in the instance.

Regards,
Han

Han,

Sorry, but there was some work that needed to be done, so I did not have an opportunity to try your suggestion untill now.

After trying it, I get an output (with option "2" ("LOCKS"), the one you mean, I presume) that I can't quite figure out:

Display configuration. Usage 'tbase6.1 P [d] <option>'
Use 'd' for detailed information. Possible options:
c : active configuration parameters
1 : processes (PROCESSES)
2 : locks (LOCKS)
3 : files (FILES)
4 : indexes (IDXDESC)
5 [<type>] : data and index buffers (BUFFERS)
only with 'd': <type>: f = free, b = busy, u = update, r = readin
11 : semaphore information
bsp@marco:/appl/baan/BAANIVc/bse> tbase6.1 P 2

Triton Base Lock Information:

row locks 15000, internal locks 6250, locks used 0, locks free 21250

bsp@marco:/appl/baan/BAANIVc/bse>

What can I actually learn from this? Wich way to go from here?

Anyway, tomorrow (very early in the morning, I'm afraid) when no-one else is on the system, I will shut down BaaN, rename the ${BSE}/log-directory, create a new one, start BaaN again, reproduce the error and add the created logfiles to this thread. Maybe that can give someone a clue.


Henk.

Henk,

The line

row locks 15000, internal locks 6250, locks used 0, locks free 21250


does tell you that you don't have any locks in your tbase environment.
It looks really like a portingset problem, do you have any possibility to try the previous one, perhaps in a test environment?

Regards,
Han

Han,

In fact the error already occurred under the former portingset, so that's not an option, I suppose.

At least I've learned that the search for locks didn't lead to anything. Because I already have a modified table ready for the reproducing of my problem tomorrow, so the "tbase6.1 P 2" should give the lock, I presume. And he doesn't; because that's in the "locks used" section, right...?:p


Henk.

To offer as much info as possible, please note the output of "bshell6.1 -v":

bsp@marco:/appl/baan/BAANIVc/bse> bshell6.1 -v
-------------------------------------------------------
Portingset : 6.1c.06.04
Port no. : PA.1979
Date : Thu Apr 25 20:56:54 METDST 2002
Uname : HP-UX torka B.10.20 A 9000/861 2016171322 two-user license
Machine-id : HP9000_PA_8000
OS-release : HPUX10.20
CFLAGS : +DS2.0 +DA2.0 +Onolimit +O2 -Ae +Oconservative +ESlit +ESsfc +Ofas
taccess -I/port.6.1c.06.04/vobs/tt/headers -I/port.6.1c.06.04/vobs/tt/mir/mir -I
/port.6.1c.06.04/vobs/tt/lib/ds_1 -I/port.6.1c.06.04/vobs/tt/mir/ds_link -I/port
.6.1c.06.04/vobs/tt/lib/licence -I/port.6.1c.06.04/vobs/tt/lib/mb -I/port.6.1c.0
6.04/vobs/tt/lib/al_1 -I/mnt1/port/rel6.1c.06.04/lib/yy_1 -I/port.6.1c.06.04/vob
s/tt/lib/dbc -I/port.6.1c.06.04/vobs/tt/bdbint -I/port.6.1c.06.04/vobs/tt/lib/nw
_1 -I/port.6.1c.06.04/vobs/tt/bisam/include -I/port.6.1c.06.04/vobs/tt/lib/qp -I
/port.6.1c.06.04/vobs/tt/lib/qpd -I/port.6.1c.06.04/vobs/tt/lib/xml -I/opt/java/
include -I/opt/java/include/hp-ux -DHP9000_PA_8000 -DHPUX10_20 -DREL6_1 -DTTYBUG
-DHPUX -DHP9000_800 -DNOSETEUID -DINCLSTDLIB -D_HPUX_SOURCE -I/usr/include/X11R
5 -DSYSV_PT -D_TSS -DQPC_LIB -DNOSELECTH -DSOCKET -DLOCAL_SOCKET -DPIPE -DMQ -DS
HM -DDWORDSIZ -DSELECTINTYPES -DCUSERIDBUG -DVOID_PTR -DSCANF_OK -DSYSMEMFUN -DI
S_OPEN_BUG -DSLOTIO -DWRITEV -DHIGH_LOW -DGETCLOCK -DWAITPID -DNOWAIT3 -DSIGNAL_
TYPE=void -DSEM_LOCK
LOADFLAGS : -z -L/usr/lib/X11R5 -Wl,+s
-------------------------------------------------------
Copyright © Baan, 1990-2002


Henk.

Henk,

same symptom with error 113 on our testbox (IVc4, SP9, BAAN Base).
The work around to solve the problem in our environment is
to leave the bshell and login again. After that the reconfigure
for the adjusted table works without problems.

Jürgen

Jürgen,

I can't deny I envy you!

Unfortunately, logging off and on hasn't been a solution for us. When the problem occurs on one of our tables, the problem will occur every time and with any user. That, ofcourse, also means we can't use any session that uses that specific table.

Nevertheless: thanx for the suggestion!


Henk.

Henk,

one question regarding your problem.

Have you check on OS level with the fuser command, if the
the corresponding table which you want to reconfigure is
in use by your HP OS.

Jürgen

Y'all,

I tried to reproduce the error this morning. One of our programmers prepared table tdsls900 for this purpose. I stopped BaaN, replaced the ${BSE}/log-directory, started BaaN again and reconfigured the table... ofcourse without a problem!

Sigh... :(

The way I will go about from here on is: I will wait till the error occurs again, then stop BaaN, replace the log-directory, start BaaN again and reconfigure the modified table. That way I know for sure the error occurs.
Ofcourse I will present the logfiles to you all.

I can hardly wait...

And Jürgen: indeed we checked if there was such a "lock" from the OS. This is, however, not the case. But thanks for the suggestion.

And so we struggle on...


Henk.

We often had error 113 while using Bisam. The most common steps we did simply were just restart the server (init 6) (also observing that there are still no attaches in shared memory, because when it's issuing number of attaches #0 it can lead to errors again ) maybe sometimes running from comand line bdbreconfig6.1 with -Z (date and indices rebuilding) and -f options.
You can also run fuser utility with the argument "full path table name") it will issue PIDs that make locks on the table specified.
Full restart of the server and especially cleaning up the shared baan memory is a good thing for Tbase6.1 We also had much fun tose years. :)

Vens,

I can imagine the fun you had in those days. We're still having it...

Unfortunately restarting the server hasn't lead to a solution in our case.
And about fuser: this also lead to nothing useful.

My guess is still that it must have something to do with the bdbreconfig-file. Although, after experimenting with several versions of this file, nothing has changed. So my guess still is nothing more than a vague guess. (And is formed by absence of another sensible idea.)
The suggestion to our programmers that I like them not to modify tables anymore was kind of laughed at. I wonder why...

I know it sounds like a very mysterious case, and in fact it is. Maybe that's the reason why BGS is so very silent for several weeks now. I'm just greatful for something like this BaanBoard. I really appreciate the fact that you're all sharing your thoughts with me, making my problem your own.


Henk.

For your convenience, here is my contribution:
System: ve1sup3 = Baan IV c4 latest weekdumps (upto week 34), latest portingset (6.1c.06.05 indeed), bisam.
After each installation I ran all sessions needed (like ttiex3226m000, ttadv5213m000 all checked, ttadv5210m000 all checked).

When running "Tabellen reorganiseren" (ttaad4225m000) on company 000 when no-one else is logged in and no other tables used (I check the locks with: `for i in 0 1 2 3 4 5 6 7 8 9 ; do for j in 0 1 2 3 4 5 6 7 8 9 ; do tbase6.1 P d 2 ; done ; done`) several tables show up with error 113 too. There seems no process that actually locks the table.

On the other hand, sometimes locking did behave strange:
When on a bigger table the export was started, the table got locked.
When the export still was running, the lock was gone.
When the import started, there was a lock again.

I run BSP in package combination B40Sc4 which is the one used for company 000.

Seems similar. Keep you posted when I find a solution - any progress.

What about registration of the tables involved?
Do they occur only once in the `tbase6.1 R d > list.reg` list.reg file?

Ome Luuk,

Thank you for sharing your troubles. It really sounds familiar!

All our tables have recently (out of desperation) been registered again, according to the way to fix error 16300. We hoped to get rid of the problem once and for all. But...

Keep us posted!


Henk.

How did you (re)register these tables? First removed all tables from registration (then removed the registration database files) and added them with a script like ?
# become root
su -
# stop Baan
cd $BSE/etc/
ksh -x ./rc.stop
# verwijder oude registry
mv $BSE/lib/tbase/reginfo.bdt $BSE/lib/tbase/reginfo.bdt.`date +%d%m%Y`
mv $BSE/lib/tbase/reginfo.bid $BSE/lib/tbase/reginfo.bid.`date +%d%m%Y`
# start database
shmmanager6.1 -i
tbase6.1 -i
# lees isamdef en registreer de tabellen
for i in `cut -f3 -d":" $BSE/lib/isamdef6.1 | sort -u | sed 's/\/#//'`
do
for j in `find $i -name "*.bid" -print | sed 's/.bid//'`
do
tbase6.1 R r $j
done
done
# stop database weer om "schoon" te beginnen
tbase6.1 -k
shmmanager6.1 -k
# start Baan en test
cd $BSE/etc/
ksh -x ./rc.start

Slightly different, but similar:


Log in as user 'root'

cd ${BSE}/bin
mv bshell6.1 bshell6.1.nologin # All users should be off the system and new ones prevented from logging in

cd ${BSE}/lib/tbase
tbase6.1 R d > /tmp/tab.lst # Create a list of registered BISAM-tables
rc.stop

mv reginfo.bdt reginfo.bdt.old # Save the original registration files
mv reginfo.bid reginfo.bid.old # Use 'mv' (not 'cp'!) to preserve the Unix i-node number

shmmanager6.1 -i
tbase6.1 -i # Restart the tbase processes. This creates empty registration information files


tbase6.1 R n /tmp/tab.lst # Rebuild the new registration file from the list of tables

tbase6.1 -k

cd ${BSE}/bin
mv bshell6.1.nologin bshell6.1

rc.start


This information can also be found at ftp://ftp.support.baan.com/documents/tools/1500.exe


Henk.

The problem with using the list like previous registered, will never remove wrong registrations in the past. That is why the other variant via isamdef is used by me... When companies are cleaned / put on another disk etc, then this seems to be the safest way.

Registration is not the issue in my case though.

Understood, but sometimes drifting off the mainpath can be very usefull.


Henk.

All,

Succes at last! That is, in reproducing the error (no, no, not the solution).

I would really like it if you would be so kind as to look at the logfiles BaaN spits out at the moment error 113 occurs.

Please, boggle your minds and don't hesitate to inform me about your thoughts.

To be frank: personally, I don't find anything enlightening in them, but it are the files BGS requested. But since my faith in BGS is reducing faster and faster, I like the BB forum to take a look; you never know what I might overlook.

Henk.

But it verifies that the 113 error occurs before bdbreconfig, which takes that one off the list once and for all.

Francesco,

Indeed, it makes the list smaller (and takes away my suspicion towards that particular file once and for all, very much to my surprise), but not necessarily easier.

Something odd has happened, though: after having seen the logfiles (and the output of "tbase6.1 P 2"), BGS finally admits that it is a mysterious case.
Well, that only took about three months :( .

Anyway, thanks for reassuring my opinion regarding the logfiles.


Henk.

(yep, I'm back, since 2 weeks now, not in a mule - don't see one for several years now, species already extinguished? - but in my new car :), but damn, I've been really busy!)

I would still bet in a portingset bug: when a bdbpre6.1 starts creates a lock on the current table and for me, it look like Baan looses track that the lock belongs to this bdbpre process and assumes that somebody else is locking the table.

This may have appeared before the latest portingset and get even worse with the current one (not the first time I see something like this happen).

despite the fact that they are born unvirtil.

And sadly enough this is probably the most intelligent thing I have to add to this case at the moment.

All,

I think it's nice to tell you the outcome of the long awaited investigation that BGS performed on our system. Warning: this information is not suitable for minors and can be expierenced as shocking ;) .


They discovered that Baan puts a lock on a table, wich cannot be found, traced or whatever. The table appears in the "Used table"-list in tbase, yet no locks are shown.
Not discovered is what causes this lock. Needless to say that also a solution is not proposed.
However, the case status is "Solution proposed", because BGS suspects it's a BISAM error, and BISAM is no longer actively supported by BGS.
In other words: case closed, good luck and we hope you learn to live with it.


I wish to thank you all for elaborating your thoughts on this problem. Ironically, I experienced a lot more support from the BB-members than from BGS...


Henk.

Henk,

So it's a final sad enough.
Absolutely no good for you now to perform your tests on Triton anymore? Migrate to smth. like oracle?

Fortunately, our own development, test and production environment work with Oracle8. So, no complaints there.

However, we also develop for customers, and on that environment we work with BISAM. Personally, I prefer a conversion to Oracle, but that's not my decision to make.


Henk.

I just received a request to anticipate in a Baan Support survey in my mail this morning.

Do you want to fill it out for me?

Francesco,

I know the kind of form you're talking about. If I'm not mistaken, it's the kind of form in wich it says that "the filling out of this form is very important to improve future service" yaddayaddayadda.
I don't know how many times I filled in a survey like that. Yet, the service stays at that remarkable level that makes you cry out of desperation. Although, as far as I'm concerned they reached their all time low with this case of "support".


Henk.