--- old/usr/src/tools/scripts/ws.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,444 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License, Version 1.0 only
-.\" " (the "License").  You may not use this file except in compliance
-.\" " with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright 2004 Sun Microsystems, Inc."
-.\" "All rights reserved"
-.\" "Use is subject to license terms."
-.TH WS 1 "28 January 1992"
-.SH NAME
-.I ws 
-\- enable SunOS avocet environments
-.SH SYNOPSIS
-.B ws
-[-e] [workspace_name]
-.LP
-.SH DESCRIPTION
-.IX "Avocet" "ws" "" "\fBws\fP"
-.LP
-.I Ws 
-will configure your environment to build the SunOS
-source base from an
-.I avocet
-workspace.  The
-.I ws
-script sets up the environment variables for a SunOS avocet
-workspace and spawns a shell for the environment 
-that has been setup.  In configuring the environment
-.I ws
-sets up the environment variables to define in which proto areas
-you will build against as well as the proto area the will be your
-install target.
-.LP
-The following Environment variables are set when you invoke this script:
-.LP
-.RS 5
-.nf
-CODEMGR_WS
-SRC
-ROOT
-PARENT_ROOT
-PATH
-MAKEFLAGS
-ENVCPPFLAGS{1-4}
-ENVLDLIBS{1-3}
-.fi
-.RE
-.LP
-The MAKEFLAGS environment variable is set to force make to
-read default make variables from the environment.
-.LP
-The ENVCPPFLAGS{1-4} and the ENVLDLIBS{1-3} environment variables
-are used to configure a hierarchy of proto areas to be used
-when compiling and linking in the SunOS environment.
-The values for these environment variables will be set according to
-your values for PROTO1, PROTO2, and PROTO3 variables(discussed below).
-.LP
-Workspace names can be specified in two forms:  pathname and
-hostname:pathname.  If the hostname:pathname form is used
-the script will access the environment through the /net automounter
-maps.  If <workspace> is is a relative pathname not found
-in the current directory, check for it in those
-directories listed in the CODEMGR_WSPATH variable (refer to the
-workspace(1) man page for more info on CODEMGR_WSPATH).  
-.LP
-Note that if a workspace argument is not given ws will try to determine
-if the current directory is in a workspace and set the environment for
-that workspace.
-.LP
-.I ws
-will also check for the presense of the ONBLD construction set 
-(/opt/onbld), if it is found it will prepend the 
-ONBLD construction set directory to the front of your PATH.
-If you set your path in your shell
-start-up file (eg: .cshrc) then that will undo what what
-.I ws
-has done.  If you do this in your shell start-up script,
-conditionally protect
-.I ws 
-from your modification with something like this:
-.LP
-.RS 5
-.nf
-if ( ! $?ONBLD_DIR  ) then
-   set path=( ~/bin $path )	# or however you wish to modify path
-endif
-.fi
-.RE
-.LP
-NOTE: this is a csh example, the code would vary with the shell type.
-.LP
-.SH OPTIONS
-.LP
-.TP
-.B \-e
-prevent ws from calling exit or exec, useful for setting environment in
-another Bourne (sh) compatible shell (hint: source ws -e)
-.LP
-.SH USAGE
-.LP
-At start-up time 
-.I ws 
-will determine the number of proto areas to
-be searched and in what order.  This information is configured
-during the first invocation of 
-.I ws
-for each workspace in the protodefs
-file.  This file is located under the avocet directory
-in your workspace:
-.LP
-.RS 5
-.nf
-$CODEMGR_WS/avocet/sunos/protodefs
-.fi
-.RE
-.LP
-In this file you may configure from one to four proto 
-variables (PROTO1, PROTO2, PROTO3, TERMPROTO).  
-These variables define the order in
-which the proto areas will be searched, starting with the PROTO1
-directory and ending in the PROTO3 directory.  
-.LP
-When you define the PROTO hierarchy you are defining a list of proto
-directories in which to search for header files and libraries during
-a build. Refer to the
-Examples section below on how you might configure these PROTO
-definitions.
-.LP
-Also, your initial value for ROOT will be assigned to PROTO1.  This
-means that if you do any install builds in the SunOS source tree;
-they will install in the proto area pointed to by PROTO1. 
-.LP
-The format for the protodefs file is very simple, it follows the
-shell script formats for assigning variables.  Here is an 
-example of some definitions
-you might find in a protodefs file:
-.LP
-.RS 5
-.nf
-PROTO1=$CODEMGR_WS/proto
-PROTO2=/parents_path/proto
-.fi
-.RE
-.LP
-The above example would specify 
-that the current workspaces proto area is
-to be searched first, and then the parent workspace's proto area will be
-searched for included files and libraries.  In that order.
-.LP
-The TERMPROTO variable is a special case from PROTO{1-3}, it is
-used to specify a terminating search path for your compiling
-and linking.  If you specify a TERMPROTO directory then during 
-your compile and link your search path for libraries and include
-files will terminate there.  If you do not specify the
-TERMPROTO variable, then the terminating point for searches will
-be on the native machine. On a 5.x machine this will be /usr/include
-and /usr/lib.
-.LP
-The default values for PROTO1 and PROTO2 will be set by
-.I ws
-initially to point to your current workspaces proto area and 
-the proto area
-of the workspace's parent, if the parent is an Avocet
-workspace.  
-.LP
-The PROTO{1-3} variables will then be used to set your ROOT variable and
-to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
-These will be set to an architecture specific directory under
-each PROTO* directory.  If, for example, PROTO1 had been set
-to PROTO1=/ws/train/proto then ROOT would be set to 
-ROOT=/ws/train/proto/root_${MACH}.  MACH would be equal to the
-architecture of the machine you are running on (ie: `uname -p`).
-.LP
-The exception to this is if there is already an existing non-architecture
-specific populated proto area 
-under one of the PROTO{1-3} variables.  If this is the case then the
-ROOT and other flags will be based on that instead of an architecture
-specific sub-directory.
-.LP
-.SH ISSUES
-.LP
-The use of Constrained Files is very different between an NSE
-environment and an avocet workspace.  Constrained files are files which
-are derived but files that you do not have source code for.  For
-example in an NSE environment, a library would be a constrained file if
-you acquired a command that depended on that library but you did not
-acquire the library's sources.  If a user is used to working in an NSE
-environment they should be aware of the differences.
-.LP
-In an NSE environment the user was isolated from updates to both
-constrained files and source files
-alike in the parent environment.  You did not see updates
-to constrained files until you 
-.I resynced 
-a command or object which depended on the
-constrained file in question.  
-This is no longer the case under Avocet.  
-.LP
-If you are using
-.I ws
-to refer to a copy of such a library located in your parent
-workspace's proto area, you are no longer isolated as you were use
-the NSE.
-If your parent updates its copy of the constrained file(libc.so)
-in it's proto area and you are referencing the parents
-proto area via ws, then
-that update is immediately visible to you.  The next time you
-build a new command in your avocet workspace you will be building
-against the new copy of the constrained file(libc.so) which you
-obtain from your parents proto area, you are no longer isolated from
-these updates as you were in the NSE.
-.LP
-If you would like to be isolated from updates in the
-world around you there are a couple of approaches you can take.  First,
-if you bringover a full copy of the SunOS source base you could
-build your own PROTO area which you would link against.  
-Secondly, you could link against a private
-PROTO area which is a stable snapshot of a global proto area.
-This proto area could be a subset
-of a full proto area and contain only those files which you are concerned
-about.  Both of these methods would protect you from updates to files
-because you would be in full control of the proto areas you are linking
-against.  It would be your responsiblity to update your proto area
-as your work progressed.
-.LP
-.SH EXAMPLES
-.LP
-In the following examples you will modify the 
-${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
-to configure a proto hierarchy to be associated with your
-avocet workspace.  I have selected the four
-most common examples that will be used with avocet workspaces,
-there can be many other combinations.
-.LP
-In the first example we will 
-configure a workspace named 
-caltrans:/bld/child,
-and it is a child of an avocet workspace named dunk:/build/parent.  The
-parent workspace (dunk:/build/parent)
-is a complete copy of the usr/src source tree, while the
-current workspace(caltrans:/bld/child) is a subset of the full
-source base.  The current(child) workspace only contains the usr/src/cmd 
-directories.  The proto areas that
-we want to search are the current workspaces proto area(/bld/child/proto)
-and then the proto area of the parent(/net/dunk/build/parent/proto), in that
-order.  
-Actually, this example is the default behavior if the workspace
-is not a child of an NSE parent.  No modification would actually have
-to have been done to the protodefs file.
-Here is what the protodefs file would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/bld/scrapbook/proto
-PROTO2=/net/dunk/build/ws/proto
-.fi
-.RE
-.LP
-This example represents a model where the current workspaces needs
-to reference a superset of its own proto area in order to build.
-.LP
-Secondly, let us consider a workspace you have named 
-polyslo:/charlie/tuna.  Your
-workspace only contains the source code for the usr/src/cmd
-directories.  Secondly, your avocet parent(dunk:/build/popeye) is not a 
-full copy of
-the source base, but it does have some files in the proto area which
-you want to refer to.  Lastly, you have a global proto area which you
-will refer to if you have not found a header file or library in either
-of the two previous proto areas, this global proto area is located
-at rainman:/space/I-team-protoarea.  Here is what your protodefs file
-would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/charlie/tuna/proto
-PROTO2=/net/dunk/build/popeye/proto
-PROTO3=/net/rainman/space/I-team-protoarea
-.fi 
-.RE
-.LP
-The above model is meant to show you some of the configurability that can
-be done
-.I ws.
-Here you have three proto areas that are searched one after the other.  You
-might configure an environment like this if needed to refer to some
-files that are in the PROTO2 area, but these files are not 
-easily placed into the 'global' I-Team proto area of PROTO3.  It should
-also be noted that there is a performance penalty for such a configuration.
-During each compile the compiler is now potentially searching through
-three directory structures to resolve the include files, this will slow
-things down.  If performance is critical you should also be aware
-of which 'subnets' the PROTO areas are located on.  The farther away
-the PROTO area is from the 'subnet' you are building on the greater
-the performance hit during compiles.
-.LP
-Next, here is a very simple example.  We have a workspace which is a small
-subset of the usr/src/cmd directory named(caltrans:/build/small_cmd) that
-has no proto area associated with it.  For our proto area we will refer
-to a Global 'I-Team' proto area for all of our files.  This area is
-located at rainman:/space/global_proto_area.  In the protodefs file
-we will only need to define PROTO1 for this example:
-.RS 5
-.nf 
-PROTO1=/net/rainman/space/global_proto_area
-.fi
-.RE
-.LP
-This is the example you would follow for very small workspaces
-with which you do not intend to modify and install any headers
-or libraries.  All of the
-include files and libraries will be pulled from the I-TEAM proto area.
-The advantage to this model is speed, there is only one area in which
-the compiler is going to search for include files and libraries, this
-will help the compilers performance.  Also, you should be aware that 
-ROOT is equal to PROTO1.  If you attempt to do an install build it
-will attempt to modify the I-Team proto area that you are pointing at!
-.LP
-Lastly, we have an avocet workspace named 
-caltrans:/bld/nse_child which is the child of an NSE environment.  
-Because the parent of the workspace is an NSE environment, that parent
-does not have a PROTO area associated with it that we can 
-refer to.  Instead there is a global PROTO area that is maintained
-by our 'I-Team' leader that we will refer to.  That global area
-is located at rainman:/space/I-team-protoarea.  Here is what
-the protodefs file would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/bld/nse_child
-PROTO2=/net/rainman/space/I-team-protoarea
-.fi
-.RE
-.LP
-This model differs from the one above in that we can not reference
-the parents proto area because the parent in an NSE environment.  
-Instead for our second proto area we point to a stable proto
-area outside of the NSE.
-.LP
-.SH ENVIRONMENT VARIABLES
-.LP
-Here is a list of the environment variables that 
-.I ws
-will set and how they are used:
-.LP
-CODEMGR_WS         
-.fi
-.RS 5
-Absolute pathname to the Avocet workspace.  This environment variable
-is referenced by the
-.I bringover
-,
-.I putback
-,
-and
-.I workspace
-commands.
-.RE
-SRC
-.RS 5
-Root of SunOS source code, referenced by SunOS Makefiles.
-.RE
-ROOT
-.RS 5
-Initial proto area for this workspace.  Again this is used by the 
-SunOS Makefiles.  This value is set based on PROTO1 as defined in
-the protodefs file.  ROOT is also the destination of 
-.I install 
-operations.
-.RE
-PARENT_ROOT
-.RS 5
-Parent proto area for this workspace.  This is used by the 
-SunOS Makefiles.  This value is set based on PROTO2 as defined in
-the protodefs file. 
-.RE
-PATH
-.RS 5
-If the construction set exists (/opt/onbld) it will  be prepended to 
-the search path.
-.RE
-MAKEFLAGS
-.RS 5
-Default MAKEFLAGS used by 
-.I make,
-set to 'e' for higher environment precedence.
-.RE
-ENVCPPFLAGS{1-4}
-.RS 5
-This set of environment variables is used to set the 
-CPPFLAGS.master macro within the SunOS source tree.  These values
-usually point to a hierarchy of Include directories for the build
-to search through.
-.RE
-ENVLDLIBS{1-3}
-.RS 5
-This set of environment variables is used to set the LDLIBS.master
-macro within the SunOS source tree.  These values usually point
-to a hierarchy of directories to search for libraries.
-.RE
-.LP
-.SH FILES
-.LP
-.nf
-$CODEMGR_WS/avocet/sunos/protodefs
-.fi
-.LP
-.SH "SEE ALSO"
-.LP
-.IR workspace (1),
-.IR bringover (1),
-.IR putback (1),
-.IR protodefs(5)
-.LP
-.SH BUGS
-.LP
-TERMPROTO is broken.
-On 5.x builds TERMPROTO is incompatible with the C++ driver.  The bug
-is that the C++ driver does not use the standard SVR4 notation
-for the -Y I, option.
-.LP
-.I ws
-can have problems with the automounter.  If you refer to a workspace
-using a relative path, and that workspace is mounted via the automounter, 
-then that workspace will be refered to via the /tmp_mnt/*
-location.  It's best to deal with automounted workspaces through
-an absolute pathname when running
-.I ws.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/ws.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,443 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License, Version 1.0 only
+.\" " (the "License").  You may not use this file except in compliance
+.\" " with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright 2004 Sun Microsystems, Inc."
+.\" "All rights reserved"
+.\" "Use is subject to license terms."
+.TH WS 1ONBLD "28 January 1992"
+.SH NAME
+.I ws 
+\- enable SunOS avocet environments
+.SH SYNOPSIS
+.B ws
+[-e] [workspace_name]
+.LP
+.SH DESCRIPTION
+.IX "Avocet" "ws" "" "\fBws\fP"
+.LP
+.I Ws 
+will configure your environment to build the SunOS
+source base from an
+.I avocet
+workspace.  The
+.I ws
+script sets up the environment variables for a SunOS avocet
+workspace and spawns a shell for the environment 
+that has been setup.  In configuring the environment
+.I ws
+sets up the environment variables to define in which proto areas
+you will build against as well as the proto area the will be your
+install target.
+.LP
+The following Environment variables are set when you invoke this script:
+.LP
+.RS 5
+.nf
+CODEMGR_WS
+SRC
+ROOT
+PARENT_ROOT
+PATH
+MAKEFLAGS
+ENVCPPFLAGS{1-4}
+ENVLDLIBS{1-3}
+.fi
+.RE
+.LP
+The MAKEFLAGS environment variable is set to force make to
+read default make variables from the environment.
+.LP
+The ENVCPPFLAGS{1-4} and the ENVLDLIBS{1-3} environment variables
+are used to configure a hierarchy of proto areas to be used
+when compiling and linking in the SunOS environment.
+The values for these environment variables will be set according to
+your values for PROTO1, PROTO2, and PROTO3 variables(discussed below).
+.LP
+Workspace names can be specified in two forms:  pathname and
+hostname:pathname.  If the hostname:pathname form is used
+the script will access the environment through the /net automounter
+maps.  If <workspace> is is a relative pathname not found
+in the current directory, check for it in those
+directories listed in the CODEMGR_WSPATH variable (refer to the
+workspace(1) man page for more info on CODEMGR_WSPATH).  
+.LP
+Note that if a workspace argument is not given ws will try to determine
+if the current directory is in a workspace and set the environment for
+that workspace.
+.LP
+.I ws
+will also check for the presense of the ONBLD construction set 
+(/opt/onbld), if it is found it will prepend the 
+ONBLD construction set directory to the front of your PATH.
+If you set your path in your shell
+start-up file (eg: .cshrc) then that will undo what what
+.I ws
+has done.  If you do this in your shell start-up script,
+conditionally protect
+.I ws 
+from your modification with something like this:
+.LP
+.RS 5
+.nf
+if ( ! $?ONBLD_DIR  ) then
+   set path=( ~/bin $path )	# or however you wish to modify path
+endif
+.fi
+.RE
+.LP
+NOTE: this is a csh example, the code would vary with the shell type.
+.LP
+.SH OPTIONS
+.LP
+.TP
+.B \-e
+prevent ws from calling exit or exec, useful for setting environment in
+another Bourne (sh) compatible shell (hint: source ws -e)
+.LP
+.SH USAGE
+.LP
+At start-up time 
+.I ws 
+will determine the number of proto areas to
+be searched and in what order.  This information is configured
+during the first invocation of 
+.I ws
+for each workspace in the protodefs
+file.  This file is located under the avocet directory
+in your workspace:
+.LP
+.RS 5
+.nf
+$CODEMGR_WS/avocet/sunos/protodefs
+.fi
+.RE
+.LP
+In this file you may configure from one to four proto 
+variables (PROTO1, PROTO2, PROTO3, TERMPROTO).  
+These variables define the order in
+which the proto areas will be searched, starting with the PROTO1
+directory and ending in the PROTO3 directory.  
+.LP
+When you define the PROTO hierarchy you are defining a list of proto
+directories in which to search for header files and libraries during
+a build. Refer to the
+Examples section below on how you might configure these PROTO
+definitions.
+.LP
+Also, your initial value for ROOT will be assigned to PROTO1.  This
+means that if you do any install builds in the SunOS source tree;
+they will install in the proto area pointed to by PROTO1. 
+.LP
+The format for the protodefs file is very simple, it follows the
+shell script formats for assigning variables.  Here is an 
+example of some definitions
+you might find in a protodefs file:
+.LP
+.RS 5
+.nf
+PROTO1=$CODEMGR_WS/proto
+PROTO2=/parents_path/proto
+.fi
+.RE
+.LP
+The above example would specify 
+that the current workspaces proto area is
+to be searched first, and then the parent workspace's proto area will be
+searched for included files and libraries.  In that order.
+.LP
+The TERMPROTO variable is a special case from PROTO{1-3}, it is
+used to specify a terminating search path for your compiling
+and linking.  If you specify a TERMPROTO directory then during 
+your compile and link your search path for libraries and include
+files will terminate there.  If you do not specify the
+TERMPROTO variable, then the terminating point for searches will
+be on the native machine. On a 5.x machine this will be /usr/include
+and /usr/lib.
+.LP
+The default values for PROTO1 and PROTO2 will be set by
+.I ws
+initially to point to your current workspaces proto area and 
+the proto area
+of the workspace's parent, if the parent is an Avocet
+workspace.  
+.LP
+The PROTO{1-3} variables will then be used to set your ROOT variable and
+to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
+These will be set to an architecture specific directory under
+each PROTO* directory.  If, for example, PROTO1 had been set
+to PROTO1=/ws/train/proto then ROOT would be set to 
+ROOT=/ws/train/proto/root_${MACH}.  MACH would be equal to the
+architecture of the machine you are running on (ie: `uname -p`).
+.LP
+The exception to this is if there is already an existing non-architecture
+specific populated proto area 
+under one of the PROTO{1-3} variables.  If this is the case then the
+ROOT and other flags will be based on that instead of an architecture
+specific sub-directory.
+.LP
+.SH ISSUES
+.LP
+The use of Constrained Files is very different between an NSE
+environment and an avocet workspace.  Constrained files are files which
+are derived but files that you do not have source code for.  For
+example in an NSE environment, a library would be a constrained file if
+you acquired a command that depended on that library but you did not
+acquire the library's sources.  If a user is used to working in an NSE
+environment they should be aware of the differences.
+.LP
+In an NSE environment the user was isolated from updates to both
+constrained files and source files
+alike in the parent environment.  You did not see updates
+to constrained files until you 
+.I resynced 
+a command or object which depended on the
+constrained file in question.  
+This is no longer the case under Avocet.  
+.LP
+If you are using
+.I ws
+to refer to a copy of such a library located in your parent
+workspace's proto area, you are no longer isolated as you were use
+the NSE.
+If your parent updates its copy of the constrained file(libc.so)
+in it's proto area and you are referencing the parents
+proto area via ws, then
+that update is immediately visible to you.  The next time you
+build a new command in your avocet workspace you will be building
+against the new copy of the constrained file(libc.so) which you
+obtain from your parents proto area, you are no longer isolated from
+these updates as you were in the NSE.
+.LP
+If you would like to be isolated from updates in the
+world around you there are a couple of approaches you can take.  First,
+if you bringover a full copy of the SunOS source base you could
+build your own PROTO area which you would link against.  
+Secondly, you could link against a private
+PROTO area which is a stable snapshot of a global proto area.
+This proto area could be a subset
+of a full proto area and contain only those files which you are concerned
+about.  Both of these methods would protect you from updates to files
+because you would be in full control of the proto areas you are linking
+against.  It would be your responsiblity to update your proto area
+as your work progressed.
+.LP
+.SH EXAMPLES
+.LP
+In the following examples you will modify the 
+${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
+to configure a proto hierarchy to be associated with your
+avocet workspace.  I have selected the four
+most common examples that will be used with avocet workspaces,
+there can be many other combinations.
+.LP
+In the first example we will 
+configure a workspace named 
+caltrans:/bld/child,
+and it is a child of an avocet workspace named dunk:/build/parent.  The
+parent workspace (dunk:/build/parent)
+is a complete copy of the usr/src source tree, while the
+current workspace(caltrans:/bld/child) is a subset of the full
+source base.  The current(child) workspace only contains the usr/src/cmd 
+directories.  The proto areas that
+we want to search are the current workspaces proto area(/bld/child/proto)
+and then the proto area of the parent(/net/dunk/build/parent/proto), in that
+order.  
+Actually, this example is the default behavior if the workspace
+is not a child of an NSE parent.  No modification would actually have
+to have been done to the protodefs file.
+Here is what the protodefs file would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/bld/scrapbook/proto
+PROTO2=/net/dunk/build/ws/proto
+.fi
+.RE
+.LP
+This example represents a model where the current workspaces needs
+to reference a superset of its own proto area in order to build.
+.LP
+Secondly, let us consider a workspace you have named 
+polyslo:/charlie/tuna.  Your
+workspace only contains the source code for the usr/src/cmd
+directories.  Secondly, your avocet parent(dunk:/build/popeye) is not a 
+full copy of
+the source base, but it does have some files in the proto area which
+you want to refer to.  Lastly, you have a global proto area which you
+will refer to if you have not found a header file or library in either
+of the two previous proto areas, this global proto area is located
+at rainman:/space/I-team-protoarea.  Here is what your protodefs file
+would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/charlie/tuna/proto
+PROTO2=/net/dunk/build/popeye/proto
+PROTO3=/net/rainman/space/I-team-protoarea
+.fi 
+.RE
+.LP
+The above model is meant to show you some of the configurability that can
+be done
+.I ws.
+Here you have three proto areas that are searched one after the other.  You
+might configure an environment like this if needed to refer to some
+files that are in the PROTO2 area, but these files are not 
+easily placed into the 'global' I-Team proto area of PROTO3.  It should
+also be noted that there is a performance penalty for such a configuration.
+During each compile the compiler is now potentially searching through
+three directory structures to resolve the include files, this will slow
+things down.  If performance is critical you should also be aware
+of which 'subnets' the PROTO areas are located on.  The farther away
+the PROTO area is from the 'subnet' you are building on the greater
+the performance hit during compiles.
+.LP
+Next, here is a very simple example.  We have a workspace which is a small
+subset of the usr/src/cmd directory named(caltrans:/build/small_cmd) that
+has no proto area associated with it.  For our proto area we will refer
+to a Global 'I-Team' proto area for all of our files.  This area is
+located at rainman:/space/global_proto_area.  In the protodefs file
+we will only need to define PROTO1 for this example:
+.RS 5
+.nf 
+PROTO1=/net/rainman/space/global_proto_area
+.fi
+.RE
+.LP
+This is the example you would follow for very small workspaces
+with which you do not intend to modify and install any headers
+or libraries.  All of the
+include files and libraries will be pulled from the I-TEAM proto area.
+The advantage to this model is speed, there is only one area in which
+the compiler is going to search for include files and libraries, this
+will help the compilers performance.  Also, you should be aware that 
+ROOT is equal to PROTO1.  If you attempt to do an install build it
+will attempt to modify the I-Team proto area that you are pointing at!
+.LP
+Lastly, we have an avocet workspace named 
+caltrans:/bld/nse_child which is the child of an NSE environment.  
+Because the parent of the workspace is an NSE environment, that parent
+does not have a PROTO area associated with it that we can 
+refer to.  Instead there is a global PROTO area that is maintained
+by our 'I-Team' leader that we will refer to.  That global area
+is located at rainman:/space/I-team-protoarea.  Here is what
+the protodefs file would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/bld/nse_child
+PROTO2=/net/rainman/space/I-team-protoarea
+.fi
+.RE
+.LP
+This model differs from the one above in that we can not reference
+the parents proto area because the parent in an NSE environment.  
+Instead for our second proto area we point to a stable proto
+area outside of the NSE.
+.LP
+.SH ENVIRONMENT VARIABLES
+.LP
+Here is a list of the environment variables that 
+.I ws
+will set and how they are used:
+.LP
+CODEMGR_WS         
+.fi
+.RS 5
+Absolute pathname to the Avocet workspace.  This environment variable
+is referenced by the
+.I bringover
+,
+.I putback
+,
+and
+.I workspace
+commands.
+.RE
+SRC
+.RS 5
+Root of SunOS source code, referenced by SunOS Makefiles.
+.RE
+ROOT
+.RS 5
+Initial proto area for this workspace.  Again this is used by the 
+SunOS Makefiles.  This value is set based on PROTO1 as defined in
+the protodefs file.  ROOT is also the destination of 
+.I install 
+operations.
+.RE
+PARENT_ROOT
+.RS 5
+Parent proto area for this workspace.  This is used by the 
+SunOS Makefiles.  This value is set based on PROTO2 as defined in
+the protodefs file. 
+.RE
+PATH
+.RS 5
+If the construction set exists (/opt/onbld) it will  be prepended to 
+the search path.
+.RE
+MAKEFLAGS
+.RS 5
+Default MAKEFLAGS used by 
+.I make,
+set to 'e' for higher environment precedence.
+.RE
+ENVCPPFLAGS{1-4}
+.RS 5
+This set of environment variables is used to set the 
+CPPFLAGS.master macro within the SunOS source tree.  These values
+usually point to a hierarchy of Include directories for the build
+to search through.
+.RE
+ENVLDLIBS{1-3}
+.RS 5
+This set of environment variables is used to set the LDLIBS.master
+macro within the SunOS source tree.  These values usually point
+to a hierarchy of directories to search for libraries.
+.RE
+.LP
+.SH FILES
+.LP
+.nf
+$CODEMGR_WS/avocet/sunos/protodefs
+.fi
+.LP
+.SH "SEE ALSO"
+.LP
+.IR workspace (1),
+.IR bringover (1ONBLD),
+.IR putback (1),
+.IR protodefs(5)
+.LP
+.SH BUGS
+.LP
+TERMPROTO is broken.
+On 5.x builds TERMPROTO is incompatible with the C++ driver.  The bug
+is that the C++ driver does not use the standard SVR4 notation
+for the -Y I, option.
+.LP
+.I ws
+can have problems with the automounter.  If you refer to a workspace
+using a relative path, and that workspace is mounted via the automounter, 
+then that workspace will be refered to via the /tmp_mnt/*
+location.  It's best to deal with automounted workspaces through
+an absolute pathname when running
+.I ws.
