I wanted to get the collective opinion of the list on a problem we are
facing with synchronous write.

In our environment we use TSM library sharing and we typically over-commit
the tape drives in our library, relying on the client sessions waiting in
a MediaW state until a drive becomes available. This works fine unless we
have synchronous write configured for the primary storage pool and there
are insufficient free drives available in the library for the copy storage
pool.

In this case, the copy storage pool is removed from the storage pool list
and the backup proceeds using only the primary storage pool.

17-08-2009 20:31:42  ANR0406I Session 76714 started for node xxxxxx
(WinNT)
                      (Tcp/Ip lng005.corp.yw.kelda(4177)). (SESSION:
76714)
17-08-2009 20:31:46  ANR0408I Session 76716 started for server TSMLM1
(Windows)
                      (Tcp/Ip) for library sharing.  (SESSION: 76714)
17-08-2009 20:31:46  ANR0409I Session 76716 ended for server TSMLM1
(Windows).
                      (SESSION: 76714)
17-08-2009 20:31:46  ANR0408I Session 76717 started for server TSMLM2
(Windows)
                      (Tcp/Ip) for library sharing.  (SESSION: 76714)
17-08-2009 20:31:46  ANR0409I Session 76717 ended for server TSMLM2
(Windows).
                      (SESSION: 76714)
17-08-2009 20:31:46  ANR4744W The server cannot acquire a sufficient
number of
                      mount points. (SESSION: 76714)
17-08-2009 20:31:46  ANR4734W The copy storage pool
REM_IBMTAPE_DOMINO_BACKUP
                      was removed from the storage pool list because of a
                      failure for session 76714. (SESSION: 76714)
17-08-2009 20:31:49  ANR0408I Session 76718 started for server TSMLM1
(Windows)
                      (Tcp/Ip) for library sharing.  (SESSION: 76714)
17-08-2009 20:32:20  ANR0409I Session 76718 ended for server TSMLM1
(Windows).
                      (SESSION: 76714)
17-08-2009 20:32:20  ANR8337I 3592 volume A02503 mounted in drive
TDC_F08R06
                      (\\.\Tape4801176). (SESSION: 76714)
17-08-2009 20:32:20  ANR0511I Session 76714 opened output volume A02503.
                      (SESSION: 76714)

This behaviour is different to that which we observed when using
externally managed ACSLS libraries accessed via Gresham EDT where the
session would wait in a MediaW state until both the mount request for the
primary and copy storage pool volumes had been satisfied. From my point of
view this would be a more suitable response.

Now we are using TSM library sharing, we are faced with some fairly hefty
storage pool backups to restore the synchronisation between primary and
copy storage pools.

IBM support say that the behaviour exhibited is by design and it would
require a DCR to change it, but I suppose I'm looking for a second opinion
as to whether the behaviour I would expect is reasonable.

For info, server is v5.5.1.1 running on Windows and maxnummp for each
client exceeds the number of mountpoints required.

Regards
Neil Schofield
Yorkshire Water


-----------------------------------------
Ever wondered how your water works? - now you can see for yourself
with a tour of our water or waste water treatment works across
Yorkshire - click here
http://www.yorkshirewater.com/see-how-your-water-works.aspx to book
now.

The information in this e-mail is confidential and may also be
legally privileged. The contents are intended for recipient only
and are subject to the legal notice available at
http://www.keldagroup.com/email.htm Yorkshire Water Services
Limited
Registered Office Western House Halifax Road Bradford BD6 2SZ
Registered in England and Wales No 2366682