Migrating from SunOS 4.1.3 to Solaris
		      jimc 940307, updated 941028

Most of the Mathnet machines (as of 941028) run SunOS 4.1.3, although
in the fairly near future they will all be converted to Solaris.  The
Scorpions (Bamboo, Deodar, Poplar, Laplace) and the new grad server
Sycamore (a dual processor 20/612) are now running Solaris v2.3.  Users who
have migrated to machines running Solaris have found relatively little
trauma; most of the differences are only visible to system administrators. 
Here are a few points to note:

1.  The executable and object files on SunOS 4.x have the "a.out" format,
whereas those on Solaris have ELF format.  Solaris can run 4.x executable
files in binary compatibility mode, and we have seen only two jobs fail to
execute properly (one system administration task, and the "inc" command
of Rand-MH, both of which depend on operating system details).  

2.  However, the Solaris linker cannot read a.out object files.  If you want
to recompile some of your program on Solaris, you will need to "make clean",
getting rid of all the a.out object files, and recompile everything on
Solaris to get ELF object files.  Here's a summary:

				     Execution on:
			Format	4.x		Solaris
4.x executable files	a.out	Can run		Can run
Solaris executables	ELF	No		Can run
4.x object files	a.out	Can link	Unreadable
Solaris object files	ELF	Unreadable	Can link

3.  Several popular software packages are not available yet for Solaris,
specifically Maple, Mathematica and NCARG.  Watch the MOTD's for a Solaris 
version of Maple.

4.  We are using the SparcCompiler 3.0 Multiprocessing Fortran Compiler.  It
is highly compatibile with the SC1.0 version in use on the 4.x machines, but
see the accompanying handouts for details of how to use the multiprocessing
features (Scorpions only).  Many of the comments in these handouts are
equally useful for non-multiprocessing programs.

5.  A number of system administration programs, such as "ps" and "df", have
non-equivalent copies in /usr/ucb and /usr/bin.  The UCB versions imitate
closely the behavior (4.2 BSD) you are used to from SunOS 4.x, whereas the
/usr/bin versions follow SysV R4 conventions, which are slightly but
annoyingly different.  The default path has /usr/ucb before /usr/bin.  If
you reverse this order you can get the SysV versions by default.  You can
also give the filename explicitly; /usr/bin/ps is the most useful. 
Unfortunately there is no "sps" for Solaris.

6.  Many programs are in different directories from 4.x.  The default path
gets them all.  If you need to adjust your path, it's best to supplement
the default path rather than replacing it completely.

7.  The "man" program is from SysV only.  To see man pages from a particular
section you must use the -s option, for example, "man -s 3f flush" to see
the page for the Fortran "flush" library subroutine.  Use "man -k keyword"
to search titles for a keyword, same as on 4.x.  

8.  The Solaris v2.3 job scheduler has been patched (940503), and while it
does not do exactly what the documentation says, it gives reasonable
results.  Jobs that run for a long time decline gradually in priority, so
that interactive jobs have priority even when the machine is very heavily
loaded.  After about 10 minutes a job's priority declines to zero, and the
zero priority jobs take turns on the available processors.

9.  The "nice" command works a lot differently on Solaris; positive "nice"
values are multiplied by 3 and subtracted from the job's priority determined
from interactive behavior.   Jobs are run in priority order, and lower
numbered jobs (higher nice) do not run until higher numbered jobs have
finished.  With the scheduling parameters we're using, interactive jobs
automatically get a high priority.  It is our intention on Solaris to adjust
scheduling classes automatically so that users will not need to use "nice". 
This mechanism is not perfect under the 2.3 scheduler but is sufficiently
operational that users can omit "nice" without guilt.  

10.  We have translated the Mathnet termcap to SysV-style terminfo.  A few
obscure terminal types had untranslatable information and had to be omitted.
One user was actually using one of these beasts...