[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

40.0. "Help! bsubmit problem when I needed it the least." by SMURF::FILTER (Automatic Posting Software - send mail/comments to flume::puck) Wed May 12 1993 09:13

Date Of Receipt: 	11-MAY-1993 17:56:33.10
From: 	WASTED::krisis::sandeep
To: 	wasted::odehelp
CC: 	flume::kenny, krisis::sandeep
Subj: 	Help! bsubmit problem when I needed it the least.

Hi,

I am getting the following problems, any ideas folks?

sandeep

--------------------------------problem 1
[xticheck.71]   bsubmit -all
Enter the defect number this submission applies to: agosmaint-542-sandeep

Retrying connection to buffer.zk3.dec.com: retry number 1
No longer using cached authorization
Retrying connection to buffer.zk3.dec.com: retry number 1
No longer using cached authorization

*** No user interaction will be required during the merge step. ***


*** VALIDATION FAILURE ***

./kernel/data/xti_data.c -- not checked in. locked.
./kernel/streamsm/xtiso.c -- not checked in. locked.
./kernel/streamsm/xtiso.h -- not checked in. locked.
./usr/ccs/lib/libtli/trcv.c -- not checked in. locked.
./usr/shlib/alpha/so_locations -- not checked in. locked.
./usr/shlib/libxti/Makefile -- not checked in. locked.

Consult the bsubmit reference page for suggested corrective actions.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.


---------------------------------- problem 2
[xticheck.53]   bsubmit -all 
Enter the defect number this submission applies to: agosmaint-518-sandeep

>> FATAL ERROR in /usr/sde/tools/alpha_ace/bin/ode/bsubmit:
>> waiting for sandbox lock via flock()
*** No user interaction will be required during the merge step. ***


*** VALIDATION FAILURE ***

./kernel/streams/str_synch.c -- not checked in. locked.

Consult the bsubmit reference page for suggested corrective actions.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.



T.RTitleUserPersonal
Name
DateLines
40.1Re: Help! bsubmit problem when I needed it the least.SMURF::FILTERAutomatic Posting Software - send mail/comments to flume::puckWed May 12 1993 09:1515
Date Of Receipt: 	11-MAY-1993 18:12:40.96
From: 	WASTED::"minsrv::[email protected]"
To: 	[email protected] (Sandeep Shah USSG)
CC: 	[email protected], [email protected]
Subj: 	Re: Help! bsubmit problem when I needed it the least.

Sandeep, it looks like you need to rm the .BCSlock file in the
sandbox's src directory -- some sandbox process locked this and
didn't unlock it.  Also, you need to check in files before you
submit them.  Lastly, make sure you have read access to the
submit tree agosmaint; since it just was moved between devices
you may need to unmount and remount (odemount -u/odemount).

-josh

40.2Re: Help! bsubmit problem when I needed it the least.SMURF::FILTERAutomatic Posting Software - send mail/comments to flume::puckWed May 12 1993 09:1511
Date Of Receipt: 	11-MAY-1993 18:34:18.79
From: 	WASTED::krisis::sandeep
To: 	minsrv::[email protected], [email protected]
CC: 	[email protected], flume::kenny, wasted::odehelp
Subj: 	Re: Help! bsubmit problem when I needed it the least.

Thanks Josh.  Remount and checking in the files first helped.  submit worked
fine.

sandeep

40.3Submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jun 07 1993 16:4042
Date Of Receipt: 	26-MAY-1993 16:25:35.69
From: 	MINSRV::"[email protected]"
To: 	[email protected]
CC: 	
Subj: 	Submit problem

Hi,
	I have been working with someone trying to overcome a problem
of submitting a file. Below is the error message. I made sure the file was 
checked in before the submit. Can somebody give me some suggetions on how
to get around this?


------- Forwarded Message

Return-Path: [email protected] 
Delivery-Date: Wed, 26 May 93 16:12:35 -0400
Return-Path: [email protected]
Received: by lars.unx.dec.com (5.65/MS-070792);
	id AA20582; Wed, 26 May 1993 16:12:34 -0400
Received: by peewee.unx.dec.com (5.57/MS-070792);
	id AA07528; Wed, 26 May 93 16:14:40 -0400
Received: by lunchtime.unx.dec.com; id AA28031; Wed, 26 May 1993 16:12:47 -0400
Date: Wed, 26 May 1993 16:12:47 -0400
From: Tony Hoffman <[email protected]>
Message-Id: <[email protected]>
Apparently-To: [email protected]

ci error: no lock set by Anthony_Hoffman for revision 1.1.4.2
[ ./usr/bin/rcs/diff/getopt.h checked in onto branch 1.1.4 ]

Please take appropriate steps and re-submit.

*** RE-SUBMISSION REQUIRED ***

- - Source control information is in an intermediate state.
- - Re-submit using -resub 16:19 [ -date 5/25/93 ]


------- End of Forwarded Message


40.4Re: Submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jun 07 1993 16:4112
Date Of Receipt: 	26-MAY-1993 16:28:29.57
From: 	KRISIS::johnf "John Flanagan OSG Test Johnf Tools Group"
To: 	"Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]" <[email protected]>
CC: 	[email protected]
Subj: 	Re: Submit problem

Try   "bcs -l ./usr/bin/rcs/diff/getopt.h"

and then try the submit again.  

John

40.5Re: Submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jun 07 1993 16:4111
Date Of Receipt: 	26-MAY-1993 16:54:59.18
From: 	LOCORE::"[email protected]"
To: 	John Flanagan <[email protected]>
CC: 	"Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]" <[email protected]>,
	[email protected]
Subj: 	Re: Submit problem

I tried  "bcs -l ./usr/bin/rcs/diff/getopt.h" and it still failed.

-Rich

40.6Re: Submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jun 07 1993 16:4331
Date Of Receipt: 	26-MAY-1993 18:33:43.69
From: 	LOCORE::"[email protected]"
To: 	MINSRV::"[email protected]"
CC: 	[email protected], [email protected]
Subj: 	Re: Submit problem

I suggest rerunning using the resub and put it in -debug,
so can get more information on what ci is doing on the server.


bsubmit -debug -resub 16:19

***************************************************

removelock(delta)

/* function: Finds the lock held by caller on delta,
 * removes it, and returns nonzero if successful.
 * Print an error message and return -1 if there is no such lock.
 * An exception is if !StrictLocks, and caller is the owner of
 * the RCS file. If caller does not have a lock in this case,
 * return 0; return 1 if a lock is actually removed.
 */
{
...
        if (!StrictLocks && myself(RCSstat.st_uid))
            return 0;
        error("no lock set by %s for revision %s", getcaller(), num);
        return -1;
}

40.7help!SMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jul 26 1993 17:0340
Date Of Receipt: 	22-JUL-1993 13:56:43.20
From: 	LOCORE::stuarth "Stuart Hollander UEG"
To: 	locore::odehelp
CC: 	
Subj: 	help!

What is the bsubmit asking me about?
And, why do the diff and rdiff and edit not do anything?


bsubmit -auto_out -all 
Enter the defect number this submission applies to: agosminor-650-stuarth

The following file(s) will require user interaction during the merge step:

 './kernel/conf/alpha/.mrg..files.dat' is a binary file that requires the use of:
   co or rco command.

 co     - check-out ./kernel/conf/alpha/.mrg..files.dat from destination branch alone
        - the copy in the submit tree will be kept intact.

 rco    - check-out ./kernel/conf/alpha/.mrg..files.dat from source configuration alone
        - the copy in the submit tree will be overwritten by your copy.

  ./kernel/conf/alpha/.mrg..files.dat
  ./kernel/conf/alpha/files

Do you wish to continue ?: [Yes] yes
Abort, ok, edit, merge, [r]co, [r]diff  []  rdiff 
Abort, ok, edit, merge, [r]co, [r]diff  [ok]  diff
Abort, ok, edit, merge, [r]co, [r]diff  [ok]  edit
Abort, ok, edit, merge, [r]co, [r]diff  [abort]  ok
Abort, ok, edit, merge, [r]co, [r]diff  [merge]  ok
Abort, ok, edit, merge, [r]co, [r]diff  [merge]  edit
Abort, ok, edit, merge, [r]co, [r]diff  [abort]  edit
Abort, ok, edit, merge, [r]co, [r]diff  [abort]  edit
Abort, ok, edit, merge, [r]co, [r]diff  [abort]  ok
Abort, ok, edit, merge, [r]co, [r]diff  [merge]  


40.8Re: help!SMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jul 26 1993 17:0764
Date Of Receipt: 	22-JUL-1993 14:01:11.09
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE"
To: 	[email protected], [email protected]
CC: 	
Subj: 	Re:  help!

Stuart, since the .mrg..files.dat file is apparently not a file with an
ode header, it has been identified to the ODE system as a "binary".

ODE now seems to have built-in restrictions that you can't do diffs or
edits on binary files (reasonable for true binary data files, but probably
not so reasonable for text files just tagged as binary).

Please use gen-ptt to report this bug/suggestion.  In the meantime,
you should possibly abort, take care of the merge "by hand", bci what
you want to use, and then use the "rco" option during bsubmit.

-josh

	From [email protected] Thu Jul 22 13:57:52 1993
	Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
		id AA17778; Thu, 22 Jul 1993 13:56:40 -0400
	Date: Thu, 22 Jul 1993 13:56:40 -0400
	From: [email protected] (Stuart Hollander UEG)
	Message-Id: <[email protected]>
	To: [email protected]
	Subject: help!
	
	
	What is the bsubmit asking me about?
	And, why do the diff and rdiff and edit not do anything?
	
	
	bsubmit -auto_out -all 
	Enter the defect number this submission applies to: agosminor-650-stuarth
	
	The following file(s) will require user interaction during the merge step:
	
	 './kernel/conf/alpha/.mrg..files.dat' is a binary file that requires the use of:
	   co or rco command.
	
	 co     - check-out ./kernel/conf/alpha/.mrg..files.dat from destination branch alone
	        - the copy in the submit tree will be kept intact.
	
	 rco    - check-out ./kernel/conf/alpha/.mrg..files.dat from source configuration alone
	        - the copy in the submit tree will be overwritten by your copy.
	
	  ./kernel/conf/alpha/.mrg..files.dat
	  ./kernel/conf/alpha/files
	
	Do you wish to continue ?: [Yes] yes
	Abort, ok, edit, merge, [r]co, [r]diff  []  rdiff 
	Abort, ok, edit, merge, [r]co, [r]diff  [ok]  diff
	Abort, ok, edit, merge, [r]co, [r]diff  [ok]  edit
	Abort, ok, edit, merge, [r]co, [r]diff  [abort]  ok
	Abort, ok, edit, merge, [r]co, [r]diff  [merge]  ok
	Abort, ok, edit, merge, [r]co, [r]diff  [merge]  edit
	Abort, ok, edit, merge, [r]co, [r]diff  [abort]  edit
	Abort, ok, edit, merge, [r]co, [r]diff  [abort]  edit
	Abort, ok, edit, merge, [r]co, [r]diff  [abort]  ok
	Abort, ok, edit, merge, [r]co, [r]diff  [merge]  
	
	

40.9Re: help!SMURF::FILTERAutomatic Posting Software - mail to flume::puckMon Jul 26 1993 17:0816
Date Of Receipt: 	22-JUL-1993 14:03:05.30
From: 	FLAMBE::johnf "John Flanagan OSG Test Johnf Tools Group  22-Jul-1993 1403"
To: 	[email protected] (Stuart Hollander UEG)
CC: 	johnf@DEC:.zko.flambe, odehelp@DEC:.zko.flambe
Subj: 	Re: help!

The file .mrg..files.dat is a file who's header is set to BIN.

Ode thinks this is a binary file, so it will not let you do the usual
text based operations on it such as rdiff, diff, edit.  You essentially
have two choices, co or rco.  The co option forces bsubmit to use the current
version in the submit tree.  rco will force it to use your version.  You want
to choose the rco option here so that your changes will be put into the file.

John

40.10submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Dec 21 1993 11:1433
Date Of Receipt: 	13-DEC-1993 15:11:32.87
From: 	QUARRY::pderr "Peter Derr USG  13-Dec-1993 1033"
To: 	odehelp@DEC:.zko.quarry
CC: 	
Subj: 	submit problem

Hi,

I had this problem submitting to agxminor.kitbld.  What's wrong?

Thanks,
Peter

> bsubmit -defect agxminor-2250-pderr -noauto_out ddif_wgt.uid
Retrying connection to trap.zk3.dec.com: retry number 1
No longer using cached authorization

*** No user interaction will be required during the merge step. ***

[ ./motif/compat/motif1.1.3/ddif_wgt.uid checked in onto branch 1.1.4 ]
[ ./motif/compat/motif1.1.3/ddif_wgt.uid Rev 1.1.4.2 checked out ]
kxct: Invalid kxct config: /usr/build/osf1/agxminor.kitbld/src/kxct.conf

read failed: No such file or directory

Please take appropriate steps and re-submit.

*** RE-SUBMISSION REQUIRED ***

- Source control information is in an intermediate state.
- Re-submit using -resub 10:31 [ -date 12/13/93 ]


40.11Re: submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Dec 21 1993 11:1823
Date Of Receipt: 	13-DEC-1993 16:46:57.66
From: 	US2RMC::"[email protected]" "John Flanagan"
To: 	"Peter Derr" <[email protected]>
CC: 	[email protected], [email protected]
Subj: 	Re: submit problem

Peter,

Try it again...

John

% Received: 	by us2rmc.bb.dec.com; id AA01240; Mon, 13 Dec 93 12:18:39 -0500
	by inet-gw-1.pa.dec.com; id AA18436; Mon, 13 Dec 93 07:44:16 -0800
	from localhost by flambe.zk3.dec.com; (5.65/1.1.8.2/01Nov93-1038AM) id AA07692; Mon, 13 Dec 1993 10:42:57 -050
% Message-Id: 	<[email protected]>
% To: 	"Peter Derr" <[email protected]>
% Cc: 	[email protected], [email protected]
% Subject: 	Re: submit problem
% In-Reply-To: 	Your message of "Mon, 13 Dec 93 10:33:54 EST." <[email protected]>
% Date: 	Mon, 13 Dec 93 10:42:57 -0500
% From: 	John Flanagan <[email protected]>
% X-Mts: 	smtp
40.12Re: submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Dec 21 1993 11:3435
Date Of Receipt: 	13-DEC-1993 16:47:51.38
From: 	US2RMC::"[email protected]" "Peter Derr"
To: 	John Flanagan <[email protected]>
CC: 	[email protected]
Subj: 	Re: submit problem

Thanks, John.  It worked.

Peter

----------------------------------------------------------------------------
To:      "Peter Derr" <[email protected]>
cc:      [email protected], [email protected]
Subject: Re: submit problem  



Peter,

Try it again...

John

% Received: 	by us2rmc.bb.dec.com; id AA01780; Mon, 13 Dec 93 12:21:01 -0500
	by inet-gw-1.pa.dec.com; id AA18563; Mon, 13 Dec 93 07:45:43 -0800
	from quarry.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/01Nov93-1038AM) id AA07717; Mon, 13 Dec 1993 10:44:31 -050
	by quarry.zk3.dec.com; id AA09443; Mon, 13 Dec 1993 10:44:35 -0500
