sar and sag broken (sadc) as well as a 630

[Jim Webb]

Re:  sar and sag have mysteriously broken on my AT&T 3B2/700.

My first inclination would be to check the crontab entries.
What should be going on is the running of /usr/lib/sa/sa1 every
so often.  It is a shell script that calls sadc.  Here, they
look like:

/usr/spool/cron/crontabs/sys:0 * * * 0,6        /usr/lib/sa/sa1
/usr/spool/cron/crontabs/sys:0 8-17 * * 1-5     /usr/lib/sa/sa1 1200 3 &
/usr/spool/cron/crontabs/sys:0 18-7 * * 1-5     /usr/lib/sa/sa1 &

They are not all that mysterious, the most important one is the
second, which means to data collect for 20 minutes (1200 seconds)
3 times.  This is done during prime time (8-5 each weekday).  These
are probably not what is shipped with the floppies, we don't run a
stock shop here.

If they look alright, then the next place to look is in a file
called /tmp/sa.adrfl.  This is the sadc address file.  When sadc
starts up, it creates this file and puts the various memory addresses
it needs in it.  This way, it does not need to do a namesearch on /unix
each time.  Saves time, sort of like ps and /etc/ps_data.  Anyway, if
for whatever reason, this file is corrupted, sadc won't work.  It
will just do nothing :-)  So, remove this file and try again.  One
easy way to test it at this point is to say "sar 2 4" which will give
you a 2 second snapshot of the system 4 times.

As for documentation for sadc:

        sadc.c - writes system activity binary data from /dev/kmem to a
                file or stdout.
        Usage: sadc [t n] [file]
                if t and n are not specified, it writes
                a dummy record to data file. This usage is
                particularly used at system booting.
                If t and n are specified, it writes system data n times to
                file every t seconds.
                In both cases, if file is not specified, it writes
                data to stdout.

Hope this helps out with that question!

Re:  layers hangs my terminal

| I'm running layers on an AT&T 3B2, with Sys V R3.2.1, and an AT&T 630 tty.
| I'm pretty pleased, but there is this problem...

Well, I like the one I am typing on a lot, too :-)  Anyway, I don't know how
what you are experiencing could be happening.  Granted, I *believe* it is
happening, mind you, but I just think something is missing somewhere.  You
say that you:

|	login successfully
|	start layers
|	do inconsequential stuff [like break sar and sag :-)]
|	^D (without leaving layers)
	
and then are dead in the water.  At this point, you should be able to just
create a new window.  Granted, the current window will indeed be dead.  But,
after creating a new one, you will be able to delete the first one.   I really
don't know why the terminal would still be dead after a power on and off (it
will be really dead after killing all the processes :-).  How many xt devices
do you have defined?  That would be #DEV in /etc/master.d/xt.  You might be
running out there, since you say you need a reboot.  Each dev corresponds to a
terminal, not a window, so, if you have 8 devs, you can have 8 terminals on
your system.

You also asked:

	2) How can I tell (in a shell script) if layers is active on my tty?
	   (If I can set my prompt string, PS1 to say "LAYERS" I can
	    avoid trying to logout while layers is running.)

Well, after layers runs, you are no longer on a tty port, but rather an xt
port.  So, I would do a tty command and look at it and if it says xt???, set
your prompt accordingly.  Eg:

	if tty | grep xt >/dev/null
	then
		PS1="LAYER$ "
	fi

Since you are running ksh, you could also say:

	set -o ignoreeof

which would blast out at you:

	Use 'exit' to logout

whenever you typed '^d' at the window.  I use this myself.

Well, I have pontificated long enough.  I hope this helps out!


-- 
Jim Webb                "Out of Phase -- Get Help"               att!mtune!jrw
#include <std/disclaimer.h>                                  jrw at mtune.att.com