Topic List (was Survey)

[Gregory G. Woodbury]

Frank has a list of topics and concepts below that could easily be a
charter for this group!

In <FWP1.90Sep10140422 at ra.CC.MsState.Edu> fwp1 at CC.MsState.Edu 
 (Frank Peters) writes:
>
>In article <richard.652960541 at fafnir.la.locus.com> richard at locus.com
 (Richard M. Mathews) writes:
>
>   It is my understanding that this group is for discussions of Unix on large
>   machines (how large is large?).  I'd be interested in starting things off
>   by finding out what large machines and what versions of Unix you have out
>   there.  For what do you use these systems?
:
>   What other large systems are out there?  What sorts of problems do you
>   have that you feel are unique to users of large systems?
>
>Well, we are developing a different kind of 'large system' that has
>its own unique complexities.
>
>We are in the process of migrating from a mainframe environment to a
>distributed environment of UNIX servers and workstations.  Though none
>of these systems taken individually are what I would call large
>(though I wouldn't call a Sun 4/490 small either), taken together they
>add up to more power and complexity than any mainframe I'm familiar
>with.
	This is also where my work site is currently.  We are/have
migrated from a mainframe IBM environment to a distributed Unix and
other "small machines" environment.  This now is a set of 21 or 22
machines (I don't feel like sitting down and figuring the exact number
right now - its more than I can keep in my head, thats a "large"
system.)

>There are a great many issues that are addressed in typical mainframe
>operating systems (and perhaps by big iron unices like UTS and
>AIX/370) that are all but ignored in the typical mini and workstation
>implementations of UNIX.
>
>I would hope that discussion of how varius users have addressed the
>following issues would be appropriate to this group.
>
>(1)  Operator driven UNIX.  The concept of a machine room operator is
>     ingrained in most mainfram operating systems.  The concept of a
>     large installation in which many of the day to day administration
>     tasks are performed by operators in a machine room rather than by
>     the user or the system administrator with root priviledges is 
>     relatively foreign to most UNIX implementations.  There are
>     really two sub issues involved here.

	Should we expect our users to be "operators" as well as
programmers and everything else necessary to keep a Unix system running
smoothly?  For our site, the next level up in mgmt (my boss) is a
technophobe of sorts and mandated that everyone should "be responsible
for their own projects."
	Needless to say, this means that I spend a lot of my time
training the users to do things and troubleshooting. Additionally, they
get frustrated when something goes wrong and my boss implies that they
are "incompetent" for not being able to keep the system running.  In
this case, its mostly a problem of personell management.

>(2)  Tape device management.  Another capability supported in
>     mainframe operating systems is the ability to gain exclusive
>     control of a tape device, request that a tape be mounted, and
>     release the device when the user is finished with it.  We would
>     like to have this capability in our UNIX environment as well.

	Good question.  I have yet to find a decent, available set of
magtape utilities for UNIX.  We currently use a mix of dd and small
custom programs and other programs to solve problems in an ad hoc
manner.  Does anyone have a decent ANSI magtape utility for Unix?

>(3)  Load balancing.  In a single box balancing the load among several
>     CPUs is relatively straitforward (at least in concept).  When
>     your CPUs are spread across a dozen or more machines how do you
>     avoid the situation of one machine being sunk to its knees while
>     another is nearly idle.  When you add multiple classes of
>     processor (is a 4/490 at 50% more loaded than a sparstation at
>     30%?) or multiple types  (how do the above two compare to a
>     decstation 3100 at 40%?) this issue can become a nightmare.

	You scream at the users to do ps's on occasion and be aware of
the problem.  More often in our environment it is a question of where is
there disk space for the project.


>(4)  Userid management.  Most UNIX boxes come with instructions about
>     which several files should be edited to add a user to the system.
>     We are developing programs to manage the addition of userids in a
>     relatively bullet proof way so that non-technical personnel can
>     add new users.  While there are programs to do that around very
>     few address the large system issues such as password file locking
>     and batch additions of large groups of users like a class roll.

	And that can handle the idiosyncrasies of different platforms!

>(5)  Accounting.  We have many projects of one sort and another which
>     require accounting of resources.  On our mainframe we have an
>     account number which can be used for this purpose.  The same
>     userid can be under many accounts.  The UNIX accounting system
>     (at least the one on a Sun running SunOS 4.1) doesn't seem to
>     have an equivalent concept.  As far as we can determine no
>     accounting information by group is available so that the newgrp
>     command gives us no help.  It looks as if we will have to have
>     multiple userids per user in this case.  The thought of that is
>     repulsive both from a personal and administrative viewpoint.
>
>I'm sure there are many other issues out there waiting for us that we
>haven't thought of yet.  Any discussion or suggestions on the above
>would be most welcome.
>--
>Frank Peters   Internet:  fwp1 at CC.MsState.Edu         Bitnet:  FWP1 at MsState

	Here is some, we all need more interaction!
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...mcnc!wolves!ggw           [use the maps!]
Domain: ggw at cds.duke.edu     ggw%wolves at mcnc.mcnc.org
[The line eater is a boojum snark! ]           <standard disclaimers apply>