% Message-Id: 	<[email protected]>
% To: 	John Flanagan <[email protected]>
% Cc: 	[email protected]
% Subject: 	Re: submit problem
% In-Reply-To: 	Your message of "Mon, 13 Dec 93 10:42:57 EST." <[email protected]>
% Date: 	Mon, 13 Dec 93 10:44:35 -0500
% From: 	"Peter Derr" <[email protected]>
% X-Mts: 	smtp
40.13submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Mar 22 1994 15:3543
Date Of Receipt: 	22-MAR-1994 14:51:29.29
From: 	WASTED::dibble "Ben Dibble"
To: 	odehelp@wasted:zko.dec
CC: 	
Subj: 	submit problem

I am attempting to submit to v13supportos pool.  When I do, I get the following
error:

V2.0 mogur:50> bsubmit -verbose kern_fork.c
Enter the defect number this submission applies to: v13supportos-7-dibble

>  build to submit to is: v13supportos.
>  Time is: 13:59; date is: 3/22/94.
>> WARNING in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> current directory not in source base: /usr/work1/osf_13/src.
>  cd'ing to sandbox source directory: /usr/work1/osf_13/src.
>  checking for lock on build: /usr/sde/osf1/build/v13supportos/src/.BCSlock
>  checking access control list on submit>  Checking environment...
>  Submitting the following files:
>  ./kern_fork.c
>  have lock on hold file.
>  checking HOLD file: 13:59.Thold /usr/sde/osf1/build/v13supportos/logs/bsubmit
.hold
>  found no holds on files being submitted.
>  added 1 files to the hold list.
>  Validating submission...
rlog error: ./RCS/kern_fork.c,v: No such file or directory
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> rlog command failed
>  cleaning up hold file; removing entries.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.

