SHOW-ITEM-LOCKS
s7bd
displays 'polling 115 ports' but never comes back. A break shows I'm
at line 323 in a process called jutil.filelock.b
Did a CLEAR-ITEM-LOCKS and tried again with the same hang.
LIST-LOCKS reports zero system locks and zero READ/UPDATE locks then
it hangs on RECORD LOCKS AND EXECUTION LOCKS hangs at line 297 and
sometimes 323 as if the program things it's doing something.
EXECUTION LOCKS:
Polling 115 ports ...
Interrupt signal
Line 297 , Source jutil.filelock.b
LISTU completes just fine.
Also, execution lock display in LIST-LOCKS also hangs.
Has anyone else tried SHOW-ITEM-LOCKS or LIST-LOCKS in jBASE 4 with
success or failure? I'm Redhat Enteprrise 4.
-BD
Jason.Sh...@cexp.com
Confirmed, yet again, Bruce.
We haven't had a functional SHOW-ITEM-LOCKS in almost 18 months
On AIX 5.3
I have to thank you, Bruce, because before this wknd I really thought I was alone in my amazement. How could I be the ONLY 4.1 site feeling this level of pain?!
Thanks, Jason
Jason Shatzkamer
Director of Electronic Customer Solutions
Corporate Express
Work: 954-379-5415
Mobile: 561-350-7364
Email: j...@cexp.com
www: http://imaging.cexp.com
Jason.Sh...@cexp.com
The best, though, is when it gets hung polling ports, and there are no other active ports running!
That's my favorite :-)
s7bd
This forum actually works pretty well because I can confirm a problem
with others before going to jBASE. It seems backwards but it saves me
time and effort having to setup proof for bugs that are widespread.
Lock lists are very important and I hope, based on the fact that both
of us are experiencing the same issue of different 4.1 releases on
different OS's that Temenos will readily open a ticket. If you don't
mind, I'll mention to jBASE/Temenos that you can also reproduce this
one.
Fwiw, the head of Strategy 7 received a call from jBASE yesterday
complaining about my posts here. I guess it has embarassed them.
Really, I think that that all of us want is more responsive support
and that is what I am finding here among my peers. So long as the
verbiage is tempered, I think its a good thing for the user community
to know what is going on with the product and the support. For
example, some of the most knowledgeable and respected members of this
list were taken by surprise when I revealed some of the features that
have been deprecated. If they are surprised then certainly other VARs
and end-users attempting to migrate are also going to be taken by
surprise when they go through a painful migration effort only to find
out that trivial but important features are missing or have changed
name and are no longer supported. These are things that used to be
published by jBASE. Now that they are not holding up that end of
their obligation to us, I think it's unfair for them to complain to
those above me when we're just trying to get the truth out there (and
perhaps some solutions).
I want to thank you, Jim Idle, Doug Miller, Ken Wallis, Greg Cooper,
Dan Klein and others that have responded. While it's been painful to
see some of these glaring defects, I feel better knowing that others
also believe that these are unacceptable and need to be fixed by
Temenos. Thanks to all for making these threads very productive (at
least for me).
Thanks,
Bruce Decker
Strategy 7 Corporation
720.733.0459
DonRobinson
This is my first post on this group although I have been lurking for
years!
Begin intro;
I work for Ashwood Computer Co, Cincinnati, Ohio and we are a jBASE
VAR, plus other MV systems.
We use jBASE 3.3.x internally for our accounting system.
We are testing jBASE 4.1.5.13 on Windows 2003.
End intro;
For several weeks, I have been trying to get out accounting system to
run on jBASE 4 with mixed results.
I just tried the LIST-LOCKS and it does not hang but it doesn't return
any locks!
I did a JED command in a second session and LIST-LOCKS showed NO locks
found.
I did a JED command in a third session on the same file & item and it
did not tell me I had it locked...
And still no locks found.
Is JED not locking records or what?
Same for ED.
As far as for the SHOW-ITEM-LOCKS, it takes about 4 seconds to
respond.
If it takes a second per port, then 100+ ports could take a couple of
minutes, I guess.
As far as other problems, we are waiting on the fix for a formatting
issue and I have reported a LOGTO problem.
And the changes to the RUN command has required some proc changes.
Other wise, I'm prodding along...
Regards,
Don
> -BD- Hide quoted text -
>
> - Show quoted text -
Jason.Sh...@cexp.com
4.1.5, but we never upgraded because the later releases came with their
own new and unique issues that we were simply not ready to deal
with...and also because of our 5 or 6 "MAJOR" issues, only the
SHOW-ITEM-LOCKS one was addressed...our hope was that more of the issues
would be resolved before we went through change control, user testing,
etc, which is involved in any DB engine upgrade, but that hope has since
faded away...
Daniel Klein
Dan
s7bd
required even on a single server jBASE environment?
Bruce Decker
Strategy 7 Corporation
720.733.0459
On Apr 24, 7:43 pm, "Daniel Klein" <danielklei...@gmail.com> wrote:
> Dan- Hide quoted text -
Eric Rave
locking in 4.1.5
http://www.jbase.com/support/41docs/jBASE%20Distributed%20Locking.pdf
s7bd
On this thread, Dan Klein asked me if I ran the locking daemon and I
replied that I did not but he didn't follow-up that comment with any
practical suggestions. So, how are you dealing with locks? Surely in
an operation of your size, you run into lock situations whereby having
a listing of locks would be instrumental in determining and resolving
the issue. Are there alternative techniques that you have developed
while awaiting Temenos to fix SHOW-ITEM-LOCKS and LIST-LOCKS?
Thanks,
Bruce Decker
Jason.Sh...@cexp.com
BUT, if we have a port in question that we need to handle, we wrote a
routine that takes in a filename (optionally also an item id) and loops
over it doing a READU on the record with a LOCKED clause...using SYSTEM
variables, we are able to determine information about the locked record
(i.e. port, user, etc.)
This at least enables us to identify what record is locked by a given
port, and - when run over an entire file - can tell us which records are
locked in that file, and by whom...since locks come and go in a
sub-second timeframe, the script is only useful for certain specific
situations...
Not a dream scenario, but better than nothing.
Running this script over all files is horribly slow, and extremely IO
intensive, but all in all performs way better than the jBASE
SHOW-ITEM-LOCKS, which continues to poll ports well after our script has
finished. (Granted we never actually ask our script to read EVERY record
in every file in our system, but we did do it once just for kicks,
confirming to ourselves that it WAS faster than SHOW-ITEM-LOCKS). This
is an example where it sucks to be right.