T.R | Title | User | Personal Name | Date | Lines |
---|
2481.1 | Re: bco hang? | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 09 1996 17:29 | 81 |
| Date Of Receipt: 9-AUG-1996 15:54:18.94
From: FLUME::"[email protected]" "Susan Schueller USG 09-Aug-1996 1553"
To: [email protected]
CC: [email protected], [email protected]
Subj: Re: bco hang?
Josh,
Any ideas?
Sue
------- Forwarded Message
Return-Path: [email protected]
Delivery-Date: Fri, 09 Aug 96 15:49:50 -0400
Return-Path: [email protected]
Received: from DECnet-Mail11.flume.zk3.dec.com by flume.zk3.dec.com;
(5.65v3.2/1.1.8.2/16Jan95-0946AM)
id AA04691; Fri, 9 Aug 1996 15:47:56 -0400
Date: Fri, 9 Aug 1996 15:47:55 -0400
Message-Id: <[email protected]>
Mime-Version: 1.0
From: [email protected] (Pete Nishimoto ZK1-1/E37
(381.1107/223.6343))
To: "[email protected]"@FLUME.enet.dec.com
Subject: Re: bco hang?
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sue,
Yep, I'm in a workon and all that. It still just "hangs"
there like it's waiting for something. Here's what it
looks like:
frazzl.zko.dec.com:peten:r6> bco -verbose -debug -odedebug vcs bitblt.c
>> DEBUG INFO in current_sb:
>> Found sb name in environment. Name is: r6.
>> DEBUG INFO in current_sb:
>> sb name is in rc file. Name is: r6.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/users/peten/sandboxes.
>> DEBUG INFO in current_sb:
>> Using default sandbox rc file: /usr/users/peten/sandboxes/r6/rc_files/local.
>> DEBUG INFO in current_sb:
>> sb name is in rc file. Name is: r6.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/users/peten/sandboxes.
>> DEBUG INFO in current_sb:
>> Using default sandbox rc file: /usr/users/peten/sandboxes/r6/rc_files/local.
>> DEBUG INFO in current_set:
>> found default set, Pete_Nishimoto_r6, in sb rcfile.
>> DEBUG INFO in current_sb:
>> sb name is in rc file. Name is: r6.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/users/peten/sandboxes.
>> DEBUG INFO in current_sb:
>> Using default sandbox rc file: /usr/users/peten/sandboxes/r6/rc_files/local.
>> DEBUG INFO in current_set:
>> matched set, Pete_Nishimoto_r6, and setdir, ., in sb rcfile.
[ SET: Pete_Nishimoto_r6 ]
and it just sits there. Any other ideas?
------- End of Forwarded Message
--
------------------------------------------------------------
Susan Schueller Digital Equipment Corporation
USG Release Engineering MS ZKO3-3/W20
(603) 881-6348 110 Spit Brook Road
[email protected] Nashua, NH 03062-2698
------------------------------------------------------------
|
2481.2 | Re: bco hang? | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 09 1996 18:30 | 52 |
| Date Of Receipt: 9-AUG-1996 16:50:04.06
From: FLUME::"[email protected]" "Susan Schueller USG 09-Aug-1996 1649"
To: wrksys::nishimoto
CC: [email protected], [email protected]
Subj: Re: bco hang?
Hi Pete,
Here is a suggestion from Evelyn Walton.
Sue
------- Forwarded Message
Return-Path: [email protected]
Delivery-Date: Fri, 09 Aug 96 16:22:41 -0400
Return-Path: [email protected]
Received: from locusla.wdec.platsol.com by flume.zk3.dec.com;
(5.65v3.2/1.1.8.2/16Jan95-0946AM)
id AA28819; Fri, 9 Aug 1996 16:22:39 -0400
Received: by locusla.wdec.platsol.com (5.65/Ultrix3.0-C)
id AA13707; Fri, 9 Aug 1996 13:32:50 -0700
Date: Fri, 9 Aug 1996 13:32:50 -0700
From: [email protected] (Evelyn Walton)
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: bco hang?
Sue,
You might have him check to see if the machine he is logged into when he
tries the bco is running the same version of OSF as the machine where his
sandbox files actually live. In the past I have had similar problems with
bco hanging where his is that was apparently some sort of compatibility
problem with nfs locking between earlier and later versions of osf (like
v32 and v32c). One way to check for this would be to try the bco from the
machine where the files live. Only a couple of ode commands were affected
by this problem.
Evelyn Walton ([email protected])
------- End of Forwarded Message
--
------------------------------------------------------------
Susan Schueller Digital Equipment Corporation
USG Release Engineering MS ZKO3-3/W20
(603) 881-6348 110 Spit Brook Road
[email protected] Nashua, NH 03062-2698
------------------------------------------------------------
|
2481.3 | Re: bco hang? | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 09 1996 18:31 | 14 |
| Date Of Receipt: 9-AUG-1996 16:59:32.31
From: FLUME::"[email protected]" "Joshua M. Friedman Digital UNIX"
To: wrksys::nishimoto, [email protected]
CC: [email protected], [email protected]
Subj: Re: bco hang?
Pete, please check your connectivity using
ping and traceroute to secret.zk3.dec.com and buffer.zk3.dec.com;
if you are on a system which nfs mounts your sandbox, please
ensure that nfs locking is enabled on both the server & client.
-josh
|
2481.4 | Re: bco hang? | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Fri Aug 23 1996 16:01 | 36 |
| Date Of Receipt: 12-AUG-1996 10:49:56.63
From: HUNCH::jmf "Joshua M. Friedman Digital UNIX"
To: wrksys::nishimoto
CC: odehelp@DEC:.zko.hunch, sschuell@DEC:.zko.hunch
Subj: Re: bco hang?
Pete, glad you're all set. The .BCSlock file is supposed to be
in your sandbox - all the b* commands create one, and if you delete it
then it gets recreated. Sometimes there can be a process which appears
to have been killed or died which isn't completely gone, and has a
"hold" on that .BCSlock file, so rm'ing it can in fact unstick some
situations. You'll find you now have a new .BCSlock - this is normal.
-josh
---------
Date: Mon, 12 Aug 1996 07:53:10 -0400
From: [email protected] (Pete Nishimoto ZK1-1/E37 (381.1107/223.6343))
To: [email protected]
Cc: " [email protected]"@AVALON.enet.dec.com
Subject: Re: bco hang?
Got it. Something was real wrong Friday. I came in this
morning, messed around a bit (.BCSlock files hanging around)
and "things started working again".
ODE magic.
At least I'm out of ODE-Hell for now. Thanks.
Pete
|