Can you help?  
Ben
---
Dictated using Dragon Dictate (Voice Recognition)

40.14Re: submit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Mar 22 1994 15:3666
Date Of Receipt: 	22-MAR-1994 15:33:30.65
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE"
To: 	dibble@wasted:zko.dec
CC: 	odehelp@wasted:zko.dec
Subj: 	Re:  submit problem

what do you get from 'pwd' and 'dirs' (if csh) from the directory where
you're submitting?  What's the value of "sandbox_base" in your sandbox's
rc_files/shared file ?   Did you do any manual setup of your sandbox,
or just "workon -sb name" or "resb name" ?

thanks...	-josh


--------
From dibble  Tue Mar 22 14:51:06 1994
Delivery-Date: Tue, 22 Mar 94 14:51:10 -0500
Return-Path: dibble
Received: from wasted.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/04Mar94-1219PM)
	id AA14077; Tue, 22 Mar 1994 14:51:06 -0500
Received: by wasted.zk3.dec.com; id AA22096; Tue, 22 Mar 1994 14:50:40 -0500
Date: Tue, 22 Mar 1994 14:50:40 -0500
From: Ben Dibble <dibble>
Message-Id: <[email protected]>
To: odehelp
Subject: submit problem


I am attempting to submit to v13supportos pool.  When I do, I get the following
error:

V2.0 mogur:50> bsubmit -verbose kern_fork.c
Enter the defect number this submission applies to: v13supportos-7-dibble

>  build to submit to is: v13supportos.
>  Time is: 13:59; date is: 3/22/94.
>> WARNING in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> current directory not in source base: /usr/work1/osf_13/src.
>  cd'ing to sandbox source directory: /usr/work1/osf_13/src.
>  checking for lock on build: /usr/sde/osf1/build/v13supportos/src/.BCSlock
>  checking access control list on submit>  Checking environment...
>  Submitting the following files:
>  ./kern_fork.c
>  have lock on hold file.
>  checking HOLD file: 13:59.Thold /usr/sde/osf1/build/v13supportos/logs/bsubmit
.hold
>  found no holds on files being submitted.
>  added 1 files to the hold list.
>  Validating submission...
rlog error: ./RCS/kern_fork.c,v: No such file or directory
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> rlog command failed
>  cleaning up hold file; removing entries.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.

Can you help?  
Ben
---
Dictated using Dragon Dictate (Voice Recognition)


40.15bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 03 1994 15:1920
Date Of Receipt: 	 1-JUN-1994 17:18:59.84
From: 	GURU::chapman "Olif Benson Chapman USG  01-Jun-1994 1718"
To: 	[email protected]
CC: 	
Subj: 	bsubmit problem

% bsubmit tcp_output.c
Enter the defect number this submission applies to:  v20supportos-75-chapman

rlog error: ./RCS/tcp_output.c,v: No such file or directory
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> rlog command failed

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.
                                                

40.16Re: bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 03 1994 15:2444
Date Of Receipt: 	 1-JUN-1994 17:37:55.89
From: 	WASTED::jmf "Joshua M. Friedman OSF/UNIX SDE  01-Jun-1994 1737"
To: 	chapman@DEC:.zko.wasted
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: bsubmit problem

Are you sure you're in the right directory?  It says the file tcp_output.c
doesn't exist in the pool.    Either use a full path or be in the right
directory.  Hopefully that's the problem.

(You can also use bsubmit -all if that's the only file you've got in your set)

-josh

--------
Return-Path: chapman 
Delivery-Date: Wed, 01 Jun 94 17:22:47 -0400
Return-Path: chapman
Received: from guru.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM)
	id AA22524; Wed, 1 Jun 1994 17:22:45 -0400
Received: by guru.zk3.dec.com; id AA29002; Wed, 1 Jun 1994 17:18:26 -0400
Message-Id: <[email protected]>
To: odehelp
Subject: bsubmit problem
Date: Wed, 01 Jun 94 17:18:26 -0400
From: chapman
X-Mts: smtp


% bsubmit tcp_output.c
Enter the defect number this submission applies to:  v20supportos-75-chapman

rlog error: ./RCS/tcp_output.c,v: No such file or directory
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> rlog command failed

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.
                                                


40.17Re: bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 03 1994 15:4084
Date Of Receipt: 	 2-JUN-1994 08:46:50.51
From: 	WASTED::chapman "Olif Benson Chapman USG  02-Jun-1994 0846"
To: 	[email protected]
CC: 	metsch@DEC:.zko.wasted, [email protected]
Subj: 	Re: bsubmit problem

Josh,

I tried it again, insuring that I was in the same directory as "tcp_output.c",
and things are different. The session below says "Submission completed 
successfully." but, the pool copy and the submitted copy differ.

Is this appropriate? I will mail /files/sandboxes/kqc2/src/8:28.Tlog as
a seperate piece.

Thank You for your help with this,
obc

*********** Transcript of session included below ******************

% bsubmit tcp_output.c
Enter the defect number this submission applies to:  v20supportos-75-chapman

no authorization to access the server: Generic kerberos error (kfailure)
kxct: Kerberos error: Ticket expired (krb_rd_req)

No longer using cached authorization
% kinit Olif_Chapman
Kerberos Initialization for "Olif_Chapman"
Password:
% bsubmit tcp_output.c
Enter the defect number this submission applies to: v20supportos-75-chapman


*** No user interaction will be required during the merge step. ***

[ ./kernel/netinet/tcp_output.c checked in onto branch 4.3.14 ]
[ ./kernel/netinet/tcp_output.c Rev 4.3.14.2 checked out ]

*** Please mail the log, /files/sandboxes/kqc2/src/8:28.Tlog,
*** to the appropriate people in your project then remove.

