Occupancy discrepency between 6.1.5.10 and 6.2.3.0 server

Doing some reorganization, we recently moved (server-to-server export) some nodes from a 6.1.5.10 server to a 6.2.3.0 server. Now, the occupancy numbers on the 6.2 (71mb) server are lower than the 6.1.5 (83mb) server, eventhough the file/object counts are identical (static file system)? All of

Re: Occupancy discrepancy between 6.1.5.10 and 6.2.3.0 server

Zoltan, occupancy numbers were made incorrect by various bugs in early 6.1 code, see apar ic73005. There is a special utility to fix the numbers, repair occupancy. It was supposed to be in 6.1.5.10 but isn't, you need an e-fix for 6.1.5.102. Of course, you can ignore the errors unless you are

Re: Slow TSM DB Backup Update#1

Hie-mail from IBM Matt Powell TSM L2 Support I have AIX support, TSM development and TSM ATS Performance teams looking at this problem. The TSM teams are also responsible for DB2. The only change to your system was the OS upgrade. The TSM ATS Performance team has had other customers

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Hi Thanks Daniel..I will also check these a and/or b could be a issue Regards -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel Sparrman Sent: Tuesday, March 06, 2012 5:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM Export issue

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Thanks David! No didn't try this I thought about it but have to discuss this with the other Admins I believe this is a long process and if I am not mistaken this was performed recently. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

I had a similar problem, tape changing to unavailable, a few months back. In my case, it was a problem with how the tape was identified. The Library, an XLS, had it as 123456. TMS has 123456 as a scratch tape and also had tape 123456L4 as the tape I wanted. I had to check 123456 out of TMS

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

If you do the audit by using checkl=barcode, the process should take no more than a few minutes to complete, so it should also be one of the activities you should perform. Audit library only takes a (very) long time to complete when you do checkl=yes since this means that TSM needs to mount

Re: Occupancy discrepancy between 6.1.5.10 and 6.2.3.0 server

Bill, Thanks for the update/info. I guess I will wait for 6.1.5.200, which is scheduled for 1Q2012. Yes, we did switch to the Unified Recovery license model but with enough room for growth/shrinkage so I don't know if this will matter that much (roughly 15TB difference on this, my only 6.1

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Thanks Ray! This is something we will take a look at also. Regards. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ray Carlson Sent: Wednesday, March 07, 2012 9:50 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM Export issue unavailable tapes

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Thanks David! Regards -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel Sparrman Sent: Wednesday, March 07, 2012 9:56 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

Sorry I mean't Daniel..Busy day typing to fast. Best regards -Original Message- From: Hughes, Timothy Sent: Wednesday, March 07, 2012 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: RE: TSM Export issue unavailable tapes causing the exports to suspend themselves Thanks David! Regards

Re: Occupancy discrepancy between 6.1.5.10 and 6.2.3.0 server

A correction/addition to this. I just went through the apar and it says it affects ALL 6.x servers...and while the apar page says it should be fixed in 6.1.5.10, Bill indicates this is not totally truenote the new REPAIR OCCUPANCY tool (

Re: Occupancy discrepancy between 6.1.5.10 and 6.2.3.0 server

I found I had to run 'audit licenses' to update the occupancy values. I have no idea why this would be the case. Jim Schneider -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: Wednesday, March 07, 2012 12:33 PM To:

Re: TSM Export issue unavailable tapes causing the exports to suspend themselves

If you use the checklabel=barcode parm of the audit library it runs very quickly. It does require that there be no activity involving the tape library. David -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Hughes, Timothy Sent: Wednesday,

TSM 6.2 SQL statement

We run this and other SQL statements that return dates in the form of days. This SQL query works on 5.4, but does not work on 6.2. I am hoping one of the more SQL savvy admins can quickly help me with this so I can fix the rest of the queries we use. The lines that don't work and I do not

Re: TSM 6.2 SQL statement

Andy, Try this: select SUBSTR(CAST(VOLUME_NAME AS char(10)),1,10) as VOLUME_NAME, SUBSTR(CAST(stgpool_name AS char(18)),1,18) as STG, PCT_UTILIZED, EST_CAPACITY_MB, TIMESTAMPDIFF(16,CHAR(current_timestamp-date(last_write_date))) as xdays, SUBSTR(CAST(status AS char(10)),1,10) as status,