ggw@wolves.uucp (Gregory G. Woodbury) (09/11/90)
Frank has a list of topics and concepts below that could easily be a charter for this group! In <FWP1.90Sep10140422@ra.CC.MsState.Edu> fwp1@CC.MsState.Edu (Frank Peters) writes: > >In article <richard.652960541@fafnir.la.locus.com> richard@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@CC.MsState.Edu Bitnet: FWP1@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@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
bernhold@qtp.ufl.edu (David E. Bernholdt) (09/12/90)
In article <1990Sep11.154433.25652@wolves.uucp> ggw@wolves.uucp (Gregory G. Woodbury) writes: >Does anyone have a decent ANSI magtape utility for Unix? We use something called 'ansitape', written by David Hayes, which was posted as Volume 8 issues 99-100 of mod.sources. I believe it can be found in the cannonical comp.sources.unix archives in volume 8. We have found this tool to work very well for reading and writing ANSI-format tapes. >More often in our environment it is a question of where is >there disk space for the project. This is our problem too. We have a set of scripts that run in conjunction with the nightly accounting that compile data on each user's consumption on each disk in the system -- how many megabytes, what percent of the disk that is, and how full the disk is overall. Users see this any time they login from a machine outside of our network, dial in, or unlock their 'lockscreen' (remember, these are Suns). We have found it an effective tool to remind people of their usage, and we encourage users to keep each other in line (politely, of course). -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365