TDP for Domino and Windows 2000 backup problems
I've got a client who is running TDP for Domino (version 1.1.1, I believe) on both Windows NT and Windows 2000 servers. His NT boxes back up his .NSF files just fine, but his 2000 boxes only get a handful of backups nightly, when he should be getting several hundred .NSF files backing up each night per Notes server. His TSM log files show nothing unusual. Has anyone else seen anything like this? -- Mark Stapleton ([EMAIL PROTECTED])
Re: TSM 4.1.1, WinNT 4.0 SP6a, San Data Gateway,and IBM 3584 LTO Lib rary
"Volovsek, Jay" wrote: > > Jeff. I would like to sincerely thank you for that input. You were right > on the money. When IBM configured the library, they configured it as four > Logical Libraries. I just blew away that configuration and set it up as one > LL. Now my servers only see one library with four drives. [major snippage concerning SANs, gateways, and fiber connections] This all goes to show that you shouldn't always blame the cutting-edge technology. It also proves that one should RTFM! The fact that the 3584 library defaults to one logical library for each physical tape drive is well documented in the 3584 docs. (In other words, it isn't a matter of how IBM configured it.) Take a little time to read the documentation, folks. It'll save you a lot of heartache later. -- Mark Stapleton ([EMAIL PROTECTED])
Re: client notification
John Bremer wrote: > > Indeed it is too bad TSM (or Veritas or Legato) doesn't supply a > notification mechanism. It's pretty simple for our UNIX clients to notify > themselves, but for others, not so easy. Indeed it is too bad that people don't understand the limitations of operating systems and the use of redirection. If you'll RTFM, you'll notice that each client that is backed up on a TSM scheduler basis has a file called DSMSCHED.LOG. TSM can redirect messages to only one location, no matter what the OS; in the case of a scheduled backup, DSMSCHED.LOG receives the message. If you want it to go somewhere else, you have to redirect it elsewhere. Sheesh. -- Mark Stapleton ([EMAIL PROTECTED])
Re: TSM 3.7 to 4.1 Upgrade
Shekhar Dhotre wrote: >I have experienced this before , upgrade deletes all drive info , and if you >try to reconfigure it , using smit tivoli ..you can`t you have to >1) delete drives from ODM use odmdelete .. (#rmdev -dl rmtx --does not work) Not true. I've upgraded from 2.x to 3.x, 3.1.x to 3.7.x, and 3.x to 4.1.x, and I've never seen an instance where 'rmdev -dl rmtX doesn't work. Trim your reply tree, Shekhar. It's much too long. -- Mark Stapleton ([EMAIL PROTECTED])
Re: TSM 3.7 to 4.1 Upgrade
Roy Lake wrote: > > Hi Chaps, > > Its coming to that time of the year where we have to think about upgrading our TSM >server from 3.7.x to 4.1.x. > > Can you please confirm what this process involves?. > > I understand that we have to re-define the licences, but do we also have to >re-define the library, and drives, etc?. > > Anywhere where I can find out more as the docs are as usual very unhelpful. Odd. I found the README file that comes with the server install files to be *extremely* helpful when it came to the gotchas of the upgrade. Actually, calling them 'gotchas' ennobles them; virtually everything mentioned as a caution in the README file was pretty much commonsense precautions. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Windows NT/2000 Daylight Savings Time Problem
Andy Raibeck wrote: > Yes, you do want to run this one. :-) > > You need to use the -d option when running IP21933_19_FULL.EXE, i.e.: > >IP21933_19_FULL -d > > This is described in the README.FTP file (it's in the same directory as the > IP21933_19_FULL.EXE file). Isn't it wonderful when people actually *read* the documentation? -- Mark Stapleton ([EMAIL PROTECTED])
Re: TDP for MS Exchange server is very slow
Leos Stehlik wrote: >From: "Vmt H|bner" <[EMAIL PROTECTED]> >>Standard Backup Clients on NT are working good, but TDP for MS Exchange >>server is very very slow (Full backup 6G/12h). > >I saw similar behavior. This could be because the TDP for Exchange by >default uses software compression >on the TDP side. We tried explicitly to set the COMPRESSION NO in the >DSM.OPT file, but this didn't solve >the problem. The goal was to do: >update node compression=no >This has been - of course - done on the server side. Keep in mind that settings that TSM uses in the dsm.opt and dsm.sys files do not necessarily affect TDP operations. (For instance, normal expirations do not affect databases backed up with TDP for SQL.) Most TDP applications have their own utilities for performing functions such as retention, expiration, and other operations. Review the manual, and look in www.redbooks.ibm.com. There is a redbook on TSM and MS Exchange. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Changing Servers OS390 to SUN
Luci Ziebart wrote: >I have numerous questions on this subject: >Today our ADSM Server 3.1.2.50 resides on OS390 2.5 and output media is on >3490e cartridges. We are planing to upgrade to TSM 4.1 and the server will >reside on UNIX Sun Solaris, the output media will be STK's 9840's PowderHorn >9310 silo and will be fibre attached to a brocade switch, in preparation >for a SAN enviorment. > >1) Can we Import our Mainframe server to the Sun? Yes. Basic steps are: 1--Install TSM on the desired Sun box. 2--Export your TSM database to a file. 3--FTP the file to your Sun box. 4--Import the file into TSM. >2)Will we beable to use the data that resides on the 3490e cartridges after we >move to the Sun Server? Yes, as long as you copy the volume history, device configurations, etc. to the new box, and the database is exported/imported to it. >Also, we will be eliminating Novell and replacing this with a NT solution. >Since, most of our archives and long term backups are associated with the Novell >servers. > >1) Will we beable to restore/retrieve a Novell file to a NT system? No. >2) Is there a conversion tool? No. Your best bet is to restore to a (legacy) Netware box left in the network, mapping a drive letter on an NT box to the Netware share that you dump the restored files to, and copying the files to the NT box. -- Mark Stapleton ([EMAIL PROTECTED])
Re: AS400 Performance problems
Reiner Sauer wrote: > we had an as400 mod. 170 and tsm V3 client . Tsm server is AIX 4.11. We have 600 >Kb/s transfer rate to the server instead of 3000 - 4000 Kb/s as the other systems >have (novell, solaris or aix). The backup tool is BRMS with tsm client option. > > Did everybody knows such problems and what can we do ? There is a well-known throughput bottleneck with BRMS. (600Kb/s is actually quite a respectable figure for BRMS.) This has existed for quite some time and appears to be unfixable. You have a couple of options. There are third-party packages that will allow AS/400s to communicate with TSM. You can also choose to ftp AS/400 files to a non-AS/400 platform such as an RS/6000, and backing those up. -- Mark Stapleton ([EMAIL PROTECTED])
Re: decision support odbc driver for db2?
Gerald Wichmann wrote: > That's not true. TDS 2.1 Includes an install options for "Tivoli 3.11 ODBC > drivers". It includes drivers for Oracle, Informix, Sybase, and MSSQL. No > DB2. So my question still stands. I have DB2 installed on an AIX box. I do > not have an NT ODBC driver for the TDS box. IBM's site is so convoluted I > can't find one there either. If anyone knows I'd appreciate some help! thx While you are correct that TDS contains those drivers, Tivoli support told me not to use them--they're rather old. You're probably *way* better off putting the database on the same box as TDS, which means installing DB2 for NT. That's how I got TDS running.[1] [1] Running is a misnomer. TDS limped badly on bloody stumps for a while; it is definitely *not* a trivial install. I also got it running with SQL Server, which is actually the easiest database engine to deal with. -- Mark Stapleton ([EMAIL PROTECTED])
Re: IBM 3583 and Ultrium Drives, Windows 2000
"Kelly J. Lipp" wrote: > > This is a reprise of a thread started in December. > > Flame on: > > HAS ANYONE MADE THIS WORK WITH TSM 4.1??? > > Flame off. > > The documentation is not clear: Does ADSMSCSI support this baby or do we > need to use the device drivers shipped with the library? The library > documentation suggests that if you are going to use TSM you should not use > the drivers shipped with the library. If, on the other hand, you simply > start the TSM device driver, one can't see the drives. > > Could anyone that has made this work please document here what you did? This may be kinda late to respond, but here's what I discovered: At this time you have to use the Windows RSM stuff to get the library to talk to the outside world--labelling, checkin, checkout, etc. There is doubtless some way to script the interaction, much like we use shell scripting to control TSM running under *NIX, but I had a customer standing next to the server, tapping his foot and waiting, and Microsoft is not exactly forthcoming with details on controlling RSM libraries. We ended up stepping back to NT 4, which itself turned out not be a trivial exercise with the new Ultrium library. The secret turned out to be this: 1. If you're using low-voltage SCSI adapters, as my customer's Compaq server uses, you're going to have a hard time getting a library with numerous drives to configure properly. The NT Tape Library applet in Control Panel will probably detect the drives but not the changer. Supposedly this has to do with the SCSI buffer size. The trick seems to be to initially configure the library with only the changer and one drive; after you accomplish this, you can add on the rest of the drives and add them. 2. The trick to setting up the drivers for the library and the drivers is to follow the directions in the PDF file in the Ultrium driver cd EXACTLY. Don't try to intuit the driver installer process; this is *definitely* a case of RTFM. The ADSMSCSI driver is not operational with Win2K as of this time. The rumor is that Tivoli development is trying to modify it to work, but there is no timetable or promises at this time. -- Mark Stapleton ([EMAIL PROTECTED])
Re: NT 4.0 TCPIP Comm failure
David Longo wrote: >We have had several machines lately that suddenly can't talk to *SM server >and vice >versa. Have to reboot NT to get back. ping and other comm works >o.k. These will >work o.k a few days then same thing. These clients have >been in production for a >good while with no problem. No recent changes to >them. > >Only messages in dsmerror is TCPIP comm failure. >Server says attempting to contact node. Whenever you get a TCP/IP comm failure message, and the traditional methods of TCP/IP communication work (ping, traceroute, etc.), your problem lies almost certainly with communication through ports 1500 or 1501 (the TCP client ports). Something has changed in your network configuration, or NT is refusing communication through one or both ports. -- Mark Stapleton ([EMAIL PROTECTED])
Re: problem restore
> From: Nicholas Cassimatis > Was anything else using the tape drives? If you have 2 drives, and are > running space reclaimation, your restore won't start until the reclamiation > ends. Same thing with migrations tying up the tape drives. This is why I > always recomend an odd number of tape drives, and only allowing one fewer > migration process (controlled by migprocess setting) than tape drives. >"Kelly J. Lipp" wrote: > Is it possible to set the restore priority in such a way that it will > preempt the other process consuming the tape drives? I've read somewhere in the TSM documentation a list of the priorities for tape operations, and I would bet a fair amount of money that restorations were on the top of the list, followed by several others such as space reclamation, with backups at the bottom of the list. This parallels my experience with TSM 3.7 and 4.1, where I've seen a restore request stop a storage pool backup and a space reclamation. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Scratch tapes...
Ray wrote: > I'm relatively new to TSM, and inherited a 3.7 server on AIX with one > 3570 library (19 tapes). We do oracle backups and Solaris/Linux/Aix/NT > backups to the same storage pool. > > The problem is we're backing up up a lot of data. Occasionally TSM will > use up all the tapes, leaving no scratch volumes. I have expiration set > to run every 6 hours, but with no scratch volumes, space reclamation > fails, and TSM is sort of stuck. At this point i have to manually move > data from one volume to a disk storage pool, to get an empty volume (or > scratch tape) so TSM can get enough "breathing room". Then reclamation can > free some volumes. But in the meantime all the previous night's backups > failed. > > What is the best rememdy for this? Should i lower the reclamation > threshold? It is at 60 now... Also i have plenty of disk space to play > with. Should i define a reclamation storage pool?? The redbook says a > reclamation storage pool is good for when the library only has one drive, > but it seems it might help in my situation. Thanks for any advice.. It strongly appears that you have inadequate tape storage resources for your level of data flow. You have several choices: 1. Lower the number of retained copies of files substantially. 2. Increate your tape resources. (Get another library, or replace the current library with a larger one.) 3. Scale up your disk pool storage, and either send some of your management classes to disk or send all data to disk first with a spillover to tape. Yes, you can set up a reclamation disk pool, but it will not solve your basic problem--too much data, not enough library. -- Mark Stapleton ([EMAIL PROTECTED])
Re: reclamation vs backup stgpool
Arnaud Brion wrote: > I'm facing an embarasting situation since I changed the way our daily job runs : I >start a reclamation job, by decreasing the rec parameter to 50 % on all storage pools >every morning at 3:00. > Two hours later I start a backup stgpool job, on all storage pools too, and what >happens is that most of the backup stgpool processes are waiting for a free drive to >begin. > This should never happen, because of the preemption system included in TSM, that >avoids this kind of painfull sitation : backup of stgpools has a higher priority than >reclamation, so why do I have this problem ? ( nopreempt parameter is set to no) > Did anybody face the same situation, and was it solved ? There is documentation in the admin guides that show the priorities that tape operations follow. Restores are at the top of the food chain, followed by several others (including reclamation), with all backups (including client and storage pool) at the bottom of the list. Whatever is higher in the priority list will take precedence over those operations that are lower. This makes sense when you consider what is most important in a backup/recovery system. Restores are the primary function, while cleanup and bookkeeping jobs are not as important. As for backups, they can be done anytime there is a drive available. -- Mark Stapleton ([EMAIL PROTECTED])
Netware clients and DSM threads
I don't know what others' experiences have been, but I have run across something interesting. It appears that Netware does not tolerate more than 3 concurrent DSM threads. I can reproduce Netware abends when there are 4 or more DSM processes. As near as I can tell, the Netware modules that chokes is FILESYS.NLM. I discover this while the Netware client had the following processes going: DSMC SCHED, a web-based backup with DSMCAD going, a regular DSMC session (which was not doing anything), and a restore coming from another Netware node. I also could abend the node while running a backup from its console with RESOURCEUTILIZATION set to 5, which set up four sessions with the TSM server. The environment is: Netware 5.1 with the latest service packs TSM client 4.1.2 TSM server 4.1.2 (Windows NT) -- Mark Stapleton ([EMAIL PROTECTED])
Re: Client Schedules won't start
Rajesh Oak wrote: >I am running TSM 4.1.0 on Win2000. For some reason, the client schedules won't start. >They were working at one time and suddenly it stopped. The Server won't kickoff any >schedules. >Please advise what to look for to make it work. Check to see if your TSM scheduler is running on the client. Look in the Services list for the name you gave the scheduler service. If it is not running, start it. (Right-clicking on the service name will give you a menu.) If it won't start or stay started, check to see how long the name of the service is. There used to be an NT bug that prevented services with names longer than 14 characters from running. I have a customer that ran across exactly the same situation on Win2K a couple of weeks ago. DO NOT rename the service; that won't fix it. You have to delete the service, and then build a new one with a shorter name. -- Mark Stapleton ([EMAIL PROTECTED])
Re: Performance Large Files vs. Small Files
bbullock wrote: > The problem that keeps me awake at night now is that we now have > manufacturing machines wanting to use TSM for their backups. In the past > they have used small DLT libraries locally attached to the host, but that's > labor intensive and they want to take advantage of our "enterprise backup > solution". A great coup for my job security and TSM, as they now see the > benefit of TSM. > > The problem with these hosts is that they generate many, many small > files every day. Without going into any detail, each file is a test on a > part that they may need to look at if the part ever fails. Each part gets > many tests done to it through the manufacturing process, so many files are > generated for each part. > > How many files? Well, I have one Solaris-based host that generates > 500,000 new files a day in a deeply nested directory structure (about 10 > levels deep with only about 5 files per directory). Before I am asked, "no, > they are not able to change the directory of file structure on the host. It > runs proprietary applications that can't be altered". They are currently > keeping these files on the host for about 30 days and then deleting them. The solution that leaps to mind right off the top of my head is multiple TSM servers sharing a library. It would be the easiest way to split the file open/file close bottleneck that plagues NT and Netware clients and their myriads of small files. This solution also splits out the database load. Look to the TSM server-to-server redbook for help. -- Mark Stapleton ([EMAIL PROTECTED])
Re: How to restore partitioning info on WindowsNT
Doug Thorneycroft wrote: > Is there a way to recover the partitioning information on Windows? Sorry for the late reply. No, within itself TSM has no way of preserving such information. You may want to look at a third-party package like Bare Metal Restore (www.tkg.com). It will work with TSM to completely rebuild a client box from the ground up. -- Mark Stapleton ([EMAIL PROTECTED])
Re: TSM Monitoring: Crystal Reports v TEC....
"Warren, Matthew James" wrote: >Has anybody looked at using Tivoli Decision Support with TSM? > >>From: Jager Frederic [mailto:[EMAIL PROTECTED]] >>I am currently evaluating a TSM KM by OTL software with >>Patrol client and >>console (you can get an evaluation copy). And I do think this is worth >>investing. Yes. TDS has some nice bells and whistles, and can output grpahically-based or text reports in multiple formats, including Crystal Reports, ODBC, comma-delimited, and Excel. It's not much more than sophisticated select statements, but its trends reports are pretty good. TDS is NOT a trivial install. It is a long haul, with Tivoli support almost certainly a necessity. -- Mark Stapleton ([EMAIL PROTECTED])