Outdate the submitted files from set Olif_Chapman_kqc2?
Outdate files?: [Yes] no

Submission completed successfully.
%what tcp_output.c
tcp_output.c:
        $RCSfile: tcp_output.c,v $ $Revision: 4.3.14.2 $ (DEC) $Date: 1994/06/02
 12:28:57 $
% mv tcp_output.c tcp_output.c_jic.sav
% mklinks .

Linking directory subtree:
  From: /files/sandboxes/kqc2/link/src/kernel/netinet/.
  To:   /files/sandboxes/kqc2/src/kernel/netinet/.

% diff tcp_output.c tcp_output.c_jic.sav
6a7,10
>  * Revision 4.3.14.2  1994/06/02  12:28:57  Olif_Chapman
>  *    cast (tp->rcv_adv - tp->rcv_nxt) as an int to avoid tcp window from goin
g negative
>  *    [1994/05/31  19:00:07  Olif_Chapman]
>  *
10c14
<  *
---
>  *
32c36
< static char   *sccsid = "@(#)$RCSfile: tcp_output.c,v $ $Revision: 4.3.5.2 $ (
DEC) $Date: 1993/05/16 21:33:28 $";
---
> static char   *sccsid = "@(#)$RCSfile: tcp_output.c,v $ $Revision: 4.3.14.2 $
(DEC) $Date: 1994/06/02 12:28:57 $";
438,439c442,443
<       if (win < (long)(tp->rcv_adv - tp->rcv_nxt))
<               win = (long)(tp->rcv_adv - tp->rcv_nxt);
---
>       if (win < (long)((int)(tp->rcv_adv - tp->rcv_nxt)))
>               win = (long)((int)(tp->rcv_adv - tp->rcv_nxt));
%

****************** End Session **********************

40.18Re: bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 03 1994 15:4229
Date Of Receipt: 	 2-JUN-1994 08:47:25.86
From: 	WASTED::chapman "Olif Benson Chapman USG  02-Jun-1994 0846"
To: 	[email protected]
CC: 	metsch@DEC:.zko.wasted, [email protected]
Subj: 	Re: bsubmit problem
***************** /files/sandboxes/kqc2/src/8: 	28.Tlog **********************
% file /files/sandboxes/kqc2/src/8: 	28.Tlog
/files/sandboxes/kqc2/src/8: 	28.Tlog:    ascii text
% m /files/sandboxes/kqc2/src/8: 	28.Tlog

Submission Log *****

  Submitted by Olif_Chapman; User name: chapman; Node name: cog.zk3.dec.com
  Date: 6/2/94; Time: 8:28
  Coordinated Universal Time: 06/02/94 12:28:29 GMT
  Number of files: 1; Defect number: v20supportos-75-chapman.
  Set name: Olif_Chapman_kqc2; Sandbox: /files/sandboxes/kqc2
  List of files and revisions:
./kernel/netinet/tcp_output.c,v 4.3.14.2

  Detailed description:

[ ./kernel/netinet/tcp_output.c ]
cast (tp->rcv_adv - tp->rcv_nxt) as an int to avoid tcp window from going negati
ve
[1994/05/31  19:00:07  Olif_Chapman]

End Log *****

40.19bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 10 1994 12:4620
Date Of Receipt: 	10-JUN-1994 11:01:39.10
From: 	WASTED::kate "Kate Baumgartner Lowrie USG  10-Jun-1994 1100"
To: 	odehelp@DEC:.zko.wasted
CC: 	kate@DEC:.zko.wasted
Subj: 	bsubmit problem

I tried to bsubmit this morning, and this is what happened.
What am I doing wrong?

Thanks,
Kate

[kate.squash.kernel] bsubmit -all
Enter the defect number this submission applies to: goldos-3068-kate

>> FATAL ERROR in /usr/sde/tools/alpha_ace/bin/ode/bsubmit:
        could not read build's rc file: /usr/sde/osf1/build/goldos/.sandboxrc
[kate.squash.kernel]


40.20Re: bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckFri Jun 10 1994 18:3249
Date Of Receipt: 	10-JUN-1994 16:49:57.79
From: 	FLAMBE::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	kate@DEC:.zko.flambe
CC: 	odehelp@DEC:.zko.flambe
Subj: 	Re:  bsubmit problem

Kate, it just looks like you don't have the goldos submit tree
mounted.

	# /usr/sde/odemount goldos

Should take care of this...		-josh


------
From [email protected]  Fri Jun 10 11:01:22 1994
Delivery-Date: Fri, 10 Jun 94 11:01:24 -0400
Return-Path: [email protected]
Received: from abelia.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM)
	id AA09889; Fri, 10 Jun 1994 11:01:22 -0400
Received: from squash.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/26May94-1021AM)
	id AA26978; Fri, 10 Jun 1994 11:00:54 -0400
Received: from localhost by squash.zk3.dec.com; (5.65/1.1.8.2/06Jun94-0933AM)
	id AA25159; Fri, 10 Jun 1994 11:00:54 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: bsubmit problem
Date: Fri, 10 Jun 94 11:00:53 -0400
From: [email protected]
X-Mts: smtp


I tried to bsubmit this morning, and this is what happened.
What am I doing wrong?

Thanks,
Kate

[kate.squash.kernel] bsubmit -all
Enter the defect number this submission applies to: goldos-3068-kate

>> FATAL ERROR in /usr/sde/tools/alpha_ace/bin/ode/bsubmit:
	could not read build's rc file: /usr/sde/osf1/build/goldos/.sandboxrc
[kate.squash.kernel]




40.21bsubmit problemSMURF::FILTERAutomatic Posting Software - mail to flume::puckTue Jun 21 1994 19:1919
Date Of Receipt: 	17-JUN-1994 14:27:45.75
From: 	RAVINE::wolklin "Tom Wolklin OSG DOC"
To: 	RAVINE::buildhelp
CC: 	
Subj: 	bsubmit problem

Hi,

I received the following error when trying to bsubmit the network configuration
worksheet.  I was able to bci the file OK and then got this error:

  >> FATAL ERROR in /usr/sde/ode2.0/tools/pmax_ultrix/bin/ode/bsubmit:
        could not read build's rc file: /usr/sde/osf1/build/goldos/.sandboxrc

Anyone know what the problem is or should I contact someone else?

Thanks,
Tom

40.22Help!SMURF::FILTERAutomatic Posting Software - mail to flume::puckThu Jul 14 1994 15:02148
Date Of Receipt: 	14-JUL-1994 12:36:52.13
From: 	ALPHA::tom "Tom Atkocaitis USG  14-Jul-1994 1235"
To: 	odehelp@DEC:.zko.alpha
CC: 	tom@DEC:.zko.alpha
Subj: 	Help!

In trying to do a build of goldos.nightly, more specifically, for
code coverage instrumentation purposes, I can't get even a basic 'build'
to start.

I have a workon, etc.  I've have -dironly links to /obj and /src made.
I have done odemount.  All other mounts are made -- I can see the source
pool, and all the links to my sandbox are in effect.

My PATH is

/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/hostbin:/usr/sde/osf1
/build/goldos.nightly0/tools/alpha_OSF1/alpha/bin:/usr/sde/osf1/build/goldos.nig
htly0/tools/alpha_OSF1/alpha/acc:/usr/sde/osf1/build/goldos.nightly0/tools/alpha
_OSF1/alpha/hostbin:/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/b
in:/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/acc:/usr/sde/ode2.
0/tools/alpha_ace/bin:/usr/ucb:/bin:/usr/bin:/sbin:/usr/sbin

But!

# cd /rz11c/sandboxes/goldos/src/kernel
# build
relative path: ./kernel.
Make: No such directory: ../obj.  Stop.

