From cmh@kipling  Mon Sep 16 10:55:26 1991
Date: Mon, 16 Sep 91 10:53:30 PDT
From: cmh@kipling (Claire Hayes)
To: cal-all@benet
Subject: NSE-->Avocet transition
Cc: sdet@plunge
Status: RO
Content-Length: 5672
X-Lines: 140

Our work on transitioning from the NSE to Avocet is progressing, as
is the Avocet product.  Here's the latest status:

Transition Status

We held a meeting on August 1st to get your input on how to transition
to Avocet.  What we heard was:

	a) Developers may be eager to transition to a new software
	   development tool quickly if the transition is to an 
	   sccs-based tool that is intuitive.

	b) Someone questioned whether we really want to bind Callisto
	   integration to the NSE.  The answer stated that the decision 
	   to continue with NSE for Callisto integration was a firm 
	   management decision made to reduce the risk to Callisto.  
	   
Attached below is our transition plan, based on your input.  If
you have additional comments or concerns about the transition,
please be sure to let us know.

Avocet Status

Just to remind everyone, Avocet is the source management product
we will be using to replace the NSE.  Avocet is still very early
in the product design and development phase, and we're heavily
influencing "what it is".  Avocet is a much simpler, more UNIX-like,
tool which started from the CSMT requirements and is fundamentally
based on the "smoosh" technology that was developed for the Bridge.

We've received an early delivery of Avocet and have started
testing and prototyping.  So far, it looks very good.  The core of
the product is in place and working.  There are many areas yet to
be fleshed out, and we're hoping to get some actual user experience
in order to prioritize the next features that are added.

We hope to release this early version of Avocet to selected developers 
to use and give us feedback.  If you're interested in trying Avocet, 
let us know.  We're especially looking for people who meet some of the 
following requirements:

	...are working on projects to be delivered after Callisto. 
	...are only working on the kernel.
	...are not under schedule pressure to deliver in the near future.

Please contact me if you are interested in using Avocet and providing
us with feedback.  Once we have feedback and once we complete some
development of complementary tools, we should be ready to introduce
Avocet as an integration tool for future releases.

You can find a postscript copy of the Avocet ten-pager on: 

	terminator:/vm/avocet/doc/avocet_info

You can view this file via the following command: 

	/usr/local/openwin/bin/pageview  avocet_info

You can find copies of Avocet man pages in the same location:

	terminator:/vm/avocet/man


................Software Development Environment Transition Plan

	We plan to introduce Avocet as the integration tool for 
future releases; we expect all post-Callisto releases to complete
their integration with Avocet.  For Callisto integration, management 
has committed to continue with the NSE.  Although developers are free 
to use the sccs based tools they choose, a change of the *integration* 
tool at this stage in Callisto is considered quite risky.

	Given that we will continue to integrate Callisto using NSE 
and that we would like to integrate future releases using Avocet, 
there may be some need for the two tools to coexist for a period of 
time.  Yet, there must be a way to migrate Callisto bug fixes into
future releases.

	We plan to introduce Avocet at the SunOSint level in the
environment hierarchy.  We intend to create a "child" of SunOSint 
that is an Avocet workspace.  If we weren't embarking on the development 
of so many releases at once (Mars, Saturn), you could consider this 
child the Train, an Avocet equivalent to SunOSint.

	Part of the motivation for introducing Avocet at the SunOSint 
level is due to the golden sccs histories contained in SunOSint.  Part 
of the motivation is that it will be easier for the integration group 
to manage the communication between NSE and Avocet.  We intend to support 
regular "resyncs" between SunOSint and the Avocet Train.

	I-teams doing development in environments under SunOSint 
will be encouraged to convert their development to an Avocet workspace
under the Train.  I-teams that do convert will still receive the
updates from i-teams still located under SunOSint via our regular
resyncs from NSE to Avocet.  The one-way flow of information between
SunOSint and the Train is designed to provide incentive to convert.

A picture of the transition hierarchy is depicted below.  Please
bear with my artistic skills.  Also, keep in mind that at the
developer level, any sccs-based tool can be used.  The requirement
is only that people *integrate* using Avocet.

		    (***************)
		    (   SunOS_5.0   )
		    (***************)
		      |		  |
	(***************) 	(***************)
	(   SunOSint    )	(   Callisto    )
	(***************)	(***************)
	   |        \	
(***************)    \ 
(     i-teams   )     \
(***************)      \
		        \
		       Bridge
		          \
		   |---------------|
	   	   |     Train	   |
		   |---------------|
  			   |
		   |---------------|
		   |     i-teams   |
		   |---------------|

LEGEND:

|----------------|	(***************)
|Avocet workspace|	(NSE Environment)
|----------------|	(***************)

The notion of the Train can be extended to handle concurrent development
of multiple releases.  If we were to undertake development of Mars and
Saturn and some future major releases concurrently, this model could
support our usage.  Avocet's reparenting feature provides us with the
flexibility to introduce the development of unplanned releases into our 
workspace development hierarchy.

We'll try to keep you informed of the status of the transition.  We
don't have enough resources to move as quickly as we would like.


From shannon@datsun Fri Nov  1 19:14 PST 1991
Date: Sat, 2 Nov 91 03:13:16 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet is available!
Content-Type: text
Content-Length: 4122
X-Lines: 130
Status: RO

Avocet is now available for use.  It's still very much a pre-alpha
version (in terms of feature-content; stability of the few features
that are there looks very good), so your feedback and patience are very
important!

This is a quick introduction to how to use Avocet under an NSE
integration environment.  There are only four commands you'll
normally need to use:

	nsebringover
		This is a combination of the NSE aquire, resync, and append
		commands.  There is also a "bringover" command that works
		between Avocet workspaces.

	nseputback
		This is the equivalent of the NSE reconcile command.  There's
		also a "putback" command that works between Avocet workspaces.

	resolve
		This is the equivalent of the NSE resolve command.  It
		will invoke fileresolve for you.

	activate
		This is a simple shell script I wrote, not part of Avocet
		itself.  It's similar to the NSE activate command in concept,
		but all it does is set some environment variables and simple
		things like that.  You can do all this yourself, but we
		encourage you to use the script because we'll make changes to
		the script to make things even easier to use in the future.

In addition, there's one other command you might use occasionally:

	workspace
		This allows you to discover information about an Avocet
		workspace.  (A workspace is analogous to an NSE environment.)

There are man pages for all these commands (except activate).  The
binaries and man pages are located in:

	4.1:	dunk:/sdet/4.x.avocet
	5.0:	dunk:/sdet/5.x.avocet




Here's a simple example using Avocet to create a child workspace of
an NSE environment.  We'll use the mailx command as an example.  We'll
be doing all this on a machine running 5.0, with no use of the NSE at
all!

First, set up your environment to get at the Avocet binaries.

	$ su
	# mkdir /opt/avocet
	# mount -F nfs dunk:/sdet/5.x.avocet /opt/avocet
	# exit
	$ PATH=$PATH:/opt/avocet/bin
	$ MANPATH=$MANPATH:/opt/avocet/man

Next, create a workspace and fill it with the files you need.

	$ nsebringover -p sysint@andrewr -w ~/mailx usr/src/cmd/mailx

Note that Avocet only brings over the source files.  You can name
individual files or directories (implying all source files under the
directory).  A local customization I made allows it to know to
bringover the various higher-level Makefiles that will be needed.
This should work for you when bringing over cmd or uts directories;
in other cases you may need to explicitly specify the additional
Makefiles.

Activate the workspace and do some work.  (Note that activate creates a
sub-shell.)

	$ activate ~/mailx
	/home/datsun/shannon/mailx

The activate script cd's us to the root of the workspace so we need to
cd down to where our source is.  (Note that there's no tfs or anything
like that involved here.)

	$ cd usr/src/cmd/mailx
	$ sccs edit main.c
	$ vi main.c

Here we edit, test, and debug our changes.

	$ sccs delget main.c

Now it's time to resync with the parent.

	$ nsebringover usr/src/cmd/mailx

If there were any conflicts we resolve them.

	$ resolve

After testing and debugging our merges, we're ready to reconcile our
changes back to the parent.

	$ nseputback usr/src/cmd/mailx

That's it, get out of our activated workspace!

	$ exit


This is a very simple procedure for very simple changes.  There are a
number of limitations which we don't expect to impact most people:

1.  We assume that using the native compilers, libraries, and include
    files on your 5.0 machine is "good enough" to build and test our
    work.  We'll relax this restriction eventually, but for now this
    is a limitation.  Of course, in the long term using the native
    stuff is not good enough, so expect changes here.

2.  You can't rename or delete files in an Avocet workspace.  Also,
    bringover (resync) won't bring down any renames from the parent.
    We expect to remove this latter limitation very shortly.

3.  Just to be sure you got it, don't rename or delete source files
    in an Avocet workspace!

If you have any questions or problems, let one of us know.

Enjoy!

	Bill Shannon
	Claire Giordano
	Tadd Ottman

From shannon@datsun Thu Nov  7 23:47 PST 1991
Date: Thu, 7 Nov 91 23:32:45 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #1 - more tips
Content-Type: text
Content-Length: 2488
X-Lines: 56
Status: RO

There's a few things people have tripped over that were not explained
well (or at all) in my previous message.


In order to use nsebringover on a 5.0 system, you must have an
/etc/auto.nse file that contains a line like this:

+auto.nse

This is now explained in the nsebringover man page.  (If you have your
own /etc/auto.master file, it must reference /etc/auto.nse.)


When using nsebringover (or bringover), the file and directory names
specified must either be absolute pathnames that name files in the
source or destination workspaces, or they must be relative pathnames
which will be interpreted relative to the root of the workspace.

For example, in the command from my original message

	$ nsebringover -p sysint@andrewr -w ~/mailx usr/src/cmd/mailx

the relative pathname "usr/src/mailx" is interpreted relative to the
root of the workspace.  For an NSE environment, the root is the "real"
root (/) when the environment is activated.  For the Avocet workspace,
the root is the directory that names the workspace, "~/mailx" in this
case.

If instead we had used the the pathname "/usr/src/cmd/mailx", Avocet
would complain because that pathname is not under either workspace;
it's not under ~/mailx and it's not under /nse/br.mumblefritz/vcs.

The simple rule when using nsebringover is to use the same pathname
you would use if you were in the activated NSE environment, but leave
off the initial "/".  When using nsebringover you'll always want to
specify a pathname that starts with "usr/src/".


The NSE provides a shorthand (":") that means "everything in the
environment".  Avocet doesn't currently provide this, but it is being
added.  In the mean time, you'll usually want to explicitly specify
what subset of usr/src you want to bringover or putback.  In some
cases, such as in the i-mt5 environment, the NSE environment might
only contain a subset of all the system source.  If you want to bringover
or putback everything in that NSE environment, you could specify
either "usr/src" or just ".".  The disadvantage of specifying just "."
is that Avocet might spend a lot of time looking through the /proto
area in the NSE environment, only to find that there are no source files
there.


The nsebringover man page didn't exist at the time of my original
message, but it's there now.  It contains lots of useful information.

In addition, the Avocet "10 pager", which is a relatively high level
description of Avocet, is in the doc directory on dunk:/sdet/*.avocet/doc.

From shannon@datsun Fri Nov  8 15:50 PST 1991
Date: Fri, 8 Nov 91 23:49:20 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #2 - NSE <-> Avocet considerations
Content-Type: text
Content-Length: 1210
X-Lines: 29
Status: RO

There are a few considerations you should keep in mind when
using Avocet with an NSE environment.


First, Avocet doesn't obey any of the NSE environment locks.
Avocet will lock with itself so that, for instance, two nseputbacks
can't occur to the same NSE environment at the same time, but
Avocet won't lock against NSE operations happening at the same
time as Avocet operations.

This will rarely be a problem for nsebringover, but it is important
to coordinate nseputbacks with NSE reconciles.  One way to do this
is to use the NSE environment locks; be sure to acquire the NSE
lock before doing an nseputback.


Second, after an nseputback, none of the changes will be available
to other NSE children environments until a preserve is done in the
parent environment.  An NSE reconcile will do this preserve automatically,
but nseputback requires you to do it by hand.  Because of this, it is
generally simpler to not mix NSE children and Avocet children of the
same environment.  If you do mix, you'll need to do a preserve when
you want to make the changes integrated with Avocet available to the
NSE children.



Needless to say, neither of these issues are problems when using a
pure Avocet environment.

From shannon@datsun Fri Nov  8 16:31 PST 1991
Date: Sat, 9 Nov 91 00:31:28 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #3 - new Avocet release
Content-Type: text
Content-Length: 2373
X-Lines: 51
Status: RO

A new release of Avoet has been installed on dunk:

	4.1:	dunk:/sdet/4.x.avocet
	5.0:	dunk:/sdet/5.x.avocet

Here's the writeup from the Avocet group describing the changes in
this new release:

This release includes several new features:

1) Access control.  When a workspace is created, it is given an
   access control file in the avocet directory.  This file provides
   control over who can bringover and putback to and from the workspace,
   who can delete the workspace, etc.  Existing workspaces don't have
   an access control file so, as bringover and putback encounter these
   workspaces, they will be given a default access control file.

2) An undo command.  Bringover and putback make backup copies of
   files before they update them.  The undo command will restore the
   backup copies and undo the effects of the bringover or putback.
   There is just one level of undo, that is, only the most recent
   bringover or putback command can be undone.

3) Bringover and putback now have a -a (all) option.  This option
   tells the commands to operate on all of the child workspace.
   Bringover and putback maintain a file ("args") in the avocet 
   directory that contains a description of all of the workspace.  
   For example, if you have brought over five different directories, 
   then the args file will contain the name of the five directories. 
   After the initial bringover, putback -a and bringover -a can be
   used.

4) An nsegetsdot command.  This command is useful for people using
   nsebringover and nseputback.  It is an NSE command that can be used
   to make sure an NSE environment has all its s-files.  For nsebringover
   to work properly, an NSE env must have all its s-files.  Since this
   is an NSE command it is available for 4.x only.

Bug fixes include:

1) Bringover-create -n was failing because it was trying to chdir
   to the workspace that would be (but was not) created.  Reported
   by Bill Shannon.
2) Bringover-create deletes the newly created workspace if it is unable
   to bringover any files.
2) Man pages for nsebringover and nseputback.
3) Bringover and putback now catch signals and clean up their locks.
4) Bringover and putback now complete their first pass to find all
   potential errors.  Reported by Mike Federwisch.
5) Added a -f (force) option to workspace reparent.  Requested by
   Mike Federwisch.

From shannon@datsun Tue Nov 12 00:59 PST 1991
Date: Tue, 12 Nov 91 00:58:39 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #4 - performance
Content-Type: text
Content-Length: 1071
X-Lines: 43
Status: RO

I did some simple, non-scientific benchmarks of nsebringover.  I did
an nsebringover of usr/src/uts from i-mt5 to my 5.0 machine and to my
4.1 machine.  In both cases the files were brought over to a local
disk.  The benchmark environment was not controlled in any manner,
and the results are very likely unrepeatable.  Here's what I got:

4.1
    initial bringover
	30:27.4 real
	 4:10.1 user
	 9:23.2 sys

    null resync bringover
	15:15.6 real
	 1:02.9 user
	 6:01.3 sys

5.0
    initial bringover
	37:17.3 real
	 3:33.7 user
	15:04.4 sys

    null resync bringover
	22:40 real
	 1:16 user
	10:52 sys

There were 1735 files involved, 47MB (SCCS files and clear files).

In addition, Tadd did a bringover of all of usr/src:

The bringover of all of usr/src for the phobos workspace finished on
dunk, a 4/390 running 4.1.1.  Here is the summary and time:

Summary:
        New files: 11495

1139.7u 2554.0s 2:18:48 44% 0+1120k 34256+109357io 20604pf+0w


That 2 hour bringover compares to something like 8 hours or more
for an acquire of all of SunOSint using the NSE.

From shannon@datsun Tue Nov 19 00:47 PST 1991
Date: Tue, 19 Nov 91 00:18:05 PST
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #5 - native kernel builds
Content-Type: text
Content-Length: 961
X-Lines: 19
Status: RO

Doing native kernel builds on 5.0 requires a little trickery.
The Makefiles are currently set up to do the builds on a 4.x
machine.  Different people have been using different techniques
to get around this.  I've come up with what I think is a simple
way to deal with this.

The kernel Makefiles explicitly call /usr/bin/cc when they need
the native compiler.  They also pass arguments that are recognized
by the 4.x cc command, but not by the 5.0 cc command.  Since there
is no /usr/bin/cc program on 5.0 (it lives in /usr/ccs/bin), I've
created a simple shell script to replace /usr/bin/cc which understands
the few 4.x-specific options the kernel Makefiles use and translates
them to the 5.0 equivalents.

I've placed my /usr/bin/cc shell script in the 5.0 Avocet bin directory
as usr_bin_cc.  If you're building the kernel on your 5.0 machine, you
should copy this shell script to /usr/bin/cc.

If you have any problems with this shell script, let me know.

From cmh@kipling  Mon Nov 18 17:13:26 1991
Date: Mon, 18 Nov 91 17:10:37 PST
From: cmh@kipling (Claire Hayes Giordano)
To: cal-dev@benet
Subject: Avocet update #6 -- SunOS workspace hierarchy
Cc: sdet@plunge, cal-cteam@benet
Content-Length: 3089
X-Lines: 86
Status: RO


The train workspace is located on:

	/net/dunk/sdet/train

The workspace roadmap for future ON development is as follows:

	((--------------------------))
	(( SunOSint a.k.a. Callisto ))
	((--------------------------))
		      |
		      |
	[[--------------------------]]
	[[ intchild a.k.a. buffer   ]]
	[[ /net/dunk/sdet/intchild  ]]
	[[--------------------------]]
		      |
		      |
	[[--------------------------]]
	[[          phobos	    ]]	
	[[ TBD... in B15 somewhere  ]]
	[[--------------------------]]
		      |
		      |
	[[--------------------------]] 
	[[	    train           ]]
	[[   /net/dunk/sdet/train   ]]
	[[--------------------------]]


((--))	NSE Environment

[[--]]	Avocet Workspace 

|
|	parent/child relationship

	... Where to work:

Anyone wanting to do Callisto bug fixing for Jupiter should continue 
work under one of the cal-big7 NSE i-team envs that are children of 
SunOSint.  Coordinate with the i-team leader with regard to policies.

Anyone wanting to contribute to Phobos development for Mars, an SMCC 
managed release, should work under the Phobos workspace.  Details 
regarding integration to Phobos will be handled by the SMCC group.  
Send mail to phobos-int@crissy with questions about Phobos integration.

Anyone wanting to contribute to Titan development for Saturn should 
work under the Train workspace.  Details regarding integration to the 
Train will be handled by the OST (Ostech) integration group, a.k.a.
cal-int@benet.  Titan integration and consolidation policies are 
still being worked.  For now, feel free to bringover a child and 
start your development.

	... Things to know:

	(1) We are going to be integrating some Makefile changes 
into the top Avocet workspace (the buffer) in the near future.  These 
Makefile changes will support native builds of ON sources on 5.0 
machines.  We will let you know when this happens.

	(2) Although avocet reparenting allows you to reparent between 
any Avocet workspace, there will be OST policies about the direction 
in which one can reparent.  Reparenting between workspaces integrating
into the same release, such as sibling i-team workspaces, will be 
allowed.  However, as you try to reparent between different releases, 
reparenting will ONLY be allowed from release N to release N+X.  Thus, 
you can reparent from Phobos to the Train, but not vice-versa.

Thus, if in doubt about which release to work under, work under 
the earliest release.  In the example above, work under the Phobos 
workspace, since ideally all Phobos changes are absorbed into the 
Train anyway, and you can reparent later if necessary.

	(3) Since the NSE doesn't handle sccs file histories in the way
that one might like, OST policies will also restrict reparenting an
Avocet workspace from under the NSE i-team environments to the new
post-Callisto Avocet hierarchy.  Just don't do it.  If you have an 
Avocet workspace under i-ddifix, don't expect to reparent it to the 
Train.  

	(4) We have named SunOSint's sccs file history as the history 
that we will carry into development of future releases.



From cmh@kipling  Tue Nov 19 16:11:26 1991
Return-Path: <cmh@kipling>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10491; Tue, 19 Nov 91 16:11:26 PST
Received: from kipling.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09852; Tue, 19 Nov 91 16:17:46 PST
Received: by kipling.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01942; Tue, 19 Nov 91 16:13:31 PST
Date: Tue, 19 Nov 91 16:13:31 PST
From: cmh@kipling (Claire Hayes Giordano)
Message-Id: <9111200013.AA01942@kipling.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New alias:  osnet-sde@stufff
Content-Length: 857
X-Lines: 22
Status: RO

I've created a new alias, osnet-sde@stufff.  It is an alias similar 
to 5-0nse with a name that is release independent.
  
We intend to use this alias for future "Avocet update" mail and mail 
regarding new Avocet deliveries installed on dunk.  It can also be 
used for informational exchange among developers regarding Avocet,
etc.

The alias currently defaults to cal-dev@benet and sdet@plunge.
If others would like to be on the alias, do not send mail to
the alias itself.  Rather, use:

	osnet-sde-request@stufff

An archive of this alias resides on the machine dunk.  If you
mount Avocet binaries from dunk:/sdet/{4.x.avocet,5.x.avocet},
you will see a hard link to this archive in the doc subdirectory.
This archive includes all the "Avocet update" mail that Bill
Shannon has already sent and the "NSE-->Avocet Transition" mail 
which I sent.

Claire

From shannon@datsun Tue Nov 19 15:57 PST 1991
Date: Tue, 19 Nov 91 23:56:26 GMT
From: shannon@datsun (Bill Shannon)
To: cal-dev@datsun
Subject: Avocet update #7 - another new version of Avocet
Content-Type: text
Content-Length: 1028
X-Lines: 21
Status: RO

A new release of Avocet has been installed.  It contains a 
few bug fixes over the previous releases.

1) Resolvetool would core dump if run on a workspace with an NSE 
   environment as its parent.  This has been fixed.  Reported by 
   Richard Zatorski.

2) The window system programs, filemerge, fileresolve and resolvetool,
   were not built to find the C++ runtime library in /usr/local.  They 
   were built to look in /usr/dist only.  They should now run in either 
   world.  Reported by Richard Zatorski.

3) Smoosh had a bug where it would choke on files with very long single
   line comments.  Smoosh's line length has been changed to be compatible
   with the rest of SCCS.  It was changed to 1024.  Reported by Bill
   Shannon.

4) If you are a 4.x user and have Avocet mounted somewhere other than
   /usr/avocet or are a 5.0 user and mount Avocet somewhere other than
   /opt/avocet then you should set the environment variable AVOCETHOME
   to indicate where Avocet can be found.  Reported by Richard Zatorski.

From tadd@widor  Mon Dec  9 10:44:40 1991
Return-Path: <tadd@widor>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29689; Mon, 9 Dec 91 10:44:40 PST
Received: from widor.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA21643; Mon, 9 Dec 91 10:46:01 PST
Received: by widor.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00683; Mon, 9 Dec 91 10:47:09 PST
Date: Mon, 9 Dec 91 10:47:09 PST
From: tadd@widor (Tadd Ottman)
Message-Id: <9112091847.AA00683@widor.Eng.Sun.COM>
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Precedence: junk
Content-Length: 2425
X-Lines: 57
Status: RO



	In response to Evan's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.
See:
    dunk:/sdet/5.x.avocet
    dunk:/sdet/4.x.avocet

	Evan's message said this about the new delivery:

1) A short-term partial rename solution has been implemented.  Nsebringover, 
   bringover, nseputback and putback all detect renames.  Nsebringover and 
   bringover assume the files in the parent were renamed and will propagate 
   the renames to the child.  Nseputback and putback also assume the files
   in the parent were renamed and will not putback any files when renames 
   are detected.

   The net affect of this short-term solution is that renames must be done 
   in the parent and then they will propagate down to all the children.  The 
   long-term solution will support propatating renames both up and down the
   workspace hierarchy.

   This technique is very similar to nselite's rename algorithm with the
   addition that rename detection is built into the commands so users are
   not required to run a separate program.  The rename code is invoked 
   only when renamed or new files are found.

   The message

	Examining names of files: NNN

   indicates that the rename algorithm is being invoked.

2) There is a first draft of an Avocet Overview document.  It is in
   doc/avo_overview.ps in the distribution directories.

3) nsegetsdot had a bug where it would not check for any files under 
   under a symlink to a directory.  This most commonly occurred with
   the control point /usr/src which is a symlink on most machines.
   This has been fixed.  Reported by Loran Ball and Jian Yuan Peng.

4) Avocet now makes use of the /net automounter map to find the
   parent workspace.  This results in better overall interactions
   with the automounter.  Requested by Mike Federwisch and Greg Onufer.

5) Filemerge would complain about unsaved edits when invoked from 
   resolvetool and when resolving more than one file.  Reported by
   Claeton Giordano.

6) Several improvements to resolvetool.  The scrolling list correctly
   resizes when the window is resized.  Double clicking in the scroll
   bar was being mistakenly interpreted as a double click on the adjacent 
   item in the scrolling list.  Resolvetool now writes to the cmdlog and 
   history files.  Reported by Mike Federwisch.



From tadd@widor  Thu Jan  9 17:54:30 1992
Return-Path: <tadd@widor>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA02168; Thu, 9 Jan 92 17:54:30 PST
Received: from widor.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07560; Thu, 9 Jan 92 17:56:10 PST
Received: by widor.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01574; Thu, 9 Jan 92 17:57:40 PST
Date: Thu, 9 Jan 92 17:57:40 PST
From: tadd@widor (Tadd Ottman)
Message-Id: <9201100157.AA01574@widor.Eng.Sun.COM>
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Precedence: junk
Content-Length: 2002
X-Lines: 53
Status: RO



	In response to Evan's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

	Evan's message said this about the new delivery:

Highlights:
	- Significant performance improvements
	- TTY resolve program
	- Bug fixes

Details:
1) This release of Avocet includes significant performance improvements.
   A bringover-create takes about 2/3 of the time it did before and a
   bringover that checks all the files but does not have to update any
   of them takes about 1/3 of the time it did before.

2) There is now a TTY resolve program called resolve_tty.  It is useful
   for resolving conflicts when there is no window system available and
   also as an expert mode.

3) The program smoosh has been renamed to sccsmerge to avoid confusion
   with nselite's and the bridge's smoosh programs.

4) Sccsmerge signatures.  When nseputback adds new deltas to an NSE env
   sccsmerge adds a line to each new delta's comment indicating who made 
   the change and when.  Requested by Joe Kowalski.

5) There is a README file in the distribution directories that gives
   step by step instructions for getting started.

6) Bringover and putback now send mail messages to a log file recording
   statistics.  Mail is sent via /bin/mail to avoid cluttering up user's
   outfolders.  Mail can be supressed by setting the shell environment 
   variable AVOCET_NOMAIL.
   
7) Sccsmerge bug fixes.  Sccsmerge now handles missing serial numbers and 
   deltas with exactly the same time.  Reported by Bill Shannon and
   Claire Giordano.

8) Checknames bug fixes.  Checknames is the program used to detect renames.
   Several bugs reported by Bill Shannon.

9) Bringover now supports bringing over from a non-workspace parent.

10) Fileresolve dumped core if the parent was an NSE env.  Reported by
    Tadd Ottman.


From msw@polyslo  Thu Jan  9 21:11:18 1992
Return-Path: <msw@polyslo>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA02546; Thu, 9 Jan 92 21:11:18 PST
Received: from polyslo.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07618; Thu, 9 Jan 92 21:12:50 PST
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00444; Thu, 9 Jan 92 21:09:51 PST
Date: Thu, 9 Jan 92 21:09:51 PST
From: msw@polyslo (Mike Walker)
Message-Id: <9201100509.AA00444@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 588
X-Lines: 22
Status: RO



	In response to Claeton's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet

	Claeton's message said this about the new delivery:


A show-stopping bug in the 5.0 version of bin/checknames has been
fixed, and a new version has been installed in the distribution.

This fixes the following problem with 5.0 bringover/putback:

	5.0 bringover and putback exit after printing:

		Examining names of files
		Alarm Clock

Claeton

From msw@polyslo  Fri Jan 10 10:34:28 1992
Return-Path: <msw@polyslo>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA02746; Fri, 10 Jan 92 10:34:28 PST
Received: from polyslo.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07845; Fri, 10 Jan 92 10:35:52 PST
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00812; Fri, 10 Jan 92 10:32:53 PST
Date: Fri, 10 Jan 92 10:32:53 PST
From: msw@polyslo (Mike Walker)
Message-Id: <9201101832.AA00812@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 388
X-Lines: 17
Status: RO



	There was a small administrative error with last night
distribution of Avocet.  The fixes that were sent out last night
were not actually distributed.  They have now been placed on
dunk.  Please bring a new copy over.

  for 5.x avocet, see    dunk:/opt/avocet

The only relevent file that you will need to update is:

	dunk:/opt/avocet/bin/checknames

Thanx for you patience

_Mike_


From msw@polyslo  Tue Jan 28 19:58:23 1992
Return-Path: <msw@polyslo>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05850; Tue, 28 Jan 92 19:58:23 PST
Received: from polyslo.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00278; Tue, 28 Jan 92 19:58:51 PST
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA04386; Tue, 28 Jan 92 19:55:36 PST
Date: Tue, 28 Jan 92 19:55:36 PST
From: msw@polyslo (Mike Walker)
Message-Id: <9201290355.AA04386@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 2727
X-Lines: 66
Status: RO



	In response to Claeton's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

Important:	If you mount Avocet from dunk, to "see" the new release
	you need to umount your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.  Until you remount
	or reboot, you will continue to "see" the previous release.


	Claeton's message said this about the new delivery:

Details:

1. Option to turn off rename checking.  When passed the '-r' option,
   bringover, putback, nsebringover and nseputback skip rename
   checking.  This is useful when bringing new files into and existing
   workspace and you *know* that there are no renames to deal with.
   This risk is that you won't pick up some renames.  If a file is
   named "bar" in parent and "foo" in the child, then instead of
   renaming foo to bar in the child, Avocet will create a new file name
   "bar" in the child.  And, any updates that should go into "foo" end
   up in "bar".  There are two new access-control fields that control
   who has permission to bringover and putback into a workspace using
   the '-r' option.  The default settings follow:

	skip-renames-bringover-to 
	skip-renames-putback-to -

   Simply put, the defaults allow anyone to skip rename checking on
   bringover but prevent anyone from skipping rename checking on
   putback.

2. Option to not do sccs gets.  When passed the new '-g' option,
   bringover and putback skip the 'sccs gets'.  When this option is
   specified at bringover-create time, the new workspace will be
   populated with SCCS files but no G-files.  Because the the 'sccs
   gets' are handled concurrently, they do not slow bringover and
   putback very much.  So using this option does not yield a large
   performance win.

3. The '-a' option has been made obsolete.  Instead of passing the -a
   option to bringover or putback those files and directories listed in
   the "args" meta-data file, users can now just pass no file/dir
   arguments:

		OLD				NEW
	bringover -w ~/ws -a	->	bringover -w ~/ws

4. Bug Fix.  A core dump in resolve_tty has been fixed.  Reported by Len
   Brown.

5. Bug Fix.  Checknames checks to see if either workspace is empty.  If
   one is empty, it doesn't check for renames because there can't be
   any.  Reported by Scott Wilson.

6. Duplicate SmIDs.  The semantics of Avocet's behavior when two or
   more files with the same first delta are encountered have been
   relaxed a little.


From cmh@kipling  Tue Feb  4 12:30:53 1992
Return-Path: <cmh@kipling>
Received: from Eng.Sun.COM (zigzag) by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10111; Tue, 4 Feb 92 12:30:53 PST
Received: from stufff.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA13303; Tue, 4 Feb 92 12:28:00 PST
Received: from kipling.Eng.Sun.COM ([129.144.50.202]) by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04595; Tue, 4 Feb 92 12:23:14 PST
Received: by kipling.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00742; Tue, 4 Feb 92 12:15:54 PST
Date: Tue, 4 Feb 92 12:15:54 PST
From: cmh@kipling (Claire Giordano)
Message-Id: <9202042015.AA00742@kipling.Eng.Sun.COM>
To: aronf@gryphon
Subject: Re: avocet: nsebringover failed
Cc: osnet-sde@stufff
Content-Length: 581
X-Lines: 17
Status: RO

Aron,

The osnet-sde alias is for discussions/q&a within the osnet groups
about software development environment tools.  

It is also used for broadcasts of updates to the avocet binaries and 
for Bill Shannon's "Avocet update #" messages.

The alias is archived in the dunk:{usr,opt}/avocet/doc directories.

There is no avocet membership on the alias, hence no one from avocet
will see your mail.  If you encounter any problems with the avocet
tools and have questions for the avocet group, please send your mail to:

	avocet-bugs@icarus (a.k.a avo-bugs@kepler)

Claire Giordano

From msw@polyslo  Wed Feb  5 09:36:18 1992
Date: Wed, 5 Feb 92 09:34:21 PST
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, 5.0nse@stufff
Subject: Update to Execset
Content-Length: 836
X-Lines: 32
Status: RO





There has been an update to the doublecross component of the execset
located on frop. If you have a copy of this execset it should be
updated from frop.  

Note:  The only component that has been updated is:

	usr/bin/.doublecross

	Because .doublecross has so many hard links to it you must
	be carefull to update it by copying the new .doublecross over
	your original doublecross to preserve the links.

	% cp .doublecross .doublecross.old
	% cp /net/frop/crossroot/usr/bin/.doublecross ./.doublecross


Fixes
-----

There are two fixes in the new .doublecross, they are:

1)  The C++ compiler would not work outside of the NSE environment.

2)  The number of arguements you could pass to any command was limited
    to 512.  We finally exceeded this limit in building libc.so.  The
    limit has now been raised to 1024.

_Mike_

From msw@polyslo  Wed Feb 26 15:42:37 1992
Date: Wed, 26 Feb 92 15:33:48 PST
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet updated on host dunk
Content-Length: 1898
X-Lines: 51
Status: RO


	In response to Evan's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

Important:	
	If you mount Avocet from dunk, to "see" the new release
	you need to umount your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.  Until you remount
	or reboot, you will continue to "see" the previous release.


Highlights:
        - Nsebringover and nseputback obey NSE locking
	- New ToolTalk interface between resolvetool and filemerge
        - Many bug fixes 
 
Warning:
       Avocet will drop support of pre-prebeta1 versions of
       SunOS in a future release.    Avocet releases delivered after
       3/16/92 will require SunOS prebeta1 or newer.    This release
       of Avocet supports pre-prebeta1 versions of SunOS.


Details:

1. Nsebringover and nseputback now obey NSE locking as they will
   try to obtain NSE locks in the parent environment.  Requested
   by Joe Kowalski.

2. Resolvetool and filemerge communicate over a new ToolTalk interface.
   Dynamic ToolTalk messages are used rather than static ones so resolve
   no longer needs to check if the proper ToolTalk ptypes are installed.

3. Warnings and errors that occur while files are being propagated
   are now written to the avocet/history file.  Requested by Len Brown.

4. Fixed an sccsmerge bug regarding a gap in the serial numbers of
   an s-file.  Reported by Phillip Saeli and Len Brown.

5. Added the workspace list subcommand.

6. Added a -c option to nsegetsdot to avoid copying the parent's s-file
   and always create a new s-file in the child.  Requested by Claire
   Giordano.

7. Many other minor bug fixes.

From msw@polyslo  Thu Mar  5 17:20:49 1992
Date: Thu, 5 Mar 92 17:20:51 PST
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet Patch Update on host dunk
Content-Length: 963
X-Lines: 26
Status: RO



	The Avocet release on dunk has been updated to include the
latest patch fix for nseputback.  Because this is just a patch to
nseputback I have updated it in the most current release being exported
from dunk - you will not need to re-mount this release.

	For those of you who have local copies you can get the newest
patch from:

  	for 5.x avocet, see    dunk:/opt/avocet
  	for 4.x avocet, see    dunk:/usr/avocet

Highlights:
        - New version of nseputback with bugfix.

Details:

1. When you do a nseputback to a NSE environment it will also place
   an avocet lock on the same NSE environment.  If the NSE environment
   was already locked then nseputback would quit without removeing the
   avocet lock that it created.  The next time you attempted to do an
   nseputback it would see the avocet lock and core dump.  

   This release fixes the bug, nseputback will now remove it's lock
   if it sees that the NSE environment has a lock against it.

From msw@polyslo  Wed Mar 11 18:42:29 1992
Date: Wed, 11 Mar 92 18:41:13 PST
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet Patch Update on host dunk
Content-Length: 766
X-Lines: 25
Status: RO




	The Avocet release on dunk has been updated to include the
latest patch fix for bringover, putback, nsebringover, nseputback and
undo. I have updated it in the most current release being exported from
dunk - you will not need to re-mount this release.

	For those of you who have local copies you can get the newest
patch from:

  	for 5.x avocet, see    dunk:/opt/avocet
  	for 4.x avocet, see    dunk:/usr/avocet

Highlights:
        - New versions of bringover, putback, nsebringover, nseputback,
	  and undo with bufixes.

Details:

The earlier release contained a bug that would result in a core dump
if a lock was encountered.  The problem was that in formatting a message
about the lock a malloc'ed buffer was overwritten and a core dump resulted.

	Evan

From msw@polyslo  Thu Mar 19 14:15:08 1992
Date: Thu, 19 Mar 92 14:15:18 PST
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 918
X-Lines: 28
Status: RO



	The OS-group reference copy of avocet binaries has been updated
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

Important:	
	If you mount Avocet from dunk, to "see" the new release
	you need to umount your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.  Until you remount
	or reboot, you will continue to "see" the previous release.


Highlights:
        - Updated copy of ws and supporting man pages
	- Updated def.dir.flg

Details:

1. New version of the ws script with support for the new construction
   sets for 5.x builds.

2. New version of def.dir.flg to support the inc.flg's and req.flg's
   that are now in the phobos source base.  A full explanation of
   these will follow in an avocet update message.

From cmh@kipling  Mon Apr  6 11:54:07 1992
Date: Mon, 6 Apr 92 11:49:28 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet update #8 -- Reparenting between callisto and phobos
Content-Length: 1356
X-Lines: 32
Status: RO


Recently as some developers have transitioned away from Callisto
development and toward Phobos development, they have wanted to
reparent their avocet workspaces. 

There is a policy for developers of the OsNet source base that advises
developers **NOT** to reparent a workspace currently a child of the Callisto 
hierarchy over to the Phobos or Titan source hierarchies.

Note that any avocet child, grandchild, or greatgrandchild in the
Callisto hierarchy has this restriction.

The avocet product allows you to reparent any avocet workspace,
assuming you have the access control to do so.  Hence this policy is
not the result of an avocet limitation, but rather it's the result of
Nse limitations.  

If you try to reparent between Callisto and Phobos/Titan, the sccs file 
histories will not match due to the way the Nse manipulates sccs 
file histories.  You will end up with myriads of conflicts and even 
if you resolve these conflicts, a putback would place the incorrect 
sccs file history into the parent workspace and would cause problems
for many other developers.  Please do *not* do this.

This is a short term restriction that we will leave behind us as
we leave the Nse behind us.

If you have any questions or concerns, let me know.

FYI:
	Callisto:  OsNet portion of Jupiter consolidation 
	Phobos:    OsNet portion of Mars consolidation

From cmh@kipling  Tue Apr  7 18:48:21 1992
Date: Tue, 7 Apr 92 18:43:38 PDT
From: cmh@kipling (Claire Giordano)
To: koreth@kipling, sarito@kipling, osnet-sde@stufff
Subject: Re:  .KEEP_STATE and .make.state files
Cc: avo-users@kepler
Content-Length: 939
X-Lines: 26
Status: RO

> Question time:  Since we're not using NSE, is there a good reason
> to activate .KEEP_STATE in the makefiles?

Since this isn't an avocet question, it's better directed at the

	osnet-sde@stufff

alias, the post-Callisto equivalent of 5-0nse@stufff.

The answer is that .KEEP_STATE is valuable with or without the NSE.
Yes, there is a good reason to use it in the Makefiles.

Available docs re .KEEP_STATE will make this obvious.  Unless we want
to return to the days of using make depend, .KEEP_STATE is the only
mechanism that creates and updates the .make.state file, allowing for
appropriate rebuilds when the graph of header file dependencies changes.

I'm told that the problem you encountered:

	file_lock: .make.state is already locked, waiting

occurs after a ctrl-c on a build which leaves a lock file around or
during concurrent builds on the same source base on the same filesystem
which are running into each other.

Claire

From cmh@kipling  Tue Apr  7 19:24:21 1992
Date: Tue, 7 Apr 92 19:19:46 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet update #9 -- locations of phobos/titan workspaces
Cc: cal-mgrs@benet
Content-Length: 2250
X-Lines: 58
Status: RO

	The phobos aspect of this message is geared only at phobos 
	developers who work in the OST and DCT organizations in 
	SunSoft.  Clearly if you work in SMCC you will use other 
	workspaces to interface with phobos.

>> Question: From where can I bringover an avocet child of Phobos?

OST and DCT will use an "i-team" model to batch bug fixes and
contributions together before integrating into Phobos.  Consider
this "i-team" workspace a child of the Phobos integration workspace.

Mike Federwisch is the initial gatekeeper for this "i-team" avocet
workspace, called SS1.  In time, a second workspace will be available;
its proposed name is SS2.  You can find SS1 on:

	berlin:/wrksp/SS1 **

>> Question: From where can I bringover an avocet child of Titan?

The titan integration workspace, called the train, is managed
by the ON integration group.  You can find the train on:

	dunk:/build/train **

** Both SS1 and the train are in sync with ON-8.1 (jup-beta2)
and phobos dev2.1.  Both workspaces are currently available for
bringover but not yet available for putback.

>> Question: What if I don't know whether to do my work under
the phobos hierarchy or the titan hierarchy?

Ed Hunter has sent out mail advising developers of the phobos CRT
and phobos integration policies.  I've appended his message.

If you are unsure nonetheless, the general recommendation is to 
bringover your workspace from the **earliest** release possible 
and to reparent to a later release if necessary.  Why?

If you were to reparent from the later release (titan) to the 
earlier release (phobos), you might accidentally introduce
titan-specific changes into phobos.  This type of reparenting will 
be restricted.

Since all phobos changes will be absorbed into titan, reparenting
from phobos to titan will not introduce any release-specific
and unwanted changes into titan.  So bringover from phobos if
you are unsure and reparent with ease later.

>> Question:  Why isn't there an avocet workspace NIS or NIS+ map
so that I don't have to remember all these pathnames?

We're working on it, we're working on it.  Soon.

>> FYI:

	Phobos:    OsNet portion of Mars consolidation
	Titan:     OsNet portion of 4/93 consolidation 
			(4/93 was formerly named Saturn)

From plocher@attaboy  Tue Apr  7 21:30:47 1992
Return-Path: <plocher@attaboy>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11691; Tue, 7 Apr 92 21:30:47 PDT
Received: from attaboy.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05589; Tue, 7 Apr 92 21:26:11 PDT
Received: by attaboy.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01825; Tue, 7 Apr 92 21:31:11 PDT
Date: Tue, 7 Apr 92 21:31:11 PDT
From: plocher@attaboy (John Plocher)
Message-Id: <9204080431.AA01825@attaboy.Eng.Sun.COM>
To: cmh@kipling
Subject: Re:  .KEEP_STATE and .make.state files
Cc: osnet-sde@stufff
Content-Length: 1720
X-Lines: 50
Status: RO


The only problem is that .KEEP_STATE: does not handle the case where I have
a source file like this:

#include <stdio.h>
#include <project/config.h>
#ifdef SVR4		/* Just an example, don't shoot me :-) */
#include <something.h>
#else
#include <other.h>
#endif

and I try to do builds for both OSs in the same src tree.  (sending the
obj files to different places, of course :-)
The dependency graph for file.c will be wrong for one of the builds.
(Of course, without REAL conditional makefiles, I can't really do it
right anyways without jumping through lots of hoops...)

On a related note, how can one handle the case where I have an object file
that requires special CPPFLAGS (or other special handling) without kludges
like hard coding stuff like:

	include ${TOPDIR}/Master.rules.mk
	SPECIAL_CPPFLAGS	= -DSPECIAL
	...
	Obj/optimized/foo.o: foo.c
		${CC} ... ${SPECIAL_CPPFLAGS} ...

or using a "conditional" like:

	Obj/optimized/foo.o :=	CPPFLAGS += ${SPECIAL_CPPFLAGS}

Both of these force me to hard code implementation details into
my Makefiles.  What if I now wish to introduce a "debug" or "tcov" or
"saber"... build method - I have to hand edit all my Makefiles
to add "variants" of the above special case code instead
of just adding targets to Master.rules.mk.  Not a good thing.


   -John


|The answer is that .KEEP_STATE is valuable with or without the NSE.
|Yes, there is a good reason to use it in the Makefiles.
|
|Available docs re .KEEP_STATE will make this obvious.  Unless we want
|to return to the days of using make depend, .KEEP_STATE is the only
|mechanism that creates and updates the .make.state file, allowing for
|appropriate rebuilds when the graph of header file dependencies changes.


From dmk@dobbs  Wed Apr  8 16:50:21 1992
Return-Path: <dmk@dobbs>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12069; Wed, 8 Apr 92 16:50:21 PDT
Received: from dobbs.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06350; Wed, 8 Apr 92 16:44:27 PDT
Received: from noho.Eng.Sun.COM by dobbs.Eng.Sun.COM (4.1/SMI-4.1)
	id AA21159; Wed, 8 Apr 92 16:48:41 PDT
Date: Wed, 8 Apr 92 16:48:41 PDT
From: dmk@dobbs (David Kahn)
Message-Id: <9204082348.AA21159@dobbs.Eng.Sun.COM>
To: cmh@kipling, plocher@attaboy
Subject: Re:  .KEEP_STATE and .make.state files
Cc: osnet-sde@stufff
Content-Length: 97
X-Lines: 5
Status: RO


Obviously, with conditional includes, you can't do both builds in the
same source tree.

-David

From tadd@widor  Thu Apr  9 19:25:21 1992
Return-Path: <tadd@widor>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12510; Thu, 9 Apr 92 19:25:21 PDT
Received: from widor.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08111; Thu, 9 Apr 92 19:19:42 PDT
Received: by widor.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05046; Thu, 9 Apr 92 19:23:45 PDT
Date: Thu, 9 Apr 92 19:23:45 PDT
From: tadd@widor (Tadd Ottman)
Message-Id: <9204100223.AA05046@widor.Eng.Sun.COM>
To: plocher@attaboy
Cc: osnet-sde@stufff
In-Reply-To: John Plocher's message of Tue, 7 Apr 92 21:31:11 PDT
Subject:  KEEP_STATE and .make.state files
Precedence: junk
Content-Length: 795
X-Lines: 26
Status: RO


John,

> The only problem is that .KEEP_STATE: does not handle the case where I have
> a source file like this:
> 
> #include <stdio.h>
> #include <project/config.h>
> #ifdef SVR4		/* Just an example, don't shoot me :-) */
> #include <something.h>
> #else
> #include <other.h>
> #endif
> 
> and I try to do builds for both OSs in the same src tree.  (sending the
> obj files to different places, of course :-)
> 

	We work around this in our source tree by placing into
empty directories small makefiles that include a common makefile
from above and use its rules to build objects with definitions
local to the small makefile.  The empty directory becomes populated
with the unique objects from those definitions and the .make.state
file correctly representing the dependency graph.

					Tadd

From tadd@widor  Mon Apr 20 15:34:14 1992
Date: Mon, 20 Apr 92 15:33:36 PDT
From: tadd@widor (Tadd Ottman)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 5181
X-Lines: 117
Status: RO



	In response to Evan's message on the availability of updated
Avocet binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

	================================================================
Important:	If you mount Avocet from dunk, to "see" the new release
	you need to *umount* your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!
	================================================================

	Evan's message said this about the new delivery:

A new release of Avocet has been installed.  The avocet releases are
now being named via a file in the distribution directory named Release.
This release is called Alpha2.  

Highlights:
	- this is the last Avocet release to support OpenWindows V2
	- GUI-based front-end for SCCS called 'vertool'
	- conflicts are handled differently, no more *.A and *.M files
	- better interaction with the automounter
	- workspace create/delete semantics have been tightened
	- many bugs fixes and RFEs

Upcoming:
	- the release after this one, currently scheduled for 4/30, 
	  will contain a new rename algorithm that is much, much
	  faster, eliminates the checknames program and allows
	  putbacks of renames.
 
Details:

1) Avocet will be dropping support for OpenWindows Version 2.  This
   will be the last release that supports OWV2, therefore the next 
   release will not include the fileresolve program.

2) This release includes vertool, sometimes known as SCCStool, which is a 
   GUI front-end to SCCS.  For more information, refer to README.vertool 
   in the distribution directory.

3) Conflicts are handled much differently.  
   Bringover no longer creates *.A and *.M files.  Instead, the information 
   about a conflict is remembered in the s-file and the resolve programs 
   materialize the ancestor and parent versions of the file during the 
   resolve procedure.  The programs resolve.old and resolve_tty.old are 
   supplied with this release for those situations where a conflict was 
   created with the old executables and still needs to be resolved.

4) As a result of 3), undo is more correct with respect to files in conflict.
   When undo restores a file that bringover found to be in conflict, the
   filename is now removed the conflicts file.  Reported by Len Brown
   and Bill Jackson.

5) The parent/children files interact better with the automounter.
   If a workspace is named thru an automounted directory then that
   name is remembered in the parent/children file.  Otherwise, the
   current machine:path name is remembered.  Requested by Scott Wilson,
   Terry Miller, and others.  Because of this change, some records in 
   the parent/children files will have a new format.  Unfortunately,
   the previous release's executables will dump core when they encounter
   this new format.

6) Semantics of workspace create/delete have changed.  By default,
   workspace create will not create a workspace on top of an existing
   directory.  The -d option can be used to override this.  By default,
   workspace delete will prompt for confirmation before removing
   a workspace and all its contents.  The -f option can be used to
   override this.

7) Bringover will no longer create a workspace over an existing 
   directory.  This coupled with 6) solves the problem reported by
   Billy Fuller and Henry Yen where bringover mistakenly deleted
   a directory full of files.

8) Section 5 man pages for all the files in the avocet directory.

9) By default, each resolvetool uses it own filemerge.  Reported
   by Len Brown.

10) Accept parent/child functionality is now available in filemerge
    in addition to resolve_tty.

11) Fix to undo.  Undo will no longer invoke rename checking and
    when directories are specified it will remove "new" files in those
    directories.  Reported by Len Brown.  

12) When putback is blocked it now writes your comments into the
    file avocet/putback.cmt in the child workspace.  Requested by
    John Chapin.

13) Bringover and putback now have a -v (verbose) option where they
    will report the status of ALL files, not just the ones being 
    brought over or putback.  Requested by Len Brown.

14) Each Avocet binary contains an SCCS what string identifying its
    release.  The command line "what bringover | grep Release" shows
    you the release of the bringover command.  Requested by David
    Kahn.

15) The access_control file format has been enhanced to accept
    commas as separators into addition to the blanks, tabs, and
    colons it already accepted.  Suggested by Geoffrey Kimbrough
    in response to Christopher Klein's problem.

16) The checknames program now catches signals and cleans up its temp
    file in a workspace's avocet directory.  Reported by Tadd Ottman.

From cmh@kipling  Mon Apr 20 17:31:31 1992
Date: Mon, 20 Apr 92 17:30:13 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet update #10 -- doc roadmap for OsNet
Cc: cal-mgrs@benet
Content-Length: 3061
X-Lines: 105
Status: RO

	Documentation Roadmap for OsNet developers

	"@(#)roadmap	1.1	92/04/20 SMI"

This mail message is intended to provide a roadmap among the
available documentation for reference by OsNet developers.
Three types of documentation are described in this message:

	Release-independent documentation
	Release-specific documentation 
	Software Development Environment Tool information

There are gaps in the documentation and it has long been a goal
of OsNet to consolidate and organize this information in a 
more reasonable fashion that serves both novice and veteran
ON developers.  We're not there yet.

This roadmap will be sent out periodically, with changes indicated
by change bars.  Managers are responsible for supplying a copy to 
new employees.

Release-independent documentation:

		terminator:/usr/integration/doc 
				
	5.x_bld_info		Overview of ON native 5.0 builds.

	make.std		Makefile Standards and Guidelines.
				Slightly out of date, still valuable.

	roadmap			The latest version of *this* document.

	cstyle.ANSI		More current email from Bill Shannon
				regarding cstyle and ANSI C.

	cstyle.mm		Written as part of the contract with
				AT&T; a description of the C style
				to be followed for SVR4 work.  Almost
				everything applies to SunOS as well.

	cstyle.ms 		An historical document on which 
				the above document was based; this 
				was written for SunOS, but left far 
				too many choices to the developer.

	ON_pkgs.mm		Overview on ON packaging tools and 
				utilities.

	breakup_BWOS.ms		Breaking Up the BWOS.  Of historical 
				interest.

	historical/		Subdirectory which contains many
				documents of historical interest
				regarding 3.x, 4.x and 5.0 integration.

	
Release-specific documentation: 

...such as Request To Integrate (RTI) forms, the rti.template,
     schedule information, specific integration criteria, etc.

		wizard:/consolidation/callisto/integration/

		wizard:/consolidation/phobos/integration/

		wizard:/consolidation/titan/integration/


Software Development Environment Tool information:

...note that in buildings other than B5, local clones of the
avocet installation on dunk have probably been created for
OsNet use.

		dunk:/usr/avocet, for 4.x
		dunk:/opt/avocet, for 5.x

	bin/			avocet binaries
	man/			avocet man pages
	
	README			Written by the avocet team, modified
				by OsNet integration, a beginner's 
				guide to using avocet.

	README.vertool		Written by the avocet team, a 
				beginner's guide to using the GUI
				front-end to SCCS.

	doc/			avocet documentation, such as:

	doc/osnet-sde		Archive of the osnet-sde alias, 
				contains messages regarding the 
				transition to Nse from avocet.
				
	doc/avo_updates		Subset of the osnet-sde archive;
				contains the "Avocet update" 
				messages which contain info
				regarding OsNet specific tools 
				developed for use with avocet.

	doc/avo_overview.ps	Written by the avocet team, a 
				customer's overview of avocet. 

	doc/avocet_info		Written by the avocet team, an 
				avocet 10-pager; slightly out of date. 

From msw@polyslo  Wed Apr 22 11:13:27 1992
Date: Wed, 22 Apr 92 10:56:03 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update #11 -- Avocet File List Generators (FLG's)
Content-Length: 6748
X-Lines: 239
Status: RO



We have introduced a new default directory file list generator,
def.dir.flg, which can operate on input provided by files populated
among the ON source tree called req.flg and inc.flg.  These file list
generators (flg's) are meant to simplify the bringover process for
subsets of the ON source tree.  To build usr/src/stand/kadb you need
900+ source files, but only a small portion of them reside under the
usr/src/stand/kadb directory.  To make the bringover of
usr/src/stand/kadb and all of its supporting source files an atomic
operation we have introduced two new file list generators into the ON
source base.  They are:

	inc.flg:  List those files which do not reside under the
		current directory but are required in order to build
		the current directory.  For example, when you build
		usr/src/stand/kadb it requires several header files
		from usr/src/uts/common/*/*.h.  It would be the
		inc.flg's responsibility to list these files so that
		avocet can find them during a bringover or putback
		operation.

	req.flg:  List those files which are required if the specified
		directory is in the path of the directory you are
		bringinging over (bringover) or putting back
		(putback).  For example, there is a req.flg in the
		usr/src directory which lists Makefile.master.  When
		you perform a bringover on the usr/src/stand/kadb
		directory the req.flg would be executed and list
		usr/src/Makefile.master.


When a bringover or a putback operation is performed on a directory by
avocet our def.dir.flg scripts will generate a file list by doing the
following:

	1) Search in the current directory and every directory above
	   it to find a req.flg.  If one is found execute it to
	   generate a list of files.

	2) Search the current directory and every directory below it
	   for inc.flg's.  Execute each one that is found for an
	   additional list of files.

	3) Search the current directory and every directory below it
	   for all SCCS files, each of these is added to the file
	   list.  (Note: this is the default behavior)


These new flg's (req.flg & inc.flg) are now part of the ON source
base and under SCCS control.  Whenever you bringover a portion of
the ON source base the matching flg's will also be brought over as
part of the source.

So, now that we have introduced these new flg's when you issue
bringover's on specific directories you may get more than you expected.
For example, when you issue a bringover on the stand/kadb directory
you will not only get the source under stand/kadb but all the source
that is required to build the stand/kadb directory.  Some of the
additional directories you will get are:

	stand/kadb
	stand/lib
	uts/sunmmu
	uts/srmmu
	uts/common/sys
	uts/common/vm
	uts/common/os
	uts/common/rpc
	uts/common/nfs
	uts/adb
	cmd/adb/sparc
	...


We have introduced inc.flg's for the following directories components:

	usr/src/stand/kadb
	usr/src/stand/boot

And we have introduced req.flg's for the following directories:

	usr/src/req.flg
	usr/src/cmd/req.flg
	usr/src/lib/req.flg
	usr/src/ucbcmd/req.flg
	usr/src/ucblib/req.flg
	usr/src/uts/req.flg


Before I go into more detail there are a couple of points
I would like to make:
   
   1) The flg concept is still evolving in the avocet group and we can
      expect a new def.dir.flg from the avocet group in the future.
      When this happens we will have to modify what we have to fit
      under there new model (although it should only require minimal
      modifications).

   2) There is room for futher development on the inc.flg's and the 
      req.flg's.  If anyone would like to introduce some more of these
      into the source base I would very much like to help.  Just shoot
      me (msw@eng) an e-mail and we can put something together.



WARNING:  The following goes into a little more detail on how exactly
   	  the inc.flg's and req.flg's work.  You only need to read
	  this if you are interested.


Here is a practical example of how these are used in the ON source
base.  Given the following file structure:



			usr/src/
			   |
			   |
	     _____________/-\___________________
	    /	     /		 \		\
	 req.flg   uts/		stand/		 */
		    /		  |
		   */	      ___/-\________________
			     /		  \	    \
			   boot/	 kadb/	    */
			    /		   \
			 inc.flg	   inc.flg



When the following command 'bringover usr/src/stand' is performed avocet
is going to execute the following scripts and commands to generate
the list of files that will be brought over:

	usr/src/req.flg 
		- list all files that are required if you include usr/src
		  in your path - Lists Makefile.master	

	usr/src/stand/boot/inc.flg
	   	- list all files not under usr/src/stand/boot that
		  are required to build usr/src/stand/boot.
		
	usr/src/stand/kadb/inc.flg	
		- list all files not under usr/src/stand/kadb that are
		  required to build usr/src/stand/kadb.

	find usr/src/stand -name "s.*" -print
	  	- lists all SCCS files under usr/src/stand.  
	


For additional information here is what a couple of the above flg's
actually look like:


::::::::::::::
usr/src/req.flg
::::::::::::::
#!/bin/sh

#
# Any directory containing usr/src in it's path must have
# usr/src/Makefile.master.

echo_file usr/src/Makefile.master

::::::::::::::
usr/src/stand/kadb/inc.flg
::::::::::::::
#!/bin/sh

#
# find_files(pat,dirs...)
#
# pat   = pattern to pass to find
# dirs  = space separated list of directories for find to visit
#
find_files() {

   	pat=$1
   	shift

	for dir in $*
	do
	   if [ -d $AVOCET_WS_ROOT/$dir ]; then
	      find $AVOCET_WS_ROOT/$dir -name "$pat" -print | grep "/SCCS/s."
	   fi
	done

} # find_files()


echo_file() {
	#
	# Check to make sure a file exists, if it does then
	# echo it out.
	#
   	if [ -f $AVOCET_WS_ROOT/$1 ]; then
      		echo $1
   	fi
} # echo_file()


#
# Find all of the header files required for the build
#
find_files "s.*.h" \
           usr/src/uts/sunmmu\
           usr/src/uts/srmmu\
           usr/src/uts/common/sys\
           usr/src/uts/common/vm\
           usr/src/uts/common/os\
           usr/src/uts/common/rpc\
           usr/src/uts/common/nfs\
           usr/src/uts/sun\
           usr/src/uts/sun4/sys\
           usr/src/uts/sun4c/sys\
           usr/src/uts/sun4m/sys\
           usr/src/uts/sparc/sys\
           usr/src/cmd/adb/sparc\
           usr/src/stand/sys\
           usr/src/head

#
# These are all of the supporting directories
#
find_files "s.*" \
           usr/src/cmd/adb/sparc\
           usr/src/stand/lib\
           usr/src/uts/adb\
           usr/src/uts/sun/promif\
           usr/src/cmd/adb/common


echo_file usr/src/lib/Makefile.lib
echo_file usr/src/cmd/Makefile.cmd
echo_file usr/src/cmd/Makefile.targ
echo_file usr/src/uts/Makefile.uts

From msw@polyslo Fri May  1 17:01 PDT 1992
Date: Fri, 1 May 92 16:42:33 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update 12 - ws
Content-Length: 3169
Content-Type: text
X-Lines: 92
Status: RO


ws is a new tool that will help with the maintaining the new avocet
workspaces, it is a very light weight mechanism meant to help
maintain avocet workspaces.  It would be used similarly to activate
under NSE, except that it is much more light weight and does not
introduce any of the bottlenecks that NSE did (TFS,...).

Here's a list of Q & A's that will hopefully answer most of your
questions:


>> Question:  What is ws?

ws is a script that helps to configure your environment for builds
of the ON source base in an Avocet workspace.  It is only a script
that sets up your environment variables for a ON build and then 
invokes a shell.

>> Question:  Who should use ws?

Anyone doing a build of the ON-Source base in an Avocet workspace.  
This would include everything from a build of phobos, titan,
and onwards.

>> Question:  Why should you use ws?

ws does several things, first it specifies which PROTO areas you will
build against.  It is now possible with ws to configure your workspace
to build against a hierarchy of PROTO areas.  When you build against a
PROTO area that is where you will find many of your include files and
the libraries you build against.  By default ws will build
against the PROTO area of your current workspace and then, if your
parent is an avocet workspace, against your parents PROTO area.
Lastly the search will terminate on your native machine which you
are building on.

Next ws will configure your ROOT (your install destination),  your SRC,
and your PATH environment variables, ROOT by default will point to your
current workspaces PROTO area.  Your PATH will have the Construction
set (more details on this to follow), if available, prepended to it on
a 5.x machine.  Note:  If your path is set by .cshrc then any
changes that ws applies to your path will be undone when the new
shell is invoked.

ws also lets you configure all of the above.  There is a file
in your avocet workspace ($AVOCET_WS/avocet/sunos/protodefs) that
you can use to set default values for your workspace.  ws will
create this file on the first invocation on a workspace and will
re-read it on each subsequent invocation to configure itself.


>> Question: How do I invoke it?

Here is a sample invocation of ws:

polyslo 364: ws /net/amtrak/build/titan_uts

Workspace ($AVOCET_WS) : /net/amtrak/build/titan_uts
Proto area ($ROOT)     : /net/amtrak/build/titan_uts/proto
Root of source ($SRC)  : /net/amtrak/build/titan_uts/usr/src
Prepended to PATH      : /opt/osbld/bin
Current directory (PWD): /net/amtrak/build/titan_uts

polyslo 1:


>> Questions: What does WS do?


WS configures your environment for builds of the ON source tree,  it
does this by reading in some configurable values from the
avocet/sunos/protodefs files and then setting the following environment
variables:

	AVOCET_WS
	SRC
	ROOT
	MAKEFLAGS
	ENVCPPFLAGS{1-4}
	ENVLDLIBS{1-3}
	PATH

>> Questions: Where is ws

ws is distributed with the OS-Net avocet binaries.  They
are located on:
		dunk:/sdet/5.x/avocet/*

>> Questions: Docs??

For more details about ws and how you can configure it please refer to
the ws(1) and protodefs(5) man pages under dunk:/sdet/5.x.avocet/man.

From msw@polyslo Fri May  1 17:03 PDT 1992
Date: Fri, 1 May 92 16:45:51 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet update 14 - Construction Set -- updated
Content-Length: 3145
Content-Type: text
X-Lines: 91
Status: RO


There is now a Construction Set available for doing ON builds natively on
a 5.x machine, the construction set is available only for 5.x ON builds.
The construction set has three goals:

	1) To provide those tools which do not come with a 
	   regularly delivered package but are needed for a  ON build
	   of the ON source tree (eg., rpcgen).

	2) To provide a stable location for those tools used by
	   the ON build which tend to vary in functionality (eg., rpcgen,
	   tic, zic, ...).  As it becomes required we will roll
	   specific version of the compilers into the construction sets
	   as the compilers start to vary. 
	3) To provide a fixed set of tools that can be associated
	   with a specific release of the build (eg: you might need one
	   set for a phobos workspace and another set for a titan
	   workspace).

The construction set is available in package format and it can
either be pkgadd'd locally to your system or it can be NFS
mounted from a server.


Distribution:
-------------

To pkgadd the Construction Set to your local 5.x system do the following:

	# /usr/sbin/pkgadd -d /net/dunk/sdet/pkgs

Or to NFS mount the Construction Set to your local system:

	# mkdir /opt/osbld
	# mount -F nfs dunk:/sdet/osbld /opt/osbld

Note:  	If you are not located in building MTV5 you should install the
  	construction set on an NFS server for general availability.


Mechanics:
----------

The directory structure below will support the construction set, where
VERS will change with the release of the construction set(1.0, 1.1,
...).

	/opt/osbld/VERS/bin/*
	/opt/osbld/bin -> VERS/bin

The use of the VERS will give us the ability to have multiple copies of
the construction set on a machine simultaneously.  This will provide
support for the possibility that you may need different copies of the
construction set on the same machine.  If you are working on different
revision levels of the ON source base it might require that you have
different versions of the tools that come with the construction set (eg.,
rpcgen).

Lastly, there is support for the construction set within the ws
activation script.  ws performs a test for the construction set and, if
it is present, inserts the construction set into your PATH.  Also, by
using the capabilities of the ws protodefs file, you can associate
specific versions of the construction set with an Avocet workspace.
For example you could insert the following line into your protodefs
file for an avocet workspace:

	OSBLD_DIR=/opt/osbld/1.0/bin

This associates the 1.0 version of the construction set with your
specific workspace.  As other versions of the construction set becomes
available, you might edit protodefs to associate other versions with
your workspace.  If you make no entries in your protodefs file then ws
will insert /opt/osbld/bin into your PATH if it exists.  This symbolic
link will always point to the most current version of the construction
set.

For more info on the protodefs file and ws refer to the ws man page.

Contents:
---------

Presently the construction set contains the following files:

tic
zic
forth
tokenizer.exe
tokenize
rpcgen
cstyle
perl

From msw@polyslo Mon May  4 10:16 PDT 1992
Date: Mon, 4 May 92 10:08:28 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, msw@polyslo
Subject: Re: Avocet update 14 - Construction Set -- updated
Content-Type: text
Content-Length: 674
Status: RO
X-Lines: 32




All,

minor typo in my earlier avocet update message - replace all occurances
of 'osbld' with 'onbld':

=> 
=> Distribution:
=> -------------
=> 
=> To pkgadd the Construction Set to your local 5.x system do the following:
=> 
=> 	# /usr/sbin/pkgadd -d /net/dunk/sdet/pkgs
=> 
=> Or to NFS mount the Construction Set to your local system:
=> 
=> 	# mkdir /opt/osbld
		     ^^^^^
	# mkdir /opt/onbld

=> 	# mount -F nfs dunk:/sdet/osbld /opt/osbld
				  ^^^^^      ^^^^^
	# mount -F nfs dunk:/sdet/onbld /opt/onbld

=> 
=> Note:  	If you are not located in building MTV5 you should install the
=>   	construction set on an NFS server for general availability.
=> 
=> 
=> 

From cmh@kipling Mon May 11 11:46 PDT 1992
Date: Mon, 11 May 92 11:42:11 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: [treacy:  Avocet News]
Cc: treacy@kipling
Content-Length: 2015
Content-Type: text
X-Lines: 57
Status: RO

----- Begin Included Message -----

Date: Mon, 11 May 92 11:01:36 PDT
From: treacy@slipknot (John Treacy)
To: avo-users@kepler
Subject: Avocet News


Hello Avocet users.

I've had a number of inquiries lately about the status of Avocet as
a project and as a product. Since others may have these questions as well,
I'm mailing to this alias.

Avocet is being developed in SunPro as part of a larger product code named
Aviary. Aviary will go to beta this summer and FCS around Thanksgiving as
SPARCworks/TeamWare. 

Aviary consists of the following components:

	CodeManager (which you know as Avocet) - including a GUI for
		manipulating Avocet workspaces and providing glue to
		other development tools.

	VersionTool - This GUI frontend to SCCS has been made available
		to avo-users along with the Avocet tools. It allows easy
		access to SCCS commands as well as graphical depiction
		of version history, branches, etc. Lots of cool features
		to take SCCS into the present, such as diffs via filemerge.

	FileMerge - This tool, which also ships with SPARCworks, is essential
		to the avocet users.

	Checkpoint - This is "version snapshots", a lot like sid-lists, but
		improved to handle branches being renumbered and files
		being moved/renamed.

	Distributed (parallel) Make - Get that build done faster by using
		ALL of your lab's resources.

As I said, we'll be starting beta this summer. There will be a few alpha
sites prior to that, but the biggest one will likely be the various Sun
business units. Avocet has been used by a great number of projects
and the feedback you have given us has been a great help in getting it right.
The next month or so we'll be concentrating on getting the last few 1.0
features in and planning/budgeting for subsequent releases. We will continue
to make improvements to the product and make them available internally
before the official release, so please keep those bugs/rfes coming.


Thanks,

John Treacy
Aviary Engineering Manager


----- End Included Message -----

From dmk@dobbs  Mon May 11 15:22:56 1992
Return-Path: <dmk@dobbs>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07664; Mon, 11 May 92 15:22:56 PDT
Received: from dobbs.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA24490; Mon, 11 May 92 15:17:55 PDT
Received: from gramercy.Eng.Sun.COM by dobbs.Eng.Sun.COM (4.1/SMI-4.1)
	id AA03617; Mon, 11 May 92 15:22:32 PDT
Date: Mon, 11 May 92 15:22:32 PDT
From: dmk@dobbs (David Kahn)
Message-Id: <9205112222.AA03617@dobbs.Eng.Sun.COM>
To: osnet-sde@stufff, cmh@kipling
Subject: Re: [treacy:  Avocet News]
Cc: treacy@kipling
Content-Length: 51
X-Lines: 5
Status: RO



When do we get to use d-make for os-net?

-David

From cmh@kipling  Tue May 12 15:54:31 1992
Return-Path: <cmh@kipling>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00401; Tue, 12 May 92 15:54:31 PDT
Received: from kipling.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01138; Tue, 12 May 92 15:49:21 PDT
Received: by kipling.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00564; Tue, 12 May 92 15:52:49 PDT
Date: Tue, 12 May 92 15:52:49 PDT
From: cmh@kipling (Claire Giordano)
Message-Id: <9205122252.AA00564@kipling.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: OsNet use of avocet binaries
Content-Length: 622
X-Lines: 14
Status: RO


For OsNet development, avocet binaries should come from dunk or local 
copies of the dunk installation in groups other than OSTech.  Please
do NOT mount your avocet binaries from earthtone.

Those of you on the avo-users@kepler alias often see new delivery 
announcements from the avocet group.  Please ignore these and wait 
for the message from the ON integration group (from msw or tadd).  

If you accidentally get your copies from earthtone you will not benefit 
from the ON value added, such as the configured FLGs which automatically 
bringover the high level Makefiles you need to build (and more).

FYI.  Claire

From msw@polyslo  Tue May 19 09:51:33 1992
Date: Tue, 19 May 92 09:50:04 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet Update 15 - /ws automounter map
Content-Length: 811
X-Lines: 21
Status: RO


There is a new automounter map in the NIS maps (auto.ws) which gives
us a common space to access public ON-Source workspaces.  If you reboot
your system you should find the new maps under /ws.  The new
maps now contain the following workspaces:


/ws/phobos.INT	-	integration workspace for phobos(mars).
/ws/phobos.REF	- 	"golden source" workspace for phobos(mars).
/ws/ON1		-	OS-Tech workspace for integration into phobos.
/ws/ON2		-	DCT workspace for integration into phobos.
/ws/train	-	Titan (Solaris 4/93) workspace.


These maps are fully populated in the EBB.Eng.Sun.COM domain already,
they are presently being pushed out to the DGDO.Eng.Sun.COM NIS
domain.

If you are not in either of the above NIS domains and you need access
to this map send me e-mail and I will extend the map to your NIS
domain.

From msw@polyslo  Thu May 21 09:39:50 1992
Date: Thu, 21 May 92 09:38:26 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 6133
X-Lines: 147
Status: RO


	The OS-group reference copy of avocet binaries has been updated
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet

Warning:
	This release of avocet introduces the new renames support, with
	this introduction there is new information in all of the s-dot
	files for the name history. The old avocet binaries know
	nothing about this new information kept in the s-dot file.  You
	should use the new avocet binaries ASAP.

	** If you use the old binaries on a workspace which has been
	updated avocet will report that all of the files have been
	updated, and that you will have to run a bringover on them -
	this isn't the case and can be very alarming.  If this happens
	you are running the old binaries and should upgrade then retry
	your bringover!!

Important:	
	If you mount Avocet from dunk, to "see" the new release
	you need to umount your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.  Until you remount
	or reboot, you will continue to "see" the previous release.


From Evan's announcement...

Highlights:
	- Full rename support
	- Notification
	- OpenWindows Version 2 support dropped
	- Vertool shows closure of branches

Upcoming:
	- Product name change (Avocet -> Code Manager)
	- GUI for copy-modify-merge paradigm (codemgrtool)
 
 
Details:

 1) Full rename support.  That is, renames can be both put back and 
    brought over.  However, nseputback does not support putting back
    renames into an NSE environment.

    The old checknames program is no longer used.  For those interested,
    a more detailed description of the rename implementation is contained 
    below.

    Owners of integration workspaces:

	The transition will go more smoothly if you run this command on
	your integration workspaces:

		workspace updatenames -z <ws_name>

	This command will bring the workspace's name tables and
	SCCS file's name histories up to date.  This command takes
	a while as it must rewrite every SCCS file in the workspace.

 2) Notification.  There is a new file in the avocet directory named
    "notification" where users register notification requests.  
    Notifications are event based, where an event is something like 
    "bringover-to", or "putback-to".  A user can specify a list of 
    files and when the event occurs and affects any of the listed files, 
    the user receives a mail message.  Newly created workspaces are given 
    an initial notification file that contains only comments describing 
    the file's format.  There is also a section 5 man page.

 3) As announced in the previous release notes Avocet no longer supports
    OpenWindows Version 2.  This means that the fileresolve program is
    not included in this distribution.

 4) Vertool now shows closure of branches.  Avocet creates branches
    within an s-file when it detects a conflict.  Resolve closes these
    branches.  Vertool's history graph shows closure via dotted lines.

 5) The 5.0 vertool would core dump at startup.  Reported by Rod Evans,
    Bill Shannon, and Neil Katin.

 6) The 5.0 resolvetool would core dump when there was no common 
    ancestor delta.  Reported by Steve Grimm.

 7) Access control violations are just warnings rather than an errors to
    "putback -n" so that the command can run to completion.  Reported by
    Achut Reddy.

 8) Resolve_tty now places ancestor, child, parent and merge filenames in 
    environment variables for commands to access.

 9) Resolve_tty can now handle a file with no common ancestor delta.

10) Resolve now records how a conflict is resolved in the merge delta
    comment.  Currently a conflict can be resolved in one of three ways:
    merge the parent's and child's versions, accept the parent's version
    or accept the child's version.

11) Even if the -v option is not specified, the verbose output appears in
    the history file.

12) Nse transition tools have been included in this release. They include:
	codemgr_acquire
	codemgr_prepare
	comp_to_flg
	namedrev_to_workspace
    The tools are available on 4.x only.  Man pages are provided for each 
    of these commands.


Details of Rename Support:
	Supporting renames consists of two fundamental steps, identifying
	that file A in one workspace is the same file as file B in another 
	workspace (the matching problem) and, determining which of
	the files was renamed.  For example, was B renamed to A in the
	first workspace or was A renamed to B in the second workspace.

	Matching.  In each workspace's avocet directory, there is an ASCII
	file containing a table of file names and unique numbers.  Given a file 
	named X in one workspace, the file is located in the other workspace 
	by calculating a unique number from X's SCCS file and looking it up 
	in the other workspace's name table.  This name table is updated
	by the bringover and putback commands.

	Renames.  Each SCCS file contains a history of the file's names
	similar the the history of the file's contents.  Bringover and
	putback compare the two file's name histories to determine which
	file was renamed.  After renaming a file, bringover and putback
	update the file's name history.

	The name history information is stored in an s-file in a special
	delta added by Avocet.  This delta is a removed delta and the
	name history information is stored in the removed delta's comments.

	The workspace command has a new subcommand called "updatenames".
	It will rebuild a workspace's name table and, optionally, ensure
	that the name histories of all the s-files are accurate.

	If a file has been renamed in both the parent and child workspaces,
	this is considered to be a "rename conflict".  Rename conflicts
	cause putback to block and bringover deals with them by renaming
	the file in the child workspace to the name of the file in the
	parent workspace.  At this point, if the name of the file in the
	child was the desired name, the file can be renamed back to that
	name and putback will put back the rename.

From msw@polyslo Thu May 28 10:09 PDT 1992
Date: Thu, 28 May 92 09:39:07 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Avocet Update #16 - sccsrm & deletion of files under Avocet
Content-Length: 1034
Content-Type: text
X-Lines: 34
Status: RO


Now that the new Avocet binaries have rename support we can now
do source code deletions under Avocet.  A file deletion under
an Avocet workspace is really just a special rename, you DO NOT
'rm' the file.  Instead we would like to follow this renaming
convention for file deletions:

   o The file should not be checked out.
   o You must rename both the 'clear' file and the 's-dot' file
   o Deleted files should follow this naming convention:

	.del-<file_name>-<month>-<day>

     So for file a.c you would do the following renames:

	file a.c   -> .del-a.c-May-19
	file SCCS/s.a.c -> SCCS/s..del-a.c-May-19


To help with this we have created a small utility (sccsrm) which will
do these operations for you.  sccsrm is to be used to do file deletions
under Avocet workspaces.  It can be used as follows:

	% sccsrm a.c


sccsrm is in the current Avocet release (dunk:/opt/avocet) and is
now available for use, there is also a short man page for sccsrm:

	dunk:/opt/avocet/bin/sccsrm
	dunk:/opt/avocet/man/man1/sccsrm.1


_Mike_

From msw@polyslo Mon Jun  1 16:04 PDT 1992
Date: Mon, 1 Jun 92 16:04:20 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Avocet updated on host dunk
Content-Length: 4711
Content-Type: text
X-Lines: 116
Status: RO



	The OS-group reference copy of avocet binaries has been updated
on host dunk.  Our copy includes OS-group customizations.

  for 5.x avocet, see    dunk:/opt/avocet
  for 4.x avocet, see    dunk:/usr/avocet


Important:	
	If you mount Avocet from dunk, to "see" the new release
	you need to umount your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts Avocet from dunk.  Until you remount
	or reboot, you will continue to "see" the previous release.


From Evan's announcement...


Highlights:
        - This is a patch release containing a couple of crucial bug
          fixes
        - An file descriptor leak has been fixed
        - In certain circumstances Avocet would produce an incorrect
          s-file.  This bug has been fixed, code has been added to
          detect earlier corruptions, and a "patch" program has been
          included to fix entire workspaces.
	- A workspace children -r core dump has been fixed

Distribution:
        Avocet is now being distributed from:
                4.x:    earthtone:/export/set/earthtone2/avocet/4.x
                5.0:    earthtone:/export/set/earthtone2/avocet/5.0

Details:
1) There was a file descriptor leak that occurred when the name histories
   of a workspace needed to be updated by bringover or putback.
2) Beginning with the Alpha3 release, Avocet creates a dummy removed
   delta in each s-file where Avocet-specific information is kept.
   The dummy delta was not added correctly if an s-file had EXACTLY
   two deltas and those deltas had EXACTLY the same dates.  Normally,
   this is a very rare situation.  However, s-files originating from
   NSE environments are much more likely to see this situation.
   In this case, the s-file that is produced is corrupted such that
   an "sccs get" gets the 1.1 delta rather than the 1.2 delta.  

   The original bug causing this problem has been fixed.  Additionally, 
   Avocet now checks for files corrupted in this manner.  When found, 
   the following message is produced:
 
        Serial number %d out of order in file "%s"
 
   where the serial number should be 3 and the filename is the name
   of the s-file in question.
 
   Alpha3.2 also includes a program called "patch" that can be run
   on a workspace to correct any corrupted s-files.  Patch is much
   like "workspace updatenames".  It takes the name of a workspace
   or NSE environment as it argument, finds all the s-files in the 
   workspace, and corrects any corrupted ones.  It prints the names 
   of the corrupted ones as it fixes them.  Its also takes a -n option 
   to tell you what it would do without doing anything.
   The usage for patch is:
 
        patch [-n] ws ...
 
   The safest thing to do is to run patch on every workspace.  It should
   certainly be run on any workspace that has had "workspace updatenames"
   run on it.

3) A core dump in "workspace children -r" has been fixed.
 
In the OS workspace hierarchy that descends from the NSE environment
SunOSint, the following files are likely to have been corrupted:

	usr/src/lib/libc/sparc/fp/.del-sigfpe.c-690826620
	usr/src/lib/libc/sparc/fp/.del-qcvt.c-690826679
	usr/src/lib/libc/sparc/fp/.del-__f77_base.c-690826656
	usr/src/lib/libnsl/rpc/.del-key_prot.c-681681699
	usr/src/lib/libnsl/key/.del-secretkey.c-681988749
	usr/src/lib/libbc/libc/gen/common/select.c
	usr/src/lib/libkrb/krb/get_admhst.c
	usr/src/lib/libkrb/krb/get_krbhst.c
	usr/src/lib/libkrb/krb/decomp_ticket.c
	usr/src/lib/libkrb/krb/get_krbrlm.c
	usr/src/lib/libkrb/krb/strcasecmp.c
	usr/src/lib/libkrb/includes/error_table.h
	usr/src/lib/libkrb/includes/klog.h
	usr/src/lib/libkrb/includes/kparse.h
	usr/src/lib/libkrb/includes/krb_conf.h
	usr/src/lib/libkrb/includes/lsb_addr_comp.h
	usr/src/lib/libkrb/includes/prot.h
	usr/src/uts/sparc/ml/.del-zs_asm.s-684812485
	usr/src/uts/sun4/sys/mon/.del-sunromvec.h-675446591
	usr/src/uts/sun4/os/.del-prom_xxx.c-682747217
	usr/src/uts/sun4/conf/.del-GENERIC-688851151
	usr/src/uts/sun/sys/.del-promlib.h-684741747
	usr/src/uts/sun/sys/.del-zsreg.h-684811983
	usr/src/uts/sun/promif/.del-prom_mem.c-684110948
	usr/src/uts/sun4c/sys/mon/.del-openprom.h-674782813
	usr/src/uts/sun4c/os/.del-prom_xxx.c-682747160
	usr/src/uts/sun4c/conf/.del-files-669113068
	usr/src/cmd/cmd-inet/usr.sbin/inetplumb.c
	usr/src/cmd/format/menu_scsi.c
	usr/src/cmd/crash/cpu.c
	usr/src/cmd/crash/mutex.c
	usr/src/cmd/iostat/Makefile
	usr/src/cmd/kerbd/kerbd.x
	usr/src/cmd/kerbd/kerbd_proc.c
	usr/src/cmd/kerbd/key_generic.c
	usr/src/cmd/kerbd/kinit.c
	usr/src/cmd/kerbd/ksrvtgt.c
	usr/src/cmd/kerbd/kerb.c
	usr/src/cmd/kerbd/Makefile
	usr/src/cmd/vmstat/Makefile

From msw@polyslo Mon Jun  1 16:12 PDT 1992
Date: Mon, 1 Jun 92 16:12:45 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff, avo-users@kepler
Subject: Re: Avocet updated on host dunk
Content-Type: text
Content-Length: 177
Status: RO
X-Lines: 11



BE SURE TO READ THE SECTION ABOUT THE POSSIBLE CORRUPTION OF
s-dot FILES AND THE UTILITY TO FIX IT IN THE PREVIOUS E-MAIL!

RUN /opt/avocet/bin/patch ON YOUR WORKSPACES!






From msw@polyslo Fri Jun  5 13:59 PDT 1992
Date: Fri, 5 Jun 92 13:46:47 PDT
From: msw@polyslo (Mike Walker)
To: osnet-sde@stufff
Subject: Introducing:  VersionTool, a graphical front end for SCCS
Content-Length: 1528
Content-Type: text
X-Lines: 58
Status: RO


Forwarded from avo-uses@kepler mail alias

....

Avocet users,

Introducing:

	VersionTool; An easy to use graphical front end for SCCS.

Some features include:

	-Graphical view of a file's delta history
	
	-Ability to invoke filemerge between two arbitrary deltas in
	a file's history
	
	-Check out a file with two mouse clicks

	-Specify a comment in an editable window while checking in groups
	of files

	-Navigate through your directory heirarchy, performing SCCS commands
	as you go.

	-Inspect the comments, owners, dates and changes associated with
	deltas in the file's history.

	-Put groups of files under SCCS control

	-And more...

"vertool" is available where you get your Avocet/CodeManager executables.
There is also a README.vertool in the top level directory with the Avocet
release.

The latest released copy of vertool lives in:

  for 5.x avocet, see    dunk:/opt/avocet/bin/vertool
  for 4.x avocet, see    dunk:/usr/avocet/bin/vertool

  The README.vertool is up one level.


In keeping with the latest "Aviary Survey Incentive Plan,"  on June 15th,
we will randomly select the name of a user who has tried vertool and
award them a gift certificate to the Tied House, or Tower Records, or
Baskin Robbins,  winner's choice.  (vertool usage within Sun is logged
via email,  please see the README.vertool if you would like to turn this
feature off)  Aviary team members and immediate families still aren't
eligible, sorry.

Please give it a try, and let us know what you think.

Thanks,

Lewie Knapp, Jr.

From cmh@kipling Mon Jun  8 18:49 PDT 1992
Date: Mon, 8 Jun 92 18:28:28 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: integration policies for OsNet (generic)
Cc: cal-mgrs@benet
Content-Length: 3748
Content-Type: text
X-Lines: 109
Status: RO

The following release-independent integration policies for OsNet have
been recently updated.  I *strongly* recommend that *NEW* ON developers 
read this document.  It lists some basic integration policies that apply 
from release to release.  

This doc resides on:  terminator:/usr/integration/doc/policy.

	Software Development and Integration Policies for OS-Net

	"@(#)policy	1.10	92/06/08 SMI"

	These policies are not new, they have always been in place.
	This message only reiterates and reinforces these existing
	policies.

	This message is not a complete description of the relevant
	policies.  It only highlights key areas.  It does not describe 
	the integration processes which may vary slightly from 
	release to release. 

	Changes since this policy was last distributed are indicated	
	by change bars in the right hand column, as to the right of
	this text.						

Simple rules
______ _____

For managers:

	If you are a manager, it is your responsibility to provide
	developers on your project with adequate resources to develop
	and test their work.

For developers, when integrating code into an i-team workspace or 
an integration workspace, it is *your* responsibility to follow these 
rules:

	Make sure that all affected code compiles after the final
	bringover but before integration.

	Test it after the final bringover but *before* integrating 
	it.

	If appropriate, make sure that your changes work on all 
	supported reference architectures.

	Make sure that the "make" and "make install" rules operate
	properly.  Follow the guidelines set forth in the Makefile
	guidelines on terminator:/usr/integration/doc/make.std.

	Check that new system headers and new libraries are installed
	by the appropriate Makefiles. 

	Files which are cstyle clean should remain cstyle clean.  
	New files must be cstyle clean.

	Understand the performance impact of your change.

	Supply meaningful and helpful SCCS comments, including any
	relevant bugids.

	Update the various bug databases to indicate that the bug is
	fixed.  When the fix has been integrated into the Train, 
	update the bug databases to indicate that the fix is
	integrated. 

	Tell the documentation people about any customer visible
	changes that may need to be documented in the relevant
	guides, the release manual or the man pages.  Follow 
	the instructions in man_pages_README located on terminator,
	/usr/integration/doc/ to update the man pages.

	All source files must be under SCCS control.

	All integration will occur via Avocet aka CodeManager.

	All source files must include appropriate SCCS keywords, once 
	these keywords are re-introduced in Phobos.  See terminator,
	/usr/integration/doc/keyword_info for more details.

	All source files created or significantly modified by Sun must 
	include appropriate SMI copyright notices such as the one below.
	Never remove another company's copyright without the approval
	of management.

	/*
	 * Copyright (c) 1992, by Sun Microsystems, Inc.
	 */

	If introducing new source files into the ON source, have
	you addressed the source product concerns that should have
	been posed by any of PSARC, ONSC, or the ON C-team?  Any
	new sources that are proprietary or that cannot be shipped
	with the source product require special architecture into
	the ON build.

You have the following additional responsibilities when integrating
changes to the kernel:

	Your changes must not introduce any lint errors.

	For the kernel, changes *must* conform to the C coding style 
	described on terminator:/usr/integration/doc/cstyle.ANSI.

	Your changes must not break boot, including diskless boot,
	or kadb.

	You must update any "kmem readers" (e.g., crash, ps, vmstat)
	if you change any kernel data structures.

From tadd@widor  Thu Jun 11 20:01:27 1992
Date: Thu, 11 Jun 92 19:55:17 PDT
From: tadd@widor (Tadd Ottman)
To: osnet-sde@stufff
Subject: "Tips" for OS-Net work with Avocet
Content-Length: 3313
X-Lines: 75
Status: RO


	Here is a new one-page document provided by the OS-Networking SDET
team to assist you in doing software development in a world without the NSE.
(SDET is the Software Development Environment Transition, away from the NSE
an into SCCS and Avocet.)

	This document's home is /opt/avocet/doc, as available from dunk.
			[now accessed through /shared/ON/teamware_docs]

					Tadd

	==============  cut here  ==================================

	"@(#)sde_start	1.6	92/06/11 SMI"

    Tips for getting started in the OS-Net software development environment

(This applies to the development of phobos and later OS-Net releases.)

Do your builds on SunOS 5.x; our source no longer supports cross-release
builds on 4.x.

Do development using SCCS; do integration using Avocet.  Get Avocet from
dunk:/opt/avocet or a local, regularly updated clone of it.  Learn Avocet
basics from /opt/avocet/README (modified by the OS-Net group).

Run "bringover" to create your source workspace; do this bringover from a
workspace that is recommended by an appropriate "gate-keeper," program
manager, manager, or integration engineer.  (See the auto.ws NIS map or
the auto_ws NIS+ table for candidate workspaces.)

Run "bringover" again whenever you want to update your source with changes
available in a recommended workspace.  Always bringover from a parent
workspace that is at an equal or greater release level to the child
workspace.  Do not "reparent" to an older release.

Think SCCS.  Allocate disk space for file histories in each workspace.

Use SCCS, but avoid rmdel, fix, and cdc subcommands.  unedit is okay.

Use the "ws" script, available from OS-Net in /opt/avocet/bin, to simplify
your builds.  "ws" also simplifies Avocet command use; you do not have to
specify the "-w" option.  See the "ws" man page in /opt/avocet/man.

Use this path setting for doing your builds (e.g., in .login):
path=(/opt/avocet/bin /usr/sbin /opt/SUNWspro/bin /usr/ccs/bin /usr/bin)

Allow "ws" to set shell variables important to the build: SRC, ROOT,
ENVCPPFLAGS*, ENVLDLIBS*, MAKEFLAGS.  Do not set these in your shell's
start-up files.  "ws" prepends to PATH, so if you must modify "path" in
your .cshrc, conditionally protect ws from your modification with:
if ( ! $?ONBLD_DIR ) then   # meaning: if ws has not set the path, then...

If you want to delete a source file and propagate this change to other
workspaces, use "sccsrm", which will rename the file and its corresponding
SCCS s-dot file to "deleted-file names" such as s..del-foo.c and allow
"putback" to propagate this "deletion" as a renamed file.

Be aware that bringover and putback operations use "find" to generate lists
of files.  A bringover (create) of all source takes about 2 hours.  A null
bringover (update) of all source takes about 40 minutes.  A null bringover
of all kernel source takes about 10 minutes.

Be sure there are no unresolved conflicts in your workspace before doing
builds.  Use "resolve -n" to check for conflicts.

Simplify references to public workspaces by using the auto.ws map (or the
auto_ws table) with your automounter.

See Also:
  "roadmap" in terminator:/usr/integration/doc
  documentation and automounted mail-archives in /opt/avocet/doc
  man pages in /opt/avocet/man
  sccs man pages such as sccs(1), sccs-get(1), and sccsfile(4)


From tadd@widor  Thu Jun 11 20:22:49 1992
Date: Thu, 11 Jun 92 20:17:58 PDT
From: tadd@widor (Tadd Ottman)
To: osnet-sde@stufff
Subject: SDET tips for gate-keepers
Content-Length: 274
X-Lines: 9
Status: RO


	There is a new two-page document from SDET to offer tips to
gate-keepers.  It is available from dunk as /opt/avocet/doc/sde_int.
If you don't know what a gate-keeper is, you're probably not interested.


					Tadd

	[sde_int now accessed through /shared/ON/teamware_docs]

From msw@polyslo  Tue Jun 23 21:24:08 1992
Date: Tue, 23 Jun 92 21:23:55 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: codemgr (Avocet) updated on host dunk
Content-Length: 7831
X-Lines: 167
Status: RO



In response to Evan's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/avocet
  for 4.x codemgr, see    dunk:/usr/avocet

	================================================================
Important:	If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your avocet directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Also, we have moved the new 'distributed make' from the
	bin directory into the bin/dmake directory.  If you want to
	use this new 'distributed make' you must 'intentionally' add 
	this directory to your path!!  
	================================================================

	Evan's message said this about the new delivery:


		Alpha4 Release Notes

A new release of SPARCworks/TeamWare, formerly Avocet, has been installed.  
The releases are being named via a file in the distribution directory
named Release.  This release is called Alpha4.  This release name can 
be used in bugtraq.


Highlights:
	- Name change.  The internal code name Avocet is no longer being
	  used.  Avocet's official name is Code Manager.  Code Manager
	  along with Version Tool, Distributed Make and FileMerge make
	  up the SPARCworks/TeamWare product.
	- Includes a GUI for Code Manager named codemgrtool.
	- Includes distributed make.
	- Enhancements to Version Tool.
	- Many bug fixes


Here is the status of several OS problems that have been affecting
TeamWare recently.
1) There was an automounter problem where a mount would occassionally 
   disappear while being used.  Carl Smith recognized this problem and
   Satinder Singh fixed it.
2) There was a problem where large bringover and putbacks would hang
   in a state where they were not running and were not killable.  This was
   a bug in the way the kernel deals with a process that has used up all
   its file descriptors and is trying to open something across NFS.  We 
   have fixed the fd leak and the kernel problem is now understood.
   Thanks to Howard Chartock and Jim Voll.
3) There was a UFS problem where, after a bringover, the time of an
   s-file would be more recent than that of its g-file, causing make
   to do a bunch of gets.  We worked around this bug and Billy Fuller 
   tells us this is fixed in 4.1.2 and 5.0.
   

Alpha4 Details:
1) Avocet has been renamed to Code Manager.  Code Manager along with
   FileMerge, Version Tool, and Distibuted Make make up the SPARCworks/TeamWare 
   product.

   Avocet kept it information in a directory named avocet.  Code Manager 
   keeps its information in directory named Codemgr_wsdata.  Alpha4
   renames avocet directories to Codemgr_wsdata.  Avocet supported several
   shell environment variables that began with AVOCET_.  These have been
   renamed to begin with CODEMGR_.  Alpha4 recognizes the old variables,
   uses their values and prints a warning.  The next release will nolonger 
   recognize the avocet directory or the AVOCET_ variables.

   We have established new aliases to replace avo-users and avo-bugs.  
   They are teamware-users and teamware-bugs.

   We are in the process of getting these name changes incorporated 
   into bugtraq as well.

2) Alpha4 includes the first release of a window interface to Code Manager 
   named codemgrtool.  Codemgrtool is an OpenLook program from which almost 
   all Code Manager functionality can be reached.  It shows workspace graphs 
   and allows users to issue bringover, putback and resolve commands as well
   as such workspace subcommands as delete, move and reparent.

3) Alpha4 includes the first release of distributed make.  This is a version
   of make that determines which targets can be built in parallel and runs
   multiple commands at the same time.  The commands are run on the same
   machine; distributed make does not yet distribute the commands across the
   network, only on the local machine.  By default, distributed make 
   parallelizes up to 4 commands at a time.  For more details see the
   README.dmake in the distribution directory.  Distributed make is named
   "make" and lives in the TeamWare bin directory.  To use distributed make, 
   make sure it appears in your path before the standard make.

   Some prelimary performance numbers:
   CPU			  Memory	Improvement
   SparcStation 1+	   16M		little
   SparcStation 2	   32M		15-20%
   Sun 4/600 (MP/2 CPUs)  128M		40%

4) Version Tool enhancements.  The property sheet allows you to setup
   your favorite editor, the double click action, information you want
   to see in the graph, etc.  However, none of this is saved to disk
   yet so it must be respecified each time vertool comes up.  Ability
   to see "prt" and "diff" output in the history popup.  Many other
   improvements.

5) Resolve and resolve_tty have been combined and resolvetool has
   gone away.  By default, resolve looks pretty much the same as before,
   it starts up a filemerge and loads the first file.  As a file is 
   saved in filemerge, the next is loaded.  However, in the window
   where resolve was started, it will also accept resolve_tty commands.
   The -c option to resolve prevents it from automatically starting a 
   filemerge.

6) The semantics regarding checked-out files have been refined.
   If a file is checked out, but has no differences from the most
   recent delta, then it is no longer considered to have changed
   and neither bringover or putback will complain about it.
   During a bringover, if a file is checked out in the parent and
   has differences, a warning is given, the file is still processed
   and all the checked in deltas are brought into the child workspace.
   Requested by Achut Ready, Billy Fuller, and Barry Holroyd.

7) Alpha4 includes an umbrella command to the Code Manager functionality.
   It is named codegmr and it subcommands are the Code Manager commands
   such as bringover, putback, workspace, etc. 

8) In the Codemgr_wsdata directory the cmdlog file has been merged into
   the history file.

9)  The notifiction and access_controls files are no longer being opened
    for read/write so you won't get error messages if you make them
    readonly.  Reported by Carl Smith and several others.

10) It is no longer an error to try to create a workspace over an
    existing directory, however, it will generate a warning.  Therefore,
    the workspace create -d option has been dropped.  Requested by Len
    Brown.

11) If no -w option is given to bringover, putback and undo they
    use the value of the CODEMGR_WS variable.  If that is not set,
    they now check to see if you are currently cd'd within a workspace
    and use that one.  Likewise for most of the workspace subcommands.
    Requested by Bill Shannon.

12) The -v option to bringover and putback no longer names files that
    are identical in the parent and child.  Requested by Bill Jackson.

13) The workspace reparent command has been folded into the workspace
    parent command in an attempt to avoid confusion.  It is now:

	workspace parent [-f] [-p newparent] [-r] [-u] [ws ...]
    
    With no options the parent subcommand lists a workspace's parent.
    The "-p newparent" option is used to reparent a workspace.
    The "-u" option is used to unparent a workspace, that is, to
    orphan a workspace.

14) The 5.0 window programs have been built to look in /usr/openwin/lib
    for dynamic libraries.  Reported by Sami Shaio and Bill Jackson.

From msw@b5mail  Thu Jul  9 12:57:52 1992
Date: Thu, 9 Jul 92 12:57:15 PDT
From: msw@b5mail (Michael Walker)
To: osnet-sde@stufff
Subject: Checkpoint - added to Avocet distribution
Cc: teamware-users@kepler
Content-Length: 3029
X-Lines: 93
Status: RO


All,

I've added the new checkpoint software to the ON avocet distribution
on dunk.  If you are already mounting Avocet from dunk you will
find the software in your bin directory.  If you've made a private
copy of the Avocet binaries you will need to copy over the new
checkpoint binaries yourself.

Avocet can be found at:

	4.x - dunk:/usr/avocet
	5.0 - dunk:/opt/avocet


Below I've included Marla's e-mail announcing the new checkpoint
software.


_Mike_

----- Begin Included Message -----

Date: Tue, 7 Jul 92 21:25:19 PDT
From: marla@lucerne (Marla Parker)
To: teamware-users@kepler
Subject: Checkpoint - First Release


	Alpha4 Release Notes for Checkpoint
	(the last piece of the SPARCworks/TeamWare product)

The first release of checkpoint and checkpointtool has been installed
alongside the existing Alpha4 installation of the rest of TeamWare.  To be
consistent with the rest of the tools, this version is called Alpha 4 even
though it is the first release.


(I tested on 4.1.2 and an April preFCS 5.0)	

What IS it?
-----------

Checkpoint is a minimal replacement tool for some scripts that generate or
use "SIDlists".  As you may have noticed, using bringover(1), resolve(1),
and putback(1) will sometimes renumber the SIDs (SCCS delta IDs) in a
source file.  Therefore Code Manager in effect breaks SIDlists.

A Checkpoint file is similar to a SIDlist file except that it contains
SCCS Mergeable IDs, or SMIDS, which do NOT change even after conflicts
have been resolved and the source file has traveled about through half a
dozen different workspaces.

Checkpointtool is a graphical user interface to checkpoint.

What can it do?
---------------

Not much, but hopefully just enough.  Script writers should make a
beeline for the checkpoint manpage and check out the "smid" and "sid"
subcommands.  They provide simple sid<->smid translations for all or
any deltas in a source file.

Checkpointtool lets you create a checkpoint file, load the contents of a
checkpoint file, or extract the versions of the sources represented by a
checkpoint file into some arbitrary new or empty directory.  The whole
point of the tool's existence is the extract step: to get back to an
old version of the sources to build.

Rename support is planned for 1.0 but is not present in alpha4.  (This
means finding the right file from which to extract the desired delta
even if the file has been renamed, and also extracting it back under
the correct old name so that the build will work.)

My PLEA
-------

Please try this out and send me your feedback.  I am very concerned about
this late edition tarnishing TeamWare's otherwise good quality.  Here are
a few things that I know I need to fix:

	- catch and display the output from Extract
	- undo edit (greyed out on the Edit menu)
	- sort the checkpoint file by file name
	- find-myself so you don't need to set HELPPATH

Comments and suggestions about the user interface are solicited.  Send
mail to me or teamware-bugs@kepler.

Thanks,
Marla

----- End Included Message -----

From bonwick@b5mail  Thu Jul 30 12:05:25 1992
Date: Thu, 30 Jul 92 12:04:49 PDT
From: bonwick@b5mail (Jeff Bonwick)
To: osnet-sde@stufff
Subject: Install(1) update
Content-Length: 291
X-Lines: 6
Status: RO

I've made two small changes to Install(1) in the Avocet distribution on dunk.
These are: (1) AVOCET_WS is now CODEMGR_WS (this has actually been in place
for a while); and (2) some special treatment for a few of the sun4 .conf
files (le.conf, esp.conf, sd.conf).  The new SID is 1.41.

Jeff

From msw@b5mail  Fri Aug  7 09:37:14 1992
Date: Fri, 7 Aug 92 09:36:30 PDT
From: msw@b5mail (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: New TeamWare release(on dunk) - Alpha5
Content-Length: 14839
X-Lines: 361
Status: RO


In response to Evan's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/teamware
  for 4.x codemgr, see    dunk:/usr/teamware

	*** NOTE - the mount point has changed for the avocet distribution,
		   It is *NO LONGER* /opt/avocet or /usr/avocet.  I will
	 	   support these mount points through this distribution.
		   However, please CHANGE your {v}fstab to reference
		   the new mount points!!!

	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Evans comments about pkgadd'ing this release.
	================================================================



	Evan's message said this about the new delivery:

		     Alpha5 Release Notes

A new release of SPARCworks/TeamWare has been installed.  The releases 
are named via a file in the distribution directory named Release.  This 
release is called Alpha5 and this release name can be used in bugtraq.

OsNet developers in SunSoft and SMCC should defer to the release
announcement message sent to the osnet-sde@stufff alias.  ON developers
should get binaries and ON value added utilities and documentation
based on the pointers provided by the osnet-sde@stufff messages.

Alpha5 is intended to be the last alpha release.  Currently, Beta
is expected in early September.

Highlights:
	- the directories to get TeamWare from have changed
	- licensing
	- installation, the filesystem layout has changed
	- internationalization
	- Avocet to CodeManager conversion complete
	- checkpoints, a replacement for SCCS SIDlists


Alpha5 Details:

1) Note that Alpha5 is being distributed from new directories.  The 5.0
   directory is now named /opt/teamware and the 4.x directory is now
   named /usr/teamware.  The old Alpha4 directories named /opt/avocet
   and /usr/avocet will be removed in about a week.

2) Alpha5 is the first licensed release of TeamWare.  Licenses have
   been added to the /usr/dist servers.  Users who mount /usr/dist
   should not have to do any license administration.  Users not 
   using /usr/dist should see the more detailed License Administration
   section below.

3) Alpha5 can be accessed in two ways.  It can be installed using
   pkgadd (on 5.0) and cdmanager (or 4.x).   TeamWare is made up of
   the following packages:
	Checkpoint	replacement for SCCS SIDlists
	CodeManager	formerly Avocet - bringover, putback, resolve, etc.
	DistributedMake	parallel make
	FileMerge	GUI for 3-way merging or 2-way diff'ing
	VersionTool	GUI for SCCS
	swmgr		SPARCworks manager - tool launcher included in
			each SunPro product that has GUIs

4) The structure under the distribution directory has changed.  
   TeamWare is one of several products from SunPro.  The filesystem
   reflects a structure where all SunPro products are expected to
   be under the same directory (/usr/lang on 4.x and /opt/SUNWspro on 5.0).

   On 5.0, /opt/SUNWspro has one directory per package where all
   the files for that package live and has bin and man directories
   that may be added to user's paths.  The bin and man directories
   are a union of all the bin and man directories within the 
   packages and, consequently, are full of symlinks into the packages.

   The 4.x layout is similar, except for compatibility reasons there
   is no bin directory.  The symlinks to the executablies live directly
   in the top-most directory (/usr/lang).

5) Alpha5 for 5.0 supports level 3 i18n.  Message catalogs are included
   in each Package under <package>/lib/locale/C/LC_MESSAGES/*.po.
   Spot help files are included under <package>/lib/locale/C/help/*.info.
   Alpha5 for 4.x does not support i18n.

6) The conversion from Avocet to Code Manager is now complete.  Alpha5
   looks only for directories named Codemgr_wsdata and no longer
   renames avocet directories to Codemgr_wsdata directories.  It also
   looks only for environment variables beginning with CODEMGR_ and
   ignores variables beginning with AVOCET_.

7) The checkpoint and checkpointtool commands are included in Alpha5.
   Checkpoints provide a replacement for SCCS's SIDlists.  A checkpoint
   is a list of mappings between a filename and a delta for that file.  
   Sometime after making a checkpoint, it may be extracted.  Extracting
   a checkpoint results in a get of each file's corresponding delta,
   thereby creaing a new directory hierarchy where each file has the
   contents they had when the checkpoint was made.

8) Sccsmerge could be confused when two files with no common ancestor
   delta were combined and then resolved.  This resulted in a message
   about misaligned files or about flags being left in a map.  Reported 
   by Isaac Salzm, Dave Hendricks and Bill Pittore.

9) Resolve no longer brings up filemerge by default.  However, it has
   a "filemerge" command that starts it up.  Resolve should be considered
   a CLI command and codemgrtool provides GUI access to resolving
   files.

10) To run resolve remotely and have filemerge appear on your screen,
    resolve required the WINDOW_PARENT environment variable to be 
    set.  This was wrong and is no longer required.  Reported by
    Carl Smith.

11) Changes to codemgrtool, including:
    a) A new button name "Tools" which allows you to startup other
       SunPro tools from within codemgrtool.  The menu behind this button
       is determined by reading a configuration file.  Use of the
       menu requires the selection of a workspace.
    b) The workspace palette was removed.
    c) The Bringover and Putback panes no longer require directories and files
       to be selected.  Selection is just used for editing the Dir/File list
       and the Bringover and Putback buttons operate on the contents of the
       list.
    d) Read-only viewing of a workspace's access_control, notification and 
       locks files.  Write access will be coming.
    e) The Load=>Workspaces popup now has a workspace chooser instead of
       a multi-line textfield.
    f) The Edit=>Rename... menu item and the Transactions=>Undo menu item
       are now functional.  An undo panel has been added allowing full undos 
       of bringovers/putbacks.  Partial undos will be coming.
    g) Code Manager tool properties can now be fully applied and saved.  
       Files read/written are ~/.codemgrtoolrc and ~/.codemgr_resrc.
    h) Dragging and Dropping a workspace onto another workspace will
       now bring up the appropriate Transaction pane (bringover create,
       bringover update, or putback).  This used to be the accelerator
       for reparent.  Shift Drag and Drop is the new reparent accelerator.
    i) The Name: textfield in the Bringover and Putback panes has been
       moved into the Edit=>Add Files to List... chooser.  The Transaction
       panes should now give more detailed feedback on user actions.
    j) File List Programs (FLPs) can now be added to bringover/putback
       transactions.  This is done by switching toggle located just
       below the Parent and Child workspace directory textfields.  FLPs
       can be added using Edit=>Add FLPs to List... via typing or
       choosing.
    k) In the Bringover and Putback transaction panes File=>Save List to
       defaults... is now enabled.  This allows users to edit and save
       the args file of the source workspace.
    l) The Transaction Output window buffer overflow problem has been
       fixed.
     
12) The "undo" command has been renamed to "ws_undo" as undo was deemed
    to be too generic.

13) Alpha5 does not contain an sccsmerge executable as we will not be
    shipping this executable in the final product.  We will be happy 
    to supply it to internal users who make a request.

14) Alpha5 includes rename notification and the ws_undo command now
    un-does renames as well.

15) The SPARCworks manager is included with TeamWare.  It is a GUI
    command named "sparcworks" which provides a palette of SunPro
    tools that are available.  With just TeamWare the palette shows
    four GUIs - checkpointtool, codemgrtool, filemerge and vertool.
    This program will ship will all SunPro products that contain
    GUIs.  Sparcworks reads configuration files to determine what
    to show in its palette, so as more SunPro products are installed
    sparcworks shows more and more tools.

16) File List Generators (FLGs) have been renamed to File List Programs
    (FLPs).  Therefore def.dir.flg has been renamed to def.dir.flp.


License Administration
----------------------

Note: on 4.x DESTDIR = /usr/teamware
      on 5.0 DESTDIR = /opt/teamware

If you did not install the TeamWare packages under one of these default
locations, substitute your location wherever $(DESTDIR) is used.

The /usr/dist servers have already been installed with TeamWare licenses.
If you don't have access to a /usr/dist server, you need to do the following.

First, make sure you installed the SunTech_License package on the server
that you want to be the license server.  You can verify this by seeing if
the license manager (lmgrd) exists on the license server.

	on 4.x:
	# ls $(DESTDIR)/lmgrd

	on 5.0
	# ls $(DESTDIR)/bin/lmgrd

If this file doesn't exist, go back and install the SunTech_License package.
See "Installation Procedures".

To setup licensing, two files need to be created.  A "license.dat" file
contains the actual license tokens and the $(DESTDIR)/lib/LICENSE_FILE
file contains a pointer to the "license.dat" file.

Step 1: license.dat File

We have setup a program that will generate a license.dat file for you.
Logging into the machine "holiday" as user "license" causes you to run 
this program:

	% rlogin holiday -l license

This will run a script and prompt you for information.  You need to know
the name and hostid of the server where your licence manager will be
running.  It will then email back the contents of the license file
(license.dat).

It consists of three lines: a SERVER line, a DAEMON line, and a FEATURE line.
Write the mail message to a temporary file.  You need to move this file
to a location where the license server and all machines running Teamware
will be able to access it.  

We suggest you move the file to $DESTDIR/SunTech_License/license.dat. 
As root, move the temporary file you created above into 
$DESTDIR/SunTech_License/license.dat

	# su
	# mv tempfile $DESTDIR/SunTech_License/license.dat
	# chmod 666 $DESTDIR/SunTech_License/license.dat

There are two edits to make to the license.dat file.  First, the mail header
probably still exists in the file.  Take out those lines.  Second, if you
didn't install in one of the default locations, you need to change the line
beginning with "DAEMON" so that the suntechd can be located.  It should be
changed to:

	on 4.x
	$DESTDIR/suntechd

	on 5.0
	$DESTDIR/bin/suntechd

Here is an example of what a license.dat file may contain:

	machine% cat /net/license-server/opt/SUNWspro/SunTech_License/license.dat
	SERVER license-server 55004d11 1710
	DAEMON suntechd $(DESTDIR)/bin/suntechd 
	FEATURE sunpro.sw_teamware suntechd 1.000 1-apr-94 100 2BE8A0D1DCEAC8022A17 "Teamware"
	machine%

Step 2: license router file, LICENSE_FILE	

The $(DESTDIR)/lib/LICENSE_FILE file is a router file.  It contains the 
fully qualified filename of the license.dat file.  The shipped contents
of this file are:

	on 4.x
	/usr/lang/SunTech_License/license.dat

	on 5.0
	/opt/SUNWspro/SunTech_License/license.dat

If you put the license.dat file in this location in Step 1, then you
may leave this file as is.  If not, you need to
edit it to point to $(DESTDIR)/SunTech_License/license.dat or wherever
you put your license.dat file.

Note: the license.dat file must be available on both the license server
and on all machines running TeamWare.  TeamWare programs read this file to
find the location of the license.dat file.  (This file is not a symlink as
it can contain more than one filename, but that is beyond the scope of
these instructions.  See the comments in the shipped license.dat file.)

Another note: In Alpha5, the actual LICENSE_DATA file is installed as
part of the CodeManager package, although all of the Teamware product
depends upon this file.

Here is an example of what a LICENSE_FILE may contain:
	machine% cat $(DESTDIR)/lib/LICENSE_FILE
	/net/license-server/$(DESTDIR)/license.dat
	machine%

Step 3: Start the license manager.

	# rlogin <license-server>

where license-server is the name of the server in the license.dat file.

	on 4.x:
	# cd $(DESTDIR)

	on 5.0:
	#cd $(DESTDIR)/bin

	# lmgrd -c $(DESTDIR)/SunTech_License/license.dat >& /tmp/logfile &

This last line should be added to an rc-file that gets executed
at boot-time.  Otherwise, this command will have to be re-executed
each time the license server is rebooted.


You should now be able to get a TeamWare license.


Installation Procedures
-----------------------

By default, TeamWare should be installed in /opt/SUNWspro on 5.0 and
in /usr/lang on 4.x.

To install on Solaris 1.0 (aka 4.x):

As root:

# cd /net/earthtone/export/set/earthtone2/teamware/Solaris1.0.cdrom
# xhost +<hostname>
# ./cdmanager &

The xhost command may or may not be necessary.  If you don't issue
it and you get an error when starting cdmanager regarding not being
authorized to connect to the X server, then issue the xhost command
and try cdmanager again.

Cdmanager presents a set of icons, one for each package.  One at a time,
select an icon and run the Install command on the floating menu.
The licensing package only needs to be installed if you need to setup
you own license server.  Note that you must do this as root, and there 
must be a shelltool in root's path.

To install on Solaris 2.0 (aka 5.0):

As root:

# pkgadd -a none -d /net/earthtone/export/set/earthtone2/teamware/Solaris2.0.cdrom

Install all of the packages listed by pkgadd except the licensing
package as it only needs to be installed if you need to setup
your own license server.

Note that the Distributed Make binary is not automatically included
in the directory with the rest of the TeamWare binaries.  See file
$(DESTDIR)/DistributedMake/README.dmake for more details.


----- End Included Message -----

From msw@polyslo  Wed Sep  9 14:47:09 1992
Date: Wed, 9 Sep 92 14:46:32 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: Filemerge Patch Available
Content-Length: 1372
X-Lines: 45
Status: RO



I have updated the ON distribution of filemerge that is delivered from
dunk:

  for 5.x codemgr, see    dunk:/opt/teamware/FileMerge/bin/filemerge
  for 4.x codemgr, see    dunk:/usr/teamware/FileMerge/bin/filemerge

If you mount these binaries directly from dunk no action is needed, if
you have made a private copy of these binaries you will need to update
that copy.

For more details refer to Evan's e-mail below.


_Mike_


----- Begin Included Message -----

Date: Wed, 9 Sep 92 14:31:21 PDT
From: evan@kepler (Evan Adams)
To: teamware-users@kepler
Subject: Filemerge Patch Available

Last week we announced a serious bug in filemerge and recommended
that people not use the "accept parent" or "accept child" features.

We are now releasing patched versions of filemerge that no
longer have this problem.  We have installed the new versions
in our standard distribution directories:

4.x:  earthtone:/export/set/earthtone2/teamware/Solaris1.0/FileMerge/bin/filemerge
5.0:  earthtone:/export/set/earthtone2/teamware/Solaris2.0/FileMerge/bin/filemerge

If you are mounting from these locations then you will automatically
get the patched versions of filemerge.  If you have a copy of
the TeamWare distribution or used pkgadd or cdimage to install,
then you should replace your version of filemerge with a patched
one.

	Evan Adams


----- End Included Message -----

From msw@polyslo  Fri Sep 25 16:12:39 1992
Date: Fri, 25 Sep 92 16:12:12 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: Avocet Update #17 - sccscp & sccsmv introduced
Content-Length: 1506
X-Lines: 49
Status: RO



We (the OsNet) group have introduced two new tools for help with
managing SCCS files in CodeMgr workspaces.  They are:


sccscp:

sccscp is to be used when you want to 'fork' a source file within
a CodeMgr workspace.  This is helpful when someone wants to 
fork a file off of the present source tree, yet keep the previous
SCCS history that has been built up in the file (eg:  copying
the usr/src/uts/sun4c/cgsix driver over to usr/src/uts/sun4f/cgsix).
sccscp uniquifies the SMID's as it copies each s-dot file.

It would be used as follows:
	% sccscp -r uts/sun4c/cgsix uts/sun4f/cgsix
	...

usage:	sccscp [-r] filename1 [ filename2...] target
	-r copy a directory and all of its files
	-g copy the sdot file, but do not sccs-get it
	-e copy most recent delta if file is currently checked out.
	-d debug mode
	
	*** Note - special thanx to the CodeMgr group for help
	    with sccscp.

sccsmv:

sccsmv is to be used to 'move' SCCS files around within a CodeMgr
workspace.  sccsmv will move both the clear files and the corresponding
s-dot files.

It would be used as follows:
	% sccsmv uts/sun4c/cgsix/Makefile uts/sparc/cgsix/Makefile
	...

usage: sccsmv filename1 [filename2 ...] target


Both of these commands have been installed under the current 
CodeMgr distribution - no action is required if you mount these
binaries off of dunk.

	dunk:/opt/teamware/bin/sccs{mv,cp}	5.x distribution
	dunk:/usr/teamware/sccs{mv,cp}		4.x distribution

For further details refer to the corresponding man pages.

From cmh@kipling  Mon Oct  5 13:38:38 1992
Date: Mon, 5 Oct 92 13:34:47 PDT
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: Avocet Update #18 - sccs help utility
Content-Length: 1314
X-Lines: 39
Status: RO


A number of people have recently encountered sccs error messages
while using the Codemgr tools.

In many cases, the sccs errors are caused by basic system problems 
which are easily and quickly solved, such as lack of write permissions.  

The sccs command provides a useful help utility which can be used
to retrieve more info regarding the problem, given the error code. 

This utility is called 'sccs help'.

You can distinguish an sccs error message from a Codemgr error
message by the distinctive all caps ERROR prefix that marks an 
sccs error message:

	ERROR: cannot create lock file (cm4)

Once recognized, you can provide the error code seen above in
parentheses as input to the 'sccs help' command:

	kipling% sccs help cm4

	cm4:
	"cannot create lock file"
	There are two known reasons why this can occur.

	1) Someone else is updating the SCCS file (or the p-file).
	   You'll have to wait until they're through, and try again.

	2) You do not have write permission in the directory where the
	   SCCS file resides.  If this is so, you are not allowed to
	   create any files (including the ``lock file'') in that
	   directory.

	If it is neither of the two reasons and the problem persists, 
	contact your Source Code Administrator (SCA).

See the man pages for sccs-help or help for more details.

From cmh@kipling  Mon Oct  5 17:07:02 1992
Return-Path: <cmh@kipling>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA02279; Mon, 5 Oct 92 17:07:02 PDT
Received: from kipling.Eng.Sun.COM by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04465; Mon, 5 Oct 92 17:00:35 PDT
Received: by kipling.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00692; Mon, 5 Oct 92 17:06:11 PDT
Date: Mon, 5 Oct 92 17:06:11 PDT
From: cmh@kipling (Claire Giordano)
Message-Id: <9210060006.AA00692@kipling.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Avocet Update #19 -- reparenting policies
X-Sun-Charset: US-ASCII
Content-Length: 1256
X-Lines: 33
Status: RO


Although the Codemgr utility allows one to reparent a workspace to
another workspace without any policy restrictions,

	there are OsNet-specific policies regarding reparenting 
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

of which you should be aware:


1) ONLY reparent from an older release such as phobos to a
   newer release such as on493.  

   Do NOT try the reverse, since such action might introduce 
   on493-specific changes into phobos.

2) WHEN reparenting from phobos to on493, realize that if
   your putback preceeds the latest update from phobos-->on493
   update, you might introduce phobos changes other than your 
   own into on493 BEFORE the natural phobos-->on493 update.

   What this implies is that if you pass as arguments to putback only 
   specific files or only specific portions of the hierarchy, you 
   might break the on493 parent even though the tests passed in your 
   workspace.  

   Why?  Because the changes in the files you putback had logical
   dependencies on other "changed" files in your workspace which
   you did not putback.

   Heads-up.  Reparent with caution.  Use 'putback -n' and 'diff'
   to detect changes other than your own which you might accidentally
   putback after reparenting.

From tadd@b5mail  Wed Oct  7 18:34:40 1992
Date: Wed, 7 Oct 92 18:33:46 PDT
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff, makestd@widor
Subject: update to makefile standards and guidelines
Content-Length: 441
X-Lines: 14
Status: RO

	A new version, 1.7, of Makefile Standards and Guidelines
is available now.  Please see it as the usual ASCII file:

  terminator:/usr/integration/doc/make.std

	This is the first update in two years.  The document is
shorter.  Now that we have stopped using the NSE, NSE-specific goals
for our builds have been cut.  I also cut examples using "config"
on kernel builds.   :-)


					Tadd

  [ now accessed through /shared/ON/general_docs ]

From tadd@b5mail  Tue Oct 13 12:06:39 1992
Date: Tue, 13 Oct 92 12:05:56 PDT
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #20 - Construction Set -- updated
Content-Length: 1867
X-Lines: 37
Status: RO

	[ newer note: pbld and spawn are already obsolete due to pmake ]

Introducing pbld, spawn, install.bin, protolist, and protocmp:

	The construction set, which contains forth and other utilities
used for OS-Net builds, has been updated and extended.  It is primarily
available as the SUNWonbld package (version 1.3) obtainable from the
/net/dunk/sdet/pkgs/1.3 directory as SUNWonbld.  You may pkgadd this
new SUNWonbld package without pkgrm'ing the earlier version(s) on your
machine.  Secondarily, you may mount /sdet/onbld from dunk onto your
/opt/onbld directory.

	Version 1.3 of the construction set package presents several
new utilities.  I am introducing pbld, a parallel-build script, with
a man page to describe it (/opt/onbld/man/man1/pbld.1).  The package
includes items used by or used with pbld, including Roger Faulkner's
spawn utility and Mike Walker's binary version of install (called
install.bin).  pbld and friends work together to build all OS-Net
source from scratch in 4 1/2 hours on a 4-way viking, 5 1/2 on a
2-way viking, and 13 1/2 hours on an SS2.  See the man page for
details.

	For calculating impact on packages, two new utilities are
introduced (documentation to follow).  These are protolist and protocmp.
They are tools for the gate keeper.  protolist lists the attributes of
files, directories, and other objects in your proto area; it functionally
replaces syslist for generating a list of ownerships and permissions
needed for specifying package definitions.  protocmp compares two lists
generated by protolist, thus revealing changes to the delivered product
and impact on packages.  (protolist calls str_format, which is also new
to the construction set.)

	If you need background information on construction sets and
the SUNWonbld package, see avocet update #14 in the avo_updates mail
folder in /opt/teamware/doc.

					Tadd

From msw@polyslo  Tue Oct 20 14:28:01 1992
Date: Tue, 20 Oct 92 14:26:41 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: New TeamWare Release(on dunk)
Content-Length: 8668
X-Lines: 176
Status: RO


In response to Evan's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/teamware
  for 4.x codemgr, see    dunk:/usr/teamware

	*** NOTE - the mount point has changed for the avocet distribution,
		   It is *NO LONGER* /opt/avocet or /usr/avocet.  The
		   /opt/avocet and /usr/avocet mount points are no
	   	   longer exported - you MUST mount /opt/teamware or
		   /usr/teamware!!!

	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Evans comments about pkgadd'ing this release.
	================================================================



	Evan's message said this about the new delivery:


		     1.0beta2 Release Notes

A new release of SPARCworks/TeamWare has been installed.  The releases 
are named via a file in the distribution directory named Release.  This 
release is called 1.0beta2 and this release name can be used in bugtraq.
The previous release, Alpha5, was very nearly identical to beta so
we did not make an internal beta release.

OsNet developers in SunSoft and SMCC should defer to the release
announcement message sent to the osnet-sde@stufff alias.  ON developers
should get binaries and ON value added utilities and documentation
based on the pointers provided by the osnet-sde@stufff messages.


Highlights:
	- docs are now available from the copy center
	- major interface changes to checkpointtool and checkpoint
	- improvement in how resolve handles checked out files
	- Distributed Make has been renamed to Parallel Make
	- Xview bug affecting codemgrtool when run on Mars alpha3.3 or beta
	  (see Codemgrtool changes below)
	- many, many bug fixes


1.0beta2 Details:

1) Complete TeamWare 1.0 Beta document sets are available from the copy
   center.  Ask for 825-1643-01.

2) Checkpoint changes:
   a) The checkpointtool interface has been redesigned.  It is now 
      patterned after the bringover and putback portions of codemgrtool.
   b) Checkpoint's interface has changed to use Code Manager workspaces
      instead of "source directories".  Additionally, the output is now
      similar to bringover and putbacks, there is a -n (show, but don't do)
      option, a -q (quiet) option to both the create and extract
      subcommands, create prompts for comments which are then stored 
      in the checkpoint file, and the -l (follow links) option has
      been removed.

3) Distributed Make changes:
   a) Distributed Make will be called Parallel Make for the first TeamWare
      release.  When it is able to distribute jobs to multiple machines
      its name will be changed back to Distributed Make.  This means that
      its has moved from the DistributedMake/bin directory to the
      ParallelMake/bin directory.
   b) Parallel Make no longer prints the "Command line XX suppressed"
      messages.
   c) Parallel Make no longer sequentializes commands with conditional 
      targets.
   d) Parallel Make will initially start the maximum number of processes
      and then back off if the load gets too high.
   e) Parallel Make will never back off to the point of running no 
      processes.

4) Version Tool changes:
   a) Vertool no longer dumps core when hitting the checkin button while a
      previous delta is selected in the history window.  Reported by David
      Miner.
   b) Vertool sometimes showed an incorrect delta graph in the history 
      window.  Reported by Len Brown.
   c) Vertool now supports area selections.

5) FileMerge changes:
   a) A few weeks ago we had sent out a patched version of filemerge
      to fix a bug with accept parent and accept child.  1.0beta2
      includes this fix.

6) Code Manager changes:
   a) Bringover-create would delete the child workspace under certain 
      error conditions.  Now it never deletes the child workspace.
      Reported by Maureen Chew.  (1100428).
   b) When resolve encounters a file that is checked out it asks that you
      check it in before resolving.  Previously, with filemerge up, this
      request was made back in the window where resolve was started and
      sometimes users did not see the request.  Now, a window comes up
      asking you to check in the file and allowing you to enter comments
      to do so.
   c) Resolve uses the PAGER and DIFF environment variables (1080480), 
      ! is an alias for the sh command (1080481), it no longer considers 
      it an error when there are no files in conflict (1097495), and the 
      commit command reports what it is doing (1093855).
   d) Resolve would go into an infinite loop if you exited filemerge early.
      Reported by Joe Eykholt.  (1100456).
   e) Notification mail no longer includes files for which there were errors. 
      Reported by Judy Hagan Payne.  (1102422).
   f) Notification mail now also reports the workspace names in machine:dir 
      form.  Requested by Tom Kessler.  (1092751).
   g) Bringover's algorithm for determining the common ancestor delta when
      there is a conflict is improved.  Previously it would only find common
      ancestor deltas on the trunk of the delta tree.  Now it will find them
      on branches as well.  This leads to smaller differences.  Reported by 
      Joe Eykholt and Len Brown.  (1101367).
   h) There is a significant performance improvement when checking a 
      netgroup for access permissions.  Reported by Mike Kupfer.  (1104006).
   i) Code Manager would dump core when trying to merge two s-files and
      the body of one did not begin with an insert line.  Reported by
      Judy Hagan Payne.  (1102585).
   j) Bringover and putback with the -n option will no longer core dump
      at the end.  Reported by many.
   k) The get command supplied with TeamWare had a bug where it would
      not materialize the correct file if there were more than 2 branches.
      Reported by Vicki Abe.  (1104016).
   l) If the TeamWare bin directory is not in your PATH, tools couldn't
      find other critical TeamWare binaries.  Reported by John Plocher.
      (1104688).
   m) Filenames written into the Codemgr_wsdata/nametable file are now
      written in a cannonical form where all extra dots, dot-dots and
      slashes are removed.  Reported by Mike Walker.  (1100944).

7) Codemgrtool changes
   WARNING: For those running any version of codemgrtool on Mars alpha3.3
   or beta or later, there is an XView bug during display of multi-line
   textfields (codemgrtool's Bringover and Putback comment fields are
   multi-line textfields) that cause codemgrtool to SEGV.  The workaround
   is to use older XView shared libraries.  For example:

   prompt% setenv LD_LIBRARY_PATH /usr/dist/sun4/openwin,v3.0.1.jup/lib
   prompt% codemgrtool &

   a) Renaming a workspace while viewing with short names no longer
      dumps core.  Reported by Martin Weiss.  (1098584).
   b) With CODEMGR_WS was set to a workspace with conflicts, codemgrtool
      would try to launch empty FileMerge on 4.x and would dump core on
      5.0.  Repored by Neil Smithline (4.x) and Dean Stanton (5.0).
      (1098830).
   c) Resolving with no autoadvance would dump core.
   d) Resolve Properties Auto Advance and Start FileMerge now work correctly.
   e) SPARCworks Manager-launched codemgrtool would dump core via a
      SPARCworks Manager Quit.  Reported by Hank Shiffman.  (1099093).
   f) Bringover-create from an unloaded Parent workspace now works correctly.
   g) Aborted bringover would hang codemgrtool.  Reported by Neil Smithline.
   h) Load Workspaces didn't expand tildes.  Reported by Marty Honda and
      Claeton Giordaon.  (1098551).
   i) File chooser now updates the directory correctly.
   j) Textfield validation and side-effects are now more consistent.
   k) Bringover and Putback panes now have Update Fields buttons
      (visible way to force fields to be consistent with each other).
   l) Added bringover and putback options Verbose, Skip SCCS gets, and 
      Force Conflicts.  Reported by many.

From msw@polyslo  Wed Nov 11 14:28:57 1992
Date: Wed, 11 Nov 92 14:27:45 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: New TeamWare release - 1.0Beta3(on dunk)
Content-Length: 6525
X-Lines: 151
Status: RO




In response to Claeton's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/teamware
  for 4.x codemgr, see    dunk:/usr/teamware

	*** NOTE - This release includes the fix for the Duplicate
    	    SMID problem that we have been having in OS-Net.  Many
     	    thanx goes to the CodeMgr group for fixing this!!!


Be sure to read Claeton's notes below.  He talks about the transition
that has to be made with this release.  You will need to run 
'% workspace updatenames <workspace>' on all of your current workspaces!!

All of the main OS-Net gates have been or are now being updated with the
new binaries.  If you are using the old binaries you will get
a warning message telling you to get the new ones - just remount
this distribution and you will be fine.


	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Evans comments about pkgadd'ing this release.
	================================================================

	Claeton's message said this about the new delivery:


		         1.0Beta3 Release Notes
                         ----------------------

A new release of SPARCworks/TeamWare has been installed.  The releases 
are named via a file in the distribution directory named Release.  This 
release is called 1.0Beta3 and this release name can be used in BugTraq
under the category "codemgr".

1.0Beta3 is intended to be the last TeamWare release before 1.0FCS due
out in late December.  The TeamWare 1.0 product will be publicly
announced Nov. 30th.

Highlights:
	- fix to rename bug caused by duplicated SCCS files 
	- this release does not inter-operate with previous releases (see
	  details on Inter-operability below)
	- read/write access_control, notification and lock from codemgrtool GUI 
 	- "checkpoint" binary renamed to "checkpt", likewise for checkpointtool
	- many bug fixes


1.oBeta3 Details:

 0) Fix to rename bug caused by duplicated SCCS files.  Fixes bugs:
	1102547 - reported by Mike Walker
	1077609 - reported by Martin Weiss
	1086194 - reported by Len Brown
 1) Fixed bug 1093472: when bo/pb "merge name histories" conflict in
    sdata is lost.
 2) CodeManager no longer reports an error when the notification file is
    empty.
 3) PMake no longer incorrectly rebuilds certain conditional targets.
 4) Long bogus hostnames in .make.machines no longer cause PMake to loop.
 5) Fixed Bug ID 1106266.  Auto-bringover doesn't work on hosts with C2
    security.
 6) Fixed Bug ID 1104592.  Don't update name history if rename fails.
    (reported by Mike Walker)

 7) Binary named "checkpoint" has been renamed to "checkpt", likewise for
    checkpointtool.
 8) codemgrtool no supported editing (read and write) of Workspace
    Properties contained in the Codemgr_wsdata files access_control,
    locks and notification.
 9) Teamware GUI choosers for SCCS files in workspaces are more uniform.
10) Bringover/Putback textfield advance/validation has been improved.
11) Update Fields buttons has been removed (Resolve Pane has Load Conflicts 
    button).
12) Bringover and Putback File List Edit menu item order now matches
    checkpttool.
13) Improved multiple selection Bringover and Putback setup.
14) Bug fix: GUI resolve sometimes can't find child's version of the file
    in conflict.

Inter-operability
-----------------

The transition is from 1.0beta2 (or an earlier TeamWare release) to
1.0beta3.  1.0beta3 does not inter-operate with 1.0beta2.  Once a workspace
has been touched by 1.0beta3, a user using 1.0beta2 won't be able to do
bringover's and putback's with that workspace.  The owners of its
children workspaces must upgrade to 1.0beta3; likewise with its
parent.   Passing a workspace's name to any 1.0beta3 binary "touches"
the workspace.  When a user tries to use 1.0beta2 on a workspace
touched by 1.0beta3, the user will see the following error message:

    Version mismatch between this binary and file
    "<workspace_name>/Codemgr_wsdata/access_control".
    This binary is compatible with version 1, but the file is version 2.
    Upgrade to a release that is more recent than release 1.0beta2. (Error 2046)

To upgrade to 1.0beta3, the 1.0beta2 user just needs to start using
1.0beta3.  (An e'mail message announcing 1.0beta3 will be sent to you
on Wed.)  After upgrading to 1.0beta3 some users may see the following
error message from CodeManager the first time they use 1.0beta3 on
their workspaces:

    Nametable in workspace: "<workspace_name>"
    cannot be read because the following SCCS files have identical root deltas
    	<file1>
    	<file2>
    Run the following command and then re-execute the "<cmd>" command:
	"workspace updatenames <workspace_name>"
	  (Error 2088)

"workspace updatenames" finds all the SCCS files in the workspace,
insures that CodeManager can distinguish them and updates the
workspace's nametable.  Once this command is run on a workspace, the
user won't see this error message again.  "workspace updatenames" runs
for about 15 minutes on a worskpace with 12,000 SCCS files.

SunOS source code users:  We've coordinated with the "gate keepers" to
upgrade their integration workspaces concurrently with the introduction
of 1.0beta3.

Why the transition?  Among the the many bug fixes in 1.0beta3, there is
fix to a rename bug.  This bug fix addresses the rename problems
introduced to the workspace hierarchy when a user makes a copy of an
SCCS file within a workspace and propagates it to other workspaces:

	% cp SCCS/s.file.c SCCS/s.newfile.c
	% putback file.c newfile.c

Though 1.0beta3 fixes this bug, 1.0beta2 can reintroduce it to a
workspace, which is why 1.0beta3 and 1.0beta2 don't inter-operate.  If
you're interested in the details of this rename bug and its fix, send
us e'mail and we'll provide a detailed explanation.

From tadd@b5mail  Thu Nov 12 18:25:00 1992
Date: Thu, 12 Nov 92 18:23:30 PST
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #21 - construction set updated
Content-Length: 760
X-Lines: 17
Status: RO

	Version 1.4 of the construction set is available.  You may
pkgadd SUNWonbld from the /net/dunk/sdet/pkgs/1.4 directory or mount
dunk:/sdet/onbld on your /opt/onbld directory.

e.g.,	pkgadd -d /net/dunk/sdet/pkgs/1.4 SUNWonbld

	Version 1.4 is smaller than 1.3.  Several utilities of use
only to gate keepers have been moved into a new SUNWongk package about
to be announced.  cstyle and the perl that it calls have been moved
out of the construction set and into the set of customizations we
applied to the recent teamware release.  Since several versions of
the construction set may be installed at once on a machine, there was
no point in having N copies of perl taking up space.

	Several updates and fixes have been applied to the pbld script.

					Tadd

From cmh@kipling  Wed Nov 18 15:19:31 1992
Date: Wed, 18 Nov 92 15:18:32 PST
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: codemgr update #22 - AVOID sccs rmdel, fix and cdc
Content-Length: 480
X-Lines: 21
Status: RO


Remember...

	DO NOT USE sccs rmdel

	DO NOT USE sccs fix

	DO NOT USE sccs cdc

in your codemgr workspaces!!!!!

The codemgr sccsmerge functionality (aka smoosh) does not work well
when the above sccs commands have been invoked.  Avoid using these
utilities!  Recently an sccs rmdel caused needless confusion and wasted
cycles for developers and gatekeepers alike.

For a one page description of codemgr tips for getting started, see:

	dunk:/opt/teamware/doc/sde_start

Claire

From tadd@b5mail  Tue Nov 24 10:10:58 1992
Date: Tue, 24 Nov 92 10:09:23 PST
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: update to construction set, SUNWonbld
Content-Length: 733
X-Lines: 17
Status: RO


	The OS-Net construction set has been updated with fixes and
enhancements to the parallel build script.  The new version is 1.4.1.
If you mount /opt/onbld from dunk:/sdet/onbld, then you already have
the update.  If you install the construction set as a local package,
then I recommend that you pkgrm SUNWonbld and pkgadd the new version
available from dunk:/sdet/pkgs/1.4.  Our friends in RMTC will be happy
to know that all objects in the package are "bin bin" owner and group
(not longer "tadd staff").

	Version 1.4.1 still contains Mars Beta versions of rpcgen, tic,
and zic for use through the development of external alpha.

	When Mars FCS versions are introduced in SUNWonbld, the version
will be 1.5 or greater.

					Tadd

From tadd@b5mail  Tue Dec  1 11:34:31 1992
Date: Tue, 1 Dec 92 11:32:47 PST
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: 5.x_bld_info doc expanded (1.9)
Cc: s493-re@benet, craigm@b5mail
Content-Length: 573
X-Lines: 17
Status: RO


	Version 1.9 of 5.x_bld_info is available in
terminator:/usr/integration/doc.

	The document describes the mechanics of doing various
builds with OS-Networking source.  I have expanded it to mention
EXPORT_SRC targets and the need to avoid libC.so on the build
host.  I restructured the document to serve two audiences:
source-product customers and Sun engineers, particularly gate
keepers.

	This is an improved version of a document long referenced
by our roadmap (also in terminator:/usr/integration/doc).

					Tadd

  [ now accessed through /shared/ON/general_docs ]

From cmh@kipling  Tue Dec  8 17:55:54 1992
Date: Tue, 8 Dec 92 17:54:49 PST
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff, on493-dev@benet
Subject: New rtitool release - 1.0(on dunk) 
Cc: on493-cteam@benet, cicci@kipling, des@kipling
Content-Length: 1517
X-Lines: 42
Status: RO


Rtitool version 1.0 is here!

Use Rtitool to file your implementor and gatekeeper RTI's!  It
is an Open Look GUI utility customized for os-net usage.

Key advantages of interest:

	Links w/bugtraq:	Fetches P/S and Synopsis info
				directly from bugtraq.

				Verifies that a bugid is evaluated.

Rtitool has been alpha and beta tested by ~15 of your peer
developers in os-net development.  The feedback has been 
overwhelmingly positive, even from those who avoid GUIs!

It is available to os-net developers thanks to the dedication of 
Catherine Cicci in SunSoft RE and the cooperation of her 
organization.  

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to update it with
the following *NEW* files and symlinks:

for 5.x rtitool, see	dunk:/opt/teamware/bin/rtitool <symlink>
			dunk:/opt/teamware/Rtitool/bin/rtitool
			dunk:/opt/teamware/Rtitool/lib/help/rtitool.general_help
			dunk:/opt/teamware/Rtitool/lib/help/rtitool.info

for 4.x rtitool, see	dunk:/usr/teamware/rtitool  <symlink>
			dunk:/usr/teamware/Rtitool/bin/rtitool
			dunk:/usr/teamware/Rtitool/lib/help/rtitool.general_help
			dunk:/usr/teamware/Rtitool/lib/help/rtitool.info

Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via: 

	The Help/Send feedback... menu button, which puts you in 
	a window (a mailtool compose window) which will automatically 
	send your feedback to rtitool-comments@plunge

From tadd@b5mail  Fri Dec 18 18:19:28 1992
Date: Fri, 18 Dec 92 18:18:21 PST
From: tadd@b5mail (Tadd Ottman)
To: osnet-sde@stufff
Subject: makefile guidelines extended
Content-Length: 568
X-Lines: 16
Status: RO


	I have extended the makefile guidelines document to include
a new topic: incremental build considerations for commands with a
local library.  You can find this appended to the incremental build
section of the document.  See version 1.8 of

  terminator:/usr/integration/doc/make.std

	The topic arose from a question concerning tradeoffs of
speed and accuracy in incremental builds of cmd/oampkg.  It applies
to a number of areas of the OS-Net source tree, including kadb and
the stand-alone libraries.

					Tadd

  [ now accessed through /shared/ON/general_docs ]

From cmh@kipling  Wed Jan 27 15:48:02 1993
Date: Wed, 27 Jan 93 15:30:49 PST
From: cmh@kipling (Claire Giordano)
To: osnet-sde@stufff
Subject: New rtitool release - 1.1(on dunk) 
Cc: on493-mgrs@benet
Content-Length: 3989
X-Lines: 96
Status: RO


The rtitool binaries have been updated on dunk to reflect a
new version of rtitool, rtitool 1.1.

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or 
update the following files and symlinks:

for 5.x rtitool, see:

		dunk:/opt/teamware/Rtitool/bin/rtitool
		dunk:/opt/teamware/Rtitool/lib/rtitool.config
		dunk:/opt/teamware/Rtitool/lib/help/rtitool.general_help
		dunk:/opt/teamware/Rtitool/lib/help/rtitool.info
		dunk:/opt/teamware/Rtitool/man/man1/rtitool.1
		dunk:/opt/teamware/man/man1/rtitool.1 <symlink>

for 4.x rtitool, see:

		dunk:/usr/teamware/Rtitool/bin/rtitool
		dunk:/usr/teamware/Rtitool/lib/rtitool.config
		dunk:/usr/teamware/Rtitool/lib/help/rtitool.general_help
		dunk:/usr/teamware/Rtitool/lib/help/rtitool.info
		dunk:/usr/teamware/Rtitool/man/man1/rtitool.1
		dunk:/usr/teamware/man/man1/rtitool.1 <symlink>

        ================================================================
Important:
                Note that until you reinvoke rtitool, you will continue to 
	"use" the previous version, rtitool 1.0.  The previous version will 
	be *removed* to another partition in two working days to make it 
	obsolete and to enforce the upgrade!
        ================================================================

Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via: 

	The Help/Send feedback... menu button, which puts you in 
	a window (a mailtool compose window) which will automatically 
	send your feedback to rtitool-comments@plunge

Rtitool 1.1 Release Notes, per Cathy Cicci:

	New features:
	1) List of releases, gates, aliases, and actions are
	   read in from a global properties file so they can
	   be modified at any time without rebuilding the tool.
	   Reported by Claire Giordano.
	2) Added "create bugid list" button menu to Deliverable
	   description window in Gatekeeper template.  Reported
	   by Claire Giordano.

	Bug fixes/RFE's:
	1) The "PSARC opinion number" field was bogus in that it
           didn't allow for opinions from other ARC's, and it
	   didn't include the year of the opinion.  So field label
	   was changed to "ARC opinion number", and ARC/year field
	   was added.  Reported by Joe Kowalski and Bill Shannon.
	2) "Gate for integration" text field changed to read-only.
	   Reported by Craig Mohrman.
	3) Fixed problem with bugtraq button where if it was
	   pressed twice in succession using a bugid with a
	   multiline synopsis, the second line was duplicated.
	   Reported by David Kahn, Jim Moore and Claire Giordano.
	4) A notice window will alert the user to unevaluated
	   bugs, in addition to the message in the error log.
	   Reported by Tim Marsland.
	5) In Gatekeeper template, an unevaluated bugid is listed
	   in the error log as a warning, not an error.  Reported
	   by Claire Giordano.
	6) Reply button is made inactive if "Load from Mail file"
	   window is empty.  Reported by Craig Mohrman.
	7) In Reply message, changed "Action: reassign" to
	   "Action: reassign to |> login <|".  Reported by Craig
	   Mohrman. 
	8) Reply window resizes correctly.  Reported by John
	   Spiller.
	9) Corrected initial default for maillog setting when
	   starting Rtitool without setting the properties.
	   Reported by David Kahn.
       10) Improved tool real estate.  Reported by Tim Marsland.
       11) Symlinks followed in searching for help files.
	   Reported by Claire Giordano.
       12) In Gatekeeper template, shell errors are captured
	   correctly when executing the "Do putback" command in
	   "create file list" menu, and "Run command" in "create
	   packaging list" menu.

	Documentation changes:
	1) Documented rtitool/mailtool interaction problem.  
	   Reported by Brent Callaghan.
	2) Added definition of "above the line" to spot help file.
	   Reported by Len Brown.
	3) A man page is now available.  Reported by Claire
	   Giordano.

From msw@polyslo  Thu Feb 11 16:21:55 1993
Date: Thu, 11 Feb 93 16:22:34 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: New TeamWare release - 1.0fcs(on dunk)
Cc: msw@polyslo
Content-Length: 4527
X-Lines: 106
Status: RO




In response to Claeton's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/teamware
  for 4.x codemgr, see    dunk:/usr/teamware


	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Evans comments about pkgadd'ing this release.
	================================================================



	Claeton's message said this about the new delivery:



		       TeamWare 1.0FCS Release Notes
                       -----------------------------

A new release of SPARCworks/TeamWare has been installed.  The releases
are named via a file in the distribution directory named Release.  This
release is called 1.0FCS, and this release name can be used in BugTraq
under the categories codemgr, pmake, checkpoint, filemerge and vertool.

OsNet developers in SunSoft and SMCC should refer to the release
announcement message sent to the osnet-sde@stufff alias.  ON developers
should get binaries and ON value added utilities and documentation
based on the pointers provided by the osnet-sde@stufff messages.

*****  This the last internal release on 4.x.  The next    *****
*****  release, 2.0alpha1, will be available only on 5.x.  *****

TeamWare 1.0 has been publicly announced and released.

Highlights:
	- many bug fixes
	- workspace conflict icon in codemgrtool
	- improved spot help
	- last internal release of TeamWare on Solaris 1.0 (SunOS 4.x)


1.0FCS Details:

 1. Changed priority of commands executed by codemgrtool from 20 back to 0.
 2. Bringover and putback set the following environment variables for FLP's
    to use: CODEMGR_WS_PARENT, CODEMGR_WS_CHILD, CODEMGR_WS_SRC,
    CODEMGR_WS_DEST and CODEMGR_CMD.
 3. Bringover and putback now verify that the destination workspace is
    writable.
 4. Workspaces with unresolved conflicts are displayed with a different
    icon in codemgrtool.
 5. Spot help messages have been improved.

Bugs fixed in this release:

 Bug 1107338: ws_undo of a directory that is not a workspace creates a
	      workspace in that directory. - Reported by Claeton Giordano
 Bug 1107192, 1107191: When a file that is in conflict but not in the
	      conflicts file, add it to the conflicts file and print a
	      message. - Reported by Jill Foley
 Bug 1103805: Workspace delete doesn't hold the workspace lock until the
	      delete is done. - Reported by Claeton Giordano
 Bug 1100793: History file does not include parent workspace name for
	      bringover. - Reported by Claeton Giordano
 Bug 1102100: Can not delete a workspace when there is no available disk space.
	      - Reported by Evan Adams
 Bug 1099410: Comments should be sanitized for quotes, etc. - Reported by
	      Larry Hoffman
 Bug 1107463: Putback to deleted parent dumps core. - Reported by John Treacy
 Bug 1097642: checkpt command line should handle conflicting options better.
	      - Reported by Marla Parker.
 Bug 1107505: Print history subcommand sometimes shows incorrect history. -
	      Reported by John Spiller.
 Bug 1097582: checkpt file not under the source dir works and should not.
	      - Reported by Rich McAllister
 Bug 1089730: Resolve complains about unsaved edits when it should not. -
	      Reported by Claeton Giordano
 Bug 1107539: Putback -b doesn't forward the -p argument to bringover. -
	      Reported by Tim Marsland
 Bug 1108451: Vertool dumps core when checking in a "pattern" of files. -
	      Reported by May Lee.
 Bug 1110230: Bringover and putback fail to merge some SCCS files. - 
	      Reported by Marilyn Shoemaker
 Bug fix:     Bringover loops (until out-of-swap space) on some truncated
	      SCCS files.
 Bug fix:     When loading child workspaces in codemgrtool, if one of a
	      workspace's children is not visible on the host, none of the
	      workspace's children are loaded.

From msw@polyslo  Tue Feb 23 12:55:35 1993
Date: Tue, 23 Feb 93 12:56:23 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: hdrchk announcement (on dunk)
Cc: jek3@polyslo
Content-Length: 4202
X-Lines: 130
Status: RO


All,

A new hdrchk utility has now been added to the OsNet distribution
of TeamWare.  If you mount teamware off of dunk then no action
is required.  If you have a private copy of the OsNet teamware
you will have to copy the following file and symlink.


for 5.x hdrchk, see	dunk:/opt/teamware/bin/hdrchk  <symlink>
			dunk:/opt/teamware/OSNet/bin/hdrchk

for 4.x hdrchk, see	dunk:/usr/teamware/hdrchk  <symlink>
			dunk:/usr/teamware/OSNet/bin/hdrchk


	Here's what jek3 has to say about this new tool:


		   	 hdrchk

A new tool for checking conformance to standards has been added to the build
utilities.  It is a perl script called hdrchk which checks a header for
conformance to PSARC/1991/041.  Actually, it checks for a bit more uniformity
with respect to uniform formatting than is specified by 1991/041, but these
`nits' are not excessive and do increase the uniformity and percieved quality
of our headers.  1991/041 has also been refered to as KNF format.

hdrchk was written and debugged for the most part by Bill Shannon at my
request.  It seems to do a pretty darn good job of noting when something
isn't right but sometimes the diagnostic issued isn't exactly descriptive
of the problem.  I encourage constructive critisism but ask that it be
directed to me first so I can filter it before enlisting Bill's help.  (Who
knows, I might even learn Perl this way.)

All the exported headers under 1093 pass the hdrchk and cstyle tools with
the few exceptions noted below.  All the Makefiles which install headers have
been modified with the addition of a `check' target which currently applies
hdrchk and cstyle to all the headers in the directory (and recursively to
interesting subdirectories).  An individual file may be checked by entering
`make file.check'.  The Makefiles know about the exceptions and will pass
these files as well.
 
The exceptions are as follows:

head/assert.h:		[hdrchk]

			This file is required by ANSI-C to not be idempotent.
			Therefore the `end guard' is not the last thing in the
			file.  This is the way it must be and should not be
			fixed - ever! 

uts/sun/sys/devops.h:	[cstyle] devops.h: 296: line > 80 characters

			This file has a macro where the formal parameters to
			the macro are greater than 80 characters.  cpp (or
			the equivalent built into acomp) does not allow
			continuation line breaks in the formal parameter
			list.  This could be fixed by giving shorter names
			to the formal parameters, but the right fix is to
			fix cpp.

			There is a version of cstyle which allows this to
			be fixed with /* CSTYLED */, but this version seems
			to not be widely distributed.  When it is, this
			exception should be removed from the Makefiles and
			embedded in the header.

lib/libcurses/screen/term.h:
			[cstyle] Many `line > 80 characters'

			This file is generated by a complex ed script.
			Someday somebody who is really bored might fix this.

All rpcgen'erated files:

			There are several reasons these aren't checked at
			this time:

			1)  A silly error in rpcgen causes it to actually
			    generate cstyle errors.

			2)  The .x input files have more violations than I
			    care to deal with.  I want to get somebody who
			    knows more about these to fix them.

			3)  There seems to be good reasons for the headers
			    generated by rpcgen to not meet all the hdrchk
			    standards.  A special version probably needs to
			    be developed to check these.


A typical new header could be generated from the following template:

/*
 * Copyright (c) 1993 by Sun Microsystems, Inc.
 */

/*
 * Template for header files.
 *
 * This assumes the file is named <sys/foo.h>.  Don't forget to change
 * the _SYS_FOO_H symbol in all three places in this template to reflect
 * the real name of your header file.  Also note that this name should
 * reflect the installed path to the file, not its location in the source.
 */

#ifndef	_SYS_FOO_H
#define	_SYS_FOO_H

#pragma ident	"%Z%%M%	%I%	%E% SMI"

/*
 * Include any headers you depend on.
 */
#include <sys/bar.h>

#ifdef	__cplusplus
extern "C" {
#endif

/*
 * Main body of <sys/foo.h> header file goes here.
 */

#ifdef	__cplusplus
}
#endif

#endif	/* _SYS_FOO_H */

From msw@polyslo  Tue Mar  2 15:00:24 1993
Date: Tue, 2 Mar 93 15:01:11 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: Alert: CodeMgr going to /usr/dist...
Content-Length: 582
X-Lines: 22
Status: RO


Who should read this:  

	Those who use the OsNet distribution of CodeMgr!

CodeMgr is about the be distributed through /usr/dist.  This means
that everyone who uses the OsNet distribution of CodeMgr is going
to have to be careful.  

If you mount /usr/dist on your machine make sure the directory
containing the OsNet distribution of CodeMgr comes before /usr/dist
in your PATH.

eg:
	PATH="<stuff>:/opt/teamware:<stuff>:/usr/dist:<stuff>"

If you don't do this you will lose the flp custimizations that
the OsNet group has added to our CodeMgr distribution.  


Thanx,
   _Mike_

From msw@polyslo  Thu Mar 11 17:00:29 1993
Date: Thu, 11 Mar 93 17:01:33 PST
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: 5.2 beta1.2 bug breaks TeamWare
Content-Length: 1398
X-Lines: 42
Status: RO

		[ this was fixed by 5.2 FCS and is no longer a problem ]
All, 

If you use CodeMgr please read!!!

_Mike_


----- Begin Included Message -----

Date: Thu, 11 Mar 93 15:45:21 PST
From: giordano@caserta (Claeton Giordano)
To: teamware-users@caserta, teamware-bugs@caserta
Subject: 5.2 beta1.2 bug breaks TeamWare


EXECUTIVE SUMMARY: run TeamWare commands only on 5.2 prebeta or earlier.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A bug in SunOS releases 5.2 beta1.2 (s493) and newer causes some SCCS
files to be corrupted.  When a host is running SunOS 5.2 beta1.2, files
which have been newly 'sccs created' in a workspace are corrupted at
bringover and putback time.  We've implemented a workaround which we
plan to announce and release internally soon.  In the meantime, the
workaround is to run TeamWare commands only on hosts running 5.2
prebeta or earlier.

Once a file has been corrupted in the parent and child workspaces, it
cannot be propagated to other workspaces because bringover and putback
do not copy the file and report the following error:

   bringover: Delta serial number 2 out of order in file "<file>"  (Error 2060)

The bug ID is 1122415.  We have verified that it's in "5.2 beta1.2" and
"5.3 DCT MT libs".  Likewise, it's *not* in "5.2 Beta 1.0", "5.2 prebeta",
"5.2 alpha5.0" and "5.2 alpha4.0".

Claeton


----- End Included Message -----


From msw@polyslo  Thu Mar 25 11:43:22 1993
Return-Path: <msw@polyslo>
Received: from Eng.Sun.COM (zigzag) by dunk.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11821; Thu, 25 Mar 93 11:43:22 PST
Received: from stufff.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA03410; Thu, 25 Mar 93 11:44:43 PST
Received: from polyslo.Eng.Sun.COM ([129.144.50.38]) by stufff.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16355; Thu, 25 Mar 93 11:28:18 PST
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA24701; Thu, 25 Mar 93 11:33:53 PST
Date: Thu, 25 Mar 93 11:33:53 PST
From: msw@polyslo (Michael Walker)
Message-Id: <9303251933.AA24701@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: CodeMgr - also a reminder about your PATH
Cc: teamware-users@kepler
X-Sun-Charset: US-ASCII
Content-Length: 336
X-Lines: 11
Status: RO



A REMINDER about your PATH.  CodeManager is now being distributed by
/usr/dist.  If you mount the OsNet CodeManager binaries off of dunk you
must be sure that the dunk binaries come BEFORE /usr/dist in your
PATH.  If you don't do this you won't get the added functionality that
we've added to the CodeManager def.dir.flp's.


_Mike_


From msw@polyslo  Tue Apr 27 17:28:06 1993
Date: Tue, 27 Apr 93 17:27:06 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #24: Removal of .del-* files from source base
Cc: on1093-gk@stufff
Content-Length: 2154
X-Lines: 57
Status: RO


THIS IS ONLY RELEVANT IF YOU WORK WITH THE OSNET SOURCE BASE - IF YOU DON'T
DELETE THIS MESSAGE NOW.

All,

I am about to do a big 'cleanup' of all of the .del-* files that we
have in the OSNet source base.  The .del-* files represent files that
have been deleted in our OsNet CodeMgr workspaces.  Because you can't
every 'truly' delete a file under CodeMgr we rename them to the .del-*
file name.  At last count we have 1900+ .del-* files in our source
base.  Its time we cleaned this up a little.  If you'd like to more
information on the .del-* files themselves please take a look at
the CodeMgr update #16 (/opt/teamware/doc/avo_updates) for more information.

I will be moving all of these .del-* files into a parallel source
tree where they should be 'more' out of the way.  Here is how
it will work.  For every .del-* files that is presently found under
usr/src/* in our source base I will move it into a parallel tree under
usr/deleted-files/*.  

	eg:
		...
		usr/src/lib/libnsl/.del-libnsl.mk-Dec-16-92
		usr/src/lib/libnsl/.del-Makefile.map-Jan-23-93
		usr/src/lib/libnsl/nis/cache/.del-sem.h-69035229
		...

	will all be moved to:

		...
		usr/deleted_files/lib/libnsl/.del-libnsl.mk-Dec-16-92
		usr/deleted_files/lib/libnsl/.del-Makefile.map-Jan-23-93
		usr/deleted_files/lib/libnsl/nis/cache/.del-sem.h-69035229
		...

Once this is done if you do a bringover of 'usr/src/uts' you will
bringover only the source code found under there and none of the over
600+ .del-* files that are presently under that tree.  This will make
your bringovers quicker and save on your disk space.

Once this big change is done I will continue to move new .del-* files
out of the usr/src/* source base over into the usr/deleted_files/*
tree.  These updates will happen periodically (probably weekly).


Executive Summary:

	o In the next couple of days or weeks you will see many renames
	  from usr/src/*/.del-* -> usr/deleted_files/*/.del-*.  Don't worry.
	o If you need to find a file that has been deleted it can now
	  be found under usr/src/deleted_files/*
	o These changes will be made to /ws/train (on1093) and propogate
	  down from there.
	

_Mike_

From msw@polyslo  Wed Apr 28 12:48:03 1993
Date: Wed, 28 Apr 93 12:49:19 PDT
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #24.5 update: Removal of .del-* files from source base
Content-Length: 312
X-Lines: 10
Status: RO


UPDATE

After consulting with the CodeMgr development team we've decided to move
the deleted file structure to $CODEMGR_WS/deleted_files instead of
$CODEMGR_WS/usr/deleted_files.  This will match with future plans the
CodeMgr group has for introducing an sccsrm command similar to what we
already have.

_Mike_

From msw@polyslo  Wed Jun 23 16:56:36 1993
Date: Wed, 23 Jun 1993 16:57:58 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: update to rtitool on dunk...
Content-Length: 1073
X-Lines: 33
Status: RO


I've just applied a minor patch to the rtitool on dunk.

If you have a copy of the teamware distribution from dunk you will want
to copy the following files into your distribution:

	dunk:/opt/teamware/Rtitool/bin/rtitool
	dunk:/usr/teamware/Rtitool/bin/rtitool

This patch includes the following fixes:

1) rtitool can now talk to the new bugtraqd daemons on elmer.

2) when rti's are submitted the sponsor is automatically cc:'d on
   the submission.


*IMPORTANT NOTE*:
If you mount your binaries from dunk and you wish to see the changes
in the configuration file reflected in rtitool, you need to exit and
reinvoke rtitool on your machine.

If you mount your binaries from elsewhere, you will also need to exit
and reinvoke rtitool once your local copy of the teamware distribution
has been updated.

Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via:

        The Help/Send feedback... menu button, which puts you in
        a window (a mailtool compose window) which will automatically
        send your feedback to rtitool-comments@plunge


From msw@polyslo  Thu Aug 12 10:01:50 1993
Date: Thu, 12 Aug 1993 10:03:01 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: CodeMgr update #25 -- codereview utility
Cc: johnz@eng
Content-Length: 2307
X-Lines: 86
Status: RO


All,

A new codereview utility has been added to the OsNet distribution
of TeamWare.  If you mount teamware off of dunk then no action
is required.  If you have a private copy of the OsNet teamware
you will have to copy the following file and symlink.


for 5.x hdrchk, see	dunk:/opt/teamware/bin/codereview  <symlink>
			dunk:/opt/teamware/OSNet/bin/codereview
			dunk:/opt/teamware/man/man1/codereview.1 <symlink>
			dunk:/opt/teamware/OsNet/man/man1/codereview.1


This utility was put together by John Zolnowsky, if you have any questions
e-mail johnz@eng with them.


Here is the man page for the new utility:


--------



CODEREVIEW(1-LOCAL)Misc. Reference Manual PageCODEREVIEW(1-LOCAL)



NAME
     lwlp - Diff list generator

SYNOPSIS
     codereview [-r] oldfile newfile

DESCRIPTION
     The codereview command expects two ASCII text files as input
     and  produces  Postscript describing the differences between
     the files.  The first file is assumed to be the  older  ver-
     sion,  and  the  second file is assumed to be the newer ver-
     sion.  The output lists all  lines  from  both  files,  with
     lines changed from the first to the second being highlighted
     in gray.  Lines deleted from the first file  are  listed  in
     italic,  while  lines added to the second file are listed in
     bold.

OPTIONS
     -r         Enable page reversal so that the pages appear  in
               the   correct  sequence  in  the  output  tray  of
               printers like the Apple LaserWriter.  The  default
               is  to not perform page reversal, which is correct
               for printers like the NEC Silentwriter LC-890.

FILES
     /tmp/lwlpXXXXXX          -  temporary  file  used  for  page
     reversal

LIMITATIONS
     The maximum input line  length  is  1024  characters.   This
     should  not present a problem since the corresponding output
     line length would be too long to be  printed.   The  program
     silently truncates input lines that are too long.

NOTES
     The command
          pageview -right -h 17 -w  11  -Ws  1100  850  -dpi  100
     out.ps

     is useful for displaying the results of codereview.

AUTHOR
     John Zolnowsky
     SunSoft, Inc.











Sun Microsystems      Last change: 93/08/09                     1

From tadd@jurassic  Mon Sep 20 09:23:22 1993
Return-Path: <tadd@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00619; Mon, 20 Sep 93 09:23:22 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00179; Mon, 20 Sep 93 09:26:42 PDT
Received: from widor.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA27714; Fri, 17 Sep 1993 19:55:39 +0800
Received: by widor.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00731; Fri, 17 Sep 1993 19:55:23 +0800
Date: Fri, 17 Sep 1993 19:55:23 +0800
From: tadd@jurassic (Tadd Ottman)
Message-Id: <9309180255.AA00731@widor.Eng.Sun.COM>
To: osnet-sde@stufff, merge@mtns
Subject: codemgr update #27 - new construction set
Content-Length: 618
X-Lines: 22
Status: RO



	Now available from dunk.eng are updated SUNWonbld packages
for *both* sparc and i386.

	To install version 2.0 for sparc do:
  pkgadd -d /net/dunk.eng/sdet/pkgs/2.0 SUNWonbld

	To install version 2.0.1 for i386 do:
  pkgadd -d /net/dunk.eng/sdet/pkgs/i386/2.0 SUNWonbld

	These contain a new link to the binary install utility in its own
directory.  This allows you to switch between slow and fast install
utilities without causing rebuilds because of name changes in .make.state
files.

	The sparc version contains 5.3 versions of rpcgen, tic, and zic.
It is being exported from /net/dunk/sdet/onbld.


					Tadd


From tadd@jurassic  Wed Sep 22 20:12:45 1993
Return-Path: <tadd@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00706; Wed, 22 Sep 93 20:12:45 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA02244; Wed, 22 Sep 93 19:46:18 PDT
Received: from widor.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA15491; Wed, 22 Sep 1993 19:44:06 +0800
Received: by widor.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00711; Wed, 22 Sep 1993 19:43:50 +0800
Date: Wed, 22 Sep 1993 19:43:50 +0800
From: tadd@jurassic (Tadd Ottman)
Message-Id: <9309230243.AA00711@widor.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: ws script and mk_bld_space script updated
Content-Length: 895
X-Lines: 24
Status: RO


OS-Networking teamware users,

	On dunk.eng I have updated two scripts we always add to teamware
as customizations; these are ws and mk_bld_space.

	For ws, I cut old "avocet" support and added the setting of the
MACH shell variable for 5.x builds.  The value for MACH comes from
running uname -p.  Merged makefiles depend on this, per the CST
engineering guide.

	For mk_bld_space, I "taught" it to skip s-dot files found
in the backup subdirectory of Codemgr_wsdata directories.  In extreme
cases, this could save you MBs of disk space in a "bld_space", since
the backup files are for workspace undo operations having nothing to
do with test builds.

	Please use version 1.26 of ws and version 1.3 of mk_bld_space.

	If you NFS mount teamware from dunk, you will already see these
versions.  Otherwise, you will await an update of your locally exported
reference copy of teamware.

					Tadd

From msw@polyslo  Fri Oct  8 17:37:19 1993
Date: Fri, 8 Oct 1993 17:38:42 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: codemgr update #29 - ws updated to support multiple architectures
Content-Length: 919
X-Lines: 24
Status: RO



OS-Networking teamware users,

	On dunk.eng I have updated ws, one of the OsNet additions to
teamware, to support both x86 & sparc proto areas.  ws now has an
'architecture' aware default location for the PROTO areas, the
ROOT, ENVCPPFLAGS{1-4}, and ENVLDLIBS{1-3} will be built in the following
way:
		ROOT=${CODEMGR_WS}/proto/root_{i386|mach}

	PROTO's will now be set in the following way.  If, when ws is
activated, there is already an 'old' PROTO area present then the 
env variables will be set as usual.  If, however, there is no 'old' PROTO
area present it will sent the env variables as ROOT is set above.

	This new setting is done to support the possibility of a 
single workspace containing, and exporting, multiple PROTO areas.  Soon
the Gatekeeper workspaces will be exporting this new format of PROTO areas
and you will be able to look to them for *both* sparc and i386 headers
and libraries.


_Mike_

From msw@polyslo  Fri Oct  8 17:37:20 1993
Date: Fri, 8 Oct 1993 17:38:47 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: update to OsNet teamware on dunk
Content-Length: 859
X-Lines: 38
Status: RO





The following tools have just been updated on dunk:

	ws & codereview


These updates are for:



ws)
	support new architecture specific PROTO areas.  See CodeMgr
	update for more info

codereview)

...(from johnz)...
	I've updated codereview to handle problems with tab space computation
	and the handling of files with no changes, and correct a glitch on the
	man page.  


** If you mount your teamware binaries from DUNK no action is required **

If you have a copy of the teamware distribution from dunk you will want
to copy the following files into your distribution:

	dunk:/opt/teamware/OSNet/bin/ws
	dunk:/opt/teamware/OSNet/bin/codereview
	dunk:/opt/teamware/OSNet/bin/mk_bld_space
	dunk:/opt/teamware/OSNet/man/man1/ws.1
	dunk:/opt/teamware/OSNet/man/man1/codereview.1
	dunk:/usr/teamware/OSNet/bin/ws
	dunk:/usr/teamware/OSNet/man/man1/ws.1


From msw@polyslo  Wed Oct 13 13:54:21 1993
Date: Wed, 13 Oct 1993 13:55:42 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: update to Rtitool on dunk
Content-Length: 1321
X-Lines: 37
Status: RO


Rtitool has been updated on dunk.

If you have a copy of the rtitool distribution from dunk you
will want to copy the following files into your distribution:

	dunk:/opt/teamware/Rtitool/*

*IMPORTANT NOTE*:
If you mount your binaries from dunk and you wish to see the changes
in the configuration file reflected in rtitool, you need to exit and
reinvoke rtitool on your machine.

If you mount your binaries from elsewhere, you will also need to exit
and reinvoke rtitool once your local copy of the teamware distribution
has been updated.


And here are a few of the changes that have been made:

	1) x86 support for Rtitool
	2) removed access to the gatekeeper rti templates from withing
	   rtitool.  Gatekeeper RTI's are once again submitted
	   from a text template and *not* from within Rtitool.
	3) Changed "codes" button to "risk&impact" button in the
	   one liner pop-up.
	4) changed several of the "risk&impact" codes on the "risk&impact"
	   pop-up.  (per request from Tim Marsland).
	5) removed NIS check for the sponsorid field.  This can be a
	   mail alias that is not nis-checkable (ie: paul.richards@central).
	6) Rtitool is no longer supported on 4.x.  If you are on a 4.x system
           you will need to remote display it onto your system.


There will be an x86 push of this later today.

_Mike_

From msw@polyslo  Thu Oct 28 15:02:24 1993
Date: Thu, 28 Oct 1993 15:03:48 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, teamware-users@kepler
Subject: New Teamware release - 1.0.2 Beta (on dunk)
Cc: msw@polyslo
Content-Length: 3243
X-Lines: 85
Status: RO



In response to Jules's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/opt/teamware


	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Jules's comments about pkgadd'ing this release.
	================================================================



	Jules's message said this about the new delivery:


		       TeamWare 1.0.2 Beta Release Notes
                       ---------------------------------

A new release of SPARCworks/TeamWare has been installed.  The releases
are named via a file in the distribution directory named RELEASE.  This
release is called 1.0.2 Beta, and this release name can be used in
BugTraq under the categories codemgr, pmake, checkpoint, filemerge and
vertool.

OsNet developers in SunSoft and SMCC should refer to the release
announcement message sent to the osnet-sde@stufff alias.  ON developers
should get binaries and ON value added utilities and documentation
based on the pointers provided by the osnet-sde@stufff messages.

As mentioned in the previous release's notes, this release is not yet
available on Solaris 1 or Solaris x86  This release is supported on
Solaris 2.x SPARC.

Highlights:

	- filemerge displays per-substring visual diffs
	- filemerge subwindows support horizontal scrolling
	- filemerge color support
	- filemerge AboutBox support
        - option to bringover/putbck to disable backups
        - "Ted Tuner"-ization (color GUI's)
        - new workspace subcommand: 'name'
	- > 60 bug fixes
	- i18n level 4 support
	- full interoperability with 1.0.


1.0.2 Beta details:

	Bug fix (1133813) : Extra lines displayed in filemerge - reported
	                    by Mark Liu
	Bug fix (1133952) : Filemerge used wrong font - reported by Mark Liu
	Bug fix (1137785) : Make truncates long macro settings when set from
	                    the command line - reported by Kevin Rushforth
	Bug fix (1140705) : Bringover dies from errant SIGALARM - reported by
	                    David Chase
	Bug fix (1143514) : Filemerge incorrectly reports that diffs are
		            resolved - reported by Alan Walworth
	Bug fix           : Bringover leaves SCCS file with open branch
	Bug fix           : Bringover can't process "twisted pairs"
	Bug fix (1142825) : filemerge displays corrupted diff strings -
	                    reported by Teruhiko Kurosaka
	Bug fix (1111118) : Notification messages cause vacation e'mail
	                    to reply. - Rich McAllister
	Many more.


Jules Damji
TeamWare Group

From tadd@jurassic  Fri Oct 29 17:45:06 1993
Date: Fri, 29 Oct 1993 17:46:46 +0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff
Subject: new linkers with KEEP_STATE
Content-Length: 1135
X-Lines: 29
Status: RO


	Rod's fix for KEEP_STATE in both sparc and i386 linkers is
now available as updated SUNWonld packages.  The problems was extra
information written to .make.state files that caused unnecessary
rebuilds.

	On sparc, the default linker does not have KEEP_STATE
functionality, so dependencies on libraries are not recorded by
the linker in .make.state files.  Dependencies are inaccurately
understated.  The SUNWonld package gives you a linker that records
accurate information.

	On i386, the default linker temporarily does have KEEP_STATE
functionality, so the SUNWonld package offers you early access to
Rod's fix.  The 2.1 i386 linker did not have KEEP_STATE, so the
SUNWonld package offers you this functionality on 2.1 systems.

	To install SUNWonld:
on sparc:  pkgadd -d /net/dunk.eng/sdet/pkgs/ld_patch  SUNWonld
on i386:   pkgadd -d /net/dunk.eng/sdet/pkgs/i386/ld_patch  SUNWonld

	The package version for both architectures is 2.4.0.2.

					Tadd

 [ now more symmetrically exported:
on sparc:  pkgadd -d /net/dunk.eng/sdet/pkgs/sparc/ld_patch SUNWonld
on i386:   pkgadd -d /net/dunk.eng/sdet/pkgs/i386/ld_patch  SUNWonld
 ]

From msw@polyslo  Tue Nov  2 15:44:25 1993
Date: Tue, 2 Nov 1993 15:45:54 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff, on-eng@dunk
Subject: new cstyle program
Cc: shannon@polyslo
Content-Length: 4502
X-Lines: 174
Status: RO


The cstyle script has been updated on dunk

** If you mount your teamware binaries from DUNK no action is required **

If you have a copy of the teamware distribution from dunk you will want
to copy the following files into your distribution:

	dunk:/opt/teamware/OSNet/bin/cstyle

Here is what Bill has to say about this update:


I've been doing a lot of work on the cstyle program recently.
In addition to fixing a few bugs, I've beefed it up to check
for *many* more errors.  Almost all of these errors are
described in the current C style document (which I'm also
updating), and the rest have been an "unwritten" part of our
style for a long time.

Here's a list of some of the new errors that cstyle is now able
to detect:

	extra space between function name and left paren
	obsolete use of VOID or STATIC
	unneeded return at end of function
	unterminated single line comment
	missing space before left brace
	bad text following right brace
	missing space between type name and *
	blank after preprocessor #
	don't use boolean ! with strcmp
	extra space between keyword and paren
	left brace starting a line
	extra space after right brace
	preprocessor statement not in column 1
	return type of function not on separate line
	missing space after right brace


You can find the new version in dunk:/opt/teamware/bin/cstyle.

This new version includes a "-t" flag to enable "transition" (or is
it "tolerant"?) mode.  In this mode cstyle will check only the things
that it used to check for.

In addition, there are a few errors that cstyle is now able to detect
but that are *far* too prevalent to even consider asking you to clean
them up.  I've added checks for these things under the "-p" (picky)
option.

My automatic cstyle reminder script will use transition mode for
the next year.  Once a month I will run it without transition mode,
to remind you of the "new" errors that still need to be fixed.  About
a year from now I will remove the transition option.

Please try out this new version and let me know of any bugs you find.
If you believe it will be too painful to clean up any of your files
over the next year, let me know the names of those files.

Thanks for your help.

	Bill


P.S.  Here's a brief explanation of the newly detected errors, in
case any of them aren't obvious:

extra space between function name and left paren

	There should be no space between the function name and the
	left paren.  Use "foo(x)", not "foo (x)".

obsolete use of VOID or STATIC

	Some of the code we got from AT&T used VOID and STATIC instead
	of void and static, for various stupid reasons.  We're trying
	to purge this stuff from the system.

unneeded return at end of function

	Functions that return void don't need a return statement at
	the end of the function.  Instead, they should just "fall
	off the end" and return implicitly.

unterminated single line comment

	Usually something like

	int	foo;	/* this is a very
			   long comment */

	Instead, use

	int	foo;	/* this is a very */
			/*   long comment */

	Or use a standard block comment before the line it applies to.

missing space before left brace

	Usually something like "if (foo){", often because someone's
	trying to squeeze the line into 80 characters.

bad text following right brace

	I think this is usually a consequence of some other error earlier
	in the file.  Also, I think there might be a few cases where cstyle
	is complaining incorrectly.  A common error that causes this is
	using more than one space, or a tab, between the "}" and the
	following "else" or "while".

missing space between type name and *

	Use "(char *)", not "(char*)".

blank after preprocessor #

	Preprocessor statements should be at the left margin, not indented
	like this:

	#	ifdef	foo		/* WRONG */

don't use boolean ! with strcmp

	Never, ever, ever do "if (!strcmp(a, b))".  Instead use
	"if (strcmp(a, b) == 0)" so that it's clear that you're
	testing for equality of the two strings.

extra space between keyword and paren

	Just one space, please.

left brace starting a line

	Usually something like:

		if (foo)
		{

	Of course, use

		if (foo) {

	instead.

extra space after right brace

	The real error that also generates the complaint "bad text
	following right brace".

preprocessor statement not in column 1

	Don't use

		if (foo) {
			#ifdef bar	/* WRONG */

return type of function not on separate line

	Don't do

	int foo(int x)
	{

	Do

	int
	foo(int x)
	{

missing space after right brace

	"}else" or "}while".

From msw@polyslo  Fri Nov  5 14:54:59 1993
Return-Path: <msw@polyslo>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA15128; Fri, 5 Nov 93 14:54:59 PST
Received: from polyslo.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA08724; Fri, 5 Nov 93 14:59:22 PST
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00730; Fri, 5 Nov 1993 14:55:46 +0800
Date: Fri, 5 Nov 1993 14:55:46 +0800
From: msw@polyslo (Michael Walker)
Message-Id: <9311052255.AA00730@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff, on-eng@benet
Subject: New version of teamware (1.0.2beta) re-pushed to dunk
Cc: on494-gk@benet, giordano@polyslo, jsd@polyslo
Content-Type: X-sun-attachment
X-Lines: 213
Status: RO
Content-Length: 11035      

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 39
X-Sun-Content-Length: 1293



All,

Thanx to the quick response of the teamware group the 1.0.2beta version
of Teamware has been fixed and I am re-installing it on dunk.

The problem actually turned out to be a bug in fscanf and
how it handles Sigalarms (bug#1148167).  The teamware group has
coded around this bug and has delivered updated versions
of bringover, putback, resolve, and ws_undo.

  for 5.x codemgr, see    dunk:/opt/teamware


	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Jules's comments about pkgadd'ing this release.
	================================================================



I've also attached the original announcement and the bug report
in question below.

_Mike_

----------
X-Sun-Data-Type: sun-deskset-message
X-Sun-Data-Name: teamware1.0.2beta_announce
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 82
X-Sun-Content-Length: 4897

begin 600 teamware1.0.2beta_announce
M1G)O;2!M<W= <&]L>7-L;R @5&AU($]C=" R." Q-3HP,CHR-" Q.3DS"D1A
M=&4Z(%1H=2P@,C@@3V-T(#$Y.3,@,34Z,#,Z-#@@*S X,# *1G)O;3H@;7-W
M0'!O;'ES;&\@*$UI8VAA96P@5V%L:V5R*0I4;SH@;W-N970M<V1E0'-T=69F
M9BP@=&5A;7=A<F4M=7-E<G- :V5P;&5R"E-U8FIE8W0Z($YE=R!496%M=V%R
M92!R96QE87-E("T@,2XP+C(@0F5T82 H;VX@9'5N:RD*0V,Z(&US=T!P;VQY
M<VQO"D-O;G1E;G0M3&5N9W1H.B S,C0W"E@M3&EN97,Z(#@Y"E-T871U<SH@
M4D\*"@H*26X@<F5S<&]N<V4@=&\@2G5L97,G<R!M97-S86=E(&]N('1H92!A
M=F%I;&%B:6QI='D@;V8@=7!D871E9 I496%M=V%R92!B:6YA<FEE<RP@22!U
M<&1A=&5D(&]U<B!/4RUG<F]U<"!R969E<F5N8V4@8V]P>2!O9B!T:&4@8FEN
M87)I97,*;VX@:&]S="!D=6YK+B @3W5R(&-O<'D@:6YC;'5D97,@3U,M9W)O
M=7 @8W5S=&]M:7IA=&EO;G,N"@H@(&9O<B U+G@@8V]D96UG<BP@<V5E(" @
M(&1U;FLZ+V]P="]T96%M=V%R90H*"@D]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]"DEM
M<&]R=&%N=#H*"0E)9B!Y;W4@;6]U;G0@8V]D96UG<B!F<F]M(&1U;FLL('1O
M(")S964B('1H92!N97<@<F5L96%S90H)>6]U(&YE960@=&\@*G5M;W5N="H@
M>6]U<B!C;V1E;6=R(&1I<F5C=&]R>2!A;F0@<F5M;W5N="!I="P@=&AU<PH)
M9F]L;&]W:6YG('1H92!N97<@<WEM;&EN:R!V86QU92!O;B!D=6YK+B @06QT
M97)N871I=F5L>2P@>6]U(&-A;@H)<F5B;V]T('1H92!H;W-T('1H870@;6]U
M;G1S(&-O9&5M9W(@9G)O;2!D=6YK+@H*"0E5;G1I;"!Y;W4@<F5M;W5N="!O
M<B!R96)O;W0L('EO=2!W:6QL(&-O;G1I;G5E('1O(")S964B"@ET:&4@<')E
M=FEO=7,@<F5L96%S92X@(%1H92!P<F5V:6]U<R!R96QE87-E('=I;&P@8F4@
M*G)E;F%M960J('1O"@EB:6XN;VQD(&EN(&]N92!W;W)K:6YG(&1A>2!T;R!M
M86ME(&ET(&]B<V]L971E(&%N9"!T;R!E;F9O<F-E"@ET:&4@=7!G<F%D92$*
M"@D)1FEN86QL>2P@=&AE($]33F5T(&1I<W1R:6)U=&EO;B!O9B!T96%M=V%R
M92!I<R!N;W0@8F5I;F<*"61I<W1R:6)U=&5D(&EN('!A8VMA9V4@9F]R;6%T
M+B @268@>6]U(&%R92!U<VEN9R!T:&4@3U-.970@9&ES=')I8G5T:6]N"@E0
M;&5A<V4@9&ES<F5G87)D($IU;&5S)W,@8V]M;65N=',@86)O=70@<&MG861D
M)VEN9R!T:&ES(')E;&5A<V4N"@D]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]"@H*"@E*
M=6QE<R=S(&UE<W-A9V4@<V%I9"!T:&ES(&%B;W5T('1H92!N97<@9&5L:79E
M<GDZ"@H*"0D@(" @(" @5&5A;5=A<F4@,2XP+C(@0F5T82!296QE87-E($YO
M=&5S"B @(" @(" @(" @(" @(" @(" @(" @+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM"@I!(&YE=R!R96QE87-E(&]F(%-005)#=V]R:W,O
M5&5A;5=A<F4@:&%S(&)E96X@:6YS=&%L;&5D+B @5&AE(')E;&5A<V5S"F%R
M92!N86UE9"!V:6$@82!F:6QE(&EN('1H92!D:7-T<FEB=71I;VX@9&ER96-T
M;W)Y(&YA;65D(%)%3$5!4T4N("!4:&ES"G)E;&5A<V4@:7,@8V%L;&5D(#$N
M,"XR($)E=&$L(&%N9"!T:&ES(')E;&5A<V4@;F%M92!C86X@8F4@=7-E9"!I
M;@I"=6=4<F%Q('5N9&5R('1H92!C871E9V]R:65S(&-O9&5M9W(L('!M86ME
M+"!C:&5C:W!O:6YT+"!F:6QE;65R9V4@86YD"G9E<G1O;VPN"@I/<TYE="!D
M979E;&]P97)S(&EN(%-U;E-O9G0@86YD(%--0T,@<VAO=6QD(')E9F5R('1O
M('1H92!R96QE87-E"F%N;F]U;F-E;65N="!M97-S86=E('-E;G0@=&\@=&AE
M(&]S;F5T+7-D94!S='5F9F8@86QI87,N("!/3B!D979E;&]P97)S"G-H;W5L
M9"!G970@8FEN87)I97,@86YD($].('9A;'5E(&%D9&5D('5T:6QI=&EE<R!A
M;F0@9&]C=6UE;G1A=&EO;@IB87-E9"!O;B!T:&4@<&]I;G1E<G,@<')O=FED
M960@8GD@=&AE(&]S;F5T+7-D94!S='5F9F8@;65S<V%G97,N"@I!<R!M96YT
M:6]N960@:6X@=&AE('!R979I;W5S(')E;&5A<V4G<R!N;W1E<RP@=&AI<R!R
M96QE87-E(&ES(&YO="!Y970*879A:6QA8FQE(&]N(%-O;&%R:7,@,2!O<B!3
M;VQA<FES('@X-B @5&AI<R!R96QE87-E(&ES('-U<'!O<G1E9"!O;@I3;VQA
M<FES(#(N>"!34$%20RX*"DAI9VAL:6=H=',Z"@H)+2!F:6QE;65R9V4@9&ES
M<&QA>7,@<&5R+7-U8G-T<FEN9R!V:7-U86P@9&EF9G,*"2T@9FEL96UE<F=E
M('-U8G=I;F1O=W,@<W5P<&]R="!H;W)I>F]N=&%L('-C<F]L;&EN9PH)+2!F
M:6QE;65R9V4@8V]L;W(@<W5P<&]R= H)+2!F:6QE;65R9V4@06)O=71";W@@
M<W5P<&]R= H@(" @(" @("T@;W!T:6]N('1O(&)R:6YG;W9E<B]P=71B8VL@
M=&\@9&ES86)L92!B86-K=7!S"B @(" @(" @+2 B5&5D(%1U;F5R(BUI>F%T
M:6]N("AC;VQO<B!'54DG<RD*(" @(" @(" M(&YE=R!W;W)K<W!A8V4@<W5B
M8V]M;6%N9#H@)VYA;64G"@DM(#X@-C @8G5G(&9I>&5S"@DM(&DQ.&X@;&5V
M96P@-"!S=7!P;W)T"@DM(&9U;&P@:6YT97)O<&5R86)I;&ET>2!W:71H(#$N
M,"X*"@HQ+C N,B!"971A(&1E=&%I;',Z"@H)0G5G(&9I>" H,3$S,S@Q,RD@
M.B!%>'1R82!L:6YE<R!D:7-P;&%Y960@:6X@9FEL96UE<F=E("T@<F5P;W)T
M960*"2 @(" @(" @(" @(" @(" @(" @8GD@36%R:R!,:74*"4)U9R!F:7@@
M*#$Q,S,Y-3(I(#H@1FEL96UE<F=E('5S960@=W)O;F<@9F]N=" M(')E<&]R
M=&5D(&)Y($UA<FL@3&EU"@E"=6<@9FEX("@Q,3,W-S@U*2 Z($UA:V4@=')U
M;F-A=&5S(&QO;F<@;6%C<F\@<V5T=&EN9W,@=VAE;B!S970@9G)O;0H)(" @
M(" @(" @(" @(" @(" @("!T:&4@8V]M;6%N9"!L:6YE("T@<F5P;W)T960@
M8GD@2V5V:6X@4G5S:&9O<G1H"@E"=6<@9FEX("@Q,30P-S U*2 Z($)R:6YG
M;W9E<B!D:65S(&9R;VT@97)R86YT(%-)1T%,05)-("T@<F5P;W)T960@8GD*
M"2 @(" @(" @(" @(" @(" @(" @1&%V:60@0VAA<V4*"4)U9R!F:7@@*#$Q
M-#,U,30I(#H@1FEL96UE<F=E(&EN8V]R<F5C=&QY(')E<&]R=',@=&AA="!D
M:69F<R!A<F4*"0D@(" @(" @(" @("!R97-O;'9E9" M(')E<&]R=&5D(&)Y
M($%L86X@5V%L=V]R=&@*"4)U9R!F:7@@(" @(" @(" @(#H@0G)I;F=O=F5R
M(&QE879E<R!30T-3(&9I;&4@=VET:"!O<&5N(&)R86YC: H)0G5G(&9I>" @
M(" @(" @(" @.B!"<FEN9V]V97(@8V%N)W0@<')O8V5S<R B='=I<W1E9"!P
M86ER<R(*"4)U9R!F:7@@*#$Q-#(X,C4I(#H@9FEL96UE<F=E(&1I<W!L87ES
M(&-O<G)U<'1E9"!D:69F('-T<FEN9W,@+0H)(" @(" @(" @(" @(" @(" @
M("!R97!O<G1E9"!B>2!497)U:&EK;R!+=7)O<V%K80H)0G5G(&9I>" H,3$Q
M,3$Q."D@.B!.;W1I9FEC871I;VX@;65S<V%G97,@8V%U<V4@=F%C871I;VX@
M92=M86EL"@D@(" @(" @(" @(" @(" @(" @('1O(')E<&QY+B M(%)I8V@@
M36-!;&QI<W1E<@H)36%N>2!M;W)E+@H*"DIU;&5S($1A;6II"E1E86U787)E
,($=R;W5P"@H*"@H*
 
end
----------
X-Sun-Data-Type: sun-deskset-message
X-Sun-Data-Name: bug#1148167
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 73
X-Sun-Content-Length: 4352

begin 600 bug#1148167
M1G)O;2!F;VQE>4!H;VQI9&%Y(%=E9"!.;W8@(#,@,#DZ-#4@4%-4(#$Y.3,*
M4F5T=7)N+5!A=&@Z(#QF;VQE>4!H;VQI9&%Y/@I296-E:79E9#H@9G)O;2!H
M;VQI9&%Y+D5N9RY3=6XN0T]-(&)Y('!O;'ES;&\N16YG+E-U;BY#3TT@*#4N
M>"]334DM4U92-"D*"6ED($%!,3,R.3 [(%=E9"P@,R!.;W8@,3DY,R P.3HT
M-3HQ-2 K,#@P, I296-E:79E9#H@8GD@:&]L:61A>2Y%;F<N4W5N+D-/32 H
M-2XP+U--22U35E(T*0H):60@04$Q.#@T.3L@5V5D+" S($YO=B Y,R P.3HT
M-#HU-B!04U0*1&%T93H@5V5D+" S($YO=B Y,R P.3HT-#HU-B!04U0*1G)O
M;3H@9F]L97E :&]L:61A>2 H2FEL;"!&;VQE>2D*365S<V%G92U)9#H@/#DS
M,3$P,S$W-#0N04$Q.#@T.4!H;VQI9&%Y+D5N9RY3=6XN0T]-/@I3=6)J96-T
M.B Q,30X,38W.B!"=6<@<F5P;W)T(&-R96%T960N"E1O.B!J:6QL+F9O;&5Y
M0$5N9RP@8G5G9F]R=V%R9$!E;&UE<BP@;7-W0'!O;'ES;&\L(&=I;W)D86YO
M0&-A<V5R=&$L"B @(" @(" @<V%B:65R<T!H97)M;W-A"E!R96-E9&5N8V4Z
M(&IU;FL*0V]N=&5N="U4>7!E.B!T97AT"D-O;G1E;G0M3&5N9W1H.B R-3(T
M"E@M3&EN97,Z(#$R,0I3=&%T=7,Z(%)/"@H*"B!"=6<@260Z(#$Q-#@Q-C<*
M($-A=&5G;W)Y.B!L:6)R87)Y"B!3=6)C871E9V]R>3H@;&EB8PH@0G5G+U)F
M93H@8G5G"B!3>6YO<'-I<SH@9G-C86YF(&)R96%K<R!W:&5N(&ET(')E8V5I
M=F5S(&$@4TE'04Q230H@2V5Y=V]R9',Z( H@4V5V97)I='DZ(#(*(%!R:6]R
M:71Y.B S"B!297-P;VYS:6)L92!%;F=I;F5E<CH@"B!$97-C<FEP=&EO;CH@
M"F9S8V%N9B!B<F5A:W,@=VAE;B!I="!R96-E:79E<R!A(%-)1T%,4DTN("!)
M(&AA=F4@82!S;6%L;"!T97-T('!R;V=R86T@=VAI8V@*<F5P<F]D=6-E<R!T
M:&ES+B @22!K;F]W('1H92!T97-T('!R;V=R86T@;&]O:W,@<FED:6-U;&]U
M<R!S;R!))VQL(&5X<&QA:6X@:&]W"G1H:7,@86QL(&-A;64@86)O=70N"@I4
M:&5R92!I<R!P<F]C97-S(",Q('=H:6-H(&]P96YS(&$@<&EP92!F;W(@<F5A
M9&EN9R!W:71H('!R;V-E<W,@(S(N("!0<F]C97-S(",@,@IW<FET97,@=&\@
M=&AE('!I<&4@870@<F%N9&]M(&EN=&5R=F%L<RX@($UE86YW:&EL92P@979E
M<GD@-2!M:6YU=&5S+"!T:&4@;&EC96YS:6YG"FUE8VAA;FES;2 @:6X@<')O
M8V5S<R C,2!S96YD<R!A(%-)1T%,4DT@=&\@;&5T('1H92!L:6-E;G-I;F<@
M9&%E;6]N(&MN;W<@=&AA= IT:&4@<')O8V5S<R!I<R!S=&EL;"!A;&EV92X@
M($EF('1H92!324=!3%)-(&]C8W5R<R!W:&EL92!F<V-A;F8@:7,@=V%I=&EN
M9R!F;W(@:6YP=70L"G1H92!F<V-A;F8@9V5T<R!A;B!%3T8L("!P<F]C97-S
M(",Q(&-L;W-E<R!T:&4@<&EP92P@86YD('!R;V-E<W,@(S(@9V5T<R!A(&)R
M;VME;@IP:7!E('-I9VYA;"X@("!"96QI979E(&ET(&]R(&YO="P@=&AI<R!O
M8V-U<G,@<75I=&4@;V9T96XN"@I3;RP@:&5R92!I<R!T:&4@<F5P<F]D=6-I
M8FQE('1E<W0@<')O9W)A;2X*"B-I;F-L=61E(#QS=&1I;RYH/@HC:6YC;'5D
M92 \<VEG;F%L+F@^"B-I;F-L=61E(#QS=&1L:6(N:#X*(VEN8VQU9&4@/'-Y
M<V5N="YH/@H*=F]I9"!S:6=?:&%N9&QE<BAI;G0I.PH*;6%I;BAI;G0@87)G
M8RP@8VAA<B J*F%R9W8I"GL*(" @(" @("!&24Q%(" @(" @(" @(" @*G!F
M<#L*(" @(" @("!C:&%R(" @(" @(" @(" @8G5F6S$P,C1=.PH@(" @(" @
M(&EN=" @(" @(" @(" @("!I(#T@,#L*"B @(" @(" @<VEG<V5T*%-)1T%,
M4DTL('-I9U]H86YD;&5R*3L*(" @(" @("!A;&%R;2@U*3L*(" @(" @("!I
M9B H*'!F<" ]('!O<&5N*")T86EL("UF("]T;7 O9F]O(BP@(G(B*2D@/3T@
M3E5,3"D@>PH@(" @(" @(" @(" @(" @9G!R:6YT9BAS=&1E<G(L(")P;W!E
M;B!F86EL961<;B(I.PH@(" @(" @(" @(" @(" @97AI="@Q*3L*(" @(" @
M("!]"B @(" @(" @=VAI;&4@*&9S8V%N9BAP9G L("(E<R(L(&)U9BD@/3T@
M,2D@>PH@(" @(" @(" @(" @(" @:2LK.PH@(" @(" @('T*(" @(" @("!P
M8VQO<V4H<&9P*3L*(" @(" @("!E>&ET*# I.PI]"@IV;VED"G-I9U]H86YD
M;&5R*&EN="D*>PH@(" @(" @('!R:6YT9B@B<F5P<F]D=6-I;F<@;W,@8G5G
M7&XB*3L*(" @(" @("!P<FEN=&8H(G)E<')O9'5C:6YG(&]S(&)U9R!A9V%I
M;EQN(BD["B @(" @(" @9F9L=7-H*'-T9&]U="D["GT*"B!7;W)K(&%R;W5N
M9#H@"@H@4W5G9V5S=&5D(&9I>#H@"@H@2G5S=&EF:6-A=&EO;CH@"@H@4W1A
M=&4@=')I9V=E<G,Z( H)06-C97!T960Z(&YO"@E%=F%L=6%T:6]N.B *"@E#
M;VUM:70@=&\@9FEX(&EN(')E;&5A<V5S.B *"49I>&5D(&EN(')E;&5A<V5S
M.B *"4EN=&5G<F%T960@:6X@<F5L96%S97,Z( H)5F5R:69I960@:6X@<F5L
M96%S97,Z( H@0V]M;65N=',Z( H*26YT<F]D=6-E9"!I;B!R96QE87-E.B *
M(%)O;W0@8V%U<V4Z( H@1&5V96QO<&UE;G0@4W1A='5S.B *($9I>"!A9F9E
M8W1S(&1O8W5M96YT871I;VXZ( H@26YT97)E<W0@;&ES=#H@;7-W+" @9VEO
M<F1A;F\L("!S86)I97)S"B!0871C:"!I9#H@"B!3964@86QS;SH@"@H@0V%L
M;&5D(&EN(&)Y.B *(" @($-U<W1O;65R.@H)0V]M<&%N>3H@4W5N4')O"@E%
M;7!L;WEE93H@"@E296QE87-E.B!S,3 Y,PH)2&%R9'=A<F4@=F5R<VEO;CH@
M<W5N-&-?-S4*"4\O4R!V97)S:6]N.B!S-#DT7V1E=C8*"55S97(@5'EP93H@
M"@E33R!.=6UB97(Z( H)4W5N($-O;G1A8W0Z(&9O;&5Y"@H@0V%L;&5D(&EN
M(&)Y.B *(" @($-U<W1O;65R.@H)0V]M<&%N>3H@4W5N4')O"@E%;7!L;WEE
M93H@"@E296QE87-E.B!S-#DS"@E(87)D=V%R92!V97)S:6]N.B!S=6XT8U\W
M-0H)3R]3('9E<G-I;VXZ(',T.31?9&5V-@H)57-E<B!4>7!E.B *"5-/($YU
M;6)E<CH@"@E3=6X@0V]N=&%C=#H@9F]L97D*"B!#86QL960@:6X@8GDZ( H@
M(" @0W5S=&]M97(Z"@E#;VUP86YY.B!3=6Y0<F\*"45M<&QO>65E.B *"5)E
M;&5A<V4Z(',T.31?9&5V-@H)2&%R9'=A<F4@=F5R<VEO;CH@<W5N-&-?-S4*
M"4\O4R!V97)S:6]N.B!S-#DT7V1E=C8*"55S97(@5'EP93H@"@E33R!.=6UB
M97(Z( H)4W5N($-O;G1A8W0Z(&9O;&5Y"B!0=6)L:6,@4W5M;6%R>3H@"@H@
?2&]O:R Q.B *($AO;VL@,CH@"B!"=6<@16YD.@H*"F,@
 
end

From shannon@datsun  Sun Nov  7 23:55:20 1993
Return-Path: <shannon@datsun>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00423; Sun, 7 Nov 93 23:55:20 PST
Received: from datsun.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA09195; Mon, 8 Nov 93 00:00:19 PST
Received: by datsun.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA23720; Sun, 7 Nov 1993 23:56:59 +0800
Date: Sun, 7 Nov 1993 23:56:59 +0800
From: shannon@datsun (Bill Shannon)
Message-Id: <9311080756.AA23720@datsun.Eng.Sun.COM>
To: on-eng@dunk, osnet-sde@stufff
Subject: updated C Style document
Content-Length: 1927
X-Lines: 48
Status: RO

A major geological event has occurred!  I've updated the C Style document!

Yes, I know it seems like dinosaurs roamed the earth the last time
the C Style document was updated, but recent events provided the
needed motivation for me to make significant updates to the document.
I believe the document now more accurately describes our C coding
style standard.  I haven't (consciously) changed our coding style
with this update, but rather have attempted to more completely
describe what many of us already "know".

Remember that this document describes *much* more than the picky
details of syntax that the cstyle program checks for.  It attempts
to give general advice and specific recommendations on many issues
of style that are far beyond what the cstyle program will ever be
capable of checking for.  (I'm also sure that the document still
doesn't describe *all* the picky details of syntax that the cstyle
program does check for, so if you notice things that are missing from
the document, let me know.)

Over the next few weeks I would be very interested in your comments
on the document.  I will likely release an updated version based on
your comments later this year.

The new version of the document is in /shared/ON/general_docs as
cstyle.ms and cstyle.ms.ps.  (The cstyle.mm document is now obsolete.)



Also, let me remind you of the rules associated with this standard:

Rule 0:	All modifications to existing code should be done in the same
	style as the existing code, even if that style is different
	than the one described by this document.

Rule 1:	All completely new code should follow the style described in
	this document.

Rule 2:	All code that currently passes the cstyle program must continue
	to pass the cstyle program.

These rules are relatively simple so that you'll remember them, but if
you get in a situation where you aren't sure how to apply the rules,
please ask for help.


Thanks!

	Bill

From msw@polyslo  Thu Nov 18 17:01:52 1993
Date: Thu, 18 Nov 1993 17:03:23 +0800
From: msw@polyslo (Michael Walker)
To: osnet-sde@stufff
Subject: Patchfix & Update for Teamware on dunk:
Content-Length: 1126
X-Lines: 35
Status: RO



** If you mount your teamware binaries from DUNK no action is required **

If you have a copy of the teamware distribution from dunk you will want
to copy the following files into your distribution:

	dunk:/opt/teamware/ParallelMake
	dunk:/opt/teamware/ParallelMake/bin
	dunk:/opt/teamware/ParallelMake/bin/make
	dunk:/opt/teamware/ParallelMake/lib
	dunk:/opt/teamware/ParallelMake/lib/License_File
	dunk:/opt/teamware/ParallelMake/lib/usage_mail_addr
	dunk:/opt/teamware/ParallelMake/man
	dunk:/opt/teamware/ParallelMake/man/man1
	dunk:/opt/teamware/ParallelMake/man/man1/make.1

			and
	
	dunk:/opt/teamware/OSNet/bin/cstyle


**Note: These updates only effect the Sparc Solaris2.x distribution.


These updates are to fix the following problem in teamware:


1) Because of problems that the OSNet source base was experiencing
   with the latest version of PMAKE(1.0.2beta) we have reverted
   back to 1.0FCS for pmake.  We've discussed our problems with the
   pmake engineer and he is looking into a solution.  Hopefully
   we will be able to upgrade in the not too distant future.

2) Update to cstyle from shannon@eng

From tadd@jurassic  Wed Dec 15 11:08:09 1993
Return-Path: <tadd@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA20519; Wed, 15 Dec 1993 11:08:09 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA07209; Wed, 15 Dec 1993 11:11:38 -0800
Received: from widor.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA24213; Wed, 15 Dec 1993 11:09:02 +0800
Received: by widor.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA00676; Wed, 15 Dec 1993 11:08:48 -0800
Date: Wed, 15 Dec 1993 11:08:48 -0800
From: tadd@jurassic (Tadd Ottman)
Message-Id: <9312151908.AA00676@widor.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: codemgr update #30 - teamware distribution changed
Precedence: junk
Content-Length: 1961
X-Lines: 44
Status: RO



OS-Net teamware users,

	Please modify your vfstab or automount maps to take advantage
of this new structure.

	The distribution of OS-Net development tools from dunk.eng has
been restructured.  Tools such as teamware, gatekeeper utilities, and
construction sets are primarily available through NFS and secondarily
through packages.  SPARC and X86 are handled side-by-side and nearly
identically.

	X86 users will no longer have to install teamware locally and
modify it with a script to install OS-Net customizations.  Instead,
x86 users may mount a customized teamware directory via NFS from dunk.

	Dunk will NFS-share reference tools in runnable format from
dunk.eng:/sdet/export/$MACH, where MACH is "sparc" or "i386" from uname -p.
For your convenience and my illustration, here are suggested vfstab lines:

On x86, you could put these lines in your vfstab:
 dunk.eng:/sdet/export/i386/opt/SUNWspro - /opt/SUNWspro nfs - yes ro,bg
 dunk.eng:/sdet/export/i386/opt/onbld    - /opt/onbld    nfs - yes ro,bg

On sparc, you could put these lines in your vfstab:
 dunk.eng:/sdet/export/sparc/opt/teamware - /opt/teamware nfs - yes ro,bg
 dunk.eng:/sdet/export/sparc/opt/onbld    - /opt/onbld    nfs - yes ro,bg

	Doing specific NFS mounts in this way keeps the tools in /opt but
permits you to install other items into /opt on your local disk.

	/opt/teamware for sparc continues to be Teamware only, without
compilers, while /opt/SUNWspro for x86 continues its traditional combination
of teamware and compilers.

	The old "dunk:/opt/teamware" mount will continue to export an
alternative path to the sparc teamware directory but not forever.

	Installing tools locally with pkgadd is optional and unnecessary.
If you wish to do so anyway, you will find packages for your architecture
in dunk.eng:/sdet/pkgs/$MACH.  The groupings below MACH are by function:
onbld, ongk, ld_patch, and make_patch.  (symlinks for the old name space
will go away someday soon.)

From tadd@jurassic  Wed Dec 15 11:09:36 1993
Date: Wed, 15 Dec 1993 11:10:28 -0800
From: tadd@jurassic (Tadd Ottman)
To: osnet-sde@stufff
Subject: codemgr update #31 - teamware customizations expanded
Content-Length: 2648
X-Lines: 83
Status: RO



OS-Net teamware users,

	Software development tools for OS-Net have been updated.

	Our customizations to teamware have been expanded and made more
consistent between x86 and sparc.  Both architectures contain an Rtitool
directory, the mk_bld_space script, the Install script, bfu (and the
fastfs it needs), the codereview utility, and a new script called newdeltas.

Here are brief descriptions of the Teamware customizations.  For more
information, you can find man pages for few of these items and you can
read the scripts for their internal documentation.  Previous announcements
of customizations are archived in the avo_updates mail folder in the
teamware/doc directory.

These are new on both sparc and x86:

newdeltas
	A script for listing source files modified in a workspace since a
	given date and the contents of the corresponding diffs.  This is
	convenient for generating the data a peer reviewer would study.

mk_bld_space
	a script providing an instruction-set-specific snapshot of source
	without SCCS history files, to do sparc and i386 builds with less
	wasted disk space.


These are new on x86:

rtitool
	A GUI for submitting Requests To Integrate implementations of
	bug fixes and requested enhancements.  This has a man page.

Install
	Jeff Bonwick's creative script for installing a kernel and kernel
	modules onto a target system directly from the binaries built in
	a workspace.  A "proto" area is not necessary, just "make all"
	in usr/src/uts.

bfu
	Bonwick, Faulkner Upgrade, utilizing fastfs to write a cpio archive
	image of the OS on top of a live target system.  The archives are
	the same as those created by "nightly" and submitted to PIT by
	gatekeepers.

codereview
	A utility for creating custom listings of source code for submitting
	to a PostScript printer, yielding a nice format for code reviews.


These are older customizations:

cstyle
	A perl script for checking many attributes of our C coding style.

hdrchk
	A perl script for checking header files for header guards and other
	required features.

perl
	Included to run perl scripts.

sccscp
	Script to facilitate copying SCCS files to fork work, with history.

sccsmv
	Script to facilitate moving SCCS files around and renaming them.

sccsrm
	Script to remove SCCS files in a Teamware-supported, official way.

ws
	Script to "activate" a workspace, giving a shell in which to do
	builds that reference libraries and header files in the workspace
	and in its parent workspace.

def.dir.flp
	Modified version of Teamware's file-list program, a script that
	finds and lists the names of files for Teamware operations such
	as bringover and putback.

From msw@polyslo  Tue Jan 11 09:40:05 1994
Return-Path: <msw@polyslo>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA21851; Tue, 11 Jan 1994 09:40:05 +0800
Received: from polyslo.Eng.Sun.COM by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA20798; Tue, 11 Jan 1994 09:44:07 -0800
Received: by polyslo.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01886; Tue, 11 Jan 1994 09:39:21 +0800
Date: Tue, 11 Jan 1994 09:39:21 +0800
From: msw@polyslo (Michael Walker)
Message-Id: <9401111739.AA01886@polyslo.Eng.Sun.COM>
To: osnet-sde@stufff, teamware-users@kepler
Subject: New Teamware release - 1.0.2 PreFcs (on dunk)
Precedence: junk
X-Sun-Charset: US-ASCII
Content-Length: 3411
X-Lines: 95
Status: O



In response to Jules's message on the availability of updated
Teamware binaries, I updated our OS-group reference copy of the binaries
on host dunk.  Our copy includes OS-group customizations.

  for 5.x codemgr, see    dunk:/sdet/export/sparc/opt/teamware


	================================================================
Important:
		If you mount codemgr from dunk, to "see" the new release
	you need to *umount* your codemgr directory and remount it, thus
	following the new symlink value on dunk.  Alternatively, you can
	reboot the host that mounts codemgr from dunk.

		Until you remount or reboot, you will continue to "see"
	the previous release.  The previous release will be *renamed* to
	bin.old in one working day to make it obsolete and to enforce
	the upgrade!

		Finally, the OSNet distribution of teamware is not being
	distributed in package format.  If you are using the OSNet distribution
	Please disregard Jules's comments about pkgadd'ing this release.
	================================================================



	Jules's message said this about the new delivery:


		       TeamWare 1.0.2 preFCS Release Notes
                       -----------------------------------

A new release of SPARCworks/TeamWare has been installed.  The releases
are named via a file in the distribution directory named Release.  This
release is called 1.0.2 preFCS, and this release name can be used in
BugTraq under the categories codemgr, pmake, checkpoint, filemerge and
vertool.

OsNet developers in SunSoft and SMCC should refer to the release
announcement message sent to the osnet-sde@stufff alias.  ON developers
should get binaries and ON value added utilities and documentation
based on the pointers provided by the osnet-sde@stufff messages.

As mentioned in the previous release's notes, this release is not yet
available on Solaris 1 or Solaris x86  This release is supported on
Solaris 2.x SPARC.

Highlights:

	- filemerge displays per-substring visual diffs
	- filemerge subwindows support horizontal scrolling
	- filemerge color support
	- filemerge AboutBox support
        - option to bringover/putbck to disable backups
        - "Ted Tuner"-ization (color GUI's)
        - new workspace subcommand: 'name'
	- > 60 bug fixes
	- i18n level 4 support
	- full interoperability with 1.0.
	- Full i18n support.

1.0.2 PreFCS details:

	Bug fix (1133813) : Extra lines displayed in filemerge - reported
	                    by Mark Liu
	Bug fix (1133952) : Filemerge used wrong font - reported by Mark Liu
	Bug fix (1137785) : Make truncates long macro settings when set from
	                    the command line - reported by Kevin Rushforth
	Bug fix (1140705) : Bringover dies from errant SIGALARM - reported by
	                    David Chase
	Bug fix (1143514) : Filemerge incorrectly reports that diffs are
		            resolved - reported by Alan Walworth
	Bug fix           : Bringover leaves SCCS file with open branch
	Bug fix           : Bringover can't process "twisted pairs"
	Bug fix (1142825) : filemerge displays corrupted diff strings -
	                    reported by Teruhiko Kurosaka
	Bug fix (1111118) : Notification messages cause vacation e'mail
	                    to reply. - Rich McAllister
	Many more.
	Licensing SIGALARM disabled.

Licensing:

The mountables licensing file points to 
/usr/dist/local/config/sparcworks/license.dat

Jules Damji.







From zombolas@jurassic Mon Jan 24 13:36 PST 1994
Date: Mon, 24 Jan 1994 13:30:43 +0800
From: zombolas@jurassic (Gene Paul Zombolas [CONTRACTOR])
To: on-eng@benet
Subject: New version of rtiroute software
Content-Length: 1514
Content-Type: text
Status: RO
X-Lines: 46

I have installed a new version of the rtiroute software on wizard.  Below is
a list of enhancements and bug fixes that have been added to this version.
The admin enhancements do not effect the user's functionality but are included
here for completeness.  Please let me know if you experience any problems
(especially if you loose a RTI submission since I was unable to verify this
bug fix).

Thanks.

-Gene Zombolas
zombolas@ogden

Enhancements (User):
====================

   *	Send an acknowledgement upon the successful submission of a new
	RTI.

   *	Submission now accepted from all Sun mail domains without the
	submitter having to be known in the Engineering domain.

   *	Evaluators will be notified every day via e-mail of expired RTI's.

   *	Evaluators can accept an RTI when they have turned themselves off
	in the evaluators list.

Enhancements (Admin):
=====================

   *	New utility to archive accepted RTI's by release.  The "query"
	action knows to search archive directories.

   *	Archive the "all-mail" mail archive on a weekly basis and throw
	away old archives after four weeks.

Bug Fixes:
==========

   *	Errors reported to the originator via e-mail.  This was in the
	original design with the idea that errors would be returned by
	sendmail.  This was lost when incoming messages were switched
	to being queued for later processing and sendmail no longer saw
	the errors.

   *	Hopefully fixed intermittently lost RTI's.  This fix was actually
	installed a couple of weeks ago.

From tadd@jurassic  Mon Jan 31 17:03:04 1994
Return-Path: <tadd@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00794; Mon, 31 Jan 1994 17:03:04 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA08571; Mon, 31 Jan 1994 17:07:23 -0800
Received: from widor.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA26844; Mon, 31 Jan 1994 17:04:09 +0800
Received: by widor.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01275; Mon, 31 Jan 1994 17:04:06 -0800
Date: Mon, 31 Jan 1994 17:04:06 -0800
From: tadd@jurassic (Tadd Ottman)
Message-Id: <9402010104.AA01275@widor.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: updated linker with KEEP_STATE
Content-Length: 484
X-Lines: 14
Status: O



	A new version of the SPARC SUNWonld package is available
from dunk.eng in /sdet/pkgs/sparc/ld_patch.  It is version  2.4.1
and contains a version of the linker with KEEP_STATE but without
a run-path that had caused problems in rare circumstances.

	As before, the KEEP_STATE functionality is not required,
but it does make your incremental builds more accurate, since
target dependencies on libraries are recorded in .make.state files.

					Tadd

p.s. This does not apply to x86.

From janet@firenze  Fri Feb  4 12:15:20 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA23625; Fri, 4 Feb 1994 12:15:20 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA13401; Fri, 4 Feb 1994 12:19:42 -0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA15017; Fri, 4 Feb 1994 12:18:02 +0800
Date: Fri, 4 Feb 1994 12:18:02 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9402042018.AA15017@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Updates on dunk
Cc: janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 629
X-Lines: 15
Status: O


** If you mount your teamware binaries from DUNK no action is required **

If you have a copy of the teamware distribution from dunk you will want
to copy the following files into your distribution:

    dunk:/opt/teamware/OSNet/bin/cstyle  (contains bug fixes from shannon)

While you're at it, you may also want to copy the following files, which
Mike Walker will cover in a separate email:

   dunk:/sdet/export/i386/opt/SUNWspro/bin/cscope-fast
   dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/cscope-fast
   dunk:/sdet/export/sparc/opt/teamware/bin/cscope-fast
   dunk:/sdet/export/sparc/opt/teamware/OSNet/bin/cscope-fast

From msw@polyslo Tue Feb  8 09:07 PST 1994
Date: Tue, 8 Feb 1994 09:07:01 -0800
From: msw@polyslo (Michael Walker)
To: on-eng@benet
Subject: cscope-fast tables now in /ws/train!!!
Cc: os-int@plunge
Content-Length: 686
Content-Type: text
X-Lines: 29
Status: RO


All,

Thanx to Brent we now have tables for the new cscope-fast utility built
for /ws/train.  If you use cscope you'll love these - they are 'lickity
split' fast!!!

If you mount teamware from dunk you will find a new cscope-fast
binary at:
		/opt/teamware/bin/cscope-fast

We now have cscope-fast tables built in the following directories in
/ws/train

		/ws/train/usr/src/csope.out.new
		/ws/train/usr/src/uts/cscope.out.new
		/ws/train/usr/src/uts/sun4*/cscope.out.new
		/ws/train/usr/src/uts/i86pc/cscope.out.new

To invoke cscope-fast on these new tables you can do the following:

		% cd /ws/train/usr/src
		% /opt/teamware/bin/cscope-fast -d -f cscope.out.new


Enjoy!

_Mike_


From janet@firenze  Fri Feb 18 17:51:58 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA08564; Fri, 18 Feb 1994 17:51:58 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA02835; Fri, 18 Feb 1994 17:56:32 -0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA10018; Fri, 18 Feb 1994 17:54:36 +0800
Date: Fri, 18 Feb 1994 17:54:36 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9402190154.AA10018@firenze.Eng.Sun.COM>
To: osnet-sde@stufff, janet@firenze
Subject: Re: Update on dunk
Cc: janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 457
X-Lines: 18
Status: O



----- Begin Included Message -----

From janet Fri Feb  4 12:18 PST 1994
From: janet (Janet Timbol)
To: osnet-sde@stufff
Subject: Updates on dunk
Cc: janet@firenze
X-Sun-Charset: US-ASCII


** If you mount your teamware binaries from DUNK no action is required **

If you have a copy of the i386 teamware distribution from dunk,
you will want to copy the following files into your distribution:

   dunk:/sdet/export/i386/opt/SUNWspro/Rtitool/bin/rtitool

From janet@firenze  Tue Mar  8 18:31:18 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11540; Tue, 8 Mar 1994 18:31:18 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA10224; Tue, 8 Mar 1994 18:31:20 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00425; Tue, 8 Mar 1994 18:33:25 +0800
Date: Tue, 8 Mar 1994 18:33:25 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9403090233.AA00425@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New rtitool release - 2.0 (on dunk)
Cc: janet@firenze, on494-mgrs@benet, zombolas@jurassic
Content-Length: 3484
X-Lines: 93
Status: O

The rtitool binaries have been updated on dunk to reflect a
new version of rtitool, rtitool 2.0.

The updated rtitool provides: 

	* new user interface 
	* new query support
	* new evaluator template for CRT members
	* support for changes in the CRT process

See the Revision Notes section below for additional details.

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update it as follows:

for sparc rtitool, get:

	dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, get:

	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

        ================================================================
Important:
        Note that until you reinvoke rtitool, you will continue to
        "use" the previous version, rtitool 1.2.  The previous version 
	will be *removed* to another partition in two working days 
	to make it obsolete and to enforce the upgrade!
        ================================================================

Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via:
 
        The Help/Send feedback... menu button, which puts you in
        a window (a mailtool compose window) which will automatically
        send your feedback to rtitool_2.x-comments@plunge.eng.
 
Rtitool 2.0 Release Notes:

	New features:

	1) Added support for CRT Advocate in the implementor
	   template; removed support for Sponsor.
	2) Added query support to query both the rtiroute 
	   database of implementor RTIs and bugtraq.
	3) Added support for multiple ARC opinion numbers.
	4) Added an evaluator template for use by CRT members.
	5) Reimplemented utility to improve supportability.
	6) Reworked "look and feel" of GUI to improve 
	   extensibility in case we choose to add patch RTI
	   or gatekeeper RTI support in the future.

	Bug fixes/RFE's:

	1)  CRT advocate expertise string now displayed in popup menu
	    exactly as it appears in the file.
	2)  CRT advocate menu button now activated/inactivated to match
	    advocate type-in.
	3)  CRT advocate menu is now pinable.
	4)  Changed the "Request Submitted" alert to a message in the
	    frame footer.
	5)  Removed on1093 as a target release.  Added on495.
	6)  Reset in Implementor template now clears CRT advocate field.
	7)  Help windows no longers appears at the top, left-hand corner
	    of the screen each time it is selected.
	8)  Fixed subframe titles and buttons/menu items which invoked
	    popup windows but was missing "...".
	9)  Fixed bug where evaluator panel was sometimes not correctly
	    resizing after switching between templates.
	10) Advocate menu now sorted by last names.
	11) Increased the stored length from 50 to 256 on the Feedback
	    window type-ins.
	12) Added Cc: line to Feedback window.
	13) Fixed seg fault if config file is not found.
	14) Use unique temp file names.
	15) Query facility reworked:
		i)	Removed "Get Selection" button
		ii)	Fix file descriptor and window leaks.
		iii)	List now sorted.
		iv)	More informative error notices.
	16) Double click in evaluator RTI list now uses query window.
	17) Query & evaluator RTI list inactivated when no RTI databases
	    are defined in the config file.
	18) Submit button changed to Send.
	19) ARC approval date removed.
	20) Changed Explain to Comments in evaluator template.
	21) New set of integration phases.
	22) Fix send and query bugs introduced in beta4.



From jrt@gap  Wed Mar  9 10:44:56 1994
Return-Path: <jrt@gap>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA12266; Wed, 9 Mar 1994 10:44:56 +0800
Received: from gap.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA10436; Wed, 9 Mar 1994 10:45:05 +0800
Received: by gap.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA14288; Wed, 9 Mar 1994 10:45:31 -0800
Date: Wed, 9 Mar 1994 10:45:31 -0800
From: jrt@gap (Joel Tornatore)
Message-Id: <9403091845.AA14288@gap.Eng.Sun.COM>
To: osnet-sde@stufff, janet@firenze
Subject: Re: New rtitool release - 2.0 (on dunk)
Cc: on494-mgrs@benet, zombolas@jurassic
X-Sun-Charset: US-ASCII
Content-Length: 4533
X-Lines: 123
Status: O

This version of rtitool needs to be run with the full path.
It looks like it is using something like dirname(argv[0])
to find the directory in which it lives, and then looks in
../lib relative to that directory to find the config file.

The fix is to execute it with the full path name, namely
	/opt/teamware/bin/rtitool


% which rtitool
/opt/teamware/bin/rtitool
% rtitool
rtitool: Unable to open configuration file: rtitool.config.
% truss -t access rtitool
access("/usr/openwin/lib/X11/Xcms.txt", 4)      = 0
access("rtitool/../lib/rtitool.config", 4)      Err#2 ENOENT
rtitool: Unable to open configuration file: rtitool.config.
% /opt/teamware/bin/rtitool
(runs fine)

joel



> From janet@firenze Tue Mar  8 18:34 PST 1994
> To: osnet-sde@stufff
> Subject: New rtitool release - 2.0 (on dunk)
> Cc: janet@firenze, on494-mgrs@benet, zombolas@jurassic
> 
> The rtitool binaries have been updated on dunk to reflect a
> new version of rtitool, rtitool 2.0.
> 
> The updated rtitool provides: 
> 
> 	* new user interface 
> 	* new query support
> 	* new evaluator template for CRT members
> 	* support for changes in the CRT process
> 
> See the Revision Notes section below for additional details.
> 
> Rtitool is available automatically if you mount your teamware
> binaries from dunk.  If you maintain a private copy of the
> ON teamware distribution, then you will need to create or
> update it as follows:
> 
> for sparc rtitool, get:
> 
> 	dunk:/sdet/export/sparc/opt/teamware/Rtitool
> 
> for x86   rtitool, get:
> 
> 	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool
> 
>         ================================================================
> Important:
>         Note that until you reinvoke rtitool, you will continue to
>         "use" the previous version, rtitool 1.2.  The previous version 
> 	will be *removed* to another partition in two working days 
> 	to make it obsolete and to enforce the upgrade!
>         ================================================================
> 
> Feedback, comments, suggestions, bugs, rfe's for rtitool can
> be filed via:
>  
>         The Help/Send feedback... menu button, which puts you in
>         a window (a mailtool compose window) which will automatically
>         send your feedback to rtitool_2.x-comments@plunge.eng.
>  
> Rtitool 2.0 Release Notes:
> 
> 	New features:
> 
> 	1) Added support for CRT Advocate in the implementor
> 	   template; removed support for Sponsor.
> 	2) Added query support to query both the rtiroute 
> 	   database of implementor RTIs and bugtraq.
> 	3) Added support for multiple ARC opinion numbers.
> 	4) Added an evaluator template for use by CRT members.
> 	5) Reimplemented utility to improve supportability.
> 	6) Reworked "look and feel" of GUI to improve 
> 	   extensibility in case we choose to add patch RTI
> 	   or gatekeeper RTI support in the future.
> 
> 	Bug fixes/RFE's:
> 
> 	1)  CRT advocate expertise string now displayed in popup menu
> 	    exactly as it appears in the file.
> 	2)  CRT advocate menu button now activated/inactivated to match
> 	    advocate type-in.
> 	3)  CRT advocate menu is now pinable.
> 	4)  Changed the "Request Submitted" alert to a message in the
> 	    frame footer.
> 	5)  Removed on1093 as a target release.  Added on495.
> 	6)  Reset in Implementor template now clears CRT advocate field.
> 	7)  Help windows no longers appears at the top, left-hand corner
> 	    of the screen each time it is selected.
> 	8)  Fixed subframe titles and buttons/menu items which invoked
> 	    popup windows but was missing "...".
> 	9)  Fixed bug where evaluator panel was sometimes not correctly
> 	    resizing after switching between templates.
> 	10) Advocate menu now sorted by last names.
> 	11) Increased the stored length from 50 to 256 on the Feedback
> 	    window type-ins.
> 	12) Added Cc: line to Feedback window.
> 	13) Fixed seg fault if config file is not found.
> 	14) Use unique temp file names.
> 	15) Query facility reworked:
> 		i)	Removed "Get Selection" button
> 		ii)	Fix file descriptor and window leaks.
> 		iii)	List now sorted.
> 		iv)	More informative error notices.
> 	16) Double click in evaluator RTI list now uses query window.
> 	17) Query & evaluator RTI list inactivated when no RTI databases
> 	    are defined in the config file.
> 	18) Submit button changed to Send.
> 	19) ARC approval date removed.
> 	20) Changed Explain to Comments in evaluator template.
> 	21) New set of integration phases.
> 	22) Fix send and query bugs introduced in beta4.
> 
> 
> 

From zombolas@jurassic  Wed Mar  9 11:24:40 1994
Return-Path: <zombolas@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA12288; Wed, 9 Mar 1994 11:24:40 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA10451; Wed, 9 Mar 1994 11:25:04 +0800
Received: from ogden.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA05759; Wed, 9 Mar 1994 11:24:52 -0800
Received: by ogden.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA03814; Wed, 9 Mar 1994 11:25:50 +0800
Date: Wed, 9 Mar 1994 11:25:50 +0800
From: zombolas@jurassic (Gene Paul Zombolas [CONTRACTOR])
Message-Id: <9403091925.AA03814@ogden.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: rtitool 2.0 start up problem
X-Sun-Charset: US-ASCII
Content-Length: 550
X-Lines: 13
Status: O

You need to start rtitool 2.0 with a full or relative path for it to find
it's config, help, and advocate DB files.  I apologize that such a simple
bug was not discovered until now.  I plan to fix this today and push another
version tonight.

The following list of known problems was left off the announcement message:

       1)  RTI logging does not work so you may want to make
           sure that your name appears under 'Mail Cc:'
       2)  Under CDE, pop up frames unexpectedly disappear.
       3)  The "Help" key is not implemented.

-Gene

From janet@firenze  Wed Mar  9 20:16:41 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13377; Wed, 9 Mar 1994 20:16:41 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA10943; Wed, 9 Mar 1994 20:16:49 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA02551; Wed, 9 Mar 1994 20:18:55 +0800
Date: Wed, 9 Mar 1994 20:18:55 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9403100418.AA02551@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: New rtitool release - 2.0 (on dunk)
Cc: janet@firenze, on494-mgrs@benet, zombolas@jurassic
X-Sun-Charset: US-ASCII
Content-Length: 4359
X-Lines: 128
Status: O

Folks,

We have updated yesterday's release of Rtitool 2.0 with the following
fixes:

  1)  Rtitool should find it's lib directory when invoked as "rtitool".

  2)  Config file will direct mail to benet instead of wizard.

  3)  There will be no attempt to query "Intel" bugtraq server 
      (fixes bug were all queries of Bug id starting with 3 failed).

If you are maintaining a private copy of the ON teamware distribution,
please update your Rtitool as detailed in yesterday's mail, copy 
attached.

A new version of cstyle is also available; please copy it from:

   dunk:/opt/teamware/OSNet/bin/cstyle

Thanks,
janet

----- Begin Included Message -----

From janet Tue Mar  8 18:33 PST 1994
From: janet (Janet Timbol)
To: osnet-sde@stufff
Subject: New rtitool release - 2.0 (on dunk)
Cc: janet, on494-mgrs@benet, zombolas@jurassic

The rtitool binaries have been updated on dunk to reflect a
new version of rtitool, rtitool 2.0.

The updated rtitool provides: 

	* new user interface 
	* new query support
	* new evaluator template for CRT members
	* support for changes in the CRT process

See the Revision Notes section below for additional details.

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update it as follows:

for sparc rtitool, get:

	dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, get:

	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

        ================================================================
Important:
        Note that until you reinvoke rtitool, you will continue to
        "use" the previous version, rtitool 1.2.  The previous version 
	will be *removed* to another partition in two working days 
	to make it obsolete and to enforce the upgrade!
        ================================================================

Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via:
 
        The Help/Send feedback... menu button, which puts you in
        a window (a mailtool compose window) which will automatically
        send your feedback to rtitool_2.x-comments@plunge.eng.
 
Rtitool 2.0 Release Notes:

	New features:

	1) Added support for CRT Advocate in the implementor
	   template; removed support for Sponsor.
	2) Added query support to query both the rtiroute 
	   database of implementor RTIs and bugtraq.
	3) Added support for multiple ARC opinion numbers.
	4) Added an evaluator template for use by CRT members.
	5) Reimplemented utility to improve supportability.
	6) Reworked "look and feel" of GUI to improve 
	   extensibility in case we choose to add patch RTI
	   or gatekeeper RTI support in the future.

	Bug fixes/RFE's:

	1)  CRT advocate expertise string now displayed in popup menu
	    exactly as it appears in the file.
	2)  CRT advocate menu button now activated/inactivated to match
	    advocate type-in.
	3)  CRT advocate menu is now pinable.
	4)  Changed the "Request Submitted" alert to a message in the
	    frame footer.
	5)  Removed on1093 as a target release.  Added on495.
	6)  Reset in Implementor template now clears CRT advocate field.
	7)  Help windows no longers appears at the top, left-hand corner
	    of the screen each time it is selected.
	8)  Fixed subframe titles and buttons/menu items which invoked
	    popup windows but was missing "...".
	9)  Fixed bug where evaluator panel was sometimes not correctly
	    resizing after switching between templates.
	10) Advocate menu now sorted by last names.
	11) Increased the stored length from 50 to 256 on the Feedback
	    window type-ins.
	12) Added Cc: line to Feedback window.
	13) Fixed seg fault if config file is not found.
	14) Use unique temp file names.
	15) Query facility reworked:
		i)	Removed "Get Selection" button
		ii)	Fix file descriptor and window leaks.
		iii)	List now sorted.
		iv)	More informative error notices.
	16) Double click in evaluator RTI list now uses query window.
	17) Query & evaluator RTI list inactivated when no RTI databases
	    are defined in the config file.
	18) Submit button changed to Send.
	19) ARC approval date removed.
	20) Changed Explain to Comments in evaluator template.
	21) New set of integration phases.
	22) Fix send and query bugs introduced in beta4.




----- End Included Message -----


From janet@firenze  Wed Mar 16 18:06:53 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05977; Wed, 16 Mar 1994 18:06:53 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13966; Wed, 16 Mar 1994 18:07:22 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA25820; Wed, 16 Mar 1994 18:09:21 +0800
Date: Wed, 16 Mar 1994 18:09:21 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9403170209.AA25820@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool release - 2.0 (on dunk)
Cc: zombolas@jurassic, on494-mgrs@benet, janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 620
X-Lines: 31
Status: O

Folks,

We have updated the rtitool binaries on dunk to fix the following
problems:

  o Configuration file not found unless rtitool 
    is invoked with the full path

  o Core dumps when "Apply" button is pushed in General Properties.

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update it as follows:

for sparc rtitool, get:

        dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, get:

        dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

Thanks--

janet




  

From richards@shangrila.Central.Sun.COM  Fri Mar 18 14:54:05 1994
Return-Path: <richards@shangrila.Central.Sun.COM>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13130; Fri, 18 Mar 1994 14:54:05 +0800
Received: from Eng.Sun.COM (engmail1) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA14511; Fri, 18 Mar 1994 14:54:37 +0800
Received: from Central.Sun.COM (central.Central.Sun.COM) by Eng.Sun.COM (4.1/SMI-4.1)
	id AA03450; Fri, 18 Mar 94 14:54:14 PST
Received: from rmtc.Central.Sun.COM by Central.Sun.COM (4.1/SMI-4.1)
	id AA28504; Fri, 18 Mar 94 16:55:09 CST
Received: from shangrila.Central.Sun.COM by rmtc.Central.Sun.COM (5.0/SMI-SVR4)
	id AA22186; Fri, 18 Mar 1994 15:55:07 +0700
Received: from shangrila (localhost) by shangrila.Central.Sun.COM (5.0/SMI-SVR4)
	id AA21429; Fri, 18 Mar 1994 15:55:05 +0700
Message-Id: <9403182255.AA21429@shangrila.Central.Sun.COM>
To: Janet.Timbol@Eng (Janet Timbol)
Cc: osnet-sde@stufff.Eng.Sun.COM, Gene.Zombolas@Eng,
        on494-mgrs@benet.Eng.Sun.COM, Paul.Richards@Central
Subject: Re: Update: rtitool release - 2.0 (on dunk) 
In-Reply-To: Your message of "Wed, 16 Mar 1994 18:09:21 +0800."
Date: Fri, 18 Mar 1994 15:55:03 MST
From: Paul Richards <richards@shangrila.Central.Sun.COM>
Content-Length: 1940
X-Lines: 43
Status: O

Followup on the rtitool 2.0 core dump while changing bugtraq login:

Here's a stack backtrace from it:

:r
SIGSEGV: Segmentation Fault (address not mapped to object)
stopped at      _siglongjmp+0x2d4:              ld      [%i1], %i5
$c
_siglongjmp(?) + 2d4
_PROCEDURE_LINKAGE_TABLE_(0x95918,0x0,0x3f734,0x0,0x9bb88,0xc) + 15c
compareDefaultsAndStore(0x55b40801,0x55140002,0x43c5c,0x4eed8,0x1,0x0) + cc
propsGeneralApplyProc(0x9dcc8,0xeffff08c,0xef562298,0x1,0x1,0xef5622a0) + b4
panel_btn_accepted(?) + 58
win_keymap(0x9dcf8,0xeffff08c,0x9dd48,0x0,0x0,0x50870) + 14598
btn_accept_preview(0x9dcf8,0xeffff08c,0x810421a,0xffffafff,0xf0a58142,0x513b0) + 1dc
panel_accept_preview(?) + 44
win_keymap(0x9dcc8,0xeffff08c,0x7c37,0x7c37,0x995c8,0x9dcf8) + 122d0
panel_default_event(?) + a80
win_keymap(0x995c8,0xeffff08c,0x6b578,0x7c37,0x7c37,0x9dcf8) + 10d1c
panel_notify_event(0x6b578,0xeffff08c,0x0,0x995c8,0x0,0x7c37) + 89c
ndet_p_event(0x0,0xeffff08c,0x6b578,0x0,0xef6c87c0,0xef6c8808) + dc
notify_post_event_and_arg(?) + 58
win_keymap(0x6b578,0xeffff08c,0x0,0x0,0xef6c87c0,0xef6c8808) + 14400
win_send(?) + 44
win_keymap(0x6b578,0xeffff08c,0x0,0x0,0xef6c87c0,0xef6c8808) + 10704
xv_input_pending(0x4eed0,0x7c00,0x4ef28,0x1,0x6b578,0x0) + 1b8
notify_fd(0x4eed0,0x0,0x1,0x1,0xff0375c0,0x3) + 74
ndis_send_ascending_fd(0x4eed0,0x3,0x3,0x8,0xeffff348,0x1) + 80
ndis_default_prioritizer(0x4eed0,0x40,0xeffff348,0xeffff2c8,0x0,0x22) + 1cc
notify_client(?) + 518
win_keymap(0x736c8,0x0,0xef6d8b40,0x3,0xef705c84,0x0) + 1443c
ndis_default_scheduler(0x0,0x93df0,0x0,0x0,0x0,0xffffffff) + 28
scheduler(0x1,0x93df0,0x0,0x0,0x0,0x9b044) + 34
ndis_dispatch(?) + 174
win_keymap(0x0,0xef705c58,0x1000,0x0,0x0,0x0) + 11484
notify_start(?) + 95c
win_keymap(0xef705aac,0xef6ff2e8,0x6,0x0,0x0,0x0) + 143a0
xv_main_loop(?) + 138
_PROCEDURE_LINKAGE_TABLE_(0x4a860,0x0,0x0,0x3fb94,0x4eed0,0x59948) + 390
main(0x1,0xeffffaac,0xeffffab4,0x47800,0x0,0x4) + 300


-Paul

From brent@jurassic  Mon Mar 28 16:29:41 1994
Return-Path: <brent@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA03343; Mon, 28 Mar 1994 16:29:41 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA16800; Mon, 28 Mar 1994 16:30:32 +0800
Received: from terra.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA24072; Mon, 28 Mar 1994 16:31:02 -0800
Received: by terra.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA19354; Mon, 28 Mar 1994 16:30:02 -0800
Date: Mon, 28 Mar 1994 16:30:02 -0800
From: brent@jurassic (Brent Callaghan)
Message-Id: <9403290030.AA19354@terra.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: os-net doc roadmap now on Mosaic
Cc: on494-mgrs@benet
X-Sun-Charset: US-ASCII
Content-Length: 2661
X-Lines: 76
Status: O


The documentation roadmap for OsNet developers is now
available as a Mosaic document.

This interface provides fast and convenient access to the
information in the roadmap.  All documents are available
via hyperlinks in the roadmap.  A single mouse click on a
hyperlink will take you to the document whether it be ascii
text, PostScript, or another Mosaic document.

Despite what you may have heard previously, there
is NO $50 charge for running Mosaic.


(1) Before you first use Mosaic, make sure that you
    have your machine configured to use DNS to 
    resolve host names.  The "hosts" entry in your
    name service switch should look something like this:

	hosts:      nisplus dns [NOTFOUND=return] files

    then check to see that you have a /etc/resolv.conf file.
    It should look like this:

	domain eng.sun.com.
	nameserver 129.144.1.15
	nameserver 129.144.1.5
	nameserver 129.145.1.27


(2) To run Mosaic use the following:

	$ /home/internet/bin.sun4.solaris2/Mosaic &

    or you might like to set this up in your OpenWindows
    .openwin-menu file with an entry like this:

	"Mosaic"      /home/internet/bin.sun4.solaris2/Mosaic 

(3) This Mosaic will display the Sun Internal Home Page.
    The hypertext links are displayed underlined and in blue.

    A single click on a hyperlink will display the document
    it refers to.  You can return to the original document
    by clicking on the "Back" button on the bottom row of
    buttons.

(4) Scroll down a few lines into the list of Sun Organizations
    and you will see a hyperlink "OS/Net developers home page".
    Click on this and Mosaic will display the "Documentation Roadmap
    for OsNet Developers".

(5) For convenient future reference, add this page to
    your "Hotlist". Just pull down the "Navigate" menu
    and select the "Add Current to Hotlist" option.
    If you want to return to this page at any future
    time just select "Hotlist" from the Navigate menu
    and click on "Documentation Roadmap for OsNet Developers".

    Any Mosaic page can be identified by its URL
    (Uniform Resource Locator).  The URL for the
    roadmap is:

	http://jurassic.eng/shared/ON/general_docs/roadmap.html

    If you would like to use the roadmap as your "home" page,
    the page that Mosaic displays first, then you can either
    run Mosaic using the URL (see above) as an argument, or
    assign the URL to the environment variable WWW_HOME.


Address questions or comments about the roadmap to 
Claire Gordiano.  If you have questions about Mosaic,
first follow the hyperlinks to Mosaic information in
the Sun Internal Home Page then try Tom Kessler or
Brent Callaghan.

From brent@jurassic  Tue Apr  5 11:26:09 1994
Return-Path: <brent@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA20333; Tue, 5 Apr 1994 11:26:09 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00906; Tue, 5 Apr 1994 11:26:47 +0800
Received: from terra.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA05996; Tue, 5 Apr 1994 11:27:12 -0700
Received: by terra.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01283; Tue, 5 Apr 1994 11:27:11 -0700
Date: Tue, 5 Apr 1994 11:27:11 -0700
From: brent@jurassic (Brent Callaghan)
Message-Id: <9404051827.AA01283@terra.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Problems running Mosaic ?
X-Sun-Charset: US-ASCII
Content-Length: 591
X-Lines: 29
Status: O


There is a 494 bug (1159787) that prevents Mosaic
connecting to local http servers on jurassic and dudette
(among others).

You may see an error that looks like this:

   Requested document (URL http://dudette.eng.sun.com/) could not be accessed.


If you have this problem, grab a new libsocket and try Mosaic again.
Here's how to install it:

	- Become root
 
	- cp /home/brent/libsocket.so.1 /tmp
 
	- cd /usr/lib
 
	- ln libsocket.so.1 libsocket.so.1-
 
	- mv /tmp/libsocket.so.1 .
 
	- exit your root shell
 
Then try Mosaic again (/home/internet/bin.sun4.solaris2/Mosaic). 

	
	Brent

From jonz@gyoll  Tue Apr 19 11:13:11 1994
Return-Path: <jonz@gyoll>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13469; Tue, 19 Apr 1994 11:13:11 +0800
Received: from gyoll.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00631; Tue, 19 Apr 1994 11:12:54 +0800
Received: by gyoll.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA07557; Tue, 19 Apr 1994 11:13:24 +0800
From: jonz@gyoll (Jon Ziegler [CONTRACTOR])
Message-Id: <9404191813.AA07557@gyoll.Eng.Sun.COM>
Subject: Solaris Test Collection get-together
To: osnet-sde@stufff
Date: Tue, 19 Apr 1994 11:13:23 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2379
X-Lines: 65
Status: O


		STC - Solaris Test Collection
			Open House
		Monday, April 25, 1994, 3PM-4PM
		   Location to be determined
			Refreshments

The STC I-Team will be holding a regular series of "open house" talks
and discussions.  All are welcome to attend.  The idea is to familiarize
people with the services provided by STC, provide a forum for some give
and take on the STC features and mechanisms, and create an opportunity
for people to talk to others who are using STC.

Please reply to this message to let me know if you will be there.  A
followup message will be sent in a few days to let people know what
room has been scheduled.  I will use the number of responses to figure
out what room to schedule and how much to provide in the way of
refreshments.  Bagels and soft drinks will be provided unless I hear
better ideas.

This first talk will be delivered by Joe Caporaletti on a subject of
his choice (probably an introduction to STC).  Feel free to make
suggestions.  The talk will take no longer than 30 minutes, the
remaining time to be devoted to Q&A.

What is STC?
	STC is several things:
	   - a collection of test suites
	   - a CodeManager workspace where tests are stored
	   - a framework for test suite creation and execution
	   - a set of tools to use in analyzing test results

Why should I use it?
	1. Source code control is a *GOOD THING*
	2. A common repository and use of STC tools helps make
	   tests reusable and maintainable.
	3. It will make your life easier.

Who is currently using it?
	Alan Parsons,  Lucy Weber and Helen Chao are currently doing
	test development using STC.  Existing test suites are in the
	process of being put under STC, starting with source control.
	Several others are using test suites under STC control.

Where is the documentation?
	The documentation has been created in HTML, intended for use
	using Mosaic.

	For those unfamiliar with Mosaic, it can be run under OpenWindows:
		/home/internet/mosaic/exe/Mosaic
	Use the Open... button at the bottom of the Mosaic window and
	enter the STC URL as follows (cut and paste works fine):
		http://kurt.eng/ostest/doc/ontest.html

	Many of the links are empty, but at this point the whole idea is to
	have many people involved in filling them out.

	** Calendar Appointment **

	Date:	04/25/94
	Start:	03:00 pm
	Stop:	04:00 pm
	Repeat:	one time
	What:	STC open house
		Location: TBD

From michaelh@atlas71.West.Sun.COM  Tue Apr 19 11:33:24 1994
Return-Path: <michaelh@atlas71.West.Sun.COM>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13478; Tue, 19 Apr 1994 11:33:24 +0800
Received: from Eng.Sun.COM (engmail1) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00639; Tue, 19 Apr 1994 11:33:36 +0800
Received: from West.Sun.COM (west.West.Sun.COM) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
	id AA15097; Tue, 19 Apr 94 11:32:57 PDT
Received: from cypress.West.Sun.COM by West.Sun.COM (5.0/SMI-5.3)
	id AA04420; Tue, 19 Apr 1994 11:32:50 +0800
Received: from atlas.West.Sun.COM (atlas71) by cypress.West.Sun.COM (4.1/SMI-4.1-900117)
	id AA14625; Tue, 19 Apr 94 11:33:49 PDT
Received: from herakles.West.Sun.COM by atlas.West.Sun.COM (5.x/SMI-SVR4)
	id AA03438; Tue, 19 Apr 1994 11:34:25 -0700
Received: by herakles.West.Sun.COM (5.x/SMI-SVR4)
	id AA04948; Tue, 19 Apr 1994 11:34:13 -0700
Date: Tue, 19 Apr 1994 11:34:13 -0700
From: michaelh@atlas71.West.Sun.COM (Michael Hulton)
Message-Id: <9404191834.AA04948@herakles.West.Sun.COM>
To: osnet-sde@stufff.Eng.Sun.COM, Jon.Ziegler@Eng
Subject: Re: Solaris Test Collection get-together
X-Sun-Charset: US-ASCII
Content-Length: 137
X-Lines: 5
Status: O


Any plans to make this talk in a room equipped with video-conferencing ?
I'm sure people here in LA would be interested ...

-- michael

From joecap@hope  Tue Apr 19 12:04:24 1994
Return-Path: <joecap@hope>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA13676; Tue, 19 Apr 1994 12:04:24 +0800
Received: from hope.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00648; Tue, 19 Apr 1994 12:04:35 +0800
Received: by hope.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11077; Tue, 19 Apr 1994 12:05:17 +0800
Date: Tue, 19 Apr 1994 12:05:17 +0800
From: joecap@hope (Joe Caporaletti)
Message-Id: <9404191905.AA11077@hope.Eng.Sun.COM>
To: michaelh@atlas71.West.Sun.COM
Subject: Re: Solaris Test Collection get-together
Cc: osnet-sde@stufff
X-Sun-Charset: US-ASCII
Content-Length: 416
X-Lines: 15
Status: O

We'll see what we can do for this time. We really should fly down there
soon too though.

-Joe

> From michaelh@atlas71.West.Sun.COM Tue Apr 19 11:37 PDT 1994
> To: osnet-sde@stufff.Eng.Sun.COM, Jon.Ziegler@Eng
> Subject: Re: Solaris Test Collection get-together
> 
> 
> Any plans to make this talk in a room equipped with video-conferencing ?
> I'm sure people here in LA would be interested ...
> 
> -- michael
> 

From janet@firenze  Tue Apr 19 17:28:53 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA14442; Tue, 19 Apr 1994 17:28:53 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00675; Tue, 19 Apr 1994 17:29:07 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA03904; Tue, 19 Apr 1994 17:30:29 +0800
Date: Tue, 19 Apr 1994 17:30:29 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9404200030.AA03904@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New rtitool release - 2.1 (on dunk)
Cc: zombolas@jurassic, on494-mgrs@benet, janet@firenze
Content-Type: X-sun-attachment
X-Lines: 122
Status: O
Content-Length: 3296       

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 39
X-Sun-Content-Length: 1318

The rtitool binaries have been updated on dunk with
rtitool version 2.1.

The updated rtitool provides:

   o New features and enhancements
   o Bug fixes
   o rtiroute enhancements

Please see the attached Revision notes for details.

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update your Rtitool directories as follows:
 
for sparc rtitool, get:
 
        dunk:/sdet/export/sparc/opt/teamware/Rtitool
 
for x86   rtitool, get:
 
        dunk:/sdet/export/i386/opt/SUNWspro/Rtitool
 
        ================================================================
Important:
        Note that until you reinvoke rtitool, you will continue to
        "use" the previous version, rtitool 1.2.  The previous version
        will be *removed* to another partition in two working days
        to make it obsolete and to enforce the upgrade!
        ================================================================
 
Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via:
 
        The Help/Send feedback... menu button, which puts you in
        a window (a mailtool compose window) which will automatically
        send your feedback to rtitool_2.x-comments@plunge.eng.

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: rev_notes2.1
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 69
X-Sun-Content-Length: 1644


                     Rtitool 2.1 Release Notes
                     =========================

New Features/Enhancements:
--------------------------

1)  A default CRT advocate can be set via props.

2)  Print option added to "File" menu.

3)  Default save to directory same as props log directory.

4)  RTI logging

5)  Evaluator CRT ID moved from props to main window.

6)  List all open RTI's (blank CRT id).

7)  Evaluator RTI list numerically sorted.

8)  Busy cursor when quering a RTI via a double click in the evaluator list.

9)  New Risk & Impact codes.

10) Risk & Impact code/strings controlled by config file.

11) Reset in ARC Opinions window resets ARC to first choice and Year to
    the current year.

12) Forward/unfoward evaluator actions supported.

13) Return on the RTI# text field in the Query popup initiates the query.

14) Intel Bugtraq props items removed.

15) Bugid Codes section added to general help.

16) RTI number automatically added to the Query list when a message is
    sent.

17) Implementor windows reset upon send.

18) Spot help added.

19) Default advocate selectable from popup menus.

Bug Fixes:
----------

1)  Subject line wrong for cancel action.

2)  Disappearing popups in CDE.

3)  Wrong window layout in older versions of XView

4)  Using fprintf to print bugids text (caused %'s to be expanded).

5)  Including blank fields in update & appeal actions which caused 
    loss of information in the RTI header.

rtiroute:

 1) Allow evaluator actions to originate from multiple domains.

 2) Updated warning message for 1.x RTI's.

 3) Updated warning messages for invalid state transitions.


From joecap@hope  Tue Apr 19 18:56:38 1994
Return-Path: <joecap@hope>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA14553; Tue, 19 Apr 1994 18:56:38 +0800
Received: from hope.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00691; Tue, 19 Apr 1994 18:56:53 +0800
Received: by hope.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA12714; Tue, 19 Apr 1994 18:57:35 +0800
Date: Tue, 19 Apr 1994 18:57:35 +0800
From: joecap@hope (Joe Caporaletti)
Message-Id: <9404200157.AA12714@hope.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Correct Mosaic URL for STC
X-Sun-Charset: US-ASCII
Content-Length: 272
X-Lines: 13
Status: O


The correct URL for stc is:

http://kurt.eng.sun.com/ostest/doc/projects/stc/stc.html

The OLD one is now a detour to the new one.

http://kurt.eng.sun.com/ostest/doc/projects/stc/onstc.html

Sorry about that. I pulled the rug out from under Jon's memo.
Mea Culpa.

-Joe

From joecap@hope  Fri Apr 22 11:37:35 1994
Return-Path: <joecap@hope>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00440; Fri, 22 Apr 1994 11:37:35 +0800
Received: from hope.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01100; Fri, 22 Apr 1994 11:37:36 +0800
Received: by hope.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA07625; Fri, 22 Apr 1994 11:38:13 +0800
Date: Fri, 22 Apr 1994 11:38:13 +0800
From: joecap@hope (Joe Caporaletti)
Message-Id: <9404221838.AA07625@hope.Eng.Sun.COM>
To: osnet-sde@stufff, jonz@gyoll
Subject: Re: Solaris Test Collection get-together
X-Sun-Charset: US-ASCII
Content-Length: 2966
X-Lines: 86
Status: O

Jon -

The "talk" will be:

	Joe Caporaletti will give a "show and tell" demo of STC's
	documentation under Mosaic and the execution of a sample test
	suite. Remote sites can connect through ShowMe for the demo.

Also, this is probably the best URL to send out.

http://kurt.eng.sun.com/ostest/doc/projects/stc/stc.html

Thanks,

-Joe

> From jonz@gyoll Tue Apr 19 11:19 PDT 1994
> Subject: Solaris Test Collection get-together
> To: osnet-sde@stufff
> 
> 
> 		STC - Solaris Test Collection
> 			Open House
> 		Monday, April 25, 1994, 3PM-4PM
> 		   Location to be determined
> 			Refreshments
> 
> The STC I-Team will be holding a regular series of "open house" talks
> and discussions.  All are welcome to attend.  The idea is to familiarize
> people with the services provided by STC, provide a forum for some give
> and take on the STC features and mechanisms, and create an opportunity
> for people to talk to others who are using STC.
> 
> Please reply to this message to let me know if you will be there.  A
> followup message will be sent in a few days to let people know what
> room has been scheduled.  I will use the number of responses to figure
> out what room to schedule and how much to provide in the way of
> refreshments.  Bagels and soft drinks will be provided unless I hear
> better ideas.
> 
> This first talk will be delivered by Joe Caporaletti on a subject of
> his choice (probably an introduction to STC).  Feel free to make
> suggestions.  The talk will take no longer than 30 minutes, the
> remaining time to be devoted to Q&A.
> 
> What is STC?
> 	STC is several things:
> 	   - a collection of test suites
> 	   - a CodeManager workspace where tests are stored
> 	   - a framework for test suite creation and execution
> 	   - a set of tools to use in analyzing test results
> 
> Why should I use it?
> 	1. Source code control is a *GOOD THING*
> 	2. A common repository and use of STC tools helps make
> 	   tests reusable and maintainable.
> 	3. It will make your life easier.
> 
> Who is currently using it?
> 	Alan Parsons,  Lucy Weber and Helen Chao are currently doing
> 	test development using STC.  Existing test suites are in the
> 	process of being put under STC, starting with source control.
> 	Several others are using test suites under STC control.
> 
> Where is the documentation?
> 	The documentation has been created in HTML, intended for use
> 	using Mosaic.
> 
> 	For those unfamiliar with Mosaic, it can be run under OpenWindows:
> 		/home/internet/mosaic/exe/Mosaic
> 	Use the Open... button at the bottom of the Mosaic window and
> 	enter the STC URL as follows (cut and paste works fine):
> 		http://kurt.eng/ostest/doc/ontest.html
> 
> 	Many of the links are empty, but at this point the whole idea is to
> 	have many people involved in filling them out.
> 
> 	** Calendar Appointment **
> 
> 	Date:	04/25/94
> 	Start:	03:00 pm
> 	Stop:	04:00 pm
> 	Repeat:	one time
> 	What:	STC open house
> 		Location: TBD
> 

From jonz@gyoll  Fri Apr 22 15:21:04 1994
Return-Path: <jonz@gyoll>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00628; Fri, 22 Apr 1994 15:21:04 +0800
Received: from gyoll.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01147; Fri, 22 Apr 1994 15:21:10 +0800
Received: by gyoll.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01037; Fri, 22 Apr 1994 15:21:39 +0800
From: jonz@gyoll (Jon Ziegler [CONTRACTOR])
Message-Id: <9404222221.AA01037@gyoll.Eng.Sun.COM>
Subject: *New Time* Solaris Test Collection get-together
To: osnet-sde@stufff, Jerry.Driscoll@EBay, Tim.Riley@EBay, bove@scotland
Date: Fri, 22 Apr 1994 15:21:38 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3553
X-Lines: 86
Status: O

Well, I've been overwhelmed by all the requests to attend, and so has
the room I had hoped to schedule.  So rather than have everybody be
uncomfortable, I am rescheduling the open house to Wednesday morning
at 11AM.  I am very sorry if this makes it impossible for some people
to attend.  Please let me know if this changes your plans.

I didn't realize the alias I mailed to pointed all over the known
universe, or I would have been more explicit, as in *hey, we're
talking about Mountain View*!  Anyway, for those who responded
from RMTC and LA, we'd like to set up ShowMe with an audio link.
If this will work for you and you want it, let me know.  Some of
the instructions below do not apply outside of the Eng domain.

The following is an update of the previous.  I suggest re-reading.
I will send out a final announcement on Tuesday.

		STC - Solaris Test Collection
			Open House
		Wednesday, April 27, 1994, 11AM-Noon
			B6, Berkeley
			Refreshments

The STC I-Team will be holding a regular series of "open house" talks
and discussions.  All are welcome to attend.  The idea is to familiarize
people with the services provided by STC, provide a forum for some give
and take on the STC features and mechanisms, and create an opportunity
for people to talk to others who are using STC.

Please reply to this message (if you didn't reply to the first one, or
the reschedule changes your plans) to let me know if you will be there.

**** FOOD/DRINK ****
I am trying to refigure refreshments in light of the new time being
right before lunch.  People have suggested juice and cookies in addition
to or instead of my proposed bagels and soft drinks.  If you have any
input, let me know.  Maybe we should just serve lunch?

**** ENTERTAINMENT ****
Joe Caporaletti will give a "show and tell" demo of STC's documentation
using Mosaic and the execution of a sample test suite. Remote sites can
connect through ShowMe for the demo.  The talk portion is intended to
take about 30 minutes.  Synchronized swimming and tap dance will follow,
with audience participation encouraged.

What is STC?
	STC is several things:
	   - a collection of test suites
	   - a CodeManager workspace where tests are stored
	   - a framework for test suite creation and execution
	   - a set of tools to use in analyzing test results

Why should I use it?
	1. Source code control is a *GOOD THING*
	2. A common repository and use of STC tools helps make
	   tests reusable and maintainable.
	3. It will make your life easier.

Who is currently using it?
	Allen Parsons,  Lucy Weber and Helen Chao are currently doing
	test development using STC.  Existing test suites are in the
	process of being put under STC, starting with source control.
	Calvin Lin is using STC suites, and adapting some new tests.

Where is the documentation?
	The documentation has been created in HTML, intended for use
	using Mosaic.

	For those unfamiliar with Mosaic, it can be run under OpenWindows:
		/home/internet/mosaic/exe/Mosaic
	Use the Open... button at the bottom of the Mosaic window and
	enter the STC URL as follows (cut and paste works fine):
		http://kurt.eng.sun.com/ostest/doc/projects/stc/stc.html
	The URL I gave before, http://kurt.eng/ostest/doc/ontest.html,
	is the OS/Net Test page, which points to the STC page.

	Many of the links are empty, but at this point the whole idea is to
	have many people involved in filling them out.

	** Calendar Appointment **

	Date:	04/27/94
	Start:	11:00 am
	Stop:	12:00 pm
	Repeat:	one time
	What:	STC open house
	Location: B6, Berkeley

From mar@jurassic  Thu Apr 28 15:06:23 1994
Return-Path: <mar@jurassic>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA09241; Thu, 28 Apr 1994 15:06:23 +0800
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA02006; Thu, 28 Apr 1994 15:06:20 +0800
Received: from adagio.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA22055; Thu, 28 Apr 1994 15:06:23 -0700
Received: by adagio.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA03701; Thu, 28 Apr 1994 15:06:10 -0700
Date: Thu, 28 Apr 1994 15:06:10 -0700
From: mar@jurassic (Sheri Mar)
Message-Id: <9404282206.AA03701@adagio.Eng.Sun.COM>
To: osnet-sde@stufff, Jerry.Driscoll@EBay, Tim.Riley@EBay, bove@scotland
Subject: STC Bi-Weekly Newsletter 4/28/94
Content-Type: X-sun-attachment
X-Lines: 691
Status: O
Content-Length: 14206      

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 26
X-Sun-Content-Length: 789


Thanks to those who attended yesterday's STC 
(Solaris Test Collection) meeting.

This will be the only time that I send this newsletter out
to the general alias.  If you'd like to receive this regularly
through email, send a request to be put on the alias to
stc-users-request@hope

This newsletter is available through the Mosaic.
Bring up Mosaic by typing:
/home/internet/mosaic/exe/Mosaic
Use the "Open..." button at the bottom of the Mosaic window and
enter the STC URL as follows (cut and paste works fine):

(this is the general STC URL)
http://kurt.eng/ostest/doc/projects/stc/stc.html

(this is the newsletter URL)
http://kurt.eng/ostest/doc/projects/stc/newsletter.html

Attached below is the postscript version of the newsletter if you
don't want to use Mosaic.

thanks,
Sheri
----------
X-Sun-Data-Type: postscript-file
X-Sun-Data-Description: postscript-file
X-Sun-Data-Name: newsletter.ps
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 651
X-Sun-Content-Length: 13065

%!PS-Adobe-1.0
%%Title: STC Bi-Weekly Newsletter Date:4/28/94
%%DocumentFonts: Times-Roman Times-Bold Times-Italic Courier Courier-Bold Courier-Oblique
%%Creator: NCSA Mosaic, Postscript by Ameet Raval & Frans van Hoesel
%%Pages: (atend)
%%EndComments
save
/D {def} def /E {exch} D
/M {moveto} D
/S {show} D
/R {rmoveto} D
/L {lineto} D
/RL {rlineto} D
/SQ {newpath 0 0 M 0 1 L 1 1 L 1 0 L closepath} D
/U {gsave currentpoint currentfont /FontInfo get /UnderlinePosition get
 0 E currentfont /FontMatrix get dtransform E pop add newpath moveto
 dup stringwidth rlineto stroke grestore S } D
/B {/r E D gsave -13 0  R currentpoint 
  newpath r 0 360 arc closepath fill grestore } D
/OB {/r E D gsave -13 0  R currentpoint 
  newpath r 0 360 arc closepath stroke grestore } D
/NP {xmargin topmargin translate scalfac dup scale } D
/HR {/l E D gsave l 0 RL  stroke grestore } D
/SF {E findfont E scalefont setfont } D
/FF {/Courier } D
/FB {/Courier-Bold } D
/FI {/Courier-Oblique } D
/RF {/Times-Roman} D
/BF {/Times-Bold} D
/IF {/Times-Italic} D
/reencodeISO {
dup dup findfont dup length dict begin
{ 1 index /FID ne { def }{ pop pop } ifelse } forall
/Encoding ISOLatin1Encoding D
currentdict end definefont
} D
/ISOLatin1Encoding [
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
/parenleft/parenright/asterisk/plus/comma/minus/period/slash
/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
/guillemotright/onequarter/onehalf/threequarters/questiondown
/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
/yacute/thorn/ydieresis
] D
[RF BF IF FF FB FI] {reencodeISO D} forall
/xmargin 43 D
/topmargin 720 D
/scalfac 0.76263 D
%%EndProlog
%%Page: 1 1
save
NP
0 -20 M
BF 24 SF
0 -20 R
(STC Bi-Weekly Newsletter 4/28/94)S
0 -48 M
0 -65 M
RF 17 SF
0 -13 R
(Welcome to the the STC newsletter. We hope that this document will help you in)S
0 -84 M
0 -13 R
(using STC.)S
0 -103 M
0 -120 M
0 -13 R
(Please send your comments about this newsletter to )S
(sheri.mar@eng.sun.com)U
0 -139 M
0 -156 M
0 -13 R
(Table of Contents:)S
0 -175 M
0 -192 M
0 -13 R
(1. STC Aliases)U
0 -211 M
0 -13 R
(2. Where to find documentation)U
0 -230 M
0 -13 R
(3. What are the workspaces?)U
0 -249 M
0 -13 R
(4. FAQs and Hints)U
0 -268 M
0 -13 R
(5. When is the next Open House?)U
0 -287 M
0 -13 R
(6. What's new)U
0 -306 M
0 -13 R
(7. Plans for the future)U
0 -325 M
0 -342 M
BF 18 SF
0 -15 R
(1. STC Aliases)S
0 -363 M
0 -380 M
BF 17 SF
0 -14 R
(stc-users@hope)S
RF 17 SF
( - alias for users and test developers of STC and general)S
0 -400 M
0 -13 R
(announcements about STC. This newsletter will be delivered bi-weekly to those on)S
0 -419 M
0 -13 R
(this alias. )S
0 -438 M
BF 17 SF
0 -14 R
(stc-users-request@hope)S
RF 17 SF
( - send email to this alias to request to be added to the)S
0 -458 M
0 -13 R
(stc-users alias)S
0 -477 M
BF 17 SF
0 -14 R
(stc-ops@hope)S
RF 17 SF
( - alias for operations like TQ, PIT, PCT, for those who will be using)S
0 -497 M
0 -13 R
(the STC scheduler for automatic load and execution of test suites.)S
0 -516 M
BF 17 SF
0 -14 R
(stc-ops-request@hope)S
RF 17 SF
( - send email to this alias to be added to the stc-ops alias.)S
0 -536 M
BF 17 SF
0 -14 R
(stc@hope)S
RF 17 SF
( - alias for STC developers. A good resource for gathering technical advice)S
0 -556 M
0 -13 R
(and reporting problems. Soon to come, a STC Bugtraq category!)S
0 -575 M
BF 17 SF
0 -14 R
(onstc-gatekeeper@eng)S
RF 17 SF
( - alias for the gatekeeper to the STC workspaces. Send email)S
0 -595 M
0 -13 R
(to this for putback permissions, workspace problems, getting a location for a new test)S
0 -614 M
0 -13 R
(suite. See the )S
(gatekeeper)U
( html for more information.)S
0 -633 M
0 -650 M
BF 18 SF
0 -15 R
(2. Where to find documentation)S
0 -671 M
0 -688 M
RF 17 SF
0 -14 R
(It's all under Mosaic. Bring up Mosaic by typing )S
BF 17 SF
(/home/internet/mosaic/exe/Mosaic)S
0 -708 M
RF 17 SF
0 -14 R
(Use the )S
BF 17 SF
(Open...)S
RF 17 SF
( button at the bottom of the Mosaic window and enter the STC URL)S
0 -728 M
0 -13 R
(as follows \(cut and paste works fine\):)S
0 -747 M
BF 17 SF
0 -14 R
(http://kurt.eng/ostest/doc/projects/stc/stc.html)S
0 -767 M
0 -784 M
RF 17 SF
0 -13 R
(I would highly recommend using Mosaic but you can also get to these docs from )S
0 -803 M
BF 17 SF
0 -14 R
(/ws/onstc-all/usr/ontest/info)S
RF 17 SF
(. )S
0 -823 M
0 -840 M
BF 18 SF
0 -15 R
(3. What are the workspaces?)S
0 -861 M
showpage restore
%%Page: 2 2
save
NP
BF 18 SF
0 0 M
BF 17 SF
0 -14 R
(/ws/onstc-all)S
RF 17 SF
( is the developer's version for adding new test suites and making)S
0 -20 M
0 -13 R
(changes.)S
0 -39 M
0 -56 M
BF 17 SF
0 -14 R
(/ws/onstc)S
RF 17 SF
( is the read-only version of the workspace for execution of test suites.)S
0 -76 M
0 -93 M
0 -13 R
(To access these workspaces make sure you are using the correct version of )S
0 -112 M
0 -13 R
(CodeManager)U
(.)S
0 -131 M
0 -13 R
(The CodeManager binaries and man pages are located on:)S
0 -150 M
0 -167 M
BF 17 SF
0 -14 R
(/net/dunk.eng/sdet/export/{sparc,i386}/opt/teamware)S
0 -187 M
0 -204 M
RF 17 SF
0 -14 R
(Make sure this is in your )S
BF 17 SF
(PATH)S
RF 17 SF
( variable before )S
BF 17 SF
(/usr/dist)S
RF 17 SF
(. See the teamware)S
0 -224 M
0 -13 R
(documentation if you need to know more about )S
(CodeManager)U
(.)S
0 -243 M
0 -260 M
BF 18 SF
0 -15 R
(4. FAQs and Hints)S
0 -281 M
0 -298 M
BF 17 SF
0 -14 R
(Q1.)S
RF 17 SF
( Where do I get CodeManager?)S
0 -318 M
BF 17 SF
0 -14 R
(A1.)S
RF 17 SF
( To access STC workspaces make sure you are using the correct version of )S
0 -338 M
0 -13 R
(CodeManager)U
(.)S
0 -357 M
0 -374 M
0 -13 R
(The CodeManager binaries and man pages are located on:)S
0 -393 M
BF 17 SF
0 -14 R
(/net/dunk.eng/sdet/export/{sparc,i386}/opt/teamware)S
0 -413 M
RF 17 SF
0 -14 R
(Make sure this is in your )S
BF 17 SF
(PATH)S
RF 17 SF
( variable before )S
BF 17 SF
(/usr/dist)S
RF 17 SF
(. See the teamware)S
0 -433 M
0 -13 R
(documentation if you need to know more about )S
(CodeManager)U
(.)S
0 -452 M
0 -469 M
BF 17 SF
0 -14 R
(Q2.)S
RF 17 SF
( I can't get my source to build without errors?)S
0 -489 M
BF 17 SF
0 -14 R
(A2.)S
RF 17 SF
( There are a few areas to check:)S
0 -509 M
BF 17 SF
0 -14 R
(Compilers)S
RF 17 SF
( - type "which cc" to verify which compiler you're using, if it returns with)S
0 -529 M
0 -13 R
("/usr/ucb/cc" that's the wrong compiler to use, you should be using the SVR4)S
0 -548 M
0 -13 R
(compilers. Most people get their compilers from "/usr/dist/exe" or load them locally.)S
0 -567 M
BF 17 SF
0 -14 R
(Activated Workspace)S
RF 17 SF
( - another item to check is if you "activated" the workspace)S
0 -587 M
0 -14 R
(before starting the build. Type )S
BF 17 SF
("env | grep CODEMGR_WS")S
RF 17 SF
(, it will print the)S
0 -607 M
0 -13 R
(workspace name if the workspace has been activated. To activate your workspace type)S
0 -626 M
BF 17 SF
0 -14 R
("ws {workspacename}")S
RF 17 SF
(. Several environment variables are set up when the)S
0 -646 M
0 -13 R
(workspace has been activated.)S
0 -665 M
BF 17 SF
0 -14 R
(Source Location)S
RF 17 SF
( - Type, "pwd". Are you really in your child workspace and in the)S
0 -685 M
0 -13 R
(test suite directory that you want to build in?)S
0 -704 M
0 -721 M
BF 17 SF
0 -14 R
(Q3.)S
RF 17 SF
( Why am I getting a license error when I try to use CodeManager?)S
0 -741 M
BF 17 SF
0 -14 R
(A3.)S
RF 17 SF
( Make sure that "/usr/dist" is mounted, that's where CodeManager gets its license.)S
0 -761 M
0 -778 M
BF 17 SF
0 -14 R
(Q4.)S
RF 17 SF
( How can I find a test suite to try on my system?)S
0 -798 M
BF 17 SF
0 -14 R
(A4.)S
RF 17 SF
( See the file )S
BF 17 SF
(/ws/onstc/usr/ontest/suite.index)S
RF 17 SF
( which contains a list of test suites)S
0 -818 M
0 -14 R
(under STC. See )S
BF 17 SF
(http://kurt.eng/ostest/doc/projects/stc/on.codemgr.html)S
RF 17 SF
( for )S
0 -838 M
0 -13 R
(Running a Suite)U
(.)S
0 -857 M
showpage restore
%%Page: 3 3
save
NP
RF 17 SF
0 0 M
BF 17 SF
0 -14 R
(Q5.)S
RF 17 SF
( Can I )S
IF 17 SF
(bringover)S
RF 17 SF
( the whole workspace and type "make results" at the top level to)S
0 -20 M
0 -13 R
(execute all the test suites?)S
0 -39 M
BF 17 SF
0 -14 R
(A5.)S
RF 17 SF
( No, you pick out specific test suites to run by searching the )S
0 -59 M
BF 17 SF
0 -14 R
(/ws/onstc/usr/ontest/suite.index)S
RF 17 SF
( file and )S
IF 17 SF
(bringover)S
RF 17 SF
( specific test suites to execute.)S
0 -79 M
0 -96 M
BF 17 SF
0 -14 R
(Q6.)S
RF 17 SF
( Can I customize my build enviroment to link from other libraries and include)S
0 -116 M
0 -13 R
(files?)S
0 -135 M
BF 17 SF
0 -14 R
(A6)S
RF 17 SF
(. Yes, the same as any CodeManager environment you can set up your)S
0 -155 M
0 -13 R
(LD_LIBRARY_PATH and change the -I search path for include files for the build.)S
0 -174 M
0 -191 M
BF 17 SF
0 -14 R
(Other Hints for Using CodeManager:)S
0 -211 M
0 -14 R
(1\))S
RF 17 SF
( Never try to modify, write, or copy files to the )S
BF 17 SF
(/ws/onstc)S
RF 17 SF
( and )S
BF 17 SF
(/ws/onstc-all)S
0 -231 M
RF 17 SF
0 -13 R
(workspaces. Always use )S
IF 17 SF
(bringover)S
RF 17 SF
( to create your own child workspace to make)S
0 -250 M
0 -13 R
(changes or to do builds. And use )S
IF 17 SF
(putback)S
RF 17 SF
( to get those changes back into the STC)S
0 -269 M
0 -13 R
(workspaces. If you have any questions about this send email to )S
0 -288 M
0 -13 R
(onstc-gatekeeper@eng.sun.com)U
(.)S
0 -307 M
BF 17 SF
0 -14 R
(2\))S
RF 17 SF
( If you do a )S
IF 17 SF
(bringover)S
RF 17 SF
( with the "-g" option to suppress the "sccs get" of the files the)S
0 -327 M
0 -13 R
(build will fail unless all the sccs files have been "gotten".)S
0 -346 M
BF 17 SF
0 -14 R
(3\))S
RF 17 SF
( Do your )S
IF 17 SF
(bringover)S
RF 17 SF
( as yourself \(your login id\) not )S
BF 17 SF
(root)S
RF 17 SF
(. If you don't, it may cause)S
0 -366 M
0 -13 R
(some permission problems later when you try to build as another user.)S
0 -385 M
BF 17 SF
0 -14 R
(4\))S
RF 17 SF
( If you are copying, moving, or deleting SCCS files in the workspace, use the)S
0 -405 M
0 -13 R
(commands )S
IF 17 SF
(sccscp)S
RF 17 SF
(, )S
IF 17 SF
(sccsmv)S
RF 17 SF
( and )S
IF 17 SF
(sccsrm)S
RF 17 SF
(, respectively. CodeManager can easily get)S
0 -424 M
0 -13 R
(confused if you don't. )S
0 -443 M
0 -460 M
BF 18 SF
0 -15 R
(5. When is the next Open House?)S
0 -481 M
0 -498 M
RF 17 SF
0 -13 R
(An "open house" is when we hold a gathering of people interested in STC and give a)S
0 -517 M
0 -13 R
(short presentation, but mostly answer questions. The next open house is scheduled for )S
0 -536 M
BF 17 SF
0 -14 R
(TBA)S
RF 17 SF
(. )S
0 -556 M
0 -573 M
BF 18 SF
0 -15 R
(6. What's new)S
0 -594 M
0 -611 M
RF 17 SF
0 -13 R
(This is the first newsletter. I'll be looking forward to your feedback.)S
0 -630 M
0 -13 R
(We have lots of new documentation under Mosaic.)S
0 -649 M
0 -14 R
(Check it out: )S
BF 17 SF
(http://kurt.eng/ostest/doc/projects/stc/stc.html)S
0 -669 M
RF 17 SF
0 -13 R
(The "make install" now creates a subdir for sparc and/or X86 depending on where the)S
0 -688 M
0 -13 R
(build is initiated from.)S
0 -707 M
0 -724 M
BF 18 SF
0 -15 R
(7. Plans for the future)S
0 -745 M
0 -762 M
RF 17 SF
0 -14 R
(Look for more information on the )S
BF 17 SF
(Scheduler)S
RF 17 SF
( as it becomes available.)S
0 -782 M
0 -13 R
(More documentation will become available under Mosaic.)S
0 -801 M
0 -13 R
(Test Qualification \(TQ\))U
( with be available soon.)S
0 -820 M
0 -837 M
IF 17 SF
0 -13 R
(This page currently maintained by )S
(Sheri Mar)U
( \(mar@eng.sun.com\) )S
showpage restore
%%Trailer
restore
%%Pages: 3

From janet@firenze  Thu May  5 18:22:41 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA00479; Thu, 5 May 1994 18:22:41 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA02820; Thu, 5 May 1994 18:23:05 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA15843; Thu, 5 May 1994 18:24:06 +0800
Date: Thu, 5 May 1994 18:24:06 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9405060124.AA15843@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Early Access to rtitool2.2 (Patch Template)
Cc: on494-mgrs@benet, gene.zombolas@Eng
X-Sun-Charset: US-ASCII
Content-Length: 1390
X-Lines: 41
Status: O


As a result of your responses to our recent patch survey, we
have extended rtitool to include a 5.x patch template.

An early access version of rtitool 2.2 is now available on dunk
as detailed below.

Please use the new patch template when submitting a patch rti.
Feedback, comments, suggestions, bugs, rfe's for rtitool can
be filed via:
 
        The Help/Send feedback... menu button, which puts you in
        a window (a mailtool compose window) which will automatically
        send your feedback to rtitool_2.x-comments@plunge.eng.


janet (for Gene Zombolas)

=============================================================

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update the following files and symlinks:

for sparc rtitool, see:

	dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, see:

	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

        ================================================================
Important:
        Note that until you reinvoke rtitool, you will continue to
        "use" the previous version.  The previous version 
	will be *removed* to another partition in two working days 
	to make it obsolete and to enforce the upgrade!
        ================================================================


From janet@firenze  Wed May 18 20:09:15 1994
Return-Path: <janet@firenze>
Received: from stufff.Eng.Sun.COM by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05350; Wed, 18 May 1994 20:09:15 +0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA04229; Wed, 18 May 1994 20:09:55 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA04367; Wed, 18 May 1994 20:10:42 +0800
Date: Wed, 18 May 1994 20:10:42 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9405190310.AA04367@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New Release of rtitool2.2
Cc: on494-mgrs@benet, gene.zombolas@Eng, janet@firenze
Content-Type: X-sun-attachment
X-Lines: 135
Status: O
Content-Length: 4367       

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 54
X-Sun-Content-Length: 1578



The rtitool binaries have been updated on dunk to reflect a
new version of rtitool, rtitool 2.2 FCS.

This version provides:

    * Patch RTI template
    * Resubmit action added to Implementor template
    * Access to rtiroute databases through
      /shared/ON/rtiroute_db automount point for improved performance 
    * Bug fixes since 2.0
    * Bug fixes since 2.2EA

Attached are the Release notes and information on using 
the /shared/ON automount map.

-----------------
Rtitool bugs/rfes:
-----------------

Please send comments, bugs, rfe's for rtitool using:
 
   The Help/Send feedback... menu button, which puts you in
   a window (a mailtool compose window) which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.

janet (for Gene Zombolas)

-----------------
Rtitool location:
-----------------

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, then you will need to create or
update the following files and symlinks:

for sparc rtitool, see:

	dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, see:

	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

================================================================
Important Note:
     Until you reinvoke rtitool, you will continue to
     "use" the previous version.  The previous version 
     will be *removed* to another partition in two working 
     days to make it obsolete and to enforce the upgrade!
================================================================

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: Release_Notes_2.2
X-Sun-Content-Lines: 29
X-Sun-Charset: us-ascii
X-Sun-Content-Length: 916


-------------------------
Rtitool 2.2 Release Notes:
-------------------------

	New Features/Enhancements:

	1)  Button marks added for popups that have been filled 
            in (ala rtitool1.2).
	2)  Patch RTI template.
	3)  Resubmit action added to Implementor template.
	4)  For improved performance, access rtiroute databases through
	    /shared/ON/rtiroute_db automount point.

	Bugs Fixed since 2.1:

	1)  Removed references to codes, ID, and Reason in bugids popup.
	2)  Removing the wrong RTI from the evaluator list when a mail
	    message is sent.

	Bugs Fixed since 2.2.EA:
	1)  Patch Justification now required.
	2)  Button marker display corrected for Patch Justification 
            popup.
	3)  N/A usual answer added to Point Patch Justification.
	4)  Don't check for integrated bugs in Patch Bugids popup.
	5)  Displaying RTI's in the evaluator list which have been 
            reassigned.

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: shared_ON_info
X-Sun-Content-Lines: 31
X-Sun-Charset: us-ascii
X-Sun-Content-Length: 1359

-----------------------------------------
Special Note on /shared/ON automount map:
-----------------------------------------

/shared/ON is an autofs automounter map available via both NIS 
and NIS+ on releases of SunOS 5.3 or greater in the Engineering 
domains.  With an autofs map, the automounter will only mount 
the needed file system.  By changing the paths for the RTI db's 
to use this new map instead of /net/wizard, the number of NFS 
mounts has been reduced from seven to one.  This will provide 
a significant performance improvement for RTI queries and 
updating the Evaluator's RTI list.

For those rtitool users outside the Engineering domain, the 
/shared/ON map may not be available.  If this is true, you can 
either:

   1)	Run rtitool from a private copy using the /net/wizard.Eng 
        paths for the RTI databases.  To do this, get complete 
        copies of both rtitool's bin and lib directory structures.  
        Within lib, rename rtitool.config-wizard to rtitool.config.  
        If your group already maintains a separate copy of rtitool, 
        contact your Sys Admin to get it updated.  Please note 
        that previous versions of rtitool.config are incompatible 
        with release 2.2.

   2)	Contact your System Administrator to install the /shared/ON 
        map

   3)	Run rtitool from an Engineering host.


From suhas@jurassic  Fri Jul 15 13:50:14 1994
Return-Path: <suhas@jurassic>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11930; Fri, 15 Jul 1994 13:50:14 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA11005; Fri, 15 Jul 1994 13:50:08 -0700
Received: from jurassic.Eng.Sun.COM (jurassic-248) by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA01085; Fri, 15 Jul 1994 13:50:45 +0800
Received: from patil.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA10995; Fri, 15 Jul 1994 13:49:59 -0700
Received: by patil.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01014; Fri, 15 Jul 1994 13:49:50 -0700
Date: Fri, 15 Jul 1994 13:49:50 -0700
From: suhas@jurassic (Suhas Patil [CONTRACTOR])
Message-Id: <9407152049.AA01014@patil.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New utility for makefiles
X-Sun-Charset: US-ASCII
Content-Length: 8729
X-Lines: 313
Status: O

    Makestyle, an audit utility for Makefiles a la cstyle, is now available
to all users. Makestyle analyzes makefiles as per the Sun guidelines
for makefiles and gives error messages.

This utility:
 
    * points out constructs which could give rise to intermittent type of errors
    * simplifies construction of makefiles
    * saves time during development and maintenance of the makefiles
    * helps to create uniform makefiles across all the groups at Sun
    * helps to improve efficiency of makefiles
    * helps to reduce build problems
    * points out pitfalls in makefiles
    * makes it easy to conform to certain makefile guidelines


--------------------
Makestyle bugs/rfes:
--------------------

   Please send your feedback, comments and rfe's to suhas.patil@eng
and file your bugs in consolidation/os-net-tools category.

-------------------
Makestyle location:
-------------------

Makestyle is available automatically if you mount your teamware
binaries from dunk.  Since it is a shell script there is no separate
version for Intel. If you maintain a private copy of the ON teamware
distribution, then you will need to copy the following files:

        dunk:/opt/teamware/OSNet/bin/makestyle
        dunk:/opt/teamware/OSNet/man/man1/makestyle.1


The arch-specific symlinks for people who mount teamware are:

sparc:
        dunk:/sdet/export/sparc/opt/teamware/bin/makestyle

x86:
        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/makestyle

The design document of this utility is available on:
        dunk:/dunk/ontools/design_docs/makestyle



-------------------
Makestyle man page:
-------------------



MAKESTYLE(1)              User Commands              MAKESTYLE(1)



NAME
     makestyle - print violations of Makefile guidelines

SYNOPSIS
     makestyle [-vishp] filenames

DESCRIPTION
     makestyle finds violations of a  selected  set  of  Makefile
     guidelines  documented  in  "Makefile  Standards  and Guide-
     lines". It issues messages for three types of checks:

     o    Violations of guidelines which must be fixed. (Default)

     o    Violations of guidelines which, when fixed, help create
         coherent makefiles. (-p option)

     o    Possible violations of guidelines. These type of viola-
         tions  are  difficult to catch in a programmatic way and
         human interpretation is required as the  algorithms  are
         complex to implement. (-h option)

OUTPUT
     The script outputs violations of guidelines,  one  violation
     to a line.  Because of the difference in the types of inputs
     available to the utility during the  first  and  the  second
     pass,  the  utility  prints messages of two different types.
     During the first pass it prints line numbers along with  the
     error  message  but  during  the  second pass it only prints
     warning messages.

OVERVIEW
     The script uses two pass algorithm to analyze the  Makefile.
     The  first  pass  does static analysis of the Makefile.  The
     second pass invokes make with -DD option to  create  a  file
     which  contains  all  the  included  files where some of the
     variables and targets  are  resolved.   This  file  is  then
     parsed  to  detect  redefinitions of macros or suffix rules.
     The design of the utility ensures that no  target  from  the
     makefile  is  actually  built during "make -DD" and hence no
     target dependencies are modified.

     The script will exit with an  error  message  during  second
     pass if the makefile contains errors that prevent successful
     invocation of make.

     The categories of violations of  the  guidelines,  based  on
     their importance and complexity in identifying them program-
     matically, is as follows:


          1. Regular checks
          2. Picky checks



SunOS 5.4           Last change: 7 July 1994                    1






MAKESTYLE(1)              User Commands              MAKESTYLE(1)



          3. Heuristic checks

     These guidelines are further divided  depending  on  whether
     the check is made during the first or the second pass.

  Regular Checks
     This is the default mode of the utility. The list of  checks
     made is as follows.

     First pass checks:

          o    Keyword, copyright and pathname identifiers should
              be  included,  where  a  pathname identifier is the
              name of the makefile with respect to the path  from
              the base of the source.

          o    No command should be used without macro reference.
              i.e. make instead of $(MAKE).

          o    Whenever a cd to another directory  is  done,  pwd
              should follow.

          o    -I and -D should not be specified in CFLAGS  macro
              but only in CPPFLAGS macro.

          o    -L should appear only in LDFLAGS macro.

          o    Install target should have no actions.

          o    INS.dir and INS.file should  be  used  instead  of
              install command.

          o    sccs command should not be explicitly used.

          o    Variables like PRINTER,  ENV  which  are  commonly
              used should not be used in makefile.

          o    Absolute path should not be used.

          o    Dynamic macro $< should appear only in the actions
              of  percent  and suffix rules. It should not appear
              in an actions list of a regular target.

          o    Pattern replacement statements should not be  used
              as targets.

          o    Operator += should be surrounded  by  white  space
              unlike "=".

          o    INC macro should not be used as in AT&T makefiles.

          o    Target .KEEP_STATE  should  be  included  in  each



SunOS 5.4           Last change: 7 July 1994                    2






MAKESTYLE(1)              User Commands              MAKESTYLE(1)



              makefile.

          o    Target all, when present, should be the first reg-
              ular target.

          o    A statement should not begin  with  space  charac-
              ters.

          o    No statement should have more than 80 characters.

     Second pass checks:

          o    Makefile.lib should be included if  a  library  is
              being built.

  Picky checks
     This mode is invoked by -p option of the utility.   Messages
     of  this  type  would  be issued for violations of following
     guidelines.   When  enabled  it  helps  create  better  than
     acceptable type of makefile.

     First pass checks:

          o    Makefile should not use wildcards. i.e. rm -rf *.o

  Heuristic checks
     This mode is invoked by -h option  of  the  utility.   These
     checks point out POSSIBLE violations of makefile guidelines.
     The messages have to be analyzed to determine  whether  they
     are indeed violations. The guidelines are as follows.

     First pass checks:

          o    The install target should have the dependencies in
              terms of ROOT instead of actual path.

          o    Target all should be included in each makefile.

     Second pass checks:

          o     Predefined suffix rules should be  used  wherever
               possible.

          o     Predefined macros should be used wherever  possi-
               ble.

USAGE
     makestyle has following options.

          -v   verbose.

          -i   Check included files for duplicate definitions  of



SunOS 5.4           Last change: 7 July 1994                    3






MAKESTYLE(1)              User Commands              MAKESTYLE(1)



               macros and suffix rules.

          -s   Skip second pass.

          -h   Perform heuristic checks that are sometimes wrong.

          -p   Perform some of the more picky checks.

     The typical invocation of the script would be as follows:

          example% makestyle path/of/Makefile

     To catch maximum number of violations, heuristic checks  and
     picky  checks  should  be  made. The usage in that situation
     would be:

          example% makestyle -h -p  path/of/Makefile

  Clean Up
     makestyle cleans up all the intermediate files it creates in
     /tmp. When errors in the makefile result in failure of make,
     the output of the most recent failed run is left in /tmp for
     possible future analysis.

DOCUMENTS
     "Makefile Standards and Guidelines"
               /shared/ON/general_docs/make_std.txt

EXIT CODES
     0         makestyle could run successfully.

     1         makestyle failed due  to  an  erroneous  input  or
               error condition encountered while running make.






















SunOS 5.4           Last change: 7 July 1994                    4

From janet@firenze  Mon Jul 25 20:45:21 1994
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA20572; Mon, 25 Jul 1994 20:45:21 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA25393; Mon, 25 Jul 1994 20:45:21 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05105; Mon, 25 Jul 1994 20:46:04 +0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05907; Mon, 25 Jul 1994 20:45:35 +0800
Date: Mon, 25 Jul 1994 20:45:35 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9407260345.AA05907@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: New Release of rtitool2.3
Cc: on494-mgrs@benet, gene.zombolas@Eng, janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 6216
X-Lines: 160
Status: O


We have updated the rtitool binaries on dunk to reflect a
new version of rtitool, rtitool 2.3 FCS.

This release features a significant change in the patch approval
process in that all patch RTIs must now be accepted by a member
of the CRT.  Please read the attached release notes from 
Gene Zombolas for details.

-----------------
Rtitool bugs/rfes:
-----------------

Please send comments, bugs, rfe's for rtitool using:
 
   The Help/Send feedback... menu button, which puts you in
   a window (a mailtool compose window) will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.

-----------------
Rtitool location:
-----------------

Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, you will need to create or
update the files and symlinks from these directories:

for sparc rtitool, see:

	dunk:/sdet/export/sparc/opt/teamware/Rtitool

for x86   rtitool, see:

	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

================================================================
Important Note:
     Until you reinvoke rtitool, you will continue to
     "use" the previous version.  The previous version 
     will be *removed* to another partition in two working 
     days to make it obsolete and to enforce the upgrade!
================================================================

-------------------------
Rtitool 2.3 Release Notes:
-------------------------

New Features/Enhancements

1)	CRT review of patch RTI's (details below).

2)	For patch RTI's, Explicit selection of release(s)/architecture(s)
	to patch (details below).

3)	Advocates may now forward CRT assignments for other advocates
	(details below).

4)	The evaluator's forward popup now contains a list of all the
	currently installed forwards.

5)	List of ARCS now configurable via the config file.  HPARC added
	to the list.

Bug Fixed:

1)	Fixed the code which corrupted the PATH environment variable.
	This caused some items in the Textsw extras menu to fail because
	the programs to perform the function could not be found.

2)	In Patch template, only show the "Security Bug?" field when a
	choice has been selected.

3)	"checkbodes" spelling error fixed in Patch justification popup.


CRT review of Patch RTI's
=========================

Patch RTI's must now be accepted by a member of the CRT.  The patch
review process works the same as implementor RTI's.

Patch RTI's are assigned the same number as the first bugid listed in
the create message prefixed with a 'P'.  After a patch RTI has been
created, all subsequent actions must reference the 'P' RTI number.

When a patch RTI is accepted  by a CRT member, a copy of the original
patch RTI including any additional information sent via an update,
resubmit, or appeal action is extracted and sent to prtiroute to begin
the patch creation process.

CRT advocates have either 24 or 48 hours to accept a patch RTI dependent
on the Escalation Type.  MELTDOWN escalations need to be accepted with
24 hours of receipt while all other escalations get 48 hours.  Rtitool
will automatically extract the value of the "Escalation Type" field from
bugtraq for every bugid listed and insert the highest type into the create
message.

When a new patch RTI is successfully created, a copy of the create message
will be sent to the patch requestor, the responsible engineer(s) (if
different than the submitter) and a notify alias of people who wish to be
imfored of every patch RTI created (this alias currently contains Claire
Giordano and Alex Simonovich).  Rtitool will automatically extract the
value of the "Responsible Engineer" field from bugtraq for every bugid
listed and insert a unique list into the create message.

IMPORTANT -- PLEASE NOTE THE FOLLOWING:

Patch RTI's are considered to live from the create (open) state to the
accept state.  If a new patch RTI needs to be created for a bugid which
has already been submitted before, the old RTI will be archived and a
new one created.  Attempting to create multiple patch RTI's for the
same bugid before the first one has been accepted, will generate an
error and the message will be returned to the sender.

Patch Releases
==============

The "Target Releases" and "Affected Architectures" fields in the Patch
template have been combined into the popup "Patch Releases".  This popup
allows you to explicitly specify which releases and architectures that
a patch needs to generated for.  The window contains a list of all
the releases that can be patched.  For each release, there is a non-
exclusive choice of all the possible architectures to patch.  Selecting
a release requires at least one architecture for that release to be chosen.
Rtitool requires you to select at least one release/architecture for a
Patch RTI.

If a patch is a generic fix, then all architectures for a release should
be selected.

If a a patch is specific to a platform, such as sun4m, this information
should be included in the "Comments" field.

New Forwarding Features (CRT Advocates Only)
============================================

The functionality of the Evaluator's "Forward" popup has been extended
to allow an advocate to install a forward for another advocate.  The
new field "Forward From" lets you specify which advocate to forward.
This field defaults to the email address of the user.  Values may be
chosen from the associated popup menu.  No value will install a forward
for the current user.

The "Current State" field shows the current forwarding state of the
advocate listed in the "Forward From".  If you change the value of
"Forward From", you can update the state field with the "Current State"
button.

A complete list of all installed forwards is displayed in the "Current
Forwards" scrollable list.  The "Update List" button will cause the
forwards database to be reread and displayed.

If a forward is install for an advocate by another advocate, a mail
message will be sent to the forwarded advocate indicating their CRT
assignments have been forwarded.

A forward can only be removed by the forwarded advocate.  Selecting the
"unforward" action will grey out both the "Forward From" and "Forward To"
fields

From bonwick@cathy Thu Jul 28 00:17 PDT 1994
Date: Thu, 28 Jul 1994 00:10:55 -0700
From: bonwick@cathy (Jeff Bonwick)
To: on-eng@benet
Subject: bfu and Install changes
Content-Length: 1772
Content-Type: text
Status: RO
X-Lines: 44

As a few of you have discovered the hard way, bfu'ing on top of
a "glommed" (Install -g) kernel can yield an unbootable system.
The reason is that new binaries installed in /usr/kernel don't
overwrite the old versions in /kernel, which comes first in the
module search path.  The mixture of new and old binaries may or
may not be compatible.  It's almost worse if they *are* compatible,
since then you may not be testing the system you think you are.

I made some changes to bfu last night so that it will automatically
delete all but the newest version of any kernel binary.  For example,
if /kernel/drv/kstat and /usr/kernel/drv/kstat both exist, then the
older one will be removed.

I also added a new option to Install.  In the post-kbi world it's
somewhat harder to have multiple kernels for two reasons: (1) we now
have all the /platform stuff in addition to /kernel and /usr/kernel;
and (2) you can't just "mkdir /foo; cd /foo; tar xvf /tmp/Install.tar"
and boot /foo/kernel/unix anymore.  The new -G option is like -g,
but takes a kernel name:

	Install -G kernel.good

creates a tar file with all files under ./platform/mumble/kernel.good.
If you install this in "/" you can then boot "kernel.good/unix" and the
right thing happens.

The new versions of Install and bfu are in /ws/on495-gate/public/bin.

Jeff

PS -- Wednesday Hack: here's how bfu removes all but the newest version
of your kernel binaries ($p, $k, and $u are the /platform/$ARCH, /, and
/usr directories, respectively):

for dup in `(for d in $p $k $u; do cd $d; find kernel ! -type d -print; done) |
	sort | uniq -d`
do
	rm -f `ls -ct1 $p$dup $k$dup $u$dup 2>/dev/null | nawk 'NR > 1'`
done

Wednesday Challenge for black-belt shell programmers: can you devise
a more compact equivalent?

Jeff

From bonwick@cathy Mon Aug 15 06:51 PDT 1994
Date: Mon, 15 Aug 1994 06:45:06 -0700
From: bonwick@cathy (Jeff Bonwick)
To: on-eng@benet
Subject: P1: command-line resolve is unsafe
Content-Length: 4584
Content-Type: text
Status: RO
X-Lines: 201

There's a bug in diff3 that can cause it to silently mismerge files.
This is truly frightening because teamware's command-line resolve
depends on diff3 to perform the merge.  The reproducible test case
in the bug report below is derived from files on which I personally
experienced the problem.

The GUI version (filemerge) does not depend on diff3 and thus
doesn't exhibit the bug.  I strongly recommend that you avoid
using command-line merge until this problem is addressed.

Jeff

----- Begin Included Message -----

From bonwick Mon Aug 15 06:06 PDT 1994
Subject: 1174768: Bug report created.
To: bonwick@cathy, bugforward@elmer, tadd@eng, msw@polyslo, cmh@Eng,
        raf@sunraf


 Bug Id: 1174768
 Category: utility
 Subcategory: program
 Bug/Rfe: bug
 Synopsis: diff3 can silently mismerge files
 Keywords: 
 Severity: 1
 Priority: 1
 Responsible Engineer: 
 Description: 
bonwick, 94/08/15:

diff3 can silently mismerge files.  The following three files
demonstrate the problem:

::::::::::::::
child
::::::::::::::
	extern void	clkstart();
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kmem async thread */
::::::::::::::
ancestor
::::::::::::::
	extern void	clkstart();
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kma daemon */
::::::::::::::
parent
::::::::::::::
	extern void	post_startup();

	post_startup();
	/* create kma daemon */

The changes are trivial and do not overlap.
The child just changed a comment:

$ diff ancestor child
7c7
< 	/* create kma daemon */
---
> 	/* create kmem async thread */

and the parent just removed clkstart():

$ diff ancestor parent
1d0
< 	extern void	clkstart();
3,4d1
< 
< 	clkstart();

Using diff3 -E to merge the files as follows:

	cp child merge
	diff3 -E child ancestor parent | ed - merge

yelds the following merged result:

$ cat merge
	extern void	post_startup();

	clkstart();

	post_startup();
	/* create kmem async thread */

The declaration of clkstart() is gone, as it should be, but the
call to clkstart() is still there!

Interestingly, doing the merge in the other order (reversing the
sense of parent and child) works correctly:

	cp parent merge
	diff3 -E parent ancestor child | ed - merge

yields the expected result:

$ cat merge
	extern void	post_startup();

	post_startup();
	/* create kmem async thread */

**********************************************************************
This is truly frightening because teamware's command-line resolve
depends on diff3 to perform the merge.  The above files are condensed
versions of files on which I actually experienced a bad resolve.
**********************************************************************

I don't know what the problem is but I have a suspicion.
diff3 ultimately invokes /usr/lib/diff3prog with pre-computed
diffs of files 1 and 2 against file 3.  Check this out:

$ diff child parent
1d0
< 	extern void	clkstart();
4,5d2
< 	clkstart();
< 
7c4
< 	/* create kmem async thread */
---
> 	/* create kma daemon */

$ diff ancestor parent
1d0
< 	extern void	clkstart();
3,4d1
< 
< 	clkstart();

Notice that in the first diff, the call to clkstart() and the *following*
blank line are deleted.  In the second diff, the call to clkstart() and
the *preceding* blank line are deleted.  There's nothing wrong with
this -- the diff is ambiguous and either way is correct.  But I suspect
this may be confusing diff3.  If I save these diffs into files and
manually modify either one of the clkstart() diffs to match the other,
and then invoke /usr/lib/diff3prog -E with these diffs, the merge
comes out correct.

Apparently this bug is ancient.  I've verified that SunOS 5.x, SunOS 4.x,
generic SVR4, and 4.3BSD all have the same problem.

 Work around: 

 Suggested fix: 

 Justification: 
Justification by: bonwick                 Date: 8/15/94  Create with Priority 1:

This bug can silently corrupt our source base since teamware's
command-line resolve relies on diff3 to perform the merge.

 State triggers: 
	Accepted: no
	Evaluation: 

	Commit to fix in releases: 
	Fixed in releases: 
	Integrated in releases: 
	Verified in releases: 
 Comments: 

Introduced in release: 
 Root cause: 
 Development Status: 
 Fix affects documentation: 
 Interest list: tadd, msw, cmh, raf
 Patch id: 
 See also: 

 Called in by: 
    Customer:
	Company: Sun Microsystems
	Employee: Jeff Bonwick
	Release: s495_dev_phase
	Hardware version: generic
	O/S version: s495_dev_phase
	User Type: D
	SO Number: 
	Sun Contact: bonwick
 Public Summary: 

 Hook 1: 
 Hook 2: 
 Bug End:



----- End Included Message -----


From janet@firenze  Wed Aug 17 18:51:41 1994
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA03903; Wed, 17 Aug 1994 18:51:41 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA06222; Wed, 17 Aug 1994 18:51:59 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA05946; Wed, 17 Aug 1994 18:51:56 -0700
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA12713; Wed, 17 Aug 1994 18:52:00 +0800
Date: Wed, 17 Aug 1994 18:52:00 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9408180152.AA12713@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool 2.3
Cc: on494-mgrs@benet, gene.zombolas@Eng, janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 1394
X-Lines: 45
Status: O


We have updated the rtitool binaries on dunk to reflect the
following bug fixes/enhancements:

  1.  Require complete email address (<user>@<domain>) for CRT
      advocate (except for default advocate) and patch requestor.
 
  2.  Ensure that "Responsible Engineer" for the patch template
      is a unique list of names.

  3.  Show all fields in a patch create.

-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, you will need to create or
update the files and symlinks from these directories:
 
for sparc rtitool, see:
 
        dunk:/sdet/export/sparc/opt/teamware/Rtitool
 
for x86   rtitool, see:
 
        dunk:/sdet/export/i386/opt/SUNWspro/Rtitool
 
================================================================
Important Note:
     Please reinvoke 'rtitool' to access these changes.
     The previous version will be *removed* within the next
     day to enforce the upgrade.
================================================================

From chua@jurassic-52  Fri Aug 26 15:29:24 1994
Return-Path: <chua@jurassic-52>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11046; Fri, 26 Aug 1994 15:29:24 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA24749; Fri, 26 Aug 1994 15:29:45 -0700
Received: from Eng.Sun.COM (zigzag) by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA09552; Fri, 26 Aug 1994 15:29:43 -0700
Received: from benet.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA09066; Fri, 26 Aug 94 15:31:25 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by benet.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04598; Fri, 26 Aug 94 15:29:13 PDT
Received: from boracay.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA24744; Fri, 26 Aug 1994 15:29:32 -0700
Received: by boracay.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01911; Fri, 26 Aug 1994 15:28:58 -0700
Date: Fri, 26 Aug 1994 15:28:58 -0700
From: chua@jurassic-52 (Georgina Chua-Fung)
Message-Id: <9408262228.AA01911@boracay.Eng.Sun.COM>
To: osnet-sde@benet
Subject: EOL of onbld/ongk/onld/onmk packages
Cc: chua@jurassic-52
X-Sun-Charset: US-ASCII
Content-Length: 1443
X-Lines: 39
Status: O

==========================================================================

Subject:        EOL of onbld/ongk/onld/onmk packages

Intended 
Audience:       Developers, Gatekeepers and Integration Engineers

From:           OS Integration Group

===========================================================================
         

The OS Integration Group will be doing some cleanup work on the tools
made available on dunk.eng.  Currently, these tools are accessed either
through mounting the exported directories that contain these tools or
through pkgadding the packaged tools.  

To make sure that everyone is using the same revs of the tools, we would 
like to do the following:

        o       remove outdated packaged tools like SUNWonbld,
                SUNWonld, SUNWongk and SUNWonmk from /net/dunk/
                sdet/pkgs; and
 
                (Note: If you're using the tools from these old
		packages, you should upgrade to mount these tools
                from /net/dunk/export/sdet/export/{arch}/opt/
                {SUNWspro,onbld,ongk,teamware})

        o       maintain mountable directory
                (/net/dunk/export/sdet/export/{arch}/opt/
                 {SUNWspro,onbld,ongk,teamware});

         
We encourage you to use cachefs to mount these tools from "dunk".

If you have any questions or problems with this, please let us know
by 09/01/94.  Please direct your questions/concerns to os-int@plunge.


From jrt@gap  Fri Aug 26 15:56:30 1994
Return-Path: <jrt@gap>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11062; Fri, 26 Aug 1994 15:56:30 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA26547; Fri, 26 Aug 1994 15:56:55 -0700
Received: from Eng.Sun.COM (zigzag) by stufff.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA09563; Fri, 26 Aug 1994 15:56:53 -0700
Received: from benet.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA11728; Fri, 26 Aug 94 15:58:34 PDT
Received: from gap.Eng.Sun.COM by benet.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04689; Fri, 26 Aug 94 15:56:22 PDT
Received: by gap.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA21091; Fri, 26 Aug 1994 15:56:29 -0700
Date: Fri, 26 Aug 1994 15:56:29 -0700
From: jrt@gap (Joel Tornatore)
Message-Id: <9408262256.AA21091@gap.Eng.Sun.COM>
To: osnet-sde@benet, chua@jurassic-52
Subject: Re: EOL of onbld/ongk/onld/onmk packages
X-Sun-Charset: US-ASCII
Content-Length: 2150
X-Lines: 64
Status: O

Mount point correction:

>         o       remove outdated packaged tools like SUNWonbld,
>                 SUNWonld, SUNWongk and SUNWonmk from /net/dunk/
>                 sdet/pkgs; and
>  
>                 (Note: If you're using the tools from these old
> 		packages, you should upgrade to mount these tools
>                 from /net/dunk/export/sdet/export/{arch}/opt/
>                 {SUNWspro,onbld,ongk,teamware})


That's /net/dunk/sdet/export/{arch}/opt/


joel



> From chua@jurassic-52 Fri Aug 26 15:32 PDT 1994
> To: osnet-sde@benet
> Subject: EOL of onbld/ongk/onld/onmk packages
> Cc: chua@jurassic-52
> 
> ==========================================================================
> 
> Subject:        EOL of onbld/ongk/onld/onmk packages
> 
> Intended 
> Audience:       Developers, Gatekeepers and Integration Engineers
> 
> From:           OS Integration Group
> 
> ===========================================================================
>          
> 
> The OS Integration Group will be doing some cleanup work on the tools
> made available on dunk.eng.  Currently, these tools are accessed either
> through mounting the exported directories that contain these tools or
> through pkgadding the packaged tools.  
> 
> To make sure that everyone is using the same revs of the tools, we would 
> like to do the following:
> 
>         o       remove outdated packaged tools like SUNWonbld,
>                 SUNWonld, SUNWongk and SUNWonmk from /net/dunk/
>                 sdet/pkgs; and
>  
>                 (Note: If you're using the tools from these old
> 		packages, you should upgrade to mount these tools
>                 from /net/dunk/export/sdet/export/{arch}/opt/
>                 {SUNWspro,onbld,ongk,teamware})
> 
>         o       maintain mountable directory
>                 (/net/dunk/export/sdet/export/{arch}/opt/
>                  {SUNWspro,onbld,ongk,teamware});
> 
>          
> We encourage you to use cachefs to mount these tools from "dunk".
> 
> If you have any questions or problems with this, please let us know
> by 09/01/94.  Please direct your questions/concerns to os-int@plunge.
> 
> 

From janet@firenze  Thu Sep  1 18:29:54 1994
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA17330; Thu, 1 Sep 1994 18:29:54 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id SAA14590; Thu, 1 Sep 1994 18:30:07 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id SAA06491; Thu, 1 Sep 1994 18:30:06 -0700
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA11265; Thu, 1 Sep 1994 18:29:49 +0800
Date: Thu, 1 Sep 1994 18:29:49 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9409020129.AA11265@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Updates on dunk: mk_bld_space, hdrchk, makestyle
Cc: suhas@jurassic, janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 1401
X-Lines: 51
Status: O


The following updates are now available on 'dunk':

  o mk_bld_space:
        1164129 : mk_bld_space should not follow symlinks to directories

  o hdrchk:
        1151627 : hdrchk forces use of /usr/dist/exe/perl
        1174068 : hdrchk should allow SunSoft S form of keywords
        1174071 : hdrchk should be able to accept continuation of 
                  ifdef statements

  o makestyle:
        <no bugid>: accepts "pragma ident" as a valid identifier

  o makestyle.1:
	Document the dependency on SRC environment variable

LOCATION OF FILES:
-----------------

If you mount teamware from dunk, no action is required.  However,
if you maintain a private copy of the OSNet teamware distribution, 
you will have to copy the following files:

   Shell Scripts:

	dunk:/opt/teamware/OSNet/bin/hdrchk
        dunk:/opt/teamware/OSNet/bin/mk_bld_space
        dunk:/opt/teamware/OSNet/bin/makestyle

   Manpage:
        dunk:/opt/teamware/OSNet/man/man1/makestyle.1

The arch-specific symlinks for people who mount teamware are:

sparc:
        dunk:/sdet/export/sparc/opt/teamware/bin/\
             {hdrchk,mk_bld_space,makestyle}
 
i386:
        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/\
             {hdrchk,mk_bld_space,makestyle}

BUGS/RFEs:
---------

Please send your feedback, comments and rfe's to suhas.patil@eng
and file your bugs in consolidation/os-net-tools category.

janet

From janet@firenze  Thu Sep  8 11:41:27 1994
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA23411; Thu, 8 Sep 1994 11:41:27 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id LAA16098; Thu, 8 Sep 1994 11:41:46 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id LAA01611; Thu, 8 Sep 1994 11:41:12 -0700
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA09013; Thu, 8 Sep 1994 11:40:47 +0800
Date: Thu, 8 Sep 1994 11:40:47 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9409081840.AA09013@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Re: Updates on dunk: codereview, rtitool
Cc: suhas@jurassic, janet@firenze
X-Sun-Charset: US-ASCII
Content-Length: 1205
X-Lines: 43
Status: O



The following files have been updated on dunk:

  o Rtitool/lib/advocates.config:
        Update ON_CRT advocates list

  o codereview:
	Add new option to eliminate unchanged functions from the
	codereview listing

  o codereview.1:
	Document new '-e' option

LOCATION OF FILES:
-----------------

If you mount teamware from dunk, please restart rtitool to
access the new advocates.config file.  However, if you maintain 
a private copy of the OSNet teamware distribution, please 
copy the following files:

	dunk:/opt/teamware/Rtitool/lib/advocates.config
	dunk:/opt/teamware/OSNet/bin/codereview
        dunk:/opt/teamware/OSNet/man/man1/codereview.1

The arch-specific symlinks for people who mount teamware are:

   sparc:
	dunk:/sdet/export/sparc/opt/teamware/Rtitool/lib/\
             advocates.config
        dunk:/sdet/export/sparc/opt/teamware/bin/codereview
        dunk:/sdet/export/sparc/opt/teamware/man/man1/\
             codereview.1
 
   i386:
	dunk:/sdet/export/i386/opt/SUNWspro/Rtitool/lib/\	
             advocates.config
        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/codereview
        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/man/man1/\
             codereview.1

janet

From janet@firenze  Thu Nov 10 15:43:07 1994
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (camilla) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA05608; Thu, 10 Nov 1994 15:43:07 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id PAA05725; Thu, 10 Nov 1994 15:43:36 -0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA18078; Thu, 10 Nov 1994 15:44:37 -0800
Received: by firenze.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA14580; Thu, 10 Nov 1994 15:38:51 +0800
Date: Thu, 10 Nov 1994 15:38:51 +0800
From: janet@firenze (Janet Timbol)
Message-Id: <9411102338.AA14580@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool 2.4
Cc: gene.zombolas@Eng, janet@firenze, on494-mgrs@benet
Reply-To: janet@firenze
content-length: 4009


We have updated the rtitool and rtiroute binaries on dunk to 
reflect the bug fixes and enhancements listed at the bottom
of this mail message.

IMPORTANT NOTES: PLEASE READ THIS!!

  1)	The new version of rtiroute is _NOT_ backwards
	compatible for patch RTIs due to the addition of
	some fields.  Please restart 'rtitool' to avoid
	difficulties in submitting patch rtis.  (Backward
	compatibility is not an issue with implementor RTIs.)

  2)	We will occasionally be updating the rtiroute
	advocates.config file.  If you are mounting
	the teamware binaries from dunk, these changes
	will be transparent to you.  However, if you access 
	your own private copy of rtitool, please send me 
	mail to get on the notification alias for updates
	to the configuration file.

janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  If you maintain a private copy of the
ON teamware distribution, you will need to create or
update the files and symlinks from these directories:
 
for sparc rtitool, see:
 
        dunk:/sdet/export/sparc/opt/teamware/Rtitool
 
for x86   rtitool, see:
 
        dunk:/sdet/export/i386/opt/SUNWspro/Rtitool
 
================================================================
Important Note:
     Please reinvoke 'rtitool' to access these changes.
     The previous version will be *removed* within the next
     hour to enforce the upgrade.
================================================================


*************************************************************************
Rtitool 2.4:  RELEASE NOTES  
(by Gene Zombolas, Nov. 10, 1994)
*************************************************************************

============
rtitool rfes
============

o  Query of RTI extended to match implementor, patch, and archived patch
   RTIs with the same RTI number a single query.

o  Additional bugtraq checks added.  Rtitool now requires Responsible
   Manager, Responsible Engineer, and Suggested Fix to be defined in bugtraq
   for all bugids before a RTI can be submitted.

o  "Code Reviewed By" field added to the implementor RTI.

o  "Test Results" field added to patch RTI.

o  "Patch Request Origin" field added to patch RTI

o  New default choices for "Patch Justification".

o  Bugtraq checks (state, RM, RE, and Suggested Fix) are redone when an
   evaluator attempts to accept a RTI.

o  Changed approval implementor RTIs for a phase to a release.

o  Removed approval of patch RTIs for patch/point patch.

o  Cancel action added to evaluator's window.

=================
rtitool bug fixes
=================

o  Now works with different font families/sizes.

o  Ensure that the bugid(s) are followed by a blank line (required by
   rtiroute).

=============
rtiroute rfes
=============

o  Code reviewer CC'd on receipt of a new RTI

o  CC of patch gatekeeper on updates to patch RTIs.

o  Archive and open new RTI for canceled patch RTIs when create message
   received with a bugid of an existing patch RTI.

o  Mail messages sent by rtiroute now have "Precedence: bulk" to prevent
   the vacation program from responding to them.

o  Patch RTI fields deliverable sources and deliverable objects now
   replace the previous value on a update or appeal.

o  Daily summaries now include all RTIs which are not in the accept or cancel
   states in addition to all RTIs which were acted upon in the last 24 hours.

==================
rtiroute bug fixes
==================

o  Evaluator comments now correctly included (under the heading Evaluator
   Comments:) in the extracted RTI sent to prtiroute.

o  Fixed bug where rtiroute munged lines with a % in included or forwarded
   mail messages.


From janet@dunk  Mon Nov 14 17:35:15 1994
Return-Path: <janet@dunk>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA08875; Mon, 14 Nov 1994 17:35:15 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id RAA07794; Mon, 14 Nov 1994 17:35:58 -0800
Received: from dunk.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id RAA00324; Mon, 14 Nov 1994 17:37:00 -0800
Received: by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA08823; Mon, 14 Nov 1994 16:26:38 +0800
Date: Mon, 14 Nov 1994 16:26:38 +0800
From: janet@dunk (Janet Timbol)
Message-Id: <9411150026.AA08823@dunk.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool 2.4.1
Cc: gene.zombolas@Eng, janet@dunk, on494-mgrs@benet
content-length: 2077


We have updated the rtitool and rtiroute binaries on dunk to 
reflect the bug fixes and enhancements listed at the bottom
of this mail message.

Please reinvoke 'rtitool' to access the changes.  The previous 
version will be *removed* within the next two hours to enforce 
the upgrade.

If you maintain a private copy of the rtitool distribution and
have not notified us, as requested in last week's mail, please
do so now, so that we can add you to the notification alias
for updates to the advocates.config file.

Thanks,
janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  However, if you maintain a private copy of 
the ON teamware distribution, you will need to:

1)  Copy ~ALL~ the files and symlinks from these directories:

        for sparc rtitool:

                dunk:/sdet/export/sparc/opt/teamware/Rtitool

        for x86   rtitool:

                dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

2)  If you are unable to access /shared/ON remotely, update the 
    lib/rtitool.config file to:

        a) Replace

                /shared/ON
           with
                /net/wizard.Eng/export/consolidation/rtiroute 
 

*************************************************************************
Rtitool 2.4.1:  RELEASE NOTES  
(by Gene Zombolas, Nov. 14, 1994)
*************************************************************************

============
rtitool rfes
============

o  Backed out approval by release.  Previous policy of approval 
   by phase reinstated.

=================
rtitool bug fixes
=================

o  Reassign/Hold requiring wrong fields in evaluator's template.

o  Erroneous error with bugtraq checks in patch template when bugtraq
   was inaccessible.


From janet@dunk  Mon Dec  5 14:48:19 1994
Return-Path: <janet@dunk>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA17155; Mon, 5 Dec 1994 14:48:19 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id OAA17394; Mon, 5 Dec 1994 14:49:18 -0800
Received: from dunk.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id OAA05831; Mon, 5 Dec 1994 14:49:16 -0800
Received: by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA17150; Mon, 5 Dec 1994 14:47:52 +0800
Date: Mon, 5 Dec 1994 14:47:52 +0800
From: janet@dunk (Janet Timbol)
Message-Id: <9412052247.AA17150@dunk.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: codereview & cstyle updates
Cc: janet@firenze, johnz@dunk, shannon@dunk
content-length: 1111

Folks,

New versions of 'codereview' and 'cstyle' have been pushed to
dunk.  Changes are:

	codereview bug fix: 
		Using -e when there are no changes to the file 
		before the end of the first function causes the 
		old version to generate a bad postscript file.

	cstyle note from Bill Shannon:
		As announced a year ago, I've removed the 
		"transition" flag from cstyle.  My automatic 
		scripts that run cstyle will thus no longer allow 
		some things that used to get by.  For the last year 
		I've done these same runs monthly and mailed the 
		results to the owners of the files.  Based on the 
		mail I've been getting, some owners haven't found 
		time in the last year to fix these errors.  Well, 
		time's up.

The updated utilities are automatically available to those
of you who mount teamware from dunk.  However, if you maintain 
your own private distribution, please copy the following files:

   sparc/i386:  dunk:/opt/teamware/OSNet/bin/cstyle
   sparc:       dunk:/sdet/export/sparc/opt/teamware/bin/codereview
   i386:        dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/codereview


janet

From tadd@jurassic  Wed Dec 21 15:00:40 1994
Return-Path: <tadd@jurassic>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA29876; Wed, 21 Dec 1994 15:00:40 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id OAA16099; Wed, 21 Dec 1994 14:59:56 -0800
Received: from Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA11632; Wed, 21 Dec 1994 15:00:04 -0800
Received: from benet.Eng.Sun.COM by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
	id AA14365; Wed, 21 Dec 94 14:59:34 PST
Received: from jurassic.Eng.Sun.COM (jurassic-248) by benet.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05010; Wed, 21 Dec 94 14:59:29 PST
Received: from widor.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id OAA16068; Wed, 21 Dec 1994 14:59:29 -0800
Received: by widor.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id OAA00478; Wed, 21 Dec 1994 14:59:01 -0800
Date: Wed, 21 Dec 1994 14:59:01 -0800
From: tadd@jurassic (Tadd Ottman)
Message-Id: <199412212259.OAA00478@widor.Eng.Sun.COM>
To: osnet-sde@benet
Subject: onbld tools updated, xgettext special
X-Sun-Protection-Factor: Sun confidential, internal-use-only
Precedence: junk
X-Sun-Charset: US-ASCII
content-length: 901


OS-Net developers,

	I have made slight updates to the onbld tools, usually mounted
as /opt/onbld/bin from dunk.eng's /sdet/export/{i386,sparc}/opt/onbld.

	I have introduced an internally enhanced version of xgettext
that supports a "-t" option for extracting dcgettext() messages from
source code (for L10n work).  (Regular builds do not use xgettext.)

	On i386, I have introduced a tic binary, since makefiles find
tic from the path to build terminfo databases.  This will not change
your i386 builds if they have been 2.5 on 2.5, but will close a hole
in the construction set if you have been building 2.5 on older x86
releases.

	On sparc, I cut some obsolete tools predating parallel make.

	The onbld directory is versioned, so I have introduced 2.1
to denote the changes.  2.0 had previously been current.  These
versions are meaningful only to customized usage of the ws script.

					Tadd

From janet@firenze  Mon Mar  6 12:06:59 1995
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.0/SMI-SVR4)
	id AA06526; Mon, 6 Mar 1995 12:06:59 +0800
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
	id MAA01172; Mon, 6 Mar 1995 12:07:37 -0800
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id MAA01063; Mon, 6 Mar 1995 12:08:46 -0800
Received: by firenze.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01692; Mon, 6 Mar 1995 12:07:02 -0800
Date: Mon, 6 Mar 1995 12:07:02 -0800
From: janet@firenze (Janet Timbol)
Message-Id: <9503062007.AA01692@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool 2.4.2
Cc: janet@firenze, margotm@donald, on494-mgrs@benet
content-length: 2594


We have updated the rtitool files on dunk to reflect the bug fixes 
and enhancement listed at the bottom of this mail message.

Please reinvoke 'rtitool' to access the changes.  The previous 
version will be *removed* within the next two hours to enforce 
the upgrade.

janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  However, if you maintain a private copy of 
the ON teamware distribution, you will need to:

1)  Copy ~ALL~ the files and symlinks from these directories:

        for sparc rtitool:

                dunk:/sdet/export/sparc/opt/teamware/Rtitool

        for x86   rtitool:

                dunk:/sdet/export/i386/opt/SUNWspro/Rtitool

2)  If you are unable to access /shared/ON remotely, update the 
    lib/rtitool.config file to:

        a) Replace

                /shared/ON
           with
                /net/wizard.Eng/export/consolidation/rtiroute 
 

*************************************************************************
Rtitool 2.4.2:  RELEASE NOTES  
(by Margot Miller March 3, 1995
*************************************************************************

============
rtitool rfes
============

o Group all bugtraq error checking to be done at one time.  

=================
rtitool bug fixes
=================

1)  "Undefined name" errors when bringing up rtitool.  Rtitool will not
     come up.  Looks like memory mgmt problem.

2)  Rtitool v2.4.1 will core dump if you try to reset the CRT advocate
    in the implementor RTI properties sheet.

3)  Security field should be mandatory in patch rti.
 
4)  Clarification of error message "Suggested Fix is undefined in
    bugtraq" and "jjv is not a valid email address".
 
5)  The Code Reviewed By: field is not cleared when you select either
    form of the Reset button in the implementor rti template: Clear
    all fields and load default values, or Clear all fields.
 
6)  "Code Reviewed by" field  in the Implementor RTI may be blank
    without rtitool complaining.
 
7)  On the Query popup window, the header field is not updated
    properly.
 
8)  Correct spot help errors.

9)  Core dump when inputting 10 digit opinion numbers in
    Arc popup.
 
10) Core dump in evaluator template when doing forwarding.


From janet@firenze  Mon Apr 10 13:11:35 1995
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA28215; Mon, 10 Apr 1995 13:11:35 -0700
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id NAA22539; Mon, 10 Apr 1995 13:14:31 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id NAA15103; Mon, 10 Apr 1995 13:16:01 -0700
Received: by firenze.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA01659; Mon, 10 Apr 1995 13:13:40 -0700
Date: Mon, 10 Apr 1995 13:13:40 -0700
From: janet@firenze (Janet Timbol)
Message-Id: <9504102013.AA01659@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: codereview updates
Cc: janet@firenze, johnz@firenze
X-Sun-Charset: US-ASCII
content-length: 763


The 'codereview' utility has been updated by John Zolnowsky
to support a -h<string> argument to specify a header string to 
appear on each page of the listing.  The header appears on the 
upper left, and the page number is displayed on the upper right.
 
If you mount teamware from dunk, you need not do anything to access
the updated utility and manpage.  However, if you maintain your 
own private distribution, please copy the following:
 
 BINARY: 
  sparc:  dunk:/sdet/export/sparc/opt/teamware/bin/codereview
  i386:   dunk:/sdet/export/i386/opt/SUNWspro/OSNet/bin/codereview
 
  sparc/i386:  dunk:/opt/teamware/OSNet/bin/cstyle 
               (minor bug fix in January)   
 
 MANPAGE::
  dunk:/sdet/export/sparc/opt/teamware/man/man1/codereview.1

janet

From janet@firenze  Mon May  1 12:32:34 1995
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA07289; Mon, 1 May 1995 12:32:34 -0700
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA04661; Mon, 1 May 1995 12:35:46 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id MAA05887; Mon, 1 May 1995 12:37:29 -0700
Received: by firenze.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA09442; Mon, 1 May 1995 12:34:42 -0700
Date: Mon, 1 May 1995 12:34:42 -0700
From: janet@firenze (Janet Timbol)
Message-Id: <9505011934.AA09442@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Updated cstyle
Cc: ns@morale, shannon@datsun, all-int@plunge, frits@jurassic, jek3@jurassic
X-Sun-Charset: US-ASCII
content-length: 564


A new version of 'cstyle' has been pushed to dunk.  This
version recognizes and ignores the contents of the new
style of source code annotation which has recently been
given ARC-approval.  For example:

   _NOTE(MUTEX_PROTECTS_DATA(mutex1, some_struct_tag::{a b c d e}))

(See /shared/sac/LSARC/1993/510/opinion.txt for details). 

If you mount teamware from dunk, you need not do anything to access
the updated cstyle.  However, if you maintain your own private
distribution, please copy this shell script from:

      dunk:/opt/teamware/OSNet/bin/cstyle

janet

From janet@firenze  Mon Jul 17 12:36:50 1995
Return-Path: <janet@firenze>
Received: from jurassic.Eng.Sun.COM (jurassic-50) by dunk.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA16574; Mon, 17 Jul 1995 12:36:50 -0700
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id MAA03309; Mon, 17 Jul 1995 12:40:39 -0700
Received: from firenze.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id MAA03744; Mon, 17 Jul 1995 12:43:08 -0700
Received: by firenze.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA20142; Mon, 17 Jul 1995 12:38:39 -0700
Date: Mon, 17 Jul 1995 12:38:39 -0700
From: janet@firenze (Janet Timbol)
Message-Id: <9507171938.AA20142@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Upate: rtitool config files
Cc: margotm@donald, janet@firenze, on494-mgrs@benet
X-Sun-Charset: US-ASCII
content-length: 1501

We have updated the rtitool configuration files on dunk to
integrate the following changes:
 
  o Add on495_PPC as a new "Target Release" field on the
    implementor template.
 
  o Add Craig Rolandelli as a new CRT advocate with the
    following areas of expertise:  boot ddi drivers PPC
 
  o Add PPC to the areas of expertise for Mike Sullivan
    and Joe Eykholt.
 
If you mount your teamware binaries from dunk, please reinvoke
'rtitool' to access the changes.   The previous version will be
*removed* within the next two hours to enforce the update.
 
However, if you maintain a private copy of the ON teamware distribution, 
you will need to:
 
1)  Update your copy of the ASCII configuration files from either 
    the sparc or x86 directory:
 
        sparc:
                dunk:/sdet/export/sparc/opt/teamware/Rtitool/lib/\
                     {advocates,rtitool}.config
        x86:
                dunk:/sdet/export/i386/opt/SUNWspro/Rtitool/lib/\
                     {advocates,rtitool}.config
 
2)  If you are unable to access /shared/ON remotely, please update 
    your copy of lib/rtitool.config file to replace '/shared/ON'
    with /net/wizard.Eng/export/consolidation/rtiroute

-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:
 
   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 

 
janet
 


From janet@jurassic  Tue Sep 19 17:17:26 1995
Return-Path: <janet@jurassic>
Received: from jurassic.Eng.Sun.COM by dunk.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA05820; Tue, 19 Sep 1995 17:17:26 -0700
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA00148; Tue, 19 Sep 1995 17:21:40 -0700
Received: from jurassic.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id RAA08504; Tue, 19 Sep 1995 17:24:40 -0700
Received: from firenze.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA00113; Tue, 19 Sep 1995 17:21:03 -0700
Received: by firenze.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA00737; Tue, 19 Sep 1995 17:20:59 -0700
Date: Tue, 19 Sep 1995 17:20:59 -0700
From: janet@jurassic (Janet Timbol)
Message-Id: <199509200020.RAA00737@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool config files
Cc: margotm@donald, janet@jurassic, on495-mgrs@benet
X-Sun-Charset: US-ASCII
content-length: 1580



We have updated the rtitool configuration files on dunk to
integrate the following changes:

  o Change on495_PPC to on596

  o Add David Brean (dbrean) as CRT advocate with 
    "sun4u pci" designation;

  o Add Greg Onufer (exodus) as CRT advocate with 
    "sun4m sun4u audio isdn" designation;

  o Add "sun4u" designation for Jerriann Meyer (jcm) and 
    John Johnson (jgj);

If you mount your teamware binaries from dunk, please reinvoke
'rtitool' to access the changes.   The previous version will be 
*removed* within the next two hours to enforce the update.

However, if you maintain a private copy of the ON teamware distribution, 
you will need to:

1)  Update your copy of the ASCII configuration files from either 
    the sparc, x86 or ppc directory:

        sparc:
                dunk:/sdet/export/sparc/opt/teamware/Rtitool/lib/\
		     {advocates,rtitool}.config
        x86:
                dunk:/sdet/export/i386/opt/SUNWspro/Rtitool/lib/\
		     {advocates,rtitool}.config

        ppc:
		dunk:/sdet/export/ppc/opt/teamware/Rtitool/lib\
			{advocates,rtitool}.config


2)  If you are unable to access /shared/ON remotely, please update 
    your copy of lib/rtitool.config file to replace '/shared/ON'
    with /net/wizard.Eng/export/consolidation/rtiroute 

-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:
 
   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
 
janet


From janet@jurassic  Tue Oct 17 15:05:45 1995
Return-Path: <janet@jurassic>
Received: from jurassic.Eng.Sun.COM by dunk.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA23941; Tue, 17 Oct 1995 15:05:45 -0700
Received: from stufff.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA04262; Tue, 17 Oct 1995 15:10:06 -0700
Received: from jurassic.Eng.Sun.COM by stufff.Eng.Sun.COM (8.6.9/SMI-SVR4)
	id PAA16464; Tue, 17 Oct 1995 15:13:48 -0700
Received: from firenze.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA04200; Tue, 17 Oct 1995 15:09:50 -0700
Received: by firenze.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id PAA05376; Tue, 17 Oct 1995 15:09:54 -0700
Date: Tue, 17 Oct 1995 15:09:54 -0700
From: janet@jurassic (Janet Timbol)
Message-Id: <199510172209.PAA05376@firenze.Eng.Sun.COM>
To: osnet-sde@stufff
Subject: Update: rtitool 2.4.3
Cc: april.chin@eng, margotm@donald, janet@jurassic, on494-mgrs@benet
X-Sun-Charset: US-ASCII
content-length: 2320


We have updated the rtitool files on dunk to include the changes 
outlined in the Release Notes attached to this mail message.

Please reinvoke 'rtitool' to access the changes.  The previous 
version will be *removed* within the next two hours to enforce 
the upgrade.

janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  However, if you maintain a private copy of 
the ON teamware distribution, you will need to:

1)  Copy ~ALL~ the files and symlinks from these directories:

        for sparc rtitool:

                dunk:/sdet/export/sparc/opt/teamware/Rtitool

        for x86   rtitool:

                dunk:/sdet/export/i386/opt/teamware/Rtitool

        for ppc   rtitool:

                dunk:/sdet/export/ppc/opt/teamware/Rtitool

2)  If you are unable to access /shared/ON remotely, update the 
    lib/rtitool.config file as follows:

        a) Replace

                /shared/ON
           with
                /net/wizard.Eng/export/consolidation/rtiroute 
 

*************************************************************************
Rtitool 2.4.3:  RELEASE NOTES  
(by Margot Miller October 17, 1995
*************************************************************************

'rtitool' binary:
================

   o Add PPC to the source base
   o Fix broken query mechanism for sparc and x86 
     (Note: Still does not work for PPC; bugtraq utilities currently 
            do not support it)

advocates.config:
================

   o ADD:
        Kevin.Clarke@eng performance library
        Kevin.Fox@eng vm tmpfs

rtitool.config:
===============

   o Patch Template:

      - Commit to Integrate:  Add on596
      - Releases to Patch:    Add on495: x86 and sparc

   o Change "mail to" alias to on-crt@lizard instead
     of on-crt@benet
 
   o Add new 2.4 RTI directory to be searched during query:
     /export/consolidation/rtiroute/archives/494rtis

help:
====

   o rtitool.general_help 
   o rtitool.info


From janet@jurassic  Mon Nov  6 11:08:54 1995
Return-Path: <janet@jurassic>
Received: from plunge.Eng.Sun.COM by dunk.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id LAA22863; Mon, 6 Nov 1995 11:08:53 -0800
Received: from jurassic.Eng.Sun.COM (jurassic-50) by plunge.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01663; Mon, 6 Nov 95 11:12:37 PST
Received: from firenze.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id LAA24438; Mon, 6 Nov 1995 11:12:22 -0800
Received: by firenze.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id LAA09478; Mon, 6 Nov 1995 11:11:12 -0800
Date: Mon, 6 Nov 1995 11:11:12 -0800
From: janet@jurassic (Janet Timbol)
Message-Id: <199511061911.LAA09478@firenze.Eng.Sun.COM>
To: osnet-sde@plunge
Subject: rtitool 2.5
Cc: april.chin@eng, margotm@donald, janet@jurassic, on495-mgrs@benet
X-Sun-Charset: US-ASCII
content-length: 2627



We have updated the rtitool files on dunk to accomodate concurrent
OS release development for on596 and on297.  To avoid compatibility 
problems, it is very important that all users reinvoke 'rtitool' ASAP
to access Rtitool Version 2.5.  The  previous version will be removed 
within the next two hours to enforce the upgrade.

Please see the attached release notes from April Chin for details.

janet


-----------------
Rtitool bugs/rfes:
-----------------
 
Please send comments, bugs, rfe's for rtitool using:

   The Help/Send feedback... menu button.  This puts you in
   a mailtool compose window which will automatically
   send your feedback to rtitool_2.x-comments@plunge.eng.
 
-----------------
Rtitool location:
-----------------
 
Rtitool is available automatically if you mount your teamware
binaries from dunk.  However, if you maintain a private copy of 
the ON teamware distribution, you will need to:

1)  Copy ~ALL~ the files and symlinks from these directories:

        for sparc rtitool:

                dunk:/sdet/export/sparc/opt/teamware/Rtitool

        for x86   rtitool:

                dunk:/sdet/export/i386/opt/teamware/Rtitool

        for ppc   rtitool:

                dunk:/sdet/export/ppc/opt/teamware/Rtitool

2)  If you are unable to access /shared/ON remotely, update the 
    lib/rtitool.config file as follows:

        a) Replace

                /shared/ON
           with
                /net/wizard.Eng/export/consolidation/rtiroute 
 

*************************************************************************
Rtitool 2.5:  RELEASE NOTES  
(by April Chin Nov 6, 1995)
*************************************************************************
 
'rtitool' binary:
================
 
  o RTI's will now be accepted for a release to integrate into.
    Formerly, they were accepted for a phase to integrate by.
    The CRT advocate now tells the implementor into which gate to
    integrate the change.
 
    All users will be required to switch over to the new rtitool because
    of this change.
 
advocates.config:
================
 
   o REMOVED:
        'postbeta' category from all advocates
        Craig Rolandelli boot ddi drivers PPC
        Joel Tornatore commands libraries standards
 
rtitool.config:
===============
 
   o Implementor template:
 
     - Target Release:  removed on495, added on297
 
   o Evaluator template:
 
     - Integrate into:  on596, on297
       replaces
       Phase: dev, prealpha, prebeta, prefcs
 
   o Patch Template:
 
      - Commit to Integrate:  Removed on495, added on297
 
help:
====
 
   o rtitool.general_help, rtitool.info
 


