Andreas:
Hi. Yes, your understanding below is correct.
To answer your additonal questions...
>>> Is it a problem in a production environment ?
No, just test, so it is not urgent for us.
>>> Do all prepares hang ?
Any statement which involved parsing SQL, i.e. a prepare(), do(), etc. hangs if
the SQL statement is valid.
>>> Is it the first prepare which hangs ?
Yes
>>> Running without debugger, do you see RDB stall with $ RMU/SHO LOCK
>>> /MODE=BLOCKING or
>>> RMU/SHO STAT and using menus: process-info, stall messages
RMU/SHOW LOCK /MODE=BLOCKING shows "no locks on this node with the specified
qualifiers"
RMU/SHO STAT, process info, stall messages shows my process:
Process.ID Since...... T Stall.reason.......... Lock.ID.
27408D09:1 locking page 1:937
Also, MONITOR PROCESSES shows the following for this process:
PID STATE PRI NAME PAGES DIOCNT FAULTS CPU TIME
27408D09 LEF 5 _FTA45: 298/1330 89892 105317 00:05:06.7
If I look at the Monitor log as I step through the debugger, here is what I see:
1) At the DBI->connect() call, it logs:
7-MAR-2001 21:07:51.25 - received user attach request from 27408D09:1
- process name _FTA45:, user MGR_FXM8
- image name "$1$DKC1:[SYS0.SYSCOMMON.PERL.][000000]PERL.EXE;1"
- for database "$1$DKC202:[FXM8.PFS.DB_DISK001.DB]FXM8_PFS_DB.RDB;2" [_$1$DKC
- sending normal user attach reply to 27408D09:1
2) At the $dbHandle->prepare() call, it logs nothing, but hangs. If I control-C
it and then issue a STOP, it logs:
7-MAR-2001 21:27:34.35 - received user image termination from 274094E9:1
and then goes through the normal recovery process.
3) When I run through this same process with a debugging session and breakpoints
set, and then step over the "prepare()" statement (i.e. since it works in the
debugger after hitting a breakpoint, I let it run PAST the _prepare() call), it
logs nothing, but I see the following in the "Active user stall messages":
Process.ID Since...... T Stall.reason......... Lock.ID.
274094E9:1 reading pages 1:6628 to 1:6639
Which seems strange, because it is in fact not stalled -- at least my Perl
program has returned from the _prepare() call and can continue to completion
without any further problems.
>>>Did you try a rebuild?
Yes, we have tried many different varieties of builds, including building
DBD::RDB on a machine with the RDB V7.0-6 development tools, then copying the
resulting files to a machine running RDB v7.0-3, and this actually worked. It
seems to fail consistently when I try to connect to a 7.0-6 database, regardless
of whether I built it using the 7.0-3 or 7.0-6 development tools.
I hope this sheds a little light on the problem...
Regards,
David E. Hansen
UBS Warburg Switzerland
______________________________ Reply Separator _________________________________
Subject: Re: DBD::RDB strangeness
Author: andreas.stiller ([EMAIL PROTECTED]) at unix,mime
Date: 03/06/01 8:48 AM
Hi David,
i repeat what i understood:
1) DBI script hangs on a prepare (RDB 7.0-6)
2) Same script runs fine on another machine (RDB 7.0-5, maybe other
differences)
3) The hang is a LEF in DBDSQL_prepare
4) It occurs with and without debugger.
4) Bug does not occur when debugging and using step over
My questions:
Is it a problem in a production environment ?
Do all prepares hang ?
Is it the first prepare which hangs ?
Running without debugger, do you see RDB stall with
$ RMU/SHO LOCK /MODE=BLOCKING or
RMU/SHO STAT and using menus: process-info, stall messages
Did you try a rebuild ?
I will try my best to build a 7.0-6 environment
Thanks
Andreas
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
