Newsgroups: bit.listserv.sfs-l
Date:         Thu, 9 Apr 1992 10:55:52 EST
From:         Elizabeth Vogt <VOGT@PURCCVM.BITNET>
Subject:      Re: SFS Questions

Theresa,

We installed VM/ESA 1.0 last summer and are planning to gradually migrate
the majority of our users to it.  Our experiences thus far have
(unfortunately?) not included performance problems or media failures,
but may nonetheless be of some interest as we also are a university
environment.

>Specific Questions:
>How did you set up your filepools (i.e., divide up your users), and
>    what were the considerations involved in your choices? (E.g.,
>    performance, administration, accessability, etc.) Do you
>    have any estimates on how much DASD space you saved?

We have organized our filepools with regard to both performance and
administratively segregated groups.  Pools vary in size and are allocated
for instructional, personal, research, test and computing center internal
accounts.  Even being conservative, I would estimate about 1,000 cylinders
of DASD space savings (We have about 6,000 users in our directory, about
half of which are student accounts. ).  Nonetheless, there is a shorter
term increase in space requirement per SFS 'convert' for us, as we have
implemented a gradual MDISK-to-filepool conversion scheme.

>How long did it take to migrate the different user groups to SFS?
>    What kinds of problems did you (& your users) encounter?

We wrote an exec which enrolls the user, copies the 191 to the top
directory, gives the 191 a new address (it is retained for 30 days) and
logs the transaction.  It takes seconds per user.  Some problems include a
user space full condition during a Fortran compile which was not
properly reflected to the user (and as temp files are not 'committed', not
too obvious) and the lack of FTP support.  The use of nicknames hasn't
bitten us yet, and we're now running NOBACKUP with complete reliance on
VMBACKUP, which reduces the risk of service interruption
associated with minidisk full conditions (automatic control
data backups and logging).

>Is anyone using VMBACKUP (full+incremental) to back up SFS files?
>    How do you handle disaster recovery (say, you have an HDA conk
>    out on a vol containing control mdisks &/or catalogs)?

We're on VMBACKUP 5.3, doing full backups once a week and incremental
backups nightly.  We initially had some minor problems which have since
been fixed by service.

>Do you have some/all software packages in SFS? How is it set up?
>    Separate filepool? (Maybe VMSYS?) Do you have each package
>    (SAS, COBOL, GDDM, etc.) in a different directory? How do
>    the users access the packages - do you have some kind of
>    cover exec(s) that sets up the access for the user?

We do not have system or program product performance in filepools and
I would vote not to do so.  My reasons:

  - Their production size allocations tend to be static,
    and the allocation elasticity of the filepool would therefore be not
    needed.

  - Placing them in a file pool increases user access path lengths
    (performance stress) as well as environment complexity
    and interdependence.

  - Availability.   Media or SFS server failure could
    put the server out of order, and with it ALL of the program
    products therein.  Also, there may be times when you don't want
    to fire up a host of servers to do basic maintenance & support work.

Good luck!  Hope that these general comments are of some use.

= Elizabeth Vogt           | Purdue University Computing Center
= VOGT@PURCCVM.BITNET      | VM/MVS Systems Programmer
= vogt@expert.cc.purdue.edu| "Only the mediocre can always be at their
                           |  best."  -Mencken.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU