Is anyone else bothered that IBM had to resort to tracing its own product
to find out how it behaves?  Aren't there written detailed program
specifications which could have provided the answer?  Or has the code
diverged from the specs to such an extent that IBM doesn't know its own
product anymore.  If so, we are all in big trouble!

--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <B4A97236C89BD311A1A040001EC062811C89CA@LDNTES02>, on 01/25/00
In <B4A97236C89BD311A1A040001EC062811C89CA@LDNTES02>, on 01/25/00
   at 12:38 PM, "Doherty, John (ANFIS)" <jdohe1 AT ANFIS.CO DOT UK> said:

>Thank you William this is very informative.

>> ----------
>> From:         William R Zehnder[SMTP:wzehnder AT JCPENNEY DOT COM]
>> Reply To:     ADSM: Dist Stor Manager
>> Sent:         25 January 2000 13:25
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      Re: Directory management problem
>>
>> I received this reply from IBM when I questioned how management classes
>> were
>> selected for directories -
>>
>> Tracing shows that the directories will go to the Management class
>> that is last in alphabetical order when the copy groups have the same
>> setting.  If all management classes have the same retention time, then the
>> last management class alphabetically will be used.
>>
>> Its from their PMR 53651,227.
>>
>>
>>
>> "Doherty, John (ANFIS)" wrote:
>>
>> > I think we have cracked the problem, apparently without the DIRMC
>> command
>> > specified the directories are dumped to the storage groups with the
>> longest
>> > management class retention.  We had both our co-located and
>> non-colocated
>> > retention times (at 90 days)  When I updated our non-located management
>> > class to 95 days the directories started going to the storage pools
>> > allocated to this.  I am not sure how the selection algorithm works if
>> both
>> > MC's are set to 90 days, obviously it picks one and sends data there.
>> > Whilst trying to understand how this happened, data had moved across
>> storage
>> > pools and corrupted our test pools.  Therefore I decided that the best
>> > solution would be start again from scratch.  I cleared out all pools and
>> > stated again.  So far everything is working as planned.  Just need to
>> try
>> > restores of full servers to see how this time compares to non-colocated
>> > data.
>> >
>> > Thanks for the tip re DIRMC in the dsm.opt file and how it would be
>> > overridden.
>> >
>> > > ----------
>> > > From:         Wayne Gorton[SMTP:wgorton AT NETTRACK.COM DOT AU]
>> > > Reply To:     ADSM: Dist Stor Manager
>> > > Sent:         24 January 2000 12:16
>> > > To:   ADSM-L AT VM.MARIST DOT EDU
>> > > Subject:      Directory management problem
>> > >
>> > > John,
>> > > Out of interest is the management class for the non collocated data
>> > > retained
>> > > longer or shorter? We've found through testing that if you specify a
>> dirmc
>> > > that
>> > > is retained for less than other management classes, the dirmc is
>> > > effectively
>> > > ignored. Strange but true.
>> > > ---------------------- Forwarded by Wayne Gorton/Nettrack/AU on
>> 01/24/2000
>> > > 10:09
>> > > PM ---------------------------
>> > >
>> > >
>> > > "Doherty, John (ANFIS)" <jdohe1 AT ANFIS.CO DOT UK> on 01/20/2000 
>> > > 08:39:30 PM
>> > >
>> > > Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>> > >
>> > > To:   ADSM-L AT VM.MARIST DOT EDU
>> > > cc:
>> > >
>> > > Subject:  Directory management problem
>> > >
>> > >
>> > >
>> > >
>> > > I am currently experiencing a problem in regards to directory
>> management.
>> > > I
>> > > have introduced
>> > > co-location in our company.  We have separate storage pools defined
>> for
>> > > co-located data and have defined the appropriate rules/management
>> classes
>> > > to
>> > > direct data from co-located nodes to the relevant co-located pools.
>> The
>> > > process we have in place is as follows:
>> > >
>> > > 1.      Data is backed up to storage pool BKUPPOOLC1
>> > > 2.      After all nodes have backed up process BKUPCC1LOCAL executes
>> to
>> > > backup all data stored in disk storage pool 'BKUPPOOL1' and copy it to
>> > > tape
>> > > storage pool 'C9840COPYC1'
>> > > 3.      Data stays on disk throughout the day and at 18:00 hrs every
>> > > evening
>> > > an administrative process executes to move the data from disk storage
>> pool
>> > > 'BKUPPOOLC1' to co-located cartridge storage pool 'C9840PRIMC1' and
>> > > empties
>> > > the disk storage pool
>> > >
>> > > The problem is that directories from non colocated nodes are appearing
>> in
>> > > the cartridge storage pool 'C9840PRIMC1' this should not be the case.
>> The
>> > > manual states the following:
>> > >
>> > > " For directories, the client can specify a management class by using
>> the
>> > > DIRMC option in the client options file. If no management class is
>> > > specified
>> > > for a directory, ADSM chooses the management class with the longest
>> > > retention period in the backup copy group (retention period
>> > > for the only backup version).  "
>> > >
>> > > We have not specified the DIRMC option on the client nodes DSM.OPT
>> file,
>> > > but
>> > > the default management class with the longest retention is a non
>> colocated
>> > > class, therefore I would expect the directories to go our non
>> colocated
>> > > storage pools.
>> > >
>> > > Strangely enough when I do a Q contents of our disk storage pool only
>> the
>> > > nodes that I have colocated appear in this.  But when the data is
>> > > transferred to cartridge directories appear from non colocated pools?
>> > >
>> > >
>> > >
>> > > John Doherty.   Tel:   +44   (0)   141 275 7793
>> > >                 Fax:  +44   (0)   141 275 9199
>> > >                 Email: JDohe1 AT Anfis.co DOT uk
>> > >
>> > > Technical Specialist, Storage Management L02S
>> > > Abbey National Financial and Investment Services Plc
>> > > 287 St Vincent Street Glasgow G2 5NB
>> > >
>>
>> --
>> Cordially,
>>
>> Bill Zehnder
>> 972-431-8733  Fax 972-531-8733
>>