home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19356 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  3.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Splitting a user disk
  5. Message-ID: <9212151431.AA02280@uu3.psi.com>
  6. Date: 15 Dec 92 13:11:05 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 80
  11.  
  12.  
  13.     I have a series of DEFINE statements in SYLOGICALS.COM like the
  14.     following:
  15.  
  16.     $ DEFINE/SYSTEM/EXEC/TRANSLATION=(CONC,TERM) STUDISK      MOE$DUB0:
  17.  
  18.     and I've told my users to use logical name and not the physical device
  19.     name in command procedures, etc., because the physical device *will*
  20.     change from time to time.
  21.  
  22.     Diskquotas are enabled on the current device (and will be on the new
  23.     pair of devices).  The users' directories are created for them in the
  24.     MFD when their accounts are created.  The users are not allowed to
  25.     created directories outside their initial login directory.  
  26.  
  27.     The time is rapidly approaching when I will need to split the current
  28.     users of "STUDISK" into two groups due to the facts that STUDISK has
  29.     recently surpassed 90% full and that it is overbooked by a factor of
  30.     more than 8!
  31.  
  32.     I would *like* to maintain the logical name of STUDISK for all current
  33.     users of the device.  Here is what I envision doing:
  34.  
  35.       Split the current users on DUB0 onto DUB1 and DUB2.  A current (and
  36.       future) user will have diskquota and directory on *only one of* DUB1
  37.       or DUB2.
  38.  
  39.       For my convenience:
  40.  
  41.         $ DEFINE/SYSTEM/EXEC/TRANSLATION=(CONC,TERM) STU1      MOE$DUB1:
  42.         $ DEFINE/SYSTEM/EXEC/TRANSLATION=(CONC,TERM) STU2      MOE$DUB2:
  43.  
  44.       The default device in SYSUAF will be STU1 or STU2.
  45.  
  46.       And to maintain the current logical STUDISK:
  47.  
  48.         $ DEFINE/SYSTEM/EXEC/TRANSLATION=(CONC,TERM) STUDISK   -
  49.           MOE$DUB1:,MOE$DUB2:
  50.  
  51.     This *appears* to work, i.e., DIR STUDISK:[000000] shows all files in
  52.     the MFD of both devices.  A bonus (I think) is that they show up as a
  53.     single list, not as separate lists as seen with DIR SYS$MANAGER, etc.
  54.     Also,  DIR STUDISK:[some-valid-directory] lists the files in that
  55.     directory as expected.
  56.  
  57.     Is there anything obvious that I'm missing?  Or worse, anything
  58.     insidious?
  59.  
  60. There are any number of situations in which this will not work quite as
  61. expected.  For example:
  62.  
  63.     - Files created using the STUDISK: logical will ALWAYS go into
  64.         MOE$DUB1: - when looking for an EXISTING file, RMS searches
  65.         all elements of a search list, but when CREATING a file, it
  66.         always uses the first element.  Note that this will happen
  67.         even if you try to create a file in a directory that only
  68.         exists in the second member of the list!
  69.  
  70.     - Setting default to a search list can produce unexpected results.
  71.  
  72.     - Doing file specification defaulting when search lists are involved
  73.         requires care.  If it's done properly through RMS, there's no
  74.         problem; but there are many programs around (no VMS standard
  75.         ones, but plenty anyway) that try to use the resultant
  76.         file specification string to get defaults for the next
  77.         parse.  They won't work properly with search lists.
  78.  
  79.         In particular, it is just about impossible to do correct
  80.         file specification defaulting in the presense of search
  81.         lists within DCL.
  82.         
  83. All in all, expect to be answering a lot of questions from puzzled users of
  84. programs that USED to work.
  85.  
  86.             Or is there a better way?
  87.  
  88. I know there are many people on this list who dislike them, but this strikes
  89. me as an ideal application for a bound volume set.
  90.                             -- Jerry
  91.  
  92.