Doesn't everyone know that vstore is a RIP-OFF. They let you set up
your own store then steal your customers. You would be better off with
an affiliate program.

The problem is that they post their vstore logo all over 'your' site
(which is ok within itself) and when 'your' customer goes to
vstore.com...guess what? It's not just for customer service...it's
designed to STEAL your customers....think about it, if they were on the
vtailers side dont you think they would have a different site for the
vtailer to log in and make vstore.com ONLY for the cunsumer...What a
RIP-OFF!!! They think they're so slick and all you SUCKERS keep falling
for it. ANYONE WITH HALF A BRAIN COULD SEE RIGHT THROUGH THEIR
SCAM....vSUCKERS!!!

http://www.boycottvstore.com/



In article <[log in to unmask]>,
  Dennis Heidner <[log in to unmask]> wrote:
> 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.
>


Sent via Deja.com http://www.deja.com/
Before you buy.