Jean,

The files will be striped in the sequence of the LDEV's,  but you may
wish to reconsider the unit numbers for the SCSI drives.

On FW-SCSI drives unit 7 is generally reserved for the controller card,
Then the priority is 6,5,4,3,2,1,0,15,14,13,12,11,10,9, and 8.

So the paths shouldn't be nn.1, they should be nn.6, nn.5, nn.4, for
ldev 1,2,3

On systems with lots of I/O low priority units can be prempted, and not
get immediate access to the scsi bus, this means you want to place the
drives that expect to have the least traffic on them on a low priority
unit number.

Before you start the process of reconfiguring the machine over the
weekend.  Make sure you have good SLT's and hard copies of the current
configuration.  Run CHECKSLT (in telesup) to verify at least one SLT.

Delete old [log in to unmask] and NMLG@ files.  If you have test databases
that haven't been used for years, store and purge them... do some house
cleaning before you start this whole process.

It sounds like you are using private volumes,  full back up the system
with everything on it (make sure you specify the ;DIRECTORY option) then
make a couple of additional backups.

The additional backups should be:

1.  system volume set stuff, @[log in to unmask], @[log in to unmask], etc
    Do a :REPORT  x.@;onvs=mpexl_system_volume_set and get the accounts
    that must be on the system volume set.  Create a backup job that
    only backs up those accounts.  On one tape, again remember the
    ;directory option

2.  For each private volume group you have do the :Report x.@;onvs=xxx
    and get the accounts that are on that volume set.  Then build a
    backup job for each private volume, remember to add the ;DIRECTORY
    AND ;ONVS=xxx to the STORE.   A  VSTORE to verify the tape may be
    good idea if you have time.

    Build a "restore stream job" for each private volume that you will
    bringing back.  Make sure these files are kept in the .PUB.SYS
    account.

3.  Before shutting down the system to reconfigure it,  use SYSGEN and
    make your changes with the drives configured the way you want.  Cut
    a new SLT, then repeat step 1 above, again storing the system volume
    set.  Mark this tape as the one to use after the initial system
    INSTALL  (why, because otherwise you'll overwrite the config changes
    you just made).  Yes this is a redundant store, I sometimes get a
    little paranoid about preserving the data at all costs.  VSTORE?

After you've backed everything up, made paper copies of the before and
the planned configuration.  Then shutdown the system and start playing.

If you are changing the path for LDEV #1, remember that you will need to
change it at the CM> prompt specify the new boot path for PRI.

When you are ready to reboot,  boot off the SLT that you cut with the
configuration changes that made in step 3.

If you are going to use two drives for the system volume set, add it now
with volutil.

Then RESTORE *coffee;@[log in to unmask]@;keep;create=creator;olddate;directory

using the last STORE of the system volume set that was made...  This
should restore all the passwords, accounts, NMMGR configs, etc to the
machine.  You will also have utitilies like EDITOR back so can edit
stream jobs if necessary.

Once the system volume set is back, you can launch the jobs to restore
the private volumes.

I prefer using jobs to do the restores, because it doesn't tie up the
console AND it means that the machine can run un-attended for several
hours if need be (time to eat and sleep),  yet the $STDLIST is still
available so you can see if some files did not restore.

The reason for separate tapes for each volume set, is that you can not
currently tell RESTORE that you only want files that belong to a
certain  volume set to be restored.  Of course you can restore by
file.group.account, but it may mean you waste time skipping files or
while the system verify that the file already exists and keep was
specified... believe me it is much faster to make the extra stores.

Also with stream jobs and multiple store tapes,  if you have multiple
DAT's you can actually be restoring TWO private volumes sets at the same
time...

Jean Huot wrote:
>
> Scsi card 1 has private volumes
>
> ldev:  2      path 48.1
>           3               48.2
>           4               48.3
>           5               48.4
>
>
> Scsi card 2 has private volumes:
>
> ldev  11      path 40.1
>          12               40.2
>          13               40.3
>          14               40.4
>
> My guess is that it will load in the sequence 2,3,4,5,11,12,13,14 which means the Scsci 1 channel wil be quite busy when I do a reload of the system.  I don't know that the "threshold overflow to the next disk is",  I assume all files will be spread evenly over all disks.
>
> How can I optimize the load on both scsi buses?  Maybe I should not worry, since all disks will be filled evenly?
>
> Should there be a performance gain if database files were loaded:
>
>          2, 11, 3, 12, 4, 5, 14
>
> Then I guess, maybe on the reload of files only.  Aftwerwards it won't make any difference.  The disks can easily send data at 40Mbytes/s,  but they will slow down to 20Mbytes/s (Scsi card and system bus speed).
>
> All disks are of the same size and type (9 Gbytes).
>
> Thanks.
>
> Jean Huot
> Northern Credit Bureaus Inc.