# HPUnixHelp.txt -- HPUX-specific help for b600 project

# To get a serial port dialog to the wave controller:

	kermit -l /dev/tty0p0 -b 9600 -c
	
	There used to be a shell script for this...

# To get a serial dialog to the wave acquisition machine:

	telnet daq

	Yes, it has to be up and running or you get to rock
	the power switch and wait.
	
# To fiddle with the desktop menu application definitions, look in;

	/etc/dt/appconfig/types/C
	
	This directory is backed up in /home/mts/b600Proj/AppSys
	
# To mount an HPUX CD volume

	mount -t cdfs /dev/dsk/c1t2d0 mountPoint

# To extend or retract the size of the logical volumes

	HP-UX has a scheme to make virtual partitions out
	of pieces taken from many disk drives. The 'pieces'
	are called physical extents. The virtual partitions
	are called logical volumes. The software agent that
	manages all this is called the logical volume manager.
	
	Before any logical volumes are created, a bunch of
	disk drives must be turned over to the logical volume
	manager with a specification of the physical extent size.
	The physical extent size is the quantum of disk space used
	for all logical and physical volume operations.
	A named group of physical volumes is called a logical volume
	group. Logical volume groups have directory entries in the
	file system: e.g. /dev/vg00  "Logical volume group 00".
	The vg00 look like a directory that contains all the logcial
	volumes in the group.
	
	A logical volume is created by specifying a size and a
	logical volume group. A file system can then be created
	(mkfs) and the volume mounted (mount) on any mount point.
	(Just like the old-fashioned partitions.)
	Logical volumes also have device entries in the file system:
	/dev/vg00/lvol1 
	"Logical volume on on volume group 00".
	
	Our HP-UX system has one disk drive which is the only
	member of one logical volume group. Someone has created
	eight logical volumes out of this group. Here are the
	file system entries for the 'devices' and the assigned
	mount points:
		
		/dev/vg00/lvol1		/stand (The boot kernel)
		/dev/vg00/lvol2		Swap space (256 blocks)	
		/dev/vg00/lvol3		/
		/dev/vg00/lvol4		/tmp
		/dev/vg00/lvol5		/home
		/dev/vg00/lvol6		/opt
		/dev/vg00/lvol7		/usr
		/dev/vg00/lvol8		/var
		
	You can grow or shrink logical volumes like this:
	
		lvextend -L <newSize> <logicalVolumeName>
		lvreduce -L <newSize> <logicalVolumeName>
		
	Extending the logical volume DOES NOT increase the size known to
	the file system on that volume. You have to do this with the appropriate
	tool. For the normal HP-UX file system this is done with extendfs:
	
		extendfs <logicalVolumeName>
		
	You do not have to unmount a volume to increate the raw size, but you
	do have to unmount a volume to perform the extendfs operation.
	
	In general, it is not possible to lvreduce a volume without destroying
	the file system structures.
	
	You cannot unmount a volume if any processes are using it.
	
	An example: To increase the size of the logical volume mounted on /home:
	
	First use df to see what logical volume is used by /home.
	
		/dev/vg00/lvol5
		
	Next, extend the size of the logical volume:
	
		lvextend -L 1000 /dev/vg00/lvol5
		
	This will make the size 1000 Mb. Actually, the size will be rounded
	off to an integral number of logical extents. The logical extent size
	for vg00 is 4Mb.
	
	Now you have to unmount /home and resize the file system on the volume
	so it knows about the extra space.
	
	Find out which processes have ahold of /home:
	
		fuser -c
		
	This will list one or more processes.
	Logout of everything you can and go to single user mode on the HP.
	
		init S
		
	Now unmount
	
		umount /home
		
	Resize the file system to fill up the space:
	
		extendfs /dev/vg00/lvol5
		
	Remount /home
	
		mount /home
		
	Go back to multiuser mode:
	
		init 5
	
		

# Using the tape drive: 
	
	There are pitfalls to working with tar archives
	that can cause the existing files on the machine
	to be lost or replaced with outdated versions.
	Please take some time to understand how tar works
	with absolute and relative file names, etc. before
	you play around with the tape drive.

	If you are familiar with tar archives to files, just
	use the tape device name where you would use a .tar
	file in the command line:  

		/dev/rmt/0m

	What a great name for a tape drive. Brad must have 
	worked for HP...

	Examples: Backing up all of the mts home directory:

		cd /home/
		tar cf /dev/rmt/0m ./mts

		In general it is a good idea not to use
		absolute path names when makeing an archive
		because this makes it harder to extract 
		the archive later to another place.

	Example: Restoring a backup

		cd somewhere
		tar xf /dev/rmt/0m 

		If you are extracting the /home/mts backup
		created in the previous example, be carefull
		not to do this in the /home directory unless
		you want to modify the existing files.
	
	Example: Listing a tape on stdout:

		tar tf /dev/rmt/0m


	Example: Extracting just one file from a tape

		tar xf /dev/rmt/0m ./mts/b600Proj/unixStartup.alt

		Note that you extract by specifying the path
		just like it appeared in the archive listing.
		When extracting from an archive	

Dealing with X server problems

	The server configuration file (normally maintained by SAM)
	may be edited by hand. After making changes, you must restart
	the X server to see the effect. We have only one "0" screen:

		/etc/X11/X0screens
	
	A complete detailed useless discussion about this file and
	other server configuration issues is located in:

		/usr/lib/X11/Xserver/info/screens/hp

	The color problem that causes our windows to show random
	colors seems to come about when XAllocColor in Alltalk 
	fails. This procedure returns the X pixel value for
	a specified RGB value in a colormap. Alltalk uses
	the default, supposedly read-only colormap associated
	with the default screen. After many hours, the call
	to XAllocColor fails and continues to fail whenever
	colors are requested. The result is a random pixel
	value which produces the weird effects we observe.

	When using a TrueColor visual, XAllocColor is supposed
	to return the best match in the colortable. As a result,
	it should never run out of color table entries and
	XAllocColor should never fail.

	When using a PseudoColor visual, XAllocColor will fail
	if an exact match cannot be allocated or found. 

	Questions: Is the default colormap for the default
	screen in fact a read-only color map? Are we getting
	a TrueColor visual? (xdpyinfo says we are...)
 


