Hi --
I'm migrating an existing chui app from 9.1D on SCO OpenServer to 10.2B on RHEL. Things are going well, but... when exiting the app, I get 331 instances of:
warning - pcondb for db utps has lkctr -nnn (395)
where nnn increments from 1 to 331.
The message is not written to the .lg file.
I read KBase article 000026044, which indicates I can turn off the warnings via the -nolkctr startup client parameter. It also says the warning "usually does not affect runtime operations or data integrity."
I am wondering if any of you have any experience with this warning message? Should I be concerned and try to doggedly hunt down the root cause? If it usually does not affect ops or integrity, what does it unusually affect?
Advice appreciated in advance --
Jim Shepherd
Level 7 Group
I am a developer in the Progress ABL core language team. This is a message indicating that an internal reference count has gotten out of sync.
Do you have code that can reliably reproduce this? If so I could you open a call with technical support. Many years ago we had issues with this
counter that proved to be benign and the issue was resolved. We'll be glad to look into it again especially if you have a reproducible case.
-regards
richard tucker
It's 100% reproducible -- I get 331 instances every time I exit the app. The problem is that it's a fully developed app. I'll see if I can whittle it down to a manageable bit of code and/or something I can get into the sports db. Thanks --
If you can that would be great, thanks
Well, I've spent the best part of today trying to reproduce it sports2000 and so far I can't reproduce it. Any clues as to what it might be related to? Is it really a "lock counter" and if so, does that imply that I need a certain number (probably large) of records to lock?
It has nothing to do with record locks but rather with acquiring and releasing the schema lock. This lock is acquired implicitly by the AVM whenever a procedure/method/function is entered that has a reference to a database and is released when the procedure is exited. It may also be acquired as a side of running a dynamic query. So what you may want to try and mimic is the procedure nesting of the application just before exiting the application.
Would it be suspicious if I found a "qh:query-open" that is eventually followed by a "delete object qh" without an intervening "qh:query-close" ?
Jim, did you find a statement that rises the warning (395)?
If you'll start a session with the -debugalert parameter or inside the session you'll set: SESSION:DEBUG-ALERT = TRUE
then you can get a procedure call stack for any message.
@George --
Thanks for the advice. With a combination of
-debugalert -clientlog /tmp/clientlog.txt
-logentrytypes DynObjects.* -logginglevel 3
I discovered 331 instances of "create buffer ..." that did not have corresponding delete events.
After modifying the code to delete them, all the errors/warnings went away.
@Richard --
I was never able to reproduce in sports2000 and since the root cause turned out to be non-deleted objects as suggested in kbase article 000026044, I'm probably not going to pursue reproducing the problem any further, unless you tell me it would be a great service to mankind at large.
Thanks again to both of you for your help !
Jim Shepherd
Level 7 Group