Here are the answers to several of your suggestions and questions.

 My reclamation (when it gets changed (57)) and collocation settings are
the same for both 3494 storage pools.

The output from:

 select volume_name as "Private Tapes NOT in Use" -

 from libvolumes -
 where status='Private' -
 and libvolumes.volume_name not in -
 (select volume_name from volumes) -
 and libvolumes.volume_name not in -
 (select volume_name from volhistory -
 where type in ('BACKUPFULL', -
 'BACKUPINCR', -
 'DBSNAPSHOT', -
 'EXPORT'))




looks like this:

Private Tapes NOT in Use
------------------------
100384
100459
100543
A00088

The "100" tapes look like DBBACKUP according to a "q libvol 3494lib1 100*"
command
Still, that's only 3 tapes accounted for.

Remember that 3494LOCAL has more tapes in the library than 3494REMOTE
although 3494REMOTE has more scratches.
Here is the output from querying both 3494 storage pools:
q stg 3494local f=d

               Storage Pool Name: 3494LOCAL
               Storage Pool Type: Primary
               Device Class Name: 3494CLASS1
         Estimated Capacity (MB): 24,384 G
                        Pct Util: 48.4
                        Pct Migr: 94.7
                     Pct Logical: 99.0
                    High Mig Pct: 90
                     Low Mig Pct: 80
                 Migration Delay: 0
              Migration Continue: Yes
             Migration Processes:
               Next Storage Pool:
            Reclaim Storage Pool:
          Maximum Size Threshold: No Limit
                          Access: Read/Write
                     Description: Local
               Overflow Location:
           Cache Migrated Files?:
                      Collocate?: Yes
           Reclamation Threshold: 100
 Maximum Scratch Volumes Allowed: 590
   Delay Period for Volume Reuse: 0 Day(s)
          Migration in Progress?: No
            Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
        Reclamation in Progress?: No
 Volume Being Migrated/Reclaimed:
  Last Update by (administrator): SWSPJCD
           Last Update Date/Time: 08/23/2004 20:00:00
        Storage Pool Data Format: Native
            Copy Storage Pool(s):
         Continue Copy on Error?:
                        CRC Data: No

q stg 3494remote f=d

               Storage Pool Name: 3494REMOTE
               Storage Pool Type: Copy
               Device Class Name: 3494CLASS2
         Estimated Capacity (MB): 19,040 G
                        Pct Util: 61.6
                        Pct Migr:
                     Pct Logical: 99.1
                    High Mig Pct:
                     Low Mig Pct:
                 Migration Delay:
              Migration Continue:
             Migration Processes:
               Next Storage Pool:
            Reclaim Storage Pool:
          Maximum Size Threshold:
                          Access: Read/Write
                     Description: Remote
               Overflow Location:
           Cache Migrated Files?:
                      Collocate?: Yes
           Reclamation Threshold: 100
 Maximum Scratch Volumes Allowed: 460
   Delay Period for Volume Reuse: 0 Day(s)
          Migration in Progress?:
            Amount Migrated (MB):
Elapsed Migration Time (seconds):
        Reclamation in Progress?: No
 Volume Being Migrated/Reclaimed:
  Last Update by (administrator): SWSPJCD
           Last Update Date/Time: 08/23/2004 20:00:00
        Storage Pool Data Format: Native
            Copy Storage Pool(s):
         Continue Copy on Error?:
                        CRC Data: No


The text below with storage pool oth-atl is not from me. This is from
someone else so it's not relevant to my problem.

 >My primary tape storage pools have a reuse delay:
 >
 >tsm: ULTSM>q stgpool oth-atl f=3Dd
 >
 >               Storage Pool Name: OTH-ATL
 >               Storage Pool Type: Primary
 ...
 > Maximum Scratch Volumes Allowed: 0      <=== ??????????????




