[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

2743.0. "re: Looks like major problem with my _bsubmit_.. [DEC India]" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Thu Jan 02 1997 14:26

Date Of Receipt: 	20-DEC-1996 16:53:58.50
From: 	FLUME::jmf "Joshua M. Friedman Digital UNIX  20-Dec-1996 1649"
To: 	[email protected]
CC: 	gillett@DEC:.zko.flume, tresvik@DEC:.zko.flume, jmf@DEC:.zko.flume,
	odehelp@DEC:.zko.flume
Subj: 	re: Looks like major problem with my _bsubmit_.. [DEC India]

Krishna,

Please accept our apologies for the delay in responding to this problem.

I have analyzed the rcs files for these files you are working on:
    steelos/src
	./usr/ccs/bin/cfe/errors.list
	./usr/ccs/bin/cfe/expr_sem.c
	./usr/ccs/bin/cfe/symtab.c

I've checked in the underlying rcs files, and there are no longer any
Krishna_Babu_Bangera_steel branches for these files, since they were
outdated at the end of the submit (log attached).  This is good and will
allow starting with a clean slate in your steel sandbox/set.  You can do a
"blog -r file" for each one to see this yourself in the "symbolic names"
section of the rcs log.

Here's how to recover: 

    Make sure that you have no references to these files in either
    .BCSset-Krishna_Babu_Bangera_steel or .BCSconfig in the
    /usr/users/krishna/Sbox/steel/src directory; these .BCS files may
    no longer exist if all the contents were outdated; this is fine;
    ode creates, modifies, and removes them as needed.

    You may have other files you're working with in these .BCS files;
    that's ok and will not interfere.  Let me know if you have any other
    hand-edits in any .BCS files; these should be investigated and cleaned
    up.  The file list in the union of all the .BCSset* files (if more
    than one) and the .BCSconfig file should match 1-to-1.

    Exit any current workon to start with a clean environment backed to
    the steelos submit tree:

	$ kinit Krishna_Babu_Bangera  /* if necessary */

	$ workon -sb steel         /* or: workon -sb sandboxname steel, if steel
					is the setname in a sandbox by a
					different name */

	$ currentsb -all           /* to check what you're backed to */

	/* if last element shows backed to something other
	   than steelos, like steelos.nightly, then do: */
		resb steelos
		exit
		workon -sb steel    /* or: workon -sb sandboxname steel */

    Check out the files "fresh", which will created a locked ode branch:

	$ cd usr/ccs/bin/cfe

	If any of these files exist, remove them:
		$ rm -f errors.list expr_sem.c symtab.c

	$ bco errors.list expr_sem.c symtab.c

    You will retrieve your 12/4 submits; please check to confirm that in
    each of the 3 files you last submit with an empty check-in comment
    like the following is the latest change; if any newer submits appear,
    then you will have a merge to do; hopefully this will not be the case:

	     * HISTORY
	     * $Log: symtab.c,v $
	     * Revision 4.3.17.2  1996/12/04  12:05:55  Krishna_Babu_Bangera
	     * *** empty log message ***
	     *

    Manually copy on top of these files your three files you've saved.  In
    general, work should not be done in this way because you run the risk
    of losing recent submits; in this case you're already checked and know
    it to be ok.

    Now check in the work to your ode branch, which also unlocks it:

	$ bci errors.list expr_sem.c symtab.c

	(or: bci -all ; if it's the whole set)

    >Or, if you don't already have history comments in the file, between
    the two header lines, eg:
	     * HISTORY
	     * any comments you want
	     * can go here 
	     * $Log: symtab.c,v $

    then you may also specify the -m"message text" switch in the bci
    to avoid having to edit 3 sets of histories during the bci.
    I.e.:
	    $ bci -m"check-in message text" errors.list expr_sem.c symtab.c

    You already completed the srequest, so just use that defect number,
    and proceed with the submit:

	$ bsubmit -defect steelos-1231-krishna errors.list expr_sem.c symtab.c

	(or: bsubmit -defect steelos-1231-krishna -all 
	 again if it's the whole set)

Please let us know how it goes.  

  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

Here is what appears to have happened from the audit trail I found.

You reported that you hand created a .BCSconfig file, which should almost
never be needed, unless some corruption or unintended action caused the
loss of this file.  Please seek "[email protected]" advise in the future
if you find you think you need to edit any .BCS* files.  It's important to
understand how the history/merge process works before handing editing
works or you could lose your work or someone else's upon a bsubmit.

If, in fact, when you ran "bcs -u" (unlock) without the -o (outdate) switch 
caused the .BCSconfig entries to be removed, then this should be reported
as a bug; it correctly threw away your work but lost the configuration
information too.  It's questionable if you should even be allowed to
"bcs -u" alone on a branch which has only been created, and has no 
revision beyond x.y.z.1 -- if this was what happened to the .BCSconfig,
please report this bug in:
	http://reng.zk3.dec.com/ode/ODE-Bugtrack.html

I'm guessing from the log you sent and the current state of the rcs files
that perhaps you did the following:

	bco files
	edit...test
	try to submit, forgetting to first bci files
	unlock files using bcs -u
	create/edit .BCSconfig
	bsubmit files -- discover work is "gone"
	
The bsubmit error "file is locked" usually means you should bci your
work.  The unlock by itself effectively means "throw away your work".

I suppose some confusion as to how ode works caused you to try to
use "bcs -u" to force the file to become unlocked.  Here's how it works:

The bci (branch check-in) command is the normal way that you unlock a
file, and save your work.  When you "bco", this creates a private branch,
and locks it (or, if it already exists, just re-locks it for more work),
then it gives you a writeable file.  When you bci, ode checks in your work
as a new revision number along your branch, and then unlocks it.

-josh



------- Forwarded Message

Return-Path: [email protected] 
Delivery-Date: Fri, 20 Dec 96 14:22:30 -0500
Return-Path: [email protected]
Received: from scobox.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
	id AA08221; Fri, 20 Dec 1996 14:22:28 -0500
Message-Id: <[email protected]>
Comments: Authenticated sender is <[email protected]>
From: "Tom Tresvik" <[email protected]>
To: jmf
Date: Fri, 20 Dec 1996 14:20:24 +0000
Subject: Re: Request Again:  Can you help with bsubmit trouble in India?
Cc: gillett, tresvik
Priority: normal
X-Mailer: Pegasus Mail for Windows (v2.42a)

Josh, can you prioritize this?  Let me know if this needs to involve 
others.

Thanks,
Tom

> To:            [email protected]
> Cc:            [email protected]
> Subject:       Request Again:  Can you help with bsubmit trouble in India?
> Date:          Fri, 20 Dec 96 09:24:57 -0500
> From:          gillett

> 
> Howdy odehelp folks:
> 
> Earlier this month (4 December to be exact) I sent email requesting
> assistance in sorting out some ODE troubles that our engineers working
> in Bangalore India were having.  I never heard anything back from
> odehelp people, and Krishna reports today that they are still having
> fairly serious ODE problems and he has not yet been able to complete
> the bsubmit.
> 
> Can you please get involved in helping out with this matter?  If you
> are unable to help, can you please direct me to the proper individuals
> who can provide assistance?   I am not an ODE expert and Krishna's
> troubles exceed my ability to be helpful.
> 
> Thanks....
> Chris
> 
> 
> ------- Forwarded Message
> 
> Return-Path: gillett 
> Delivery-Date: Wed, 04 Dec 96 09:40:19 -0500
> Return-Path: gillett
> Received: from flume.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
> 	id AA31457; Wed, 4 Dec 1996 09:40:17 -0500
> Received: from sledgeomatic.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
> 	id AA30464; Wed, 4 Dec 1996 09:40:27 -0500
> Received: from localhost by sledgeomatic.zk3.dec.com; (5.65v3.2/1.1.8.2/28Jul95-0202PM)
> 	id AA20030; Wed, 4 Dec 1996 09:40:10 -0500
> Message-Id: <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Can you help with bsubmit trouble in India?
> Date: Wed, 04 Dec 96 09:40:10 -0500
> From: gillett
> X-Mts: smtp
> 
> 
> Howdy Folks:
> 
> I'll forward you another message about this (my reply to Krishna) after
> this message.
> 
> Can you help out here?  It looks like they're having a major ODE
> problem of some sort (they may have shot themselves in the foot...I'm
> nowhere near ready to blame ODE for this yet), and looks like a bsubmit
> got trashed.  I'm not sure what the best course of action is, so would
> like to ask for your assistance.
> 
> Krishna's email attached below, my reply follows next.  Anything you
> can do to help him out will be most appreciated.  Remember, there is
> a 10.5 hour time shift between here and Bangalore, India, so as I 
> type this message it 8:10 in the evening there, so they will probably
> not respond quickly to any email.  Krishna does sometimes work late
> though.
> 
> Thanks very much!
> 
> Chris
> 
> 
> - ------- Forwarded Message
> 
> Return-Path: [email protected] 
> Delivery-Date: Wed, 04 Dec 96 08:37:33 -0500
> Return-Path: [email protected]
> Received: from flume.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
> 	id AA28722; Wed, 4 Dec 1996 08:37:28 -0500
> Received: from indus.xko.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
> 	id AA13308; Wed, 4 Dec 1996 08:37:35 -0500
> Received: from localhost by indus.xko.dec.com (5.65v3.2/1.1.10.5/20Nov96-0538PM)
> 	id AA28151; Wed, 4 Dec 1996 19:07:10 +0530
> Message-Id: <[email protected]>
> To: [email protected]
> Subject: Looks like major problem with my _bsubmit_..
> Date: Wed, 04 Dec 96 19:07:10 +0530
> From: [email protected]
> X-Mts: smtp
> 
> 
> Hi, Chris.
> 
> Today i was doing my bsubmit for 'steelos-1231-krishna'
> 
> I have attached 'bsubmit -verbose .... ' output for your ref.
> I think, it has deleted all  revisions (done by me so far) from the
> ode pool. Don't worry - i have backup of all my changes so far.
> 
> Itz first time happening to me, today i spent whole day
> to find out what went wrong but couldn't find the reason.
> 
> Following are the summary of things i did today:
> - - ------------------------------------------------
> 
> * One thing, i did in the morning was that i created and edited
>   /usr/users/krishna/Sbox/steel/src/.BCSconfig file. Actually it was
>   not there in the corr directory, and bsubmit was complaining that
>   entries were not found in this .BCSconfig file.
> 
> * bsubmit again failed complaining something like-
> 	VALIDATION FAILED
> 	.../errors.list locked
> 	.../expr_sem.c  locked
> 	.../symtab.c    locked
> 
>   next i unlocked this file using
>   'bcs -u  errors.list, expr_sem.c, symtab.c'
> 
> See below for next.... 
> - - ----------------------
> 
> krishna@devil:/usr/users/krishna/Sbox/steel/src/usr/ccs/bin/cfe>cat 
> ../../../../.BCSconfig
> ./usr/ccs/bin/cfe/errors.list,v	4.2.21.2
> ./usr/ccs/bin/cfe/expr_sem.c,v  4.3.31.6
> ./usr/ccs/bin/cfe/symtab.c,v	4.3.16.2
> 
> 
> krishna@devil:/usr/users/krishna/Sbox/steel/src/usr/ccs/bin/cfe> bsubmit 
> - - -verbose errors.list expr_sem.c symtab.c
> >  Reading rc file : /home/indus/krishna/.sandboxrc
> >  build to submit to is: steelos.
> >  Time is: 17:24; date is: 12/4/96.
> >  cd'ing to sandbox source directory: /usr/users/krishna/Sbox/steel/src.
> >  checking for lock on build: /usr/sde/osf1/build/steelos/src/.BCSlock
> >  checking access control list on submit
> Outdate files if successful submission? [Y]es, [N]o, [Q]uery later]: [Yes] 
> >  Checking environment...
> 
> Enter the defect number this submission applies to: steelos-1231-krishna
> >  Submitting the following files:
> >  ./usr/ccs/bin/cfe/errors.list
> >  ./usr/ccs/bin/cfe/expr_sem.c
> >  ./usr/ccs/bin/cfe/symtab.c
> >  have lock on hold file.
> >  checking HOLD file: 17:24.Thold /usr/sde/osf1/build/steelos/logs/bsubmit.hold
> >  found no holds on files being submitted.
> >  added 3 files to the hold list.
> >  Validating submission...
> >  base revision 4.2.21.2
> >  common ancestor 4.2.21.2; will just use revision 4.2.20.4
> >  No merge required
> >  base revision 4.3.31.6
> >  common ancestor 4.3.31.6; will just use revision 4.3.30.2
> >  No merge required
> >  base revision 4.3.16.2
> >  common ancestor 4.3.16.2; will just use revision 4.3.15.2
> >  No merge required
> 
> *** No user interaction will be required during the merge step. ***
> 
> >  Performing merge(s)...
> >  ./usr/ccs/bin/cfe/errors.list
> >  Retrieving revision 4.2.20.4
> >  Base revision 4.2.21.2
> >  Common ancestor 4.2.21.2; will just use revision 4.2.20.4
> >  ./usr/ccs/bin/cfe/expr_sem.c
> >  Retrieving revision 4.3.30.2
> >  Base revision 4.3.31.6
> >  Common ancestor 4.3.31.6; will just use revision 4.3.30.2
> >  ./usr/ccs/bin/cfe/symtab.c
> >  Retrieving revision 4.3.15.2
> >  Base revision 4.3.16.2
> >  Common ancestor 4.3.16.2; will just use revision 4.3.15.2
> >  Preparing for check-in(s)...
> >  Checking files in; Set: 'STEELOS'
> >  ./usr/ccs/bin/cfe/errors.list
> >  Scanning for HISTORY and $Log...$ messages
> >> WARNING in bsubmit:
> >> Empty or non-existant mesgfile.
> >> File: '/usr/users/krishna/Sbox/steel/tmp/_LOG_'
> >> No log information was recorded!!
> ci warning: missing message for -m option
> ./usr/ccs/bin/cfe/errors.list,v  <--  
> OdeSrvrTmpKrishna_Babu_Bangera024724/errors.list
> new revision: 4.2.20.5; previous revision: 4.2.20.4
> done
> [ ./usr/ccs/bin/cfe/errors.list checked in onto branch 4.2.20 ]
> >  Updating ./.BCSlog-Krishna_Babu_Bangera_steel
> >  ./usr/ccs/bin/cfe/expr_sem.c
> >  Scanning for HISTORY and $Log...$ messages
> >> WARNING in bsubmit:
> >> Empty or non-existant mesgfile.
> >> File: '/usr/users/krishna/Sbox/steel/tmp/_LOG_'
> >> No log information was recorded!!
> ci warning: missing message for -m option
> ./usr/ccs/bin/cfe/expr_sem.c,v  <--  
> OdeSrvrTmpKrishna_Babu_Bangera009469/expr_sem.c
> new revision: 4.3.30.3; previous revision: 4.3.30.2
> done
> [ ./usr/ccs/bin/cfe/expr_sem.c checked in onto branch 4.3.30 ]
> >  Updating ./.BCSlog-Krishna_Babu_Bangera_steel
> >  ./usr/ccs/bin/cfe/symtab.c
> >  Scanning for HISTORY and $Log...$ messages
> >> WARNING in bsubmit:
> >> Empty or non-existant mesgfile.
> >> File: '/usr/users/krishna/Sbox/steel/tmp/_LOG_'
> >> No log information was recorded!!
> RCS file: ./usr/ccs/bin/cfe/symtab.c,v
> 4.3 locked
> done
> ./usr/ccs/bin/cfe/symtab.c,v  <--  OdeSrvrTmpKrishna_Babu_Bangera023313/symtab.c
> new revision: 4.3.17.1; previous revision: 4.3
> done
> RCS file: ./usr/ccs/bin/cfe/symtab.c,v
> 4.3 unlocked
> done
> RCS file: ./usr/ccs/bin/cfe/symtab.c,v
> 4.3.17.1 locked
> done
> ci warning: missing message for -m option
> ./usr/ccs/bin/cfe/symtab.c,v  <--  OdeSrvrTmpKrishna_Babu_Bangera010968/symtab.c
> new revision: 4.3.17.2; previous revision: 4.3.17.1
> done
> [ ./usr/ccs/bin/cfe/symtab.c checked in onto branch 4.3.17 ]
> >  Updating ./.BCSlog-Krishna_Babu_Bangera_steel
> >  Updating default build; Set: 'STEELOS'
> >  from directory: /usr/sde/osf1/build/steelos/src.
> >  ./usr/ccs/bin/cfe/errors.list
> ./usr/ccs/bin/cfe/errors.list,v  -->  
> OdeSrvrTmpKrishna_Babu_Bangera009566/errors.list
> revision 4.2.20.5
> done
> [ ./usr/ccs/bin/cfe/errors.list Rev 4.2.20.5 checked out ]
> >  ./usr/ccs/bin/cfe/expr_sem.c
> ./usr/ccs/bin/cfe/expr_sem.c,v  -->  
> OdeSrvrTmpKrishna_Babu_Bangera013353/expr_sem.c
> revision 4.3.30.3
> done
> [ ./usr/ccs/bin/cfe/expr_sem.c Rev 4.3.30.3 checked out ]
> >  ./usr/ccs/bin/cfe/symtab.c
> ./usr/ccs/bin/cfe/symtab.c,v  -->  OdeSrvrTmpKrishna_Babu_Bangera014079/symtab.c
> revision 4.3.17.2
> done
> [ ./usr/ccs/bin/cfe/symtab.c Rev 4.3.17.2 checked out ]
> >  Updating log files...
> >  Creating list of files and revisions submitted...
> >  
> Full name for the log: Krishna_Babu_Bangera
> >  have lock on log files.
> >  updating SNAPSHOT, DEFUNCT, and submit logs.
> >  Finished updating log files.
> >  cleaning up hold file; removing entries.
> >  Outdating the submitted files from the set: Krishna_Babu_Bangera_steel
> RCS file: ./usr/ccs/bin/cfe/errors.list,v
> deleting revision 4.2.21.1
> deleting revision 4.2.21.2
> done
> [ ./usr/ccs/bin/cfe/errors.list outdated revisions in set 
> Krishna_Babu_Bangera_steel ]
> >  Removing from ./.BCSconfig:
> >  ./usr/ccs/bin/cfe/errors.list
> >  ./usr/ccs/bin/cfe/errors.list,v      4.2.21.2
> 
> >  rm: removing ./usr/ccs/bin/cfe/errors.list
> RCS file: ./usr/ccs/bin/cfe/expr_sem.c,v
> deleting revision 4.3.31.1
> deleting revision 4.3.31.2
> deleting revision 4.3.31.3
> deleting revision 4.3.31.4
> deleting revision 4.3.31.5
> deleting revision 4.3.31.6
> done
> [ ./usr/ccs/bin/cfe/expr_sem.c outdated revisions in set 
> Krishna_Babu_Bangera_steel ]
> >  Removing from ./.BCSconfig:
> >  ./usr/ccs/bin/cfe/expr_sem.c
> >  ./usr/ccs/bin/cfe/expr_sem.c,v       4.3.31.6
> 
> >  rm: removing ./usr/ccs/bin/cfe/expr_sem.c
> RCS file: ./usr/ccs/bin/cfe/symtab.c,v
> deleting revision 4.3.16.1
> deleting revision 4.3.16.2
> done
> [ ./usr/ccs/bin/cfe/symtab.c outdated revisions in set 
> Krishna_Babu_Bangera_steel ]
> >  Removing from ./.BCSconfig:
> >  ./usr/ccs/bin/cfe/symtab.c
> >  ./usr/ccs/bin/cfe/symtab.c,v 4.3.16.2
> 
> >  rm: removing ./.BCSconfig
> >  rm: removing ./.BCSset-Krishna_Babu_Bangera_steel
> >  rm: removing ./.BCSlog-Krishna_Babu_Bangera_steel
> >  rm: removing ./usr/ccs/bin/cfe/symtab.c
> 
> Submission completed successfully.
> 
> - - -------------------------------
> 
> 
> Chris, it didn't prompt before while removing files. And other thing
> is i tried same bsubmit command with -info option. That time also it
> didn't tell much  about the merge operation itz going to do.
> 
> I can extract the changes from my backup and then check-in, followed
> by srequest, bsubmits.  Do you have any other alternatives for this.
> 
> I am sure i can find a better way to do this, without loosing any of
> the check-in information).
> 
> Bye, and Sorry for troubling you.
> 
> Krishna.
> 
> 
> 
> 
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 
> 


------- End of Forwarded Message


T.RTitleUserPersonal
Name
DateLines