Note:

# ls -l obj
lrwxrwxrwx   1 root     system        22 Jul 14 11:22 obj -> 
../../obj/alpha/kernel

Any thoughts?  What have I missed?

thanks,

/t

ps - here's my environment:

A_OUT_GCC_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha
/gcc/
BACKED_PATH=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/hostbin:/
usr/sde/osf1/build/g
oldos.nightly0/tools/alpha_OSF1/alpha/bin:/usr/sde/osf1/build/goldos.nightly0/to
ols/alpha_OSF1/alpha
/acc:/usr/sde/ode2.0/tools/alpha_ace/bin:/usr/ucb:/bin:/usr/bin:/sbin:/usr/sbin
BACKED_SOURCEDIR=/rz11c/sandboxes/goldos/src:/usr/sde/osf1/build/goldos.nightly0
/src
BCSDIRECTORY=/usr/sde/ode2.0
BCSHEADERS=/usr/sde/alpha/headers
BCSPORT=548
[email protected],[email protected],[email protected]
k3.dec.com
CC_SUITE=ACC
COFF_ACC_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/
acc/
COFF_GCC_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/
gcc/
COFF_MCC_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/
mcc/
COMP_HOST_ROOT=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/acc
COMP_HOST_ROOT_M64=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/mc
c/
COMP_TARGET_ROOT=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/acc
COMP_TARGET_ROOT_M64=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/
mcc/
C_COMPILER=cc
DISPLAY=:0.0
EDITOR=vi
EXPORTBASE=/rz11c/sandboxes/goldos/export/alpha
GROUP=bin
HOME=/
INCDIRS=-I/rz11c/sandboxes/goldos/export/alpha/usr/include 
-I/usr/sde/osf1/build/goldos.nightly0/exp
ort/alpha/usr/include
LANG=
LATEST=ALPHA;<99/12/31,23:59:59
LEXER=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/lib/ncform
LIBDIRS=-L/rz11c/sandboxes/goldos/export/alpha/usr/ccs/lib 
-L/usr/sde/osf1/build/goldos.nightly0/exp
ort/alpha/usr/ccs/lib
LOGNAME=root
MACHO_GCC_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha
/macho/
MAKEFILEPATH=${MAKETOP}/usr/lib/makefiles
MIGCOM=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/hostbin/migcom
NEW=GOLDOS;AGOSMINOR_BL9;AGOSMAINT_BL6;alpha_bl012;<>
OBJECTDIR=../obj/alpha
OBJECT_FORMAT=COFF
OWNER=bin
PATH=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/hostbin:/usr/sde
/osf1/build/goldos.n
ightly0/tools/alpha_OSF1/alpha/bin:/usr/sde/osf1/build/goldos.nightly0/tools/alp
ha_OSF1/alpha/acc:/u
sr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/hostbin:/usr/sde/osf1/b
uild/goldos.nightly0
/tools/alpha_OSF1/alpha/bin:/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1
/alpha/acc:/usr/sde/
ode2.0/tools/alpha_ace/bin:/usr/ucb:/bin:/usr/bin:/sbin:/usr/sbin
PRINCIPAL=Tom_Atkocaitis
PROJECT_NAME=ALPHA
RELEASE_OPTIONS=-idfile `genloc /src/setup/osf1_idlist`
SANDBOX=goldos
SHELL=/bin/sh
SHLIBDIRS=-L/rz11c/sandboxes/goldos/export/alpha/usr/shlib 
-L/usr/sde/osf1/build/goldos.nightly0/exp
ort/alpha/usr/shlib
SITE=OSF
SOURCEBASE=/rz11c/sandboxes/goldos/src
SOURCEDIR=/usr/sde/osf1/build/goldos.nightly0/src
SUBMIT_REVIEW=/usr/sde/osf1/submit_review
TARGET_EXEC_PREFIX=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/ho
stbin/
TARGET_MACHINE=ALPHA
TARGET_OS_TYPE=OSF1
TERM=xterm
TERMCAP=vs|xterm|vs100|xterm terminal emulator (X window system):       
:do=^J:le=^H:ho=\E[H:   :co#
80:li#24:cl=\E[H\E[2J:bs:am:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:     
:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us
=\E[4m:ue=\E[m: :md=\E[1m:mr=\E[7m:me=\E[m:     
:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H: :k1=\EOP:k2=
\EOQ:k3=\EOR:k4=\EOS:pt:sf=\n:sr=\EM:   :al=\E[L:dl=\E[M:ic=\E[@:dc=\E[P:       
:MT:ks=\E[?1h\E=:ke=
\E[?1l\E>:xn:   :AL=\E[%dL:DL=\E[%dM:IC=\E[%d@:DC=\E[%dP:       
:hs:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds
=\E[?E: :is=\E\E[m\E[?7h\E[?1;4l:cs=\E[%i%d;%dr:        
:rs=\E[r\E<\E[m\E[H\E[2J\E[?7h\E[?1;3;4;6l:
ULT_INCDIRS=-I/usr/include
ULT_LIBDIRS=-L/usr/lib -L/lib
USER=root
WINDOWID=50331661
WORKON=1
YACCPAR=/usr/sde/osf1/build/goldos.nightly0/tools/alpha_OSF1/alpha/lib/yaccpar
cc_suite=acc
host_machine=alpha
host_os_type=OSF1
machine=alpha
project_name=alpha
submit_defect_check=true
target_machine=alpha
target_os_type=osf1

40.23Re: Help!SMURF::FILTERAutomatic Posting Software - mail to flume::puckThu Jul 14 1994 15:0319
Date Of Receipt: 	14-JUL-1994 13:04:45.10
From: 	FLUME::jmcg "Jim McGinness"
To: 	[email protected]
CC: 	buildhelp@DEC:.zko.flume
Subj: 	Re:  Help!
There are a couple of things that don't quite seem right: 	

1) I don't think you want a -dironly link to /obj if you are attempting
to do a build.

2) It doesn't seem right to have a link named obj pointing to a directory
named kernel.

If you would let slip which node /rz11c/sandboxes lives on and if it
were possible for someone to either log in there or nfs mount the
file system, I could probably give you a more definitive diagnosis.

	-- jmcg

40.24Submit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckMon Feb 20 1995 16:5134
Date Of Receipt: 	17-FEB-1995 00:14:00.62
From: 	SMURF::WASTED::"[email protected]" "17-Feb-1995 0012"
To: 	[email protected]
CC: 	
Subj: 	Submit problem

Hi,

This problem occurs whenever anyone submits to a shared sandbox
which used to work before.  The submit (and resubmit) fails with the 
following:

	$ bsubmit -resub 23:59 --date-2/16/95--defectddeltacde-63-alaa
	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
	>> source_cover line missing in sandbox rc file.
	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
	>> source_host line missing in sandbox rc file.
	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
	>> source_owner line missing in sandbox rc file.
	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
	>> source_testdir line missing in sandbox rc file.
	[ ./admin/build/test.file Rev 1.1.2.2 checked out ]

	Please take appropriate steps and re-submit.

	*** RE-SUBMISSION REQUIRED ***

	- Source control information is in an intermediate state.
	- Re-submit using -resub 23:59 [ -date 2/16/95 ]

Thanks,

- Alaa

40.25Re: Submit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckMon Feb 20 1995 16:5247
Date Of Receipt: 	17-FEB-1995 09:20:58.55
From: 	SMURF::FLAMBE::"[email protected]" "17-Feb-1995 0919"
To: 	[email protected]
CC: 	
Subj: 	Re: Submit problem

Hi,

I have found the problem.  The sb line in the .sandboxrc file of the shared
sandbox was missing the local.sharedsandbox line.

Thanks,

- Alaa
 
----------------
>From:  "Alaa Zeineldine (908) 577 6014" <alaa>
>To:  alaa
>
>Hi,
>
>This problem occurs whenever anyone submits to a shared sandbox
>which used to work before.  The submit (and resubmit) fails with the 
>following:
>
>	$ bsubmit -resub 23:59 --date-2/16/95--defectddeltacde-63-alaa
>	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
>	>> source_cover line missing in sandbox rc file.
>	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
>	>> source_host line missing in sandbox rc file.
>	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
>	>> source_owner line missing in sandbox rc file.
>	>> WARNING in /usr/sde/ode2.1/tools/alpha_OSF1/bin/ode/bsubmit:
>	>> source_testdir line missing in sandbox rc file.
>	[ ./admin/build/test.file Rev 1.1.2.2 checked out ]
>
>	Please take appropriate steps and re-submit.
>
>	*** RE-SUBMISSION REQUIRED ***
>
>	- Source control information is in an intermediate state.
>	- Re-submit using -resub 23:59 [ -date 2/16/95 ]
>
>Thanks,
>
>- Alaa

40.26bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:0430
Date Of Receipt: 	14-APR-1995 11:50:18.68
From: 	SMURF::WASTED::tmark "TIM MARK USG  14-Apr-1995 1149"
To: 	odehelp@DEC:.zko.wasted
CC: 	
Subj: 	bsubmit problem

Hi.

I'm having a problem with bsubmit:

% bsubmit -auto -auto_out -defect ptos-1173-tmark vquot.c vquot.msg

*** No user interaction will be required during the merge step. ***

getwd: getwd: can't open ..
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> Unable to parse sandbox
Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.

I have done an odemount of ptos.  I am backed against ptos.nightly.  The 
permissions on my sandbox directory are 755.

Any help would be appreciated.

Tim

40.27Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:0541
Date Of Receipt: 	14-APR-1995 12:10:08.79
From: 	SMURF::WASTED::"[email protected]" "14-Apr-1995 1208"
To: 	[email protected]
CC: 	[email protected]
Subj: 	Re: bsubmit problem

Have you done an odemount of ptos.nightly? It's your sandbox it's complaining 
about. Also what directory were you in when you tried this?

Try doing an odemount -v ptos.nightly - just to make sure you have all the 
required mounts. Then a new workon and cd to usr/sbin/vquot and try again.


	-Grant


| Hi.
| 
| I'm having a problem with bsubmit:
| 
| % bsubmit -auto -auto_out -defect ptos-1173-tmark vquot.c vquot.msg
| 
| *** No user interaction will be required during the merge step. ***
| 
| getwd: getwd: can't open ..
| >> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
| >> Unable to parse sandbox
| Please take appropriate steps and run bsubmit again.
| - No work has been done for this submission.
| - No files have been changed in any way.
| - The files in this submission are not held.
| - The use of the -resub option is not required and will not be recognized.
| 
| I have done an odemount of ptos.  I am backed against ptos.nightly.  The 
| permissions on my sandbox directory are 755.
| 
| Any help would be appreciated.
| 
| Tim


40.28Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:0613
Date Of Receipt: 	14-APR-1995 12:13:52.89
From: 	SMURF::WASTED::tmark "TIM MARK USG  14-Apr-1995 1212"
To: 	"Grant Van Dyck" <[email protected]>
CC: 	[email protected], [email protected]
Subj: 	Re: bsubmit problem

Grant,

I did as you suggested but the problem still occurs.
Any other thoughts?

Tim

40.29Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:1626
Date Of Receipt: 	14-APR-1995 13:32:58.61
From: 	SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group  14-Apr-1995 1331"
To: 	tmark@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: bsubmit problem

Tim,

Can you try this again with the -debug flag with bsubmit?

Thanks,

John


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flambe::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________



40.30Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:1628
Date Of Receipt: 	14-APR-1995 13:50:47.29
From: 	SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group  14-Apr-1995 1349"
To: 	tmark@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: bsubmit problem

Tim,

Are you working in a sandbox that is remotely mounted from another machine?
I've seen this error when you are working in a remotely mounted sandbox.

For example, you've mounted flume:~tmark/sandboxes onto a local file system
on your workstation...ode can't cd above the mountpoint to do the submit...

Is this the case?


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flambe::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________



40.31Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:2456
Date Of Receipt: 	14-APR-1995 14:22:33.06
From: 	SMURF::WASTED::tmark "TIM MARK USG  14-Apr-1995 1421"
To: 	John Flanagan - UNIX Systems Group <johnf@DEC:.zko.wasted>
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: bsubmit problem

John,

I am working on a local sandbox, not a remotely-mounted one.
Here is the output from the -debug run of bsubmit, starting after
bsubmit determines that no merge will be needed:


*** No user interaction will be required during the merge step. ***

>> DEBUG INFO in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> Leaving validate_submission
>> DEBUG INFO in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> Entering sci_trackfile
>> DEBUG INFO in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> Leaving sci_trackfile
>> DEBUG INFO in current_sb:
>> sb name is in rc file.  Name is: ptos.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/sde/osf1/build.
>> DEBUG INFO in current_sb:
>> Found sandbox rc file in usr rcfile. File is: local.sharedsandbox.
getwd: getwd: can't open ..
>> FATAL ERROR in /usr/sde/ode2.0/tools/alpha_ace/bin/ode/bsubmit:
>> Unable to parse sandbox>  cleaning up hold file; removing entries.
>> DEBUG INFO in ui_init:
>> Contents of interface table:
>> 6 : -noauto: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 8 : -auto: maxe=1; dup=0; mina=0; maxa=0; a=.
>>     e=-auto; numa=0; nume=1.
>> 20: -sb_rc: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>> 25: !-*: maxe=2; dup=0; mina=0; maxa=0; a=.
>>     e=: Tim_Mark; Date: 4/14/95; Time: 14:13; numa=0; nume=1.
>> 26: -rc: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>> 42: -info: maxe=1; dup=0; mina=0; maxa=0; a=.
>> vl=7; ap=8; ip=42.
>> DEBUG INFO in holdcleanup:
>> Arg is: : Tim_Mark; Date: 4/14/95; Time: 14:13.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.


Hope this helps.

Tim
                                                                

40.32Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Apr 18 1995 21:2723
Date Of Receipt: 	14-APR-1995 14:53:34.65
From: 	SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group  14-Apr-1995 1452"
To: 	odehelp@DEC:.zko.flume
CC: 	John Flanagan - UNIX Systems Group <johnf@DEC:.zko.flume>,
	tmark@DEC:.zko.flume
Subj: 	Re: bsubmit problem

Fyi, Tim's all set.  He wasn't in group staff.

John


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flambe::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________



40.33submit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jun 01 1995 18:1642
Date Of Receipt: 	 1-JUN-1995 16:12:59.18
From: 	SMURF::WASTED::"[email protected]" "01-Jun-1995 1611"
To: 	[email protected]
CC: 	[email protected]
Subj: 	submit problem

I have been trying to do a submit to the clustwav3dx pool since last Friday 
(5/26) without success. I started this on Friday. There were network problems 
and when I did a bsubmit it would error about not connecting to either darla or 
odie and then fail. The command I was using was;

            bsubmit -all -auto -auto_out

Finally it started without errors but it printed nothing up until the time I 
went home. When I came in Monday my system had robooted due to pawer problems. I 
checked the files and saw they were not in the tree. I then reentered the 
bsubmit command. It told me that the files were locked and I should do a:

            bsubmit -resub 15:20 -date 5/26

So I did. It now got to the point where it had checking a little more then half 
the files and hung again. I was told to cntl-c it and start do a resubmit. I did 
this and got the following error: 

>> FATAL ERROR in /usr/sde/ode2.1/tools/alpha_ace/bin/ode/bsubmit:
>> stat ./motif/clients/cmon/rmnew.xpm 

Please take appropriate steps and re-submit.

*** RE-SUBMISSION REQUIRED ***
.BCSconfig
- Source control information is in an intermediate state.
- Re-submit using -resub 15:20 [ -date 5/26/95 ]

This was the file it had hung on. I was told to remove this file from the 
.BCSset_Howard_Rifkin_clustwav3dx file and the .BCSconfig file. I did this. Now 
when I do the bsubmit -resub it asks for the defect number and then hangs.

Help!

Howard

40.34bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jan 11 1996 15:5737
Date Of Receipt: 	11-JAN-1996 15:21:27.72
From: 	SMURF::ALPHA::tomp "Tom Peterson USG  11-Jan-1996 1519"
To: 	odehelp@DEC:.zko.alpha
CC: 	tomp@DEC:.zko.alpha
Subj: 	bsubmit problem

Hello,

I'm trying to bsubmit from a sandbox backed by ptos and am seeing
the following error:

$ bsubmit -all
Enter the defect number this submission applies to: ptos-4384-tomp

>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> No information for ./usr/ccs/lib/libc/alpha/alloca.c in .BCSconfig file.
>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> No information for ./usr/ccs/lib/libc/alpha/machdep.mk in .BCSconfig file.
>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> No information for ./usr/include/alpha/alloca.h in .BCSconfig file.
>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> No information for ./usr/include/c_asm.h in .BCSconfig file.
>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> No information for ./usr/shlib/libc/alpha/machdep.mk in .BCSconfig file.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.


I had no trouble with another submit to ptos just before this from
a different sandbox.  Thanks in advance for your help with this.

- Tom

40.35Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jan 11 1996 16:0322
Date Of Receipt: 	11-JAN-1996 15:28:16.32
From: 	SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group  11-Jan-1996 1525"
To: 	Tom Peterson (USG) <tomp@DEC:.zko.flume>
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: bsubmit problem

This would imply that you don't have these files in your sandbox, or that
they haven't been bco'ed or bci'd.


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flume::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________




40.36Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jan 11 1996 16:1737
Date Of Receipt: 	11-JAN-1996 15:34:26.96
From: 	SMURF::ALPHA::tomp "Tom Peterson USG  11-Jan-1996 1532"
To: 	johnf@DEC:.zko.alpha
CC: 	odehelp@DEC:.zko.alpha
Subj: 	Re: bsubmit problem

$ bstat -all

[ ./usr/ccs/lib/libc/alpha/alloca.c ]
version 1.2.10.2 selected

[ ./usr/ccs/lib/libc/alpha/machdep.mk ]
version 1.2.36.2 selected

[ ./usr/include/alpha/alloca.h ]
version 1.1.5.2 selected

[ ./usr/include/c_asm.h ]
version 1.1.9.2 selected

[ ./usr/shlib/libc/alpha/machdep.mk ]
version 1.1.28.2 selected

$ more .BCSset-Thomas_Peterson_cxx9
./usr/ccs/lib/libc/alpha/alloca.c
./usr/ccs/lib/libc/alpha/machdep.mk
./usr/include/alpha/alloca.h
./usr/include/c_asm.h
./usr/shlib/libc/alpha/machdep.mk
$
$ ls -l `cat .BCSset-Thomas_Peterson_cxx9`
-r--r--r--   1 tomp     staff       7052 Jan  5 12:04 ./usr/ccs/lib/libc/alpha/alloca.c
-r--r--r--   1 tomp     staff      20402 Jan  5 11:37 ./usr/ccs/lib/libc/alpha/machdep.mk
-r--r--r--   1 tomp     staff       3426 Jan  5 12:01 ./usr/include/alpha/alloca.h
-r--r--r--   1 tomp     staff       6864 Jan  5 11:11 ./usr/include/c_asm.h
-r--r--r--   1 tomp     staff      15894 Jan  5 12:06 ./usr/shlib/libc/alpha/machdep.mk

40.37Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jan 11 1996 17:3750
Date Of Receipt: 	11-JAN-1996 16:43:04.52
From: 	SMURF::WASTED::jmf "Joshua M. Friedman OSF/UNIX SDE  11-Jan-1996 1640"
To: 	Tom Peterson (USG) <tomp@DEC:.zko.wasted>
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: bsubmit problem

Tom,

The setname you've shown in this case is Thomas_Peterson_cxx9, which
means the setname you used is cxx9; this may or may not be your sandbox
name, that doesn't matter.  What does matter, however, is that this
setname is unique amongst all your sandboxes.

By any chance do you have a 'cxx9' set in any other sandbox(es)?  If
so, then in the sandbox in which the first check-out was done to a cxx9
set, you've got a .BCSset-Thomas_Peterson_cxx9 file, and you also have
the .BCSconfig file entries for those check-outs.

Subsequent bco's in another sandbox with the same setname should be blocked
by ODE, but this is not in the current functionality.  Instead it just
gets your own private cxx9 version, and it assumes that no new .BCSconfig
entry is needed.  This could be the case here; if so, then you need to
be very careful if you care about work in different cxx9 sets, since they
all share a single RCS configuration (branch).

This has been reported and will be fixed at some point, but if this is
the case here, then when you do any bco's or outdates of any files in
one cxx9 set, it really applies to the file in all/any sandboxes which
share the same setname.

Regarding the "sandboxes sucked dry" problem, no there is no such thing
as timeouts or automatic cleanups, except as I noted above; if you
outdate a file in a set in one sandbox, that private rev of the file
will now be inaccessible via ode "b*" commands in other sandboxes with
the same set.  

In this case, if you bci'd the files and then they got removed from
your sandbox, a "bco -u" from the same sandbox/set will restore them,
and, presuming they are still listed in your .BCSset-*/.BCSconfig
files, everything will work as it originally did.  Note that ode also
has a notion of a "default" sandbox (listed at the top of
~/.sandboxrc); if this sandbox or its backing tree are not mounted,
you'll get errors which are really warnings when it attempts to
reference your default sandbox (which is does when you do a mksb).  I
recommend you update your default (just edit the file) to something
current that you really use and is mounted.

-josh


40.38Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Jan 11 1996 17:4059
Date Of Receipt: 	11-JAN-1996 17:00:17.30
From: 	SMURF::WASTED::tomp "Tom Peterson USG  11-Jan-1996 1658"
To: 	jmf@DEC:.zko.wasted
CC: 	odehelp@DEC:.zko.wasted
Subj: 	Re: bsubmit problem

> By any chance do you have a 'cxx9' set in any other sandbox(es)?

No, I don't use multiple sets in a sandbox.  All my set names should
be the same as my sandbox names (and I make sure all my sandbox names
are different).

> In this case, if you bci'd the files and then they got removed from
> your sandbox, a "bco -u" from the same sandbox/set will restore them,

This assumes I can workon to that sandbox, which I can't.

> and, presuming they are still listed in your .BCSset-*/.BCSconfig
> files, everything will work as it originally did.

There are no .BCS* files in ANY of my sandboxes, except for the two
I did submits from today and the 'odeisbroken' one I just created.

$ lsa -1 sb/*/src/.BCS*
sb/cxx9/src/.BCSlock
sb/fix2/src/.BCSlock
sb/odeisbroken/src/.BCSlock
$

I have about 35 or so sandboxes & I find it hard to believe that (other
than those 3 above) NONE of them have .BCS* files in them.

> Note that ode also
> has a notion of a "default" sandbox (listed at the top of
> ~/.sandboxrc); if this sandbox or its backing tree are not mounted,
> you'll get errors which are really warnings when it attempts to
> reference your default sandbox (which is does when you do a mksb).  I
> recommend you update your default (just edit the file) to something
> current that you really use and is mounted.

My default sandbox is 'tools'.  It is backed by ptos:

$ ls -ld sb/tools/link
lrwxr-xr-x   1 tomp     staff         24 Aug  4 10:29 sb/tools/link@ -> /usr/sde
/osf1/build/ptos/

However:

$ workon -sb tools
>> WARNING in current_set:
>> ERROR: cannot read from sets rc file
  /home/tomp/sb/tools/rc_files/sets.
>> FATAL ERROR in workon:
        no default set name; none entered.
$


- Tom

40.39submit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckThu Feb 01 1996 14:2748
Date Of Receipt: 	 1-FEB-1996 13:54:46.17
From: 	SMURF::FLUME::dgraham "David Graham USG  01-Feb-1996 1352"
To: 	odehelp@DEC:.zko.flume
CC: 	gerson@DEC:.zko.flume
Subj: 	submit problem

------- Forwarded Message

Return-Path: gerson
Received: from galpha.zk3.dec.com by flume.zk3.dec.com; 
(5.65v3.2/1.1.8.2/16Jan95-0946AM)
	id AA00710; Thu, 1 Feb 1996 09:30:56 -0500
Received: by falpha.zk3.dec.com; (5.65v3.2/1.1.8.2/20May95-1022AM)
	id AA27125; Thu, 1 Feb 1996 09:30:52 -0500
Date: Thu, 1 Feb 1996 09:30:52 -0500
From: Dave Gerson USG <gerson>
Message-Id: <[email protected]>
To: [email protected]
Subject: submit access list problem


[portsmouth..ws] bsubmit -defect ptos-4569-gerson -auto -auto_out pcxal.c
>> FATAL ERROR in /usr/sde/ode3.0/tools/alpha_ace/bin/ode/bsubmit:
>> You are prevented from submitting to: /usr/sde/osf1/build/ptos.
>> No entry in submit or sadmin access lists.


have approval as follows:

Message  5:
>From daemon Wed Jan 31 10:59:33 1996
Date: Wed, 31 Jan 1996 10:59:31 -0500
From: Fred Canter <[email protected]>
To: [email protected]
Subject: ptos-4569-gerson
Cc: [email protected]


Hardware_submit approves ptos-4569-gerson

Fred


	Dave

------- End of Forwarded Message


40.40help!AOSG::FILTERAutomatic Posting Software - mail to flume::puckThu May 09 1996 10:0319
Date Of Receipt: 	 9-MAY-1996 08:55:52.10
From: 	WASTED::thompson "Pete Thompson USG  09-May-1996 0849"
To: 	odehelp@DEC:.zko.wasted
CC: 	thompson@DEC:.zko.wasted
Subj: 	help!

Hi,

	It appears my kerberos account has expired??  Can you please help?

Thanks,
-Pete


threeputt.zk3.dec.com> kinit $PRINCIPAL
Kerberos Initialization for "Peter_S_Thompson"
kinit: Principal expired (kerberos)
threeputt.zk3.dec.com>

40.41bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Oct 15 1996 19:2540
Date Of Receipt: 	 4-OCT-1996 10:06:49.32
From: 	FLUME::"[email protected]"
To: 	[email protected]
CC: 	
Subj: 	bsubmit problem

Hi,

I'm having some bsubmit difficulties with which I need assistance.

I've bcreated and bcied about 363 files for ptbqa.  Upon bsubmitting
(bsubmit -l -all), I received a couple errors.  Initially they were 
somewhat minor (I had files set for write and bsubmit did not like that).

At one point, bsubmit said there were errors and it was exiting, but I had 
the option to preserve my bsubmit state.  I selected preserve.  On a 
subsequent bsubmit (bsubmit -resub -time <time>) I resolve the error 
(missing copyright tag in one file), but I received additional errors that 
I've not seen before:

    >> FATAL ERROR in /usr/sde/tools/alpha_osf1/bin/ode/bsubmit:
    >> open ./test/filesystems/suites/cthon96/tools/Makefile

There were a dozen or so of these.  I suspected (and hoped) that they 
were due to the directory above the files not having write access.  I
set the directory to write access and tried to bsubmit again with
bsubmit -resub -time <time>, but received the same set of errors.

I noticed some additional files in ./src in my sandbox.  
    16:34.bcssteps
        Appears to contain files from .BCSconfig
    16:34.Thold
        This file contains names of files I am NOT checking in.  In fact,
        Jeff Detjen's name is in this file.  Don't know if that's good or
        bad.

Any assistance would be appreciated.

Brian

40.42Re: bsubmit problemAOSG::FILTERAutomatic Posting Software - mail to flume::puckTue Oct 15 1996 19:3487
Date Of Receipt: 	 4-OCT-1996 16:07:27.07
From: 	FLUME::"[email protected]" "Susan Schueller USG  04-Oct-1996 1605"
To: 	Baker Brian USG <[email protected]>
CC: 	[email protected], [email protected]
Subj: 	Re: bsubmit problem

Hi Brian,
  I went around to ask  a couple of people in my group..Josh Friedman
is taking a look at it now.  Josh did say that it is OK if the "Thold" 
log shows the names of files that others are checking in; it's because
the log can show simultaneous submits from different people into the
same pool (shared sandbox).

Sue

> Sue,
> 
> Any news on my bsubmit difficulties yet?
> 
> Thanks,
> 
> Brian
> 
> > 
> > Hi Brian,
> >   I'm the odehelp admin-of-the-day. I'm looking into this for you now.
> > 
> > Sue Schueller
> > Steel Release Engineering Project Leader
> 
> > 
> > > Hi,
> > > 
> > > I'm having some bsubmit difficulties with which I need assistance.
> > > 
> > > I've bcreated and bcied about 363 files for ptbqa.  Upon bsubmitting
> > > (bsubmit -l -all), I received a couple errors.  Initially they were 
> > > somewhat minor (I had files set for write and bsubmit did not like that).
> > > 
> > > At one point, bsubmit said there were errors and it was exiting, but I had 
> > > the option to preserve my bsubmit state.  I selected preserve.  On a 
> > > subsequent bsubmit (bsubmit -resub -time <time>) I resolve the error 
> > > (missing copyright tag in one file), but I received additional errors that 
> > > I've not seen before:
> > > 
> > >     >> FATAL ERROR in /usr/sde/tools/alpha_osf1/bin/ode/bsubmit:
> > >     >> open ./test/filesystems/suites/cthon96/tools/Makefile
> > > 
> > > There were a dozen or so of these.  I suspected (and hoped) that they 
> > > were due to the directory above the files not having write access.  I
> > > set the directory to write access and tried to bsubmit again with
> > > bsubmit -resub -time <time>, but received the same set of errors.
> > > 
> > > I noticed some additional files in ./src in my sandbox.  
> > >     16:34.bcssteps
> > >         Appears to contain files from .BCSconfig
> > >     16:34.Thold
> > >         This file contains names of files I am NOT checking in.  In fact,
> > >         Jeff Detjen's name is in this file.  Don't know if that's good or
> > >         bad.
> > > 
> > > Any assistance would be appreciated.
> > > 
> > > Brian
> > 
> > -- 
> > ------------------------------------------------------------
> > 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
> > ------------------------------------------------------------
> > 
> > 
> > 
> 

-- 
------------------------------------------------------------
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
------------------------------------------------------------