John


 How about your reclaim and collocation settings? Are they equal?
 regards
 joachim=20

 -----Urspr=FCngliche Nachricht-----
 Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]Im
 Auftrag von
 John C Dury
 Gesendet: Dienstag, 24. August 2004 13:21
 An: ADSM-L AT VM.MARIST DOT EDU
 Betreff: Re: 2 3494 Tape libraries seem to have very different
 capacities. Any ideas?


 Somehow this thread got a little messy so I'll update it with everything =
 I
 know and answer everyone's questions (I think).

 A recap: We have 2 3494 libraries, one local and one remote. The remote =
 one
 is used for backing up the local one only. There is a huge discrepancy
 between the number of scratch tapes in the local and remote libraries
 although they both appear to have the same amount of data.

 Things people suggested I check:
 Compression is on for all drives in both libraries. I checked.
 I have "reuse delay" set at 0 on both 3494 libraries so no tapes go into
 pending on either library. They immediately become scratches after
 reclamation.
 We run a job nightly that deletes volhistory for database backups. (del
 volhist type=3Ddbb todate=3Dtoday-2).
 See immediately below for a possible explanation although I don't
 understand why this would cause it. Anyone?

 Looks like I'll be caling IBM.
 <sigh>
 John


  We originally had a combination of 3590J and 3590K tapes in the =
 3494LOCAL
  library. I moved the data off of the 3590J tapes and then checked them =
 out
  and checked in 3590K volumes that has the same volume labels as the
  original 3590J volume. Essentially I replaced all the 3590J tapes with
  3590K tapes with the same volume labels. The libary manager was updated =
 to
  reflect the new 3590K volumes before they were checked in.  Could this
  have
  caused this problem?
  John


  ----- Forwarded by John C Dury/DLC on 08/23/2004 02:37 PM -----

               John C Dury/DLC

               08/23/2004 02:28                                           =
 To
               PM                        ADSM-L
                                                                          =
 cc

                                                                     =
 Subject
                                         Re: 2 3494 Tape libraries seem =
 to
                                         have very different capacities. =
 Any
                                         ideas?









  Here is the output from that command. It looks pretty similar to me. I
  also
  checked compression for both local and remote libraries. All are on. We
  also run a job every night that deletes the dbb volhistory which allows
  only 2 days of retention. (del volhist type=3Ddbb todate=3Dtoday-2)

   STGPOOL_NAME: 3494LOCAL
    Unnamed[2]: 38531539
    Unnamed[3]: 11776076.83
    Unnamed[4]: 11886072.01

  STGPOOL_NAME: 3494REMOTE
    Unnamed[2]: 38513745
    Unnamed[3]: 11773755.03
    Unnamed[4]: 11876887.56

  These are all great suggestions which is why I asked here but I'm still =
 at
  a complete loss.
  John

   The output from "select
   stgpool_name,sum(num_files),sum(logical_mb),sum(physical_mb) from
   occupancy group by stgpool_name" should give some indication of =
 whether
   the same amount of stuff is getting to the remote storagepools.

   David

   >>> jdury AT DUQLIGHT DOT COM 8/23/2004 1:26:57 PM >>>
         We have 2 3494 tape libraries. One is local and the other is
   remote.
   The local one (3494LOCAL) receives all the data from the nightly
   backups as
   it gets migrated from disk. The remote one (3494REMOTE) is only used =
 as
   the
   target of backing up the 3494LOCAL storage pool which gets done
   everyday
   during the day. 3494LOCAL has 577 library volumes in it. 3494REMOTE =
 has
   494
   library volumes in it. Both tape libraries only have 3590K tapes in
   them.
         My problem is that 3494LOCAL has 62 scratch tapes available and
   3494REMOTE has 207 scratch tapes in it. Reclamation runs daily and =
 sets
   the
   same percentage (57) for both libraries. How can there be such a huge
   difference in the number of scratch tapes if both libraries should
   roughly
   have the same amount of data? It's making me a little nervous that
   3494REMOTE doesn't have the same data or something somewhere is going
   wrong.
   Any ideas?
   Thanks,
   John