> Could you please expand a little on the last paragraph? > How does it 'all fall over'? What symptoms are exhibited?
It hung and nothing seemed to get it going again. Not having made any notes on how I did yesterday's experiment, I had to try again and (of course) it all worked more sensibly today and just hung the process that was trying to do the delete. A "LIST.READU EVERY" report showed that this user was waiting for a lock owned by user 0 which is probably UV's way of saying that it is waiting for any user who owns a lock in the full lock table row to go away. When the program that holds all the locks terminates, the hung user completes correctly but I do get several pages of "READU threshold reached" messages. These are fine though they are not very helpful when the application finishes. All in all, it looks like UV survives the situation that I was interested in experimenting with. So, back to square one (if we can remember the original question that started all this!) - what is holding the T30File semphore for lengthy periods? I still maintain that it may be the process of moving locks in the lock tables. All that my experiments have shown is that the system survives this operation when the lock cannot be moved. We may also be looking for the wrong thing here. A semaphore collision count of 6 really is nothing to get excited over, especially if the system had been up for a while. Looking back to Karl's original posting, I think we need to know a bit more about how the "performance hits" exhibit themsleves. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
