Re: expire inventory and delete filespace hangs
Just went from v6.3.5.100 to v7.1.1.300. The procedure went smoothly, but so far I'm not impressed with the client backup - slow to start, slow to run. I'd hate to think that the only solution for the performance is a bit of sleight of hand to reconstruct the tablespace. Database is only ~350G with ~360 million objects. Just not sure if I'm going to stay at v7. Gretchen Thiele Princeton University From: ADSM: Dist Stor Manager [ADSM-L@vm.marist.edu] on behalf of Stef Coene [stef.co...@docum.org] Sent: Monday, August 10, 2015 10:51 AM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] expire inventory and delete filespace hangs Hi, We have a V7 TSM server (upgraded from V6). Expire inventory hangs after running a few hours and we also found a filespace that we can not delete. The delete filespaces command just hangs. The only way to cancel the expire inventory and the delete filespace is to halt TSM. The TSM database is 850 GB. When we contacted IBM support and after tracing the server, they told us it's a performance problem. I don't understand why they think it's performance related because all the clients and other server processes are running fine. The fact that the TSM database, recovery log and archive log is stored on a SVC with FlashSystem 840 as backend was not impressive enough. To resolve the performance issues, they want us to convert the DB2 from V6 tablespace format to V7 tablespace format. They can provide scripts for this, but you need to be a DB2 guru to execute the scripts. This will give as an extra performance boost, but also a 30% reduction of the database! Since they consider this a performance issue, the upgrade procedure is not free. Has someone else got the same advice and if yes, have you followed the procedure and what was the result? Stef
Re: million files backup
If you are not using HSM, the virtual mountpoint approach is a good one. Since we do have an integrated TSM/HSM system on GPFS, we can't do that. It takes a bit over 3 days to wade through 130+ million files. Not enough disk to use mmbackup, which basically 'journals' the changes. I do run incrementals on directories that are critical while the overall incremental runs. What version of GPFS and TSM are you using? We are a bit backlevel at GPFS 3.3 and TSM 5.5, but are in the process of upgrading. I think a more current combination will allow for faster backups. Gretchen Thiele Princeton University -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Lee, Gary Sent: Thursday, February 02, 2012 9:50 AM To: ADSM-L@vm.marist.edu Subject: Re: [ADSM-L] million files backup Is it organized into subdirectory trees? If so, virtual mountpoints might be a way to go. Gary Lee Senior System Programmer Ball State University phone: 765-285-1310 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Jorge Amil Sent: Thursday, February 02, 2012 9:30 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] million files backup Hi everybody, Does anyone know what is the best way to make a filesystem backup than contains million files? Backup image is not posible because is a GPFS filesystem and is not supported. Thanks in advance Jorge
Re: IBM FTP Site
Which site are you using? I had problems with ftp.software.ibm.com last week and went back to index.storsys.ibm.com which I can get to this morning. Gretchen Thiele Princeton University -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Gill, Geoffrey L. Sent: Tuesday, October 27, 2009 11:15 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] IBM FTP Site Does anyone know if there has been a change to the download site or if it is just down? I can't get there from my saved links any longer. Thanks, Geoff Gill TSM/PeopleSoft Administrator SAIC M/S-B1P 4224 Campus Pt. Ct. San Diego, CA 92121 (858)826-4062 (office) (858)412-9883 (blackberry)
IBM FTP server asking for userid and password
Is there any reason why ftp.software.ibm.com is asking for a userid and password now? I've rerouted all requests for TSM software to index.storsys.ibm.com, but this one can be flakey at times, too. I did try userid=anonymous and password=email, but no luck. Gretchen Thiele Princeton University
Re: IBM FTP server asking for userid and password
Thanks to all for your responses. The userid/password prompts are now gone. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Laughlin, Lisa Sent: Friday, October 23, 2009 2:21 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] IBM FTP server asking for userid and password Hmm, You can go directly to ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance for instance, and it doesn't ask thanks! lisa -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Gretchen L. Thiele Sent: Friday, October 23, 2009 12:40 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] IBM FTP server asking for userid and password Is there any reason why ftp.software.ibm.com is asking for a userid and password now? I've rerouted all requests for TSM software to index.storsys.ibm.com, but this one can be flakey at times, too. I did try userid=anonymous and password=email, but no luck. Gretchen Thiele Princeton University
GPFS, HSM and backups
We've been using GPFS-directed HSM for a while now, working quite well (with a few bugs, but they're being worked on). The 'problem' I'm seeing is the mounting of HSM media (tapes, in particular) during the running of an incremental backup. Since we have the requirement that nothing can be migrated without a backup in place, this just doesn't make sense to me. It's also frustrating that I don't see any type of info on the server after a recall as to the size of the file being recalled, etc. - much like you would see after a backup, restore, archive or retrieve (separate from the issue above). Server and client (BA and HSM) all at 5.5.1.1 (upgrade to 5.5.3.x when I can get downtime in a month or so) on SLES 10. Any ideas? Gretchen Thiele Princeton University
Re: GPFS, HSM and backups
Thanks, Joerg, for reminding me that the accounting records contain this info! I was hoping that there was, in addition, something that I could spot check (using 'q act', for example) a bit more easily (accounting is currently turned off - too much data). -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Joerg Pohlmann Sent: Thursday, September 24, 2009 11:17 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] GPFS, HSM and backups Gretchen, I don't know about the first part, but as to information about recall activity, use the accounting records (set accounting on) - fields 26-29 relate to migration and recall activity. Joerg Pohlmann 250-245-9863 - Original Message - From: Gretchen L. Thiele gretc...@princeton.edu Date: Thursday, September 24, 2009 7:56 am Subject: [ADSM-L] GPFS, HSM and backups To: ADSM-L@VM.MARIST.EDU We've been using GPFS-directed HSM for a while now, working quite well (with a few bugs, but they're being worked on). The 'problem' I'm seeing is the mounting of HSM media (tapes, in particular) during the running of an incremental backup. Since we have the requirement that nothing can be migrated without a backup in place, this just doesn't make sense to me. It's also frustrating that I don't see any type of info on the server after a recall as to the size of the file being recalled, etc. - much like you would see after a backup, restore, archive or retrieve (separate from the issue above). Server and client (BA and HSM) all at 5.5.1.1 (upgrade to 5.5.3.x when I can get downtime in a month or so) on SLES 10. Any ideas? Gretchen Thiele Princeton University
OpenSolaris and TSM
Just got a report from a user that running TSM 6.1.0.2 on OpenSolaris 5.11 (SPARC) is core dumping on 'dsmc incr'. This is the first I've seen of OpenSolaris, but it's probably not the last (big upsurge in Ubuntu installs, too). I'm heading over to see the 'victim', but thought I check in with the list and see if anyone is successfully running TSM on OpenSolaris. Thanks in advance, Gretchen Thiele Princeton University
Problem with Mac TSM client and new Java
I've just run into a roadblock with the TSM gui on the Macintosh - both v5 and v6 clients. There apparently was a Java software update (1.5.0_19) that was just released and I believe it to be causing the problem with the TSM client. If you start the GUI, you get an ANS1971E (v6) or ANS5179E (v5) - both of which state problems with the remote client agent. I can run dsmc/dsmadmc manually just fine. Has anybody else run into this? Can anyone else verify that the Java update is the problem? Have seen a link from Penn State that they are seeing this as well. Thanks! Gretchen Thiele Princeton University
Re: Problem with Mac TSM client and new Java
The notice in the software update states for Mac OS X 10.5.7 and later. Formally, it's this update: Java for Mac OS X 10.5 Update 4 Version 1.0 IBM/Tivoli has several PMRs open on this one (I've added our incident to the list), and it's in the hands of the developers. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Jason Zerdin Sent: Wednesday, June 17, 2009 1:14 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Problem with Mac TSM client and new Java Hi, We had a user with this today on TSM 5.5, and I've recreated the error on a second machine by upgrading to that version of Java. So it seems likely that you're right that it's the Java update. We're now wondering whether this will affect all Mac clients that have upgraded to Java 1.5.0_19... Best wishes, Jason -- Dr Jason Zerdin Systems and Storage Administrator HFS OUCS http://www.oucs.ox.ac.uk/hfs/ Gretchen L. Thiele wrote: I've just run into a roadblock with the TSM gui on the Macintosh - both v5 and v6 clients. There apparently was a Java software update (1.5.0_19) that was just released and I believe it to be causing the problem with the TSM client. If you start the GUI, you get an ANS1971E (v6) or ANS5179E (v5) - both of which state problems with the remote client agent. I can run dsmc/dsmadmc manually just fine. Has anybody else run into this? Can anyone else verify that the Java update is the problem? Have seen a link from Penn State that they are seeing this as well. Thanks! Gretchen Thiele Princeton University
'Greening' TSM; position available
I'm getting pressured (gently now, much stronger in the future) to come up with a way to back up our desktops without leaving them on overnight. I don't think 'wake up on lan' is appropriate since the TSM servers are on their own separate segment on the network. I've looked into prompted, but we do have a lot of computers that use wireless and therefore have inconsistent hostnames. Backing up during the day, even with journalling and subfile backups, still monopolizes the clients' computers (Vista, Mac OS X, Linux) and I get complaints. I think this list has touched on this before, but I'm checking again to see if anyone else is getting a nudge to do this or if there is something I'm not considering. Has anyone used pre and/or post sched commands to shut down computers after backing up? I have limited access to clients' desktops, so something more server-centric is preferred... Also, we have a TSM administrator position open. For details, visit http://jobs.princeton.edu and search the open positions for 'tsm'. I can be contacted *off list* for more details. Gretchen Thiele Princeton University
TSM Server v5.4.1.2
I notice that there are 5.4.1.2 server versions on the ftp site this morning, but nothing in the README that points to the problems that have been fixed. Is this just a repackaging of 5.4.1.1 in light of the security announcement earlier this week? Also, as I moved from 5.4.0.x to 5.4.1.x on my AIX servers, I've noticed that the 'pick order' for reclamations has changed. It used to be that the volumes with the most amount of available space were reclaimed first; with 5.4.1.x (5.4.1.1 at least), it's using the recl=xx setting and working its way 'backwards'. As an example, if I have three volumes with the following amounts of reclaimable space: VOL000 99.9 VOL001 98.3 VOL002 95.7 Under 5.4.0.x, a rec=95 would start processing VOL000 first and then proceed to VOL001 and then VOL002. Under 5.4.1.x, issuing the same rec=95, the server starts processing in the reverse order, starting with VOL002. Is this 'fixing' something? Gretchen Thiele Princeton University
Re: Immortal sessions
Yes, it came out in 5.3.something (at least here it did). It's now being addressed by APAR IC53464. Gretchen Thiele Princeton University -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Fred Johanson Sent: Thursday, August 23, 2007 1:12 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Immortal sessions Came in Monday after a week off and saw this on one of my machines: Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name Number Method StateTimeSent Recvd Type -- -- -- -- --- --- - -- 9,299 Tcp/Ip IdleW 302.6 11.6 M 7.2 K Node WinNTUCTECHSHARE H 9,708 Tcp/Ip Run 0 S 423 1.8 K Node WinNTUCTECHSHARE 16,642 Tcp/Ip IdleW 254.1 11.6 M 7.2 K Node WinNTUCTECHSHARE H 16,957 Tcp/Ip Run 0 S1.1 M 335.8 K Node WinNTUCTECHSHARE 20,296 Tcp/Ip IdleW 230.7 11.7 M 7.2 K Node WinNTUCTECHSHARE H 20,600 Tcp/Ip Run 0 S1.1 M 335.8 K Node WinNTUCTECHSHARE 31,976 Tcp/Ip IdleW 157.5 16.9 M 1.8 K Node Linux86 ORWELL H 32,464 Tcp/Ip Run 0 S1.6 M 1.8 K Node Linux86 ORWELL 49,883 Tcp/Ip IdleW 38.8 H 11.7 M 7.3 K Node WinNTUCTECHSHARE 50,283 Tcp/Ip Run 0 S8.2 K 8.6 K Node WinNTUCTECHSHARE 53,680 Tcp/Ip IdleW 14.2 H 10.1 M 6.6 K Node WinNTUCTECHSHARE 54,124 Tcp/Ip Run 0 S3.0 M 337.9 K Node WinNTUCTECHSHARE Server is 5.4.1.0, UCT.. Is 5.3.4.0, and ORWELL is 5.4.0.2 Only these two out of 140 clients. Other 5 machines have similar immortals. Anyone else seeing such?
v5.4.1.0 for Apple Mac
Checking to see if anyone else has this problem with TSM v5.4.1.0 for an Intel Mac... I just upgraded a Mac to 10.4.10, but the TSM client installation is failing, stating that I must be at OS X 10.4.3 or higher. I don't think the installer is parsing the trailing '10' correctly... I have not tried an installation with 5.4.0.4 since going to 10.4.10, but I would presume that the same check is in place. Gretchen Thiele Princeton University
FTP site down?
Greetings, Where is everyong ftp'ing their TSM software from these days? The ftp hosts that I've been using are index.storsys.ibm.com and service.boulder.ibm.com. Both appear to be empty. Gretchen Thiele Princeton University
Re: FTP site down?
Thanks! Ochs, Duane wrote: ftp.software.ibm.com/storage/tivoli-storage-management/ Just used it this morning.
Re: Still huge problems with Mac OSX client 5.2.3.12
A more recent client, v5.3.2.1, is now available. I haven't seen any major problems yet. On Dec 2, 2005, at 4:22 AM, James R Owen wrote: Farren, Is there some reason that you can't upgrade to the latest Mac TSM client: 5.3.2.? All/most of our OSX backup complaints were fixed with Mac TSM client 5.3.2.0.
Re: Mac tiger 5.3 client date?
Oops, I meant that v5.2.4.0 was visible to me with IE, the other browsers were 'iffy'. I also think that IBM/Tivoli believes 5.2.4.0 to be a maintenance level, hence its location. I've seen this modus operandi before. It's only when the level changes does it become a 'patch'. Watch out for memory conditions with larger Macs with lots of files. I thought the April 1st date appropriate... Roger Deschner wrote: V5.2.4 for Mac was invisible because there are two different locations for this kind of thing, and IBM has failed to match up all the symlinks correctly. I had been looking at /storage/tivoli-storage-management/patches/client/v5r2/Mac which only contains up to v523. However, v524 is located at /storage/tivoli-storage-management/maintenance/client/v5r2/Mac The difference is that patches has become maintenance. Gretchen: I bet the reason you are having different results with different browsers is that you have bookmarked one or the other of these two different URLs in your different browsers. I was able to find Mac 5.2.4 just fine with IE. And, Gretchen, thanks for tipping me off to the fact that it existed, because then I was able to torture the search feature until it confessed. Our Mac tiger folks will be trying 5.2.4 out today.
Re: Mac tiger 5.3 client date?
Roger, There is a v5.2.4.0 client available (as of April 1st). It isn't visible via IE or Safari (haven't checked since the Safari software update), but you can 'see' it if you use command line ftp or Netscape. Our Mac Tiger people have been running this fairly successfully for a while. It would be nice to see the Mac version catch up to the rest of the clients. Be aware that changing the memory efficient backup in the GUI Preferences doesn't update the underlying Preference file... Gretchen Thiele Princeton University Roger Deschner wrote: We've got a growing number of people running Mac OS X 10.4 (tiger) who are having problems with the ISTM Mac Client 5.2.3. There was discussion a while back of 5.3 coming out on September 30. Is that still likely?
v5.3.1.0 server on AIX 5.1
Is anybody experiencing a 'freeze up' on v5.3.1.0? I'm running AIX 5.1 with all of the requisite updated libraries. Not doing anything out of the ordinary when the server just runs like mud. Can't issue any commands, all new sessions in a Start state. It means killing off the process from the operating system and restarting the server. No other changes other than the move from 5.3.0.2. At first I thought it was ACSLS/tape related, since going to the new ACSLS driver weird things have been happening in the silo (I let TSM manage its own scratch tapes, with the new server it can't find them anymore, even though q libvol shows they exist). However, I have backed off the ACSLS package back to v5.3.0.2 and the freeze and scratch tape problem still exist. Probably not a driver issue since one of the freeze ups happened without any tapes in use or mounted. Getting ready to call this in, but checking with the list first... Thinking about peeling off v5.3.1.0 and going back to v5.3.0.2 at this point. Gretchen Thiele Princeton University
Re: Anyone installed 5.3 yet?
Would you please elaborate on your problem with FILE volumes? Are you no longer using them? Thanks, Gretchen Jurjen Oskam wrote: On Mon, Jan 24, 2005 at 01:15:47AM -0700, Paul Fielding wrote: I'm interested to know if anyone has tried installing 5.3 yet and what they've found... Yes, we're on AIX 5.2 and TSM 5.3 here. Very smooth upgrade (from 5.2.3), runs OK. We did hit a bug with FILE volumes, and cannot reliably use FILE volumes. Fortunately, it was quite easily worked around by temporarily using DISK volumes.
Re: client 'set access' command
By 'disrupt' I mean moving a node to another server... I presume renaming the node would preserve the 'set access' rules. No select that I can issue to see what they've done? Andrew Raibeck wrote: I can't think of any other way to do what you are talking about. Just out of curiosity: how would you disrupt someone's set access commands? This is something the user can do without admin intervention.
Re: SQL Help
The group by statement is incorrect, use the following: group by pending_date the conversion to date format is already taken care of in the first part of the select statement. David E Ehresman wrote: tsm: ULTSM select date(pending_date) as Date,count(*) from volumes where - cont status='PENDING' group by Date ANR2940E The reference 'Date' is an unknown SQL column name. | .V. e,count(*) from volumes where status='PENDING' group by Date ANS8001I Return code 3. [EMAIL PROTECTED] 11/30/2004 9:09:03 AM From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of David E Ehresman I'm trying to get a count of tapes pending by date. I'm using: select date(pending_date),count(*) from volumes where status='PENDING' - group by date(pending_date) but I get the error message: ANR2904E Unexpected SQL key word token - 'DATE'. pointing to the date in the group by clause. Anyone know how to get a pending count by date? Try select date(pending_date) as Date,count(*) from volumes where status='PENDING' group by Date -- Mark Stapleton ([EMAIL PROTECTED]) Berbee Information Networks Office 262.521.5627
Re: To know what are empty scratch volumes in a pool
select volume_name, status from libvolumes where status='Scratch' or, if you have multiple libraries attached: select library_name, volume_name, status from libvolumes where status='Scratch' Sandra wrote: Dear All, Please give me the knowledge of a query that can give me the names of tapes, that in my scratch pool. I know there are 3 tapes that are scratch, but i don't know the volume labels. What command would give me the volume labels for those tapes? Kind Regards, Sandra
Re: TSM and IBM NAS100 device
I am currently testing a NAS device from NetApp and using it as a primary disk pool (it's being used 'raw', then I'll set it up as devt=file and so forth). NetApp gave me a white paper on using their devices with TSM and it's available on their web site, netapp.com, search for TSM and you'll find it. Gretchen Thiele Princeton University Nicolas Savva wrote: Hi to all, I have one question regarding TSM and IBM NAS100 box. Can i use NAS100 as a primary storage pool for TSM? This is because i want NAS100 device to be configured as a TSM Primary storage pool.
New Mac Client, dual problems?
A new Mac client, v5.2.2.10, was just released. Has anyone been able to run the Mac client successfully on a dual G4 or dual G5? OS is 10.3.x. I know one of the duals is an XServe, not sure about any of the others that are having problems. Gretchen Thiele Princeton University
v5.2.2.4 patch on Solaris
Has anybody successfully installed this patch yet (yup, I realize that it just came out last night)? I was upgrading from v5.2.2.3 to v5.2.2.4, when it gave me the license hasn't been accepted yet message. It further instructs to remove the partial install, install v5.2.2.0 (which I did ages ago), accept the license and then apply the patch. No go, even going back to v5.2.2.0 and then forward to v5.2.2.4. Bad package assembly? The README says that it should install over a v5.2.2.x base where the v5.2.2.0 license has been accepted. By the way, this is Solaris 9. Gretchen Thiele Princeton University
[Fwd: v5.2.2.4 patch on Solaris]
To shed more light on this situation, it looks like it depends on whether or not you do a pkgadd with the '-R' option (which we do). The license check is only looking for the license file (status.dat) in the BASEDIR (default is /opt) directory. Can't change either the checkinstall file or the pkginfo file because the file sizes and file checksums are checked as well. Changing the installation from /var/local/opt to /opt isn't an option. I would then expect this patch to install successfully for default installation paths (/opt) and fail for anything else. So my question has changed somewhat, has anyone been able to install the Solaris v5.2.2.4 server patch in a directory other than the default? Original Message Subject: v5.2.2.4 patch on Solaris Date: Wed, 14 Apr 2004 13:12:45 -0400 From: Gretchen L. Thiele [EMAIL PROTECTED] To: ADSM: Dist Stor Manager [EMAIL PROTECTED] Has anybody successfully installed this patch yet (yup, I realize that it just came out last night)? I was upgrading from v5.2.2.3 to v5.2.2.4, when it gave me the license hasn't been accepted yet message. It further instructs to remove the partial install, install v5.2.2.0 (which I did ages ago), accept the license and then apply the patch. No go, even going back to v5.2.2.0 and then forward to v5.2.2.4. Bad package assembly? The README says that it should install over a v5.2.2.x base where the v5.2.2.0 license has been accepted. By the way, this is Solaris 9. Gretchen Thiele Princeton University
Re: [Fwd: v5.2.2.4 patch on Solaris]
Hi Bill, Where is your status.dat file? I suspect that since you used the default install first, it is in /opt/tivoli/tsm/server/license - since that is where the preinstall file looks for it. I use pretty much the same command, although without the -a option. What do you have in your admin file? Regards, Gretchen On Apr 14, 2004, at 4:58 PM, William F. Colwell wrote: I install tsm to the default directory and run the library manager from it. Then I install to other directories and run server in those; I currently have 4 alternate installations. The command I used is - pkgadd -a /opt/tsmmisc/adminfile -R /opt/tsminst/1a -d $IN
Client/Server Expiration Problem
Due to a change in policy (and limited storage), we're going to limit what we back up. The problem lies in how to 'expire' the files on the server without re-backing up the data, while maintaining deleted files for the duration of retonly. While we could rename the filespace and implement the new policy, this is a lot of administrative work and I don't think we would be able to accomodate the data (storage and bandwidth). Prior to the v4.2 client, you could simply exclude the files on the client side and the files would be expired. This probably led to unpleasant/unexpected results, so this doesn't work anymore and the client expire was introduced. THE PROBLEM: I need to expire subdirectories without explicitly naming them. The client expire command only expires the named subdirectory, ignoring any include/exclude statements in the config files and not accepting -subdir=yes on the command line. If I enter 'expire c:\junk\*', I expire all of the files in the junk directory, but none of the files in any subdirectories will be expired. Wildcards, such as c:\junk\...\*, aren't supported, and the -filelist option requires explicit filenames and/or directories. Since I need to run this from the server as a scheduled command and it's not feasible to get the precise list of subdirectories for each of 5,000 clients, I'm stumped. Am I missing something? Server is AIX 5.1, TSM 5.2.2.1 and the clients are Windows (Win9x, Win2K, WinXP) with TSM 5.x.x.x (will work on Unix nodes after these are done). Gretchen Thiele Princeton University
Re: Client/Server Expiration Problem
I've tried this, but the files are not expired on the server (no Expiring --- message in the dsmsched.log). The unexpected or unpleasant side effects that I am referring to are actually expiring the files on the server - maybe people didn't expect this to work this way? Principle of least astonishment? Should I expect to see expiring messages or a change in the number of files expired (when I run the incremental manually)? When I change the dsm.opt and run either the scheduled incremental or a manual incremental, run the server expiration, then check from the client, the files I want to get rid of are still there, both active and inactive versions. I don't have a problem with excluding a directory. My problem is getting the files to expire on the server after I have excluded the directory. I want to be able to modify the client dsm.opt file (or in our case, put these statements in a client option set) to implement our new policy, and then run an expire command on each client to force the expiration of the files on the server that aren't part of the new policy. I can do this if I specify each and every directory and subdirectory on the client, but this could run into the thousands and would be different on each computer. I need the client expire command to support directory wildcards or recognize the -subir=yes option. Maybe the exclude on the client should force the expiration of those files on the server? Andrew Raibeck wrote: Gretchen, I don't understand the following: Prior to the v4.2 client, you could simply exclude the files on the client side and the files would be expired. This probably led to unpleasant/unexpected results, so this doesn't work anymore and the client expire was introduced. What unpleasant/unexpected results are you referring to? If no longer wish to back up files in c:\junk and it's subdirectories, then I don't see why using EXCLUDE.DIR wouldn't work. You could use a client options set to do this. Gretchen Thiele Princeton University
Re: Client/Server Expiration Problem (long post)
Hi Andy, That's what I'm doing, but I'm not seeing the results that you are. I do notice that there is a difference in the servers we are both using, yours is v5.2.0.0 (Windows) and mine is v5.2.2.1 (AIX). What your output shows is exactly what I want to happen... either a problem with the platform or the version? Andrew Raibeck wrote: OK, I'm probably missing something in what you are saying, but I still don't understand. Excluded files are expired during regular (full) incremental backup processing. Nothing has changed in that regard. Using EXPIRE has the same effect as EXCLUDE: The files are expired on the TSM server and managed per criteria as deleted files (i.e. subject to VERDELETED, RETEXTRA, and RETONLY). I've attached sample data for directory c:\amrtest. The steps I performed are as follows: a) Ran QUERY BACKUP to show the existing active and inactive versions. b) Defined a client option set that contains an EXCLUDE.DIR statement for c:\amrtest (not shown here). c) Ran INCREMENTAL. Note the expiring files. d) Repeat (a) above. This time note that there are fewer versions (VERE=5, VERD=2). All versions are inactive and will expire per management class criteria. Is there anything here that does not accomplish what you wish? By the way, the EXPIRE command would do the same thing: leave the 2 versions due to VERDELETED, which will expire based on RETEXTRA and RETONLY value. Gretchen Thiele Princeton University
Re: Tsm not using drives
What does 'q path' show? Gretchen Thiele Princeton University Lee, Gary D. wrote: Have a devclass 3590 with mountlimit=4. However, when doing migration, I never see more than three drives in use. Even though I seem to have available mountpoints, always there is at least one process waiting for mountpoint. I do a q mount and never shows all four in use. TSM v5.1.6.2 on solaris 2.8, library is 3494 with four 3590b drives. All drives show on-line and available from q dr. Any ideas of where to start looking?
Re: OSX, TSM 5.1.5.0 Not backing up long shortnames
Actually, you now need to go to a v5.2.x.x client. It's not perfect, but it's better (still needs to run when the user(s) is(are) logged off! ftp://index.storsys.ibm.com/tivoli-storage-management/maintenance/ client/v5r2/Mac/v520/ Gretchen Thiele Princeton University On Wednesday, Aug 6, 2003, at 16:47 US/Eastern, Alexander Lazarevich wrote: What is the FTP site? tivoli.com says nothing. I have 5.1.5.0, need 5.1.5.13.
Macintosh 5.2 client
Well, on the whole, I'm happier with this client than I have been in a long time. There is unicode support, so make sure that you have 'autofsrename yes' in the client files or just update the node on the server. A couple of oddities, though. 1) There isn't an exclude.dir for the OS X System folder, but it doesn't show up in the backup directory window. When you go to the exclude-include tab in the preferences window, it's there! No duplicate version of the 'dsm.sys' (shorter than typing out the entire Mac name) file exists. If you save the new file from this window, the exclude.dir for the system folder now appears! 2) Some strange behavior when upgrading from 5.1 with regard to passwordaccess generate (just taking the default). The first time I signed on, a new v5.1 folder was created (I had trashed the old 5.1 folder) and the encrypted password was placed in it. After I threw that one away, I was prompted again for it and it created a new encrypted entry in the correct, v5.2 folder. The second one was more of a nuisance and I'm trying to recreate it to see if it's going to affect a rollout. The first one concerns me - or should it? Is the OS X system folder 'restorable'? If I have to do a 'bare metal restore' (or as close as I can get to that), will I need to worry about the System folder. The System 9 folder was backed up on dual boot machines. Gretchen Thiele Princeton University
Re: Macintosh 5.2 client
The scheduler and scheduler daemon work fine. But my caveat is that I haven't tried to run it as 'root', only from a logged on (and left on) user. Ideally, I'd like it to run as the Windows scheduler does, backing up even if no one is logged on. This may be implemented, but I haven't found it or figured it out yet! By the way, it's the TSM Scheduler that creates (and recreates!) the v5.1 folder for the encrypted password. I'm going to try to define another location for it and see if it's still a problem. Relocating the encrypted password hasn't worked in the past, so I'm reluctant to futz with it. Fred Johanson wrote: Gretchen, How's the scheduler working??? That's something my MAC guys have been complaining about for a long time. Gretchen Thiele Princeton University
Re: v5.2 update...
On Saturday, Jun 21, 2003, at 10:02 US/Eastern, Bill Boyer wrote: So you mean that the new TSM V5.2 is only supported on AIX 5.1 and above? Correct, AIX 4.3.3 is not supported for TSM v5.2. I vaguely remember this restriction being discussed, because I had planned to get to AIX 5.1 this summer. I wouldn't be upgrading AIX if TSM didn't require it. Gretchen Thiele Princeton University
v5.2!
WAHOO! The v5.2 media is here! Off to install it on our test server... Gretchen Thiele Princeton University
Re: v5.2!
Pearson, Dave wrote: Where is the TSM Version 5.2? I only see up to 5.1... It isn't available on the web pages - this is a physical distribution on CDs. HOWEVER, checked the doc and it says that AIX 4.3.3 is supported, but when I go to install, everything fails because I'm missing two prerequisites: bos.rte 5.1.0.0 and bos.mp64 5.1.0.1, which are both AIX 5.1 filesets. Bummer. Going to poke around a bit further. Gretchen Thiele Princeton University
v5.2 update...
Well, even though the v5.2 Quick Start Guide says that AIX 4.3.3 is supported, it isn't. There's an error in the Quick Start Guide for AIX on the web page. Oh well, was worth a shot. Heading off to work on an AIX upgrade! Gretchen Thiele Princeton University
v5.1.7.0 - so far, so good
I've had v5.1.7.0 in test for a bit and went live with it on two servers this morning. I was pleasantly surprised (and pleased) that I could now delete filespaces and nodes that had been problematic earlier (see my earlier posting on auditing a db and Jim Owen's explanation of the problem). Server is AIX 4.3.3. Gretchen Thiele Princeton University
Re: Error 2 deleting row from table Expiring.Objects [was Re: Auditdb timing]
Arrgh. Thanks, Jim, for posting all of this information. I've gone back and reviewed our logs for the past couple of days and I can't believe how many of the imbkins.c messages I'm finding. I suppose this means that I'll have trouble deleting these accounts when the time comes. Although most of the errors I'm seeing are on fairly current clients with Win2K or WinXP (v5.1.5.9), I am getting a few of these for Linux clients. Probably not the same problem. I hope they come up with a cleanup utility for this - I can't see running audits all the time to correct this. It also isn't doing wonders for my confidence in the backups (will test a few of them this weekend). Gretchen Thiele Princeton University On Tuesday, May 27, 2003, at 05:19 PM, James R Owen wrote: Gretchen, et al. We have been working with IBM level 2 support on this same problem. We discovered it while trying to delete a SYSTEM OBJECT filespace, but the problem first appears during the SYSTEM OBJECT backups.
Re: I don't know where to look
This is a client publication that was last updated circa v4.2.x.x, so it is in the v4.2 client publication section: http://publib.boulder.ibm.com/tividd/td/IBMTivoliStorageManagerClient4.2.html Where can I find the following publication: Tivoli Storage Manager Trace Facility Guide GC32-0792 Gretchen Thiele Princeton University
Re: Dumb License Question
I've found that you can indeed delete licenses by setting the number of licenses to zero (I think you must be fairly current with your server, mine are at v5.1.6.3): register license file=./library.lic number=0 removes all of the library entries. Similarly, register license file=./mgsyslan.lic number=0 removes all of the clients. Note that you can also *lower* the number of licenses. If you are licensed for 2,000 clients, you can reduce that license to 1,000 clients: register license file=./mgsyslan.lic number=1000 Gretchen Thiele Princeton University Hart, Charles wrote: Thanks, that's what I was afraid of. Regards, Charles -Original Message- From: Sias Dealy [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 7:47 AM To: [EMAIL PROTECTED] Subject: Re: Dumb License Question Charles, If you register the wrong license or too many license. There is not a remove or a delete license command. If you want to see this feature in future release of TSM, need to call IBM TSM Support and submit a design change request. To change the license. Need to locate the nodelock file. It should be in /opt/tivoli/tsm/server/bin/ . Stop the TSM server application. Rename or move the nodlock file to another directory. Restart the TSM application, then re-register all the license. Sias Get your own 800 number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On, Hart, Charles ([EMAIL PROTECTED]) wrote: TSM 4.1.6 on Solaris 8 I added to many mgsyslan.lic licenses and now I would like to reduce it. I looked in the Ref and Admin guide and found no REM or DEL lic, there's reference to the Nodelock file, but not sire if I could blow it a way and re-register? Fat fingers in the Morning Thanks!!!
Re: 5.1.6.2 Upgrade
On Wednesday, Feb 26, 2003, at 04:17 US/Eastern, Gerhard Rentschler wrote: In my opinion 5.1.6.2 seems to be the stable version we have been waiting for. I think I can second this. I've been at v5.1.6.2 on our production servers for about a week and the big issue here was the recovery log pinning. It seems to be better behaved and I'm not getting paged at night to deal with log problems. I haven't seen the help message formatting problem (reread the README to see why you have to select the 'install all software'). My only complaint is the speed of the expiration - it's never fast enough for me. Gretchen Thiele Princeton University
Re: ACSLS or Native TSM manager
Dameon White wrote: We just bought a used STK L700 with 4 DLT7000 drives. We have TSM 5.1.5.2 on AIX and I am confused as to why/if I would need to use ACSLS to manage the library? Does ACSLS You don't need ACSLS for an L700. I found that I could do everything I wanted without it (I do have ACSLS managing a 'regular' silo and two L700s without it). My L700s are dedicated to TSM - if yours are not, you probably could benefit from ACSLS. Gretchen Thiele Princeton University
v5.1.6.1, so far and v5.1.6.2
The problem I was having with v5.1.6.1 can be traced to a monitoring package we were trying out. It's a problem that manifests itself on heavily loaded servers with a ton of scheduled sessions. Working with the vendor to do further problem determination. Now, as for v5.1.6.2, I've put it on my test servers and will go live with it this week. I need the fix for the EOT problem. Gretchen Thiele Princeton University
v5.1.6.1, so far
The two situations where I could force a core dump in v5.1.6.0 have been resolved, but I think there is now a different problem in v5.1.6.1. Granted, my servers run flat out all the time with sessions constantly, but I rarely pin the 13 GB log with dirty pages (at least not over 60 to 70%). It's happening all the time now. I've had to cut back on my workload by two thirds in order to get the log to settle down. Not good. It took out two of my servers a couple of times over the weekend until I severely limited the number of sessions and scheduled sessions. The log would creep up and I'd get the 'log is pinned by a dirty page' from 'show logpin'. When the log started to cool off, but not drop in utilization, this message would alternate with the 'log not pinned, will be cleared at next commit'. It took one server over 5 hours last night to 'calm down' - I disabled sessions when it hit 40% and it climbed to over 80% before it started to wane. Also, when it's a client that has the log throttled, it's almost impossible to cancel the session before the log fills and core dumps the server. A 'cancel session force=yes' would be really nice about now. It's about a wash whether or not to allow the log to fill and core dump or just halt the server and let it come up again and 'figure' things out. It'd be nice to know if we can force a commit or if it's time based, just when does it happen? Gretchen Thiele Princeton University
Re: TSM Server 5.1.6.1
Hi Geoff, I noticed that v5.1.6.1 was made available late on Friday and I, too, put it on test servers this weekend. So far, so good. I plan to go live this week. In debugging the v5.1.6.0 problem, I was asked to enable a server trace. This bogged down the server but at least avoided all of the core dumps. I need to lose the server traces asap. Gretchen Thiele Princeton University
v5.1.5.4 redux
Just a heads up to anyone who might have installed AIX server version 5.1.5.4 prior to last Thursday (12/12) morning. The .gz file was replaced and now includes a 5.1.5.4 version of the common services file (server.com). It doesn't appear that the server.rte and messages file were changed. Gretchen Thiele Princeton University
Re: TSM SERVER 5.1.5.2
Be advised that v5.1.5.3 was pulled off the ftp site on Friday and replaced with 5.1.5.4. There is a problem with the expiration not actually deleting the files. A new cleanup utility will be introduced in v5.1.6.x (per support contact yesterday). I was advised to upgrade our v5.1.5.3 servers *immediately*... Gretchen Thiele Princeton University
show logpin vs. show log pin
SHOW LOGPIN is not in v5.1.1.6. It was added back in on the newest maintenance/patch - v5.1.5.1. The command is: show log pin ...and it works on 5.1.1.6 on AIX But it's not the 'same' command. 'show log pin' is different from 'show logpin'. For example, on a v4.2.2.12 system (looks the same on v5.1.5.1): show log pin Log status information:HeadLsn:2735079.236.3435 TruncLsn: 735079.223.313 Log record read statistics:NumRandReq=352207, NumRandRead=8 997 (Hit 77.00%)Sampled batch read time (ms): *** no sampled data *** Sampled read batch size (#pages): *** no sampled data *** Sampled random age read time (ms): *** no sampled data *** Log record write statistics: NumForces=226331, NumForceWait=154618 (Hit 31.69%) NumPushes=2348501, NumPus Wait=0 (Hit 100.00%)Sampled append time (ms): *** no sampled data *** Sampled push time (ms): *** no sampled data *** Sampled force time (ms): *** no sampled data *** Sampled log bytes between forces: *** no sampl d data *** Log Writer thread statistics:Sampled full batch write time (ms) *** no sampled data *** Sampled full batch size (#pages): *** no sam led data *** Estimated mean page write time (ms): 0.00 show logpin Dirty page Lsn=2735079.232.2161, Last DB backup Lsn=2735079.236.3843, Transaction table Lsn=0.0.0, Running DB backup Lsn=0.0.0, Log truncation Lsn=2735079.223.313 Lsn=2735079.223.313, Owner=DB, Length=190 Type=Update, Flags=C2, Action=ExtInse t, Page=228, Tsn=0:69060303, PrevLsn=0.0.0, UndoNextLsn=0.0.0, UpdtLsn=2735079.222.3355 === ObjName=Activity.Log, Index=32, RootAddr=49, PartKeyLen=0, NonPartKeyLen=9, DataLen=81 The recovery log is not pinned. Space in the recovery log will be freed at the next checkpoint The latter command, show logpin, is the one that is missing in v5.1.1.6 on all platforms - I pointed this out to support and they verified that it was missing and said it would be added back in the next maintenance release, v5.1.5.0. 'sho logpin', if the log is actually pinned, will show you who the culprit is or what process is pinning the log. It's very useful command. 'sho log pin' doesn't do much for me! Gretchen Thiele Princeton University
SYSTEM OBJECT problem back in v5.1.5.1?
I've just put v5.1.5.1 into test and it looks like the SYSTEM OBJECT problem (failure to expire the elements in the SYSTEM OBJECT filespace for Win2K and WinXP) is back. Has anyone else seen this? My test server: Solaris 2.8, TSM v5.1.5.1 Clients: WinXP, TSM v5.1.1.0 and Win2K, TSM v4.2.1.0 I ran the expiration successfully and to completion as well as the cleanup backupgroups command. Will check this out on AIX 4.3.3, TSM v5.1.5.1 this afternoon. Gretchen Thiele Princeton University
show logpinned
What is the show command to see who has the log pinned? Is it in AIX server 5.1.1.6 level? SHOW LOGPIN is not in v5.1.1.6. It was added back in on the newest maintenance/patch - v5.1.5.1. Gretchen Thiele Princeton University
Re: Anyone tried 5.1.1.6?
Hi Fred, I just took a v4.2.2.12 AIX server to v5.1.1.6 last Saturday. All I can say is 'not pretty'. This is due to the SYSTEM OBJECT problem. If you don't know what this is, you will soon if you have WinXP and Win2K clients backing up to v4 and pre v5.1.1.6 servers. The basic problem is that TSM isn't expiring anything in the SYSTEM OBJECTs filespace. Some of our clients had over 20GB in these filespaces! Needless to say, the database blew up while trying to find out what was going on. To see if you have this problem, you can type in show version nodename SYSTEM OBJECT namet=uni file (only use namet=uni if the filespace is unicode). Then check through the file and look for the number of occurrences of a file, say ROUTE.EXE. A normal SYSTEM OBJECT filespace, with four versions, shouldn't be over a gig. The good news is that v5.1.1.6 does NOT have the SYSTEM OBJECT problem and the new server is doing very well. I am writing up the post mortem on the conversion and will post to the list later this week (at the request of Tivoli level 2). Gretchen Thiele Princeton University
Re: Anyone tried 5.1.1.6?
Hi Fred, I've seen the SYSTEM OBJECT problem, it's especially pretty when you can't run expiration for six weeks. It's a pain, I've got a routine set up to find the oversized SYSTEM OBJECT filespaces and then delete them, but I have two servers with thousands of WinXP/2K nodes that bloated the databases up to 250GB. I'm just trying to stay above water on these two and then just move the nodes to a v5 server for a big 'do over'. Sigh. Bottom line, get your SYSTEM OBJECT filesystems in check now! But I haven't had a scheduled session accepted since I hit MAXSESS at 3:04 yesterday morning. Are you seeing this in 5.1.1.6? Not sure what problem you are seeing. If all of your sessions are in use, i.e., you've hit MAXSESS, I wouldn't expect any scheduled sessions to get in. Or am I missing something? Gretchen Thiele Princeton University
CLEANUP BACKUPGROUPS in v5.1.1.6
I ran into this in my conversion, too: ANRD imutil.c(6663): ThreadId67 Failure deleting member 0 585368742 for group 1637 3 - encountered repeatedly in loop. It took an audit (fix=yes detail=yes) to correct. If you try to run expire invent, you will notice that it has a tough time ending. There are other things that I ran into during the audit that I will write up and submit this week. Gretchen Thiele Princeton University
Re: Anyone tried 5.1.1.6?
Hi John, I've looked at our servers and have over 1.2 terabyte in system object data, and 11,700,000 files. This from 1400 nodes. Do you mean to say by delete them you actually go out and del fi * SYSTEM OBJECT? Yup, delete them, they'll back up again. We had over 15TB in these files and I'm down to 11TB now. If you delete them now (presumably without error), you'll save yourself a lot of CLEANUP BACKUPGROUPS processing later. Either way, it has to happen. Oh, and you might have to defrag your database... I've done this on a small server (4.5% utilized on 166 GB allocated) and it took all day to get to v5.1.1.6. I probably would have fared better if I had deleted all of the SYSTEM OBJECT files, but I only nuked the ones above 1 GB. I didn't defrag this one because the level of fragmentation was only about one percent. Again, I'm writing the whole thing up for the list... It's a risk, because our bare metal restore procedures depend on a current SYSTEM OBJECT backup, but I can't let the database swell to infinite proportions - the performance is horrible. Luckily, the problem is fixed in v5.1.1.6. Gretchen Thiele Princeton University
Re: Anyone tried v5.1.1.6?
You can always rename the filespace and allow a backup or two to complete before deleting the old filespace.(At least on the NT platform) This is an excellent suggestion! Also, you don't want to do so many at a time that your database becomes 'unbalanced' (a level 2 caveat). Again, identify that you have the problem, then plan your course of action. Gretchen Thiele Princeton University
Re: Anyone tried 5.1.1.6?
I found that the SYSTEM OBJECT which were not unicode were never deleted unless I did it manually. A QUERY OCC * SYSTEM OBJECT (without the NAMETYPE=UNICODE option) will let you know if you have that problem. Also, did you run the command CLEANUP BACKUPGROUPS? For me, on 5.1.1.4 it ran but never cleaned everything up and it wouldn't run on 5.1.1.6. I finally had to do an AUDITDB FIX=YES. Actually, this problem occurs with both unicode and nonunicode SYSTEM OBJECT filesystems. If you delete the nonunicode filesystem it will rebackup as unicode. The new unicode SYSTEM OBJECT filesystem will continue accumulate extra versions as well. I could run CLEANUP BACKUPGROUPS with an earlier v5 version, but it didn't work (I ran it, but then ran it again and it found more errors). The CLEANUP didn't work (got the loop problem) under v5.1.1.6, but then the AUDITDB didn't work! This is what I'm writing up... Gretchen Thiele Princeton University
Re: TSM v4.2.2.5 to v5.1.0.0 upgrade failed (AIX) - resolution
Is this problem unique to us? Probably not. It's related to a client problem that showed up about two weeks earlier. An error about deleting entries from the Expiring.Objects table (or something close to that). Check out all of your recent ANRDs. In any event, this error represented a 'corruption' in the database and you can't upgrade a database in this condition. I did try to delete the account in the hope that it would take the bad whatever with it, but that, too, failed. The audit is required to fix this situation so that we can upgrade. If you aren't seeing any errors, you probably won't have a problem. I always go into an upgrade prepared - backups, migrate everything off disk, etc., so that I can recover on a moment's notice. Having recovered WDSF/ADSM/TSM databases *way* too many times in the past, it's a lot easier now than it has been. Since I don't have the luxury of a test system, I approach every upgrade as a recovery 'opportunity'. Gretchen Thiele Princeton University
Re: TSM v4.2.2.5 to v5.1.0.0 upgrade failed (AIX) - resolution
Here is the newly minted APAR number for the problem I experienced last week: IC33977 This was the problem that prevented me from upgrading to v5.1.x and requires a database audit. It was too late to get everyone's agreement last Friday to run the audit, so it will happen over the July 4th weekend. Will post the results when done. Gretchen Thiele Princeton University
TSM v4.2.2.5 to v5.1.0.0 upgrade failed (AIX) - resolution
I now have an answer from Level 2 - it's a known problem and requires a database audit to resolve. This is an 86% utilized 100 GB database and should run two, if not three days (I hope!). Again the error message was: ANRD iminit.c(820): ThreadId0 Error 8 converting Group.Members to Backup.Groups. Getting clearance from those affected now and will try to run this over the weekend and upgrade next week. Will post audit stats at the end of the process. Gretchen Thiele Princeton University
upgrade from v4.2.2.5 to v5.1.0.0 failed (AIX)
I now in the process of recovering to v4.2.2.5 from an attempted upgrade to v5.1.0.0 (from the CD). All went well from an installation point of view, but when I started the server I got: ANRD iminit.c(820): ThreadId0 Error 8 converting Group.Members to Backup.Groups. Called it in as a sev 1 over an hour ago, but haven't gotten a callback yet. Since this is production, I can't wait anymore and decided to recover. Not sure what to do now except wait for support to call back. I really need the move nodedata command... Gretchen Thiele Princeton University
Re: upgrade from v4.2.2.5 to v5.1.0.0 failed (AIX)
Did you apply the latest patches to 5.1.0.0? (5.1.0.2, I believe.) Yes, when the v5.1 CD didn't come up, I applied v5.1.1.0 (in the maintenance section of the ftp site). Same results. It's acting like some of the database wasn't converted with the upgrade. I then tried to do ./dsmserv upgradedb, no change. When I put v4.2.2.5 back on, I tried starting it up on the chance that the database hadn't been converted. No such luck. So, after 6.5 hours, I have my 100GB server back! Gretchen Thiele Princeton University
Mac OS X scheduler
Well, I suppose this makes sense. There was a file called TSM Timer.txt (or something close to that) in previous versions. This was a flat ASCII file that kept a date/time stamp for either the next scheduled event or the next/last contact with the server. I'll give this a shot, too. I can't seem to find confirmation anywhere of successful implementation of the 5.1 client on Mac OS X, particularly the scheduler daemon. I spoke with Level 2 and they asked us to trace the scheduler daemon by creating a file called TSM Daemon.txt in the directory where the scheduler daemon is installed. Just thought I'd pass that along and see if anyone has any thoughts, success, etc. Gretchen Thiele Princeton University
Re: TSM mtx devices unavailable after reboot?
I was experiencing the same phenomenon - each reboot of the server would blot out my mtx devices and I have to remove them and then redefine them. Trying to troubleshoot another problem, I found that the microcode for the FC adapter cards was woefully backlevel. Once the cards were updated, no more problems with rebooting. Gretchen Thiele Princeton University
v4.2.2.2 - problems with expire inventory
On our well-behaved and moderately loaded system, I am not seeing a problem with anything in v4.2.2.2 (AIX 4.3.3). However, on the more 'abused' systems, ones that are constantly migrating and have users on them all the time, the expiration hangs whenever there is a migration, reclamation or move data going on. Simultaneous expiration and migration wasn't a problem on the well-behaved server. I am letting one run with a migration right now to see if it eventually resolves itself (deadlock?). Right now, it's going on 15 minutes and has locked up the other migration process. I'm not sure if backups to the disk pool are affected yet. At 30 minutes or so, I'll halt the server, restart and call the problen in. Gretchen Thiele Princeton University
v4.2.2.2 patch
So far, the v4.2.2.2 patch on AIX 4.3.3 has held its own for the past 24 hours, even through several expires. A little more testing today and then I'll apply it to my problem servers. I have been collecting a sampling of the output of the show logpinned command to see what the results look like at various stages of 'distress' on the server. It's going to be a useful tool, as previously I just started cancelling the oldest sessions that didn't seem to be moving much data. Still, it would be nice to resolve this issue (other than expanding the log past 13 GB)! Gretchen Thiele Princeton University
downlevel client code - has anybody found a workaround?
Server: v4.2.1.11 (AIX 4.3.3) Client: v4.2.1.0 (Win2K), and later patch levels as well I am getting hit hard by the problem with the Windows client (or is it a server problem?) resetting the platform and the version so that an earlier operating system can't access the account. Case 1: Client backs up Win2K box with current TSM client, decides to revert back to Win98 with the same client, but can't access the data because the operating system is not as current (perceived by the server as being downlevel). Case 2: Client backs up a Mac with a current TSM client, administrator is asked to restore files, but uses a Win2K box to 'impersonate' the Mac (which they thought was a Windows box) to get the files. Mac can no longer access the account, because it is now downlevel. Case 3: Dual boot Win2K/Linux box, client backs up Linux side first, then does Win2K, goes back to Linux and gets the downlevel message. Note that cases 2 and 3 are *not* trying to do a cross platform restore. In case 2, it was a mistake by the admin, and in case 3, it is our policy to use one account for one computer - less 'stuff' to remember. This is going to be a huge problem for us. Looking through the archives, I haven't seen anybody's resolution to this. Other than exporting, deleting and importing the node in case 2 (who needs to do an emergency restore), I can't see a way out of this. Is this 'working as designed'? It never used to be this awkward. Any ideas? Gretchen Thiele Princeton University
Re: downlevel client code - has anybody found... solved
At Andy's suggestion, I called this problem into support. Not for the faint of heart, but the critical restore that I needed to get done today has now completed. This only affects WinNT and Win2K clients and the problem is the server, not the client. Support says that it will be fixed in the next release, whether or not that is v4.2.2.x or v.5.1.x.x, he didn't know. A unicode 'thing'. Thanks for everyone's responses. Gretchen Thiele Princeton University
Length of database audit and other migration lessons...
I'm currently in the process of migrating 8 v3.1 servers on VM, one v3.7 server on Solaris and one v4.1.2.0 server on AIX to totally different 'homes'. Mostly migrating to AIX v4.3.3 and TSM v4.1.4.0 (I'm a little gunshy about going to v4.2.whatever after reading the list lately and with all of the other changes). Because I have a 'spare' box, I'm practicing bare metal TSM server recovery. LOTS of lessons learned here, most of which I will cover at a session next SHARE. However, as long as I was playing around and had the time, I thought I'd run a db audit on the recovered server just to see how long it would take and perhaps provide a benchmark for others. Here is the environment: H80 (or whatever it's called now), 2 processors, 1 GB memory, AIX v4.3.3, TSM v4.1.4.0. The database is 110GB, 35% utilized (planning on growth!). db audit start: 20:17 10/22/2001 db audit end: 17:35 10/23/2001 elapsed:21:18 Over 350 million database entries processed. It sure would be nice to know approximately how many 'entries' there are in order to gauge how much further the audit process has to go. Anybody know where you can find this? Gretchen Thiele Princeton University
CompuServe Forum
Here's a bit more history on the CompuServe Forum. It was set up and officially supported by IBM because they were in control of the content and managed the forum itself. This was a service, pre-web, that CompuServe was offering companies. At a previous employer, we used CS forums for customer feedback, updates, etc. I thought it was kind of funky that IBM was venturing into what was then the 'PC world' and applauded this effort. It's since fallen into disuse and probably doesn't even exist anymore. IBM/Tivoli probably can't ever 'officially' endorse ADSM-L because they aren't in charge of it, don't own the equipment it's on (now, wait, it *is* Marist, so maybe...), and can't guarantee the accuracy of the information. Gretchen Thiele Princeton University
Re: Issues with Win2K SYSTEM OBJECT/SYSTEM FILES backup
We have another issue with Win2K backup of the SYSTEM OBJECT, namely, that it doesn't update its backup status when an incremental is run on it: Node Name: nodename Filespace Name: SYSTEM OBJECT Platform: WinNT Filespace Type: NTFS Capacity (MB): 0.0 Pct Util: 0.0 Last Backup Start Date/Time: Days Since Last Backup Started: Last Backup Completion Date/Time: Days Since Last Backup Completed: And this is after an explicit incremental. Maybe herein lies the problem? We noticed this because we use the Last Backup Start and Completion fields in our backup reports that we sent to users. The surge in the number of calls and emails was my first clue! Gretchen Thiele Princeton University
Re: TSM client for Mac OS X (again)
I can see where a full-function GUI client may take them a little time to complete, but the underlying API of MacOS X is BSD Unix. I'd expect a command line only client would be easy enough to port at least on an unsupported basis to accommodate the early adopters. There isn't a FreeBSD client either (another growing segment for us), but a student here is running the Linux client on FreeBSD in Linux emulation/compatibility (can't remember the term he used). We offered to do the port or assist with it, but because of the proprietary nature of the software that idea went nowhere. I was hoping that Apple would hold off on the rollout until the school year was over. This way, I'd have the summer to figure something out. Gretchen Thiele Princeton University
Re: WG: TSM Client for OS X
K! I've got a thousand Macs, all of them headed for OS X this summer. I heard that the Mac developer left and there was some scrambling to get out a new Mac client that could actually *restore* (thanks for that!), but to not support OS X would be devastating for us. If it hasn't been mentioned on the list already, there is a new Mac client in the patches subdir that solved a lot of our restore problems, on both VM and AIX servers. Gretchen Thiele Princeton University
Re: WG: TSM Client for OS X
OS X is very keen (as Richard noted) and will ship on all new Macs (as Paul noted). It is UNIX essentially, but it's based on BSD. I have a small, but vocal contingent wanting TSM on FreeBSD - maybe we could knock off two at once? The alternative is to hope that TSM works in Classic mode and find something else for the UNIXy side, much like I treat dual boot Winux (Windows/Linux) boxes (don't even get me started on VM Ware and Virtual PC problems). Gretchen Thiele Princeton University
Re: I cant delete a backupset . . .
I have the same problem, AIX v4.1.2.0. I used the 'delete backupset' command and it completed successfully, but the entry still clogging up the volume history file. I'd like to get rid of it without taking down the server, editing the file and starting the server up again. The backupset expired over a month ago. Gretchen Thiele Princeton University
Re: Can Mac clients restore ?????
The short answer appears to be "not very well". We've had a myriad of problems with our Mac clients. First the scheduler and now the inability to restore folders. Granted, we are running ADSM v3.1.2.5x on VM, but support assured me that v3.7 and even v4.1 clients would work (new features, of course, not available). We're stuck with v3.1.0.8 if we wish to backup and restore folders. If we went to v3.7.2 and tried to restore folders (files seemed to work fine, but try to restore an entire Mac by selecting each file individually!), it bombed; a new backup with v3.7 and the same thing happened. Likewise with v4.1.2. Our Mac community (over 1200 of them) needs v4.1 for the scheduler and OS 9.0.4 support. We *are* going to AIX and v4.1, but the transition doesn't happen over night (I have 6,500 accounts left to move before March 2002), and Macs are very important to us. Testing on AIX with Macintosh clients is going 'ok' so far, but I'm not holding my breath... Gretchen Thiele Princeton University
