SV: Multiple companies using the same TSM server
Hi No, Im running just like you! //Niklas -Ursprungligt meddelande- Från: O'Connell, John R [mailto:John.R.O'[EMAIL PROTECTED]] Skickat: den 21 september 2000 01:14 Till: [EMAIL PROTECTED] Ämne: Multiple companies using the same TSM server Our TSM server running on a OS/390 serves multiple customers. For each customer I have a separate policy domain & separate archive & backup disk storage pools and when they migrate they migrate to a common 9840 cartridge storage pool. For those who are backing up more than one customer from a TSM server, do you also have a separate 9840 cartridge or separate 3590 cartridge pool for each customer? John R. O'Connell Phone:408-492-2042 Pager:408-949-1432 John.R.O'[EMAIL PROTECTED]
Re: Slow restore for large NT client outcome.. appeal to Tivoli
Kelly, I don't know regarding Arcserve as you couldn't pay me to go near it, but BE I do know. Restore of a 600MB directory (talking small here) on ADSM to a Netware server takes up to (no exageration here) 6 hours. And this is after we made all sorts of changes (not me, our AS400 guy as that's where it sits, I just complain) to the system. Under BE, the same 600MB takes under 45 minutes. In both cases we are talking about a backup system sitting on another system and not the backed up one. Mike > -Original Message- > From: Kelly J. Lipp [SMTP:[EMAIL PROTECTED]] > Sent: ã ñôèîáø 20 2000 23:38 > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to > Tivoli > > Could someone with experience doing large restores with ArcServe or > BackupExec provide some performance numbers? I've been in shops where the > backups were taking a very long time. Longer than my TSM backup took. I > never witnessed a restore but how can it be better. > > I want the facts. I'm tired of hearing about how much faster ArcServe and > BackupExec are (in theory) compared to TSM in reality. > > I'm sick and tired of it and I won't take it anymore! > > This is what happens when you TSM 24 hours per day. Your brain. Your > brain > on TSM. Not a pretty picture. > > Kelly J. Lipp > Storage Solutions Specialists, Inc. > PO Box 51313 > Colorado Springs CO 80949-1313 > (719) 531-5926 > Fax: (719) 260-5991 > Email: [EMAIL PROTECTED] > www.storsol.com > www.storserver.com > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > Keith E. Pruitt > Sent: Wednesday, September 20, 2000 12:03 PM > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo > > > Jeff, we too have a problem with small files. At first I thought it was a > Netware thing because the servers we have the greatest amount of files on > reside > on the Netware servers. > But reading emails from several users I see that I may have a future > problem > on > the NT side. We store Word and WordPerfect docs on two Netware 5 machines > and > each server holds about 1.8 Million files apiece. Needless to say these > files > are not that big. It took over 11 hours to back each of the servers up and > they > total around 30GB per server. We were forced to perform a Full backup > because > our director and other new admins don't understand and feel comfortable > with > the > "incremental forever" logic. I would hate to see what a restore would look > like. > In contrast, we just backed up a directory on an NT server we are using > for > our > Backoffice conversion and that dir totals 35GB. That took 2h20m. We also > performed a large restore from one AIX machine to another one of about > 25GB. > Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM > server > according to performance guides and other suggestions and still have > issues > with > small files. > > We will be moving our documents from Netware to NT soon and our NT guys > like > to > refer to ADSM as crap. They are used to Arcserve but our now raving about > BackupExec. It is going to be extremely difficult to explain if our huge > machine > can't keep up with their backup server. I know that overall ADSM is a > better > and > more stable product but what do you do when you have a mixture of servers > with > large databases(ADSM's favorite) and (the more common) servers with small > files > that Arcserve and others like? I'm hoping another ADSM/TSM user has some > tricks > or tweaks that can help in this area. Anyone from any universities out > there? > > Reply Separator > Subject:Slow restore for large NT client outcome.. appeal to Tivoli > > Author: Jeff Connor <[EMAIL PROTECTED]> > Date: 09/20/2000 12:21 PM > > Our NT group was a hard sell for replacing Arcserve with TSM. > Since the switch, I have taken quite a beating about TSM restore > performance. Our NT admins take the position, "we'll try TSM but > if the performance doesn't improve we are going with a tried and > true solution like Compaq Enterprise Backup. TSM seems to us > like a UNIX product trying to make it in the NT space. It is not > typically selected by companies for NT backup and recovery". > Not a word for word quote but generally sums up their position. > The Compaq solution would use Arcserve from what I've been told. > > I know Tivoli/IBM have tried to address the small files issue > with things like small file aggregation but I haven't noticed > much improvement from version to version for big restores of > servers with small files. I've heard different reasons for slow > performance with small files over the years like the amount of > TSM database lookups, NT file system processing/inefficiencies, > etc.I have > suggested to our NT admins that we break that big D: partition > into multiple smaller partitions so I can
Re: Problems backing up Novell servers with TSM 3.7.1 client
Jeff, I do not have such big Netware servers - they've all been converted to NT. What I can remember in terms of performance when you have quite big netware volumes is to try two options - maybe together. The first is incremental by date option - specified by -incr on the backup command line or as -incr on the overriding client options on your schedule. Then there is processorutil - this specifies the number of CPU slices Adsm must use the CPU before releasing it for another process to use. There is a final option where you can specify verbose no - that will not write each file being backed up to the schedule log - this makes quite a big difference. The incremental by date option causes the backup to run a lot quicker because there is less overhead than when running a normal incr backup. It only looks at the date to decide to backup or not. Don't blame the backup software here - I think your biggest problem is the NDS on Netware - when backing up if anything in the NDS is not working like it should you end up with the backup process waiting on the NDS to respond. I'm not a netware guy - so maybe find out from your netware people what can cause the backup process to perform badly from the netware point of view. Sorry I can not give you more than this - but it should keep you busy for a while. As a last resort you can try putting on traceoptions to see what exactly the client is spending it's time on. Regards Christo Heuer ABSA Bank Johannesburg SOUTH AFRICA > Help! > > > TSM Server: TSM 3.7.2 for NT > Clients effected:Novell 4.X and 5.00 Servers using TSM 3.7.1 client > > Issue: > > I'm encountering major problems backup up these Novell servers with these > clients It's just 2 out of 20+ Novell servers, but they are highly > visible. What's happening is that it will sometimes take up to 52+ hours > to complete an incremental backup of around only 2 gigs. This is > completely unacceptable. We have other Novell servers that will do same > amount of data in less than 2 hours. It's somewhat sporatic, and does not > happen all the time, but when it does, the following appears on Novell > console: > > > ANS1802E > > Incremental backup of 'SYS': finished with XX failure > > > [- ] > > It will sit in this state for hours. > > At this point it is apparently attempting to access the "VOL1" volume (or > "SDATA") volume etc. Both of these servers have more than just the "SYS" > volume.. These volumes are not that large, only about 60 gigs. I have > tried a variety of switches in DSM.OPT file including "memoryef y", as per > Tivoli's suggestion. Nothing seems to work. I don't recall seeing this > type of problem with the ADSM 3.1.XX client. I've sent logs and more logs > to Tivoli in attempt to resolve this problem w/o success. Any insight > appreciated. > > Thanks > Jeff
TSM server 3.7.3.0 crashing
Hi *SM-ers! My TSM 3.7.3.0 server is crashing at least once a day for the last 5 days. There no addition information in the Activity log. The only output is a core dump and some unclear messages in the dsmserv.err: 09/21/2000 10:14:28 ANR7834S Thread 49 (tid 3196) terminating on signal 11 (Segmentation violation). 09/21/2000 10:14:28 ANR7834S GPR 0: 0x, 1: 0x366c7c80, 2: 0x3012003c, 3: 0x 09/21/2000 10:14:28 ANR7834S GPR 4: 0x31a30fec, 5: 0x13711301, 6: 0x1102, 7: 0x 09/21/2000 10:14:28 ANR7834S GPR 8: 0x1000732b, 9: 0x1000732b, 10: 0x, 11: 0x34e0 09/21/2000 10:14:28 ANR7834S GPR 12: 0x0200, 13: 0x366cbf9c, 14: 0x35b2edf0, 15: 0x 09/21/2000 10:14:28 ANR7834S GPR 16: 0x018c, 17: 0x366cbc6c, 18: 0x366c9600, 19: 0x366c89c4 09/21/2000 10:14:28 ANR7834S GPR 20: 0x0002, 21: 0x, 22: 0x35fd4038, 23: 0x00041e19 09/21/2000 10:14:28 ANR7834S GPR 24: 0x35fd4020, 25: 0x35b205f0, 26: 0x, 27: 0x0001 09/21/2000 10:14:28 ANR7834S GPR 28: 0x079e, 29: 0x366c8dc4, 30: 0x366c80f8, 31: 0x35fd4000 09/21/2000 10:14:28 ANR7834S IAR: 0x100121fc LR: 0x10081d98 CONTEXT: 0x366c7900 09/21/2000 10:14:28 ANR7833S Server thread 1 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 2 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 3 terminated in response to program abort. etc. etc. Anybody seen this before? Kindest regards, Eric van Loon ** This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Slow restore for large NT client
My view on the slow restore problem is that it is down to the tape technology. I've done quite a bit of testing with restores on AIX, NetWare and NT and can say the following: 1. I can rule out the network and server performance as the bottle neck. Doing a full backup and restore will give comparable performance and ADSM will run as fast as the network will allow. Also as fast as any other product (Arcserve, BackupExec). 2. Large filesystems containing large files will give a reasonable restore performance. Large filesystems with lots of small files give a terrible restore performance. What I think is happening is this: Due to the incremental forever backup method the files are becoming fragmented on the tapes. A file changes so a new version is written to the tape. The oldest version is then deleted leaving a gap on the tape. The problem with fragmented tapes is that the seek speed of the tape drives is very slow. Some are better than others, I've found Magstar 3570's are quite a bit faster than DLT's. So when we come to do a full restore the tape drives are spending most of the time searching rather than transferring data. Arcserve and the like do not have this problem as they are generally setup for a weekly full, daily differential so are able to stream data off the tapes in one big block and are only really limited by the transfer rate of the tape drive. The probem with ADSM has really got worse over the last few years due to the amazing growth in disk capacity/price. It is now becoming a real problem when we have these big fileservers going in. I'm not sure what the answer is. Some things that can help are to make sure you are collocation on your tape pools and run regular reclamation to reduce the fragmentation.
Re: ADSM for Exchange Restores
For those watching and interested on the results of this... It was discovered that there was not problem with TDP for Exchange in this case. The problem was that more than one backup product was being used to run "full" backups on the same Exchange server. When this happens, you interrupt the "Full" + "Differential" backup scheme. By the way...if one of the backup products had been running "Copy" backups it would have been OK since the log files would not have been truncated. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] -- Forwarded by Del Hoobler/Endicott/IBM on 09/21/2000 08:01 AM --- Del Hoobler 09/18/2000 08:00 AM To: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> cc: From: Del Hoobler/Endicott/IBM@IBMUS Subject: Re: ADSM for Exchange Restores (Document link: Del Hoobler) Paul, The first thing I would do is get the latest version of TDP for Exchange. You should be getting TDP for Exchange version 1.1.1.01, which can be found on the ftp.software.ibm.com FTP server. Look in /storage/tivoli-storage-management/patches/agents/ntexch/1.1.1 for: IC25816_01.EXE Secondly, if you are not using/checking the "erase existing" option during restore, you need to be very aware of the sequential order of the restored AND pre-existing logs to make sure there is no gap in sequence. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] Paul Dowie <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 09/17/2000 10:52:01 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: ADSM for Exchange Restores Hi Is anyone using ADSM for Exchange with differential backups ?. I am having no problem with Full backups and then restoring but when restoring a differential and then attempting to roll forward I am having inconsistent problems with restarting the IS. Server is OS390 v3.release1.level2.5, client is ADSM v1 r1 level 0 Does anyone have any best practise suggestions for restoring from incr or diff ? thanks [EMAIL PROTECTED]
Re: Oracle 64bit backups
Hi All, ForAIX, HP, NT, is Oracle8.1.6 supported or not by TDP? >From http://www.tivoli.com/support/storage_mgr/tdp_oracle.html, it is supported. But from README files of TDP fixes, Oracle is supported upto 8.1.5. Furthermore, About HP, is Oracle 8.1.6 32-bit supported, but not Oracle 8.1.6 running 64-bit? Thanks in advance. Regards, Eric Tang
Re: Unknown Exchange API error
Thomas, We have seen this a few times but cannot pinpoint it without a trace... TDP for Exchange is calling an Exchange API to do something and the Exchange Server is giving an error that even it as no error message for... ...which means the Exchange Server wasn't expecting it to experience this error either... First thing to try, is stopping and restarting the Microsoft Exchange service. If that doesn't work, reboot the entire machine. I know some folks don't like this because it masks the root of the problem.. ...that is "how did we get to this state?"...I agree... ... but I want to get your backups running again if this is a production server. If it a test server and you have time to help us and Microsoft find out what the problem is and why the Exchange Server is in this state GREAT...call IBM support. If it still doesn't clear up, IBM will need a trace to see exactly the error message and return code so that we can determine the error and possibly get Microsoft involved to help us diagnose the problem with the Exchange Server. Thanks, Del Del Hoobler IBM Corporation [EMAIL PROTECTED] "Rupp Thomas (Illwerke)" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 09/20/2000 04:05:05 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Unknown Exchange API error Hi TSMers, I'm running the TDP for Exchange Version 1 Release 1 Level 1.0 (IP21909) and suddenly get the following messages. 09/14/2000 23:01:38,COMMAND LINE : C:\ADMIN\ADSM\agentexc\excdsmc /backup:dir,full /adsmoptfile:C:\ADMIN\ADSM\agentexc\dsm.opt /logfile:C:\ADMIN\ADSM\agentexc\excdsm.log 09/14/2000 23:03:03,ACN3025E -- Backup error encountered. ACN4226E -- Exchange Error: ACN3516E -- An unknown Exchange API error has occured. 09/14/2000 23:03:03,BACKUP(CLC) - Database: DIR, Type: FULL, Actual bytes: N/A, Secs: 0.00, Kb/Sec: 0.00, Exchange server: POST, TSM server: C:\ADMIN\ADSM\agentexc\dsm.opt, Status: ACN4226E -- Exchange Error: ACN3516E -- An unknown Exchange API error has occured. I searched the archives but couldn't find anything specific. Is there a TDP or Exchange log file that further explains this error? Kind regards Thomas Rupp Vorarlberger Illwerke AG MAIL: [EMAIL PROTECTED] TEL:++43/5574/4991-251 FAX:++43/5574/4991-820-8251
Re: Slow restore for large NT client
>My view on the slow restore problem is that it is down to the tape >technology. ... Mark - Thanks for that corroboration. Too many customers implement technology on the basis of popularity, without critical consideration of what it really does, what its weaknesses are, or how well its capabilities meet site needs. As you observe, DLTs are inferior performers to Magstar technology in real-world applications. Some tape technology is just plain inefficient at random positioning, taking considerable time to settle at a given location. That is, while they are sold on the basis of their "streaming" (continuous reading/writing) speed, the "start-stop" demands of real-world applications like TSM makes them a liability in some environments. (See the postings of various customers in the List archives regarding their experience with this factor.) When the non-TSM people in customer shops stick their tongue out at TSM and cite the wonderful performance of some other backup/restore product, they are of course just pointing out what it can do under certain limited conditions. In making a point, they certainly aren't addressing all the things that other product *can't* do, but that TSM can. If you want TSM to perform fast - but inflexible - restorals, then do only full, or image, backups. You'll drive your tape in streaming mode and get optimum throughput. TSM provides many choices and opportunities. You can configure it to operate in any number of ways. It's all in the manuals and redbooks. It's all a matter of choice of technologies and configurations. One thing any storage administrator should do is perform periodic tests of backups and restores. I think what we're seeing in some postings is administrators backed into a corner when finally confronted with a production file system restoral. Remember that configuration is not a one-time thing: you need to periodically take stock and make adjustments as necessary. Don't let the stuff under your control catch you off-guard: ride herd on it and really know what's going on and what can happen. If nothing else, you'll have a lot more real confidence. Richard Sims, BU
Re: Slow restore for large NT client
It has been our experience that what degrades our performance in the large filesystem/many small files situation has been *SM database lookups. Of course, we have been reclaiming tapes when they hit the 50% mark. Now that circumstances (hours in the day) have forced us to reclaim tapes at the 10% mark, perhaps we will begin to see problems due to fragmented tapes. As a solution, I would suggest using the virtual mount option to slice up large file systems into more reasonably-sized partitions and develop a priority mechanism to determine which should be restored first. In a file system containing several million files, surely some must be more important than others... Jim > -- > From: Mark Bryant[SMTP:[EMAIL PROTECTED]] > Reply To: ADSM: Dist Stor Manager > Sent: Thursday, September 21, 2000 7:19 AM > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client > > My view on the slow restore problem is that it is down to the tape > technology. I've done quite a bit of testing with restores on AIX, NetWare > and NT and can say the following: > > 1. I can rule out the network and server performance as the bottle neck. > Doing a full backup and restore will give comparable performance and ADSM > will run as fast as the network will allow. Also as fast as any other > product (Arcserve, BackupExec). > 2. Large filesystems containing large files will give a reasonable restore > performance. Large filesystems with lots of small files give a terrible > restore performance. > > What I think is happening is this: > Due to the incremental forever backup method the files are becoming > fragmented on the tapes. A file changes so a new version is written to the > tape. The oldest version is then deleted leaving a gap on the tape. The > problem with fragmented tapes is that the seek speed of the tape drives is > very slow. Some are better than others, I've found Magstar 3570's are > quite a bit faster than DLT's. So when we come to do a full restore the > tape drives are spending most of the time searching rather than > transferring data. > Arcserve and the like do not have this problem as they are generally setup > for a weekly full, daily differential so are able to stream data off the > tapes in one big block and are only really limited by the transfer rate of > the tape drive. > The probem with ADSM has really got worse over the last few years due to > the amazing growth in disk capacity/price. It is now becoming a real > problem when we have these big fileservers going in. > I'm not sure what the answer is. Some things that can help are to make > sure > you are collocation on your tape pools and run regular reclamation to > reduce the fragmentation. >
Re: TSM server 3.7.3.0 crashing
>My TSM 3.7.3.0 server is crashing at least once a day for the last 5 days. ... >ANR7834S Thread 49 (tid 3196) terminating on signal 11 (Segmentation violation). Eric - Segv is a flat-out programming error. If you can identify the circumstances under which it's occurring, you may be able to avoid it; but in the long run you'll need to get a fix from Tivoli. (Consider using SHOW THREADS and opsys thread display commands, before the next failure, to help identify the one that does fail on Segv, to possibly help you avoid the operation involved.) I regard TSM 3.7 as the painful version of the product in transitioning from IBM ADSM to Tivoli TSM development. I'm avoiding 3.7 - and very much hope that 4.x exhibits stabilized development. Richard Sims, BU
Re: Slow restore for large NT client outcome.. appeal to Tivoli D evelopment/Support
>That may be because from what I have seen in TSM 3.7, directories are >actually kept in the TSM database and not on tape. Careful, there. It depends upon the file system type and added baggage. Ordinary Unix file system directory information is like an empty file, and so its limited info can be kept in the database. But add an Access Control List (ACL) to an AIX directory, for example, and it has to be stored in a storage pool. From what I've seen, file systems such as NTFS, laden with additional info, always have to be stored in a storage pool. When in doubt, a Query Content should reveal what's really happening. Richard Sims, BU
Re: Slow restore for large NT client
From: Matthew Glanville I have found that many times I overlook a very significant item that is really the cause of the slow restore/backup on NT. Make sure that there is NO Virus scanning software running I have been hit at least 5 times by the NT admin complaining about a slow backup/restore, and me spending hours trying to figure it out, only to find that they had the virus scanner scanning all incoming/outgoing data! (It just happened to me again!!!) For those extremely large NT systems with 1 million plus files, seeing the virus scanning software running 23 hours every day, the TSM backups running 2-3 hours, and then the left over CPU cycles doing what that large system was designed to do, server files to users or run an application. However, after turning off the virus scanning software, and seeing 2-4 times improvement in files/hour or GB/hour, I still have to say that performance is too slow for most of my customers. But how slow is it? I really would appreciate some people posting some statistcs about other backup software! Also, worth considering is the amount of time and effort spent by the backup administrators/local administrators to maintain the system in order to achieve that type of restore performance. With ADSM/TSM me and one other person maintain 6 TSM servers backing up over 600 computers. (we are overworked :) Matthew Glanville
MPTHREADING
Hello everyone, We are running ADSM V3.1.2.50 on OS/390 2.8 and I was wondering if anyone out there is using the MPthreading option and if so how is it working? We would like to boost ADSM BU/Archive performance any way that we can and I want to make sure that this option won't cause us any problems. Any information that you can provide to me on this topic would be appreciated. Brian L. Nick System Programmer - Storage Solutions Phoenix Home Life Mutual Ins. 100 Bright Meadow Blvd Enfield CT. 06082-1900 E-MAIL: [EMAIL PROTECTED] PHONE: (860)403-2281
Re: Slow restore for large NT client outcome.. appeal to Tivoli
When reading this I have to ask 600Mb how? 1. What kind of systems (ADSM/BE server, client)? 2. What kind of network? 3. What kind of tape devices? 4. How many files in the directory? 5. Is the ADSM server shared or dedicated? Its possible to create patholgical cases that can trash any backup system's backup and restore times. In our case, thanks to raid, we do a lot more single file restores than restores of entire filesystems. Jim > -- > From: Mike Glassman - Admin[SMTP:[EMAIL PROTECTED]] > Reply To: ADSM: Dist Stor Manager > Sent: Thursday, September 21, 2000 2:57 AM > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to > Tivoli > > Kelly, > > I don't know regarding Arcserve as you couldn't pay me to go near it, but > BE > I do know. > > Restore of a 600MB directory (talking small here) on ADSM to a Netware > server takes up to (no exageration here) 6 hours. And this is after we > made > all sorts of changes (not me, our AS400 guy as that's where it sits, I > just > complain) to the system. > > Under BE, the same 600MB takes under 45 minutes. > > In both cases we are talking about a backup system sitting on another > system > and not the backed up one. > > Mike > > > -Original Message- > > From: Kelly J. Lipp [SMTP:[EMAIL PROTECTED]] > > Sent: ã ñôèîáø 20 2000 23:38 > > To: [EMAIL PROTECTED] > > Subject: Re: Slow restore for large NT client outcome.. appeal to > > Tivoli > > > > Could someone with experience doing large restores with ArcServe or > > BackupExec provide some performance numbers? I've been in shops where > the > > backups were taking a very long time. Longer than my TSM backup took. > I > > never witnessed a restore but how can it be better. > > > > I want the facts. I'm tired of hearing about how much faster ArcServe > and > > BackupExec are (in theory) compared to TSM in reality. > > > > I'm sick and tired of it and I won't take it anymore! > > > > This is what happens when you TSM 24 hours per day. Your brain. Your > > brain > > on TSM. Not a pretty picture. > > > > Kelly J. Lipp > > Storage Solutions Specialists, Inc. > > PO Box 51313 > > Colorado Springs CO 80949-1313 > > (719) 531-5926 > > Fax: (719) 260-5991 > > Email: [EMAIL PROTECTED] > > www.storsol.com > > www.storserver.com > > > > > > -Original Message- > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > > Keith E. Pruitt > > Sent: Wednesday, September 20, 2000 12:03 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo > > > > > > Jeff, we too have a problem with small files. At first I thought it was > a > > Netware thing because the servers we have the greatest amount of files > on > > reside > > on the Netware servers. > > But reading emails from several users I see that I may have a future > > problem > > on > > the NT side. We store Word and WordPerfect docs on two Netware 5 > machines > > and > > each server holds about 1.8 Million files apiece. Needless to say these > > files > > are not that big. It took over 11 hours to back each of the servers up > and > > they > > total around 30GB per server. We were forced to perform a Full backup > > because > > our director and other new admins don't understand and feel comfortable > > with > > the > > "incremental forever" logic. I would hate to see what a restore would > look > > like. > > In contrast, we just backed up a directory on an NT server we are using > > for > > our > > Backoffice conversion and that dir totals 35GB. That took 2h20m. We also > > performed a large restore from one AIX machine to another one of about > > 25GB. > > Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM > > server > > according to performance guides and other suggestions and still have > > issues > > with > > small files. > > > > We will be moving our documents from Netware to NT soon and our NT guys > > like > > to > > refer to ADSM as crap. They are used to Arcserve but our now raving > about > > BackupExec. It is going to be extremely difficult to explain if our huge > > machine > > can't keep up with their backup server. I know that overall ADSM is a > > better > > and > > more stable product but what do you do when you have a mixture of > servers > > with > > large databases(ADSM's favorite) and (the more common) servers with > small > > files > > that Arcserve and others like? I'm hoping another ADSM/TSM user has some > > tricks > > or tweaks that can help in this area. Anyone from any universities out > > there? > > > > Reply Separator > > Subject:Slow restore for large NT client outcome.. appeal to Tivoli > > > > Author: Jeff Connor <[EMAIL PROTECTED]> > > Date: 09/20/2000 12:21 PM > > > > Our NT group was a hard sell for replacing Arcserve with TSM. > > Since the switch, I have taken quite a beating about TSM restor
Re: Oracle 64bit backups
Is there a version that supports Oracle on 64-bit AIX? Date sent: Mon, 18 Sep 2000 14:32:30 -0700 Send reply to: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> From: Neil Rasmussen <[EMAIL PROTECTED]> Subject:Re: Oracle 64bit backups To: [EMAIL PROTECTED] > Currently, there is no solution for TDP for Oracle on HPUX-11 64-bit. > > Regards, > > > Neil G. Rasmussen > TDP Oracle > Phone: 408-256-8265, t/l 276-8265 > E-mail: [EMAIL PROTECTED] > > > Good Friend <[EMAIL PROTECTED]> on 09/18/2000 12:32:55 PM > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > cc:(bcc: Neil Rasmussen/Tivoli Systems) > Subject: Re: Oracle 64bit backups > > > > > So there is noway currently to used TDPO on 8.1.6 64 bit Oracle DB's? > > Thanks, > allwyn x37218 > > - Original Message - > From: "Neil Rasmussen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 18, 2000 3:17 PM > Subject: Re: Oracle 64bit backups > > > > Allwyn, > > > > TDPO does not currently support HP 64 bit, it is in plan for future > release. > > However, a date has not been set yet for this release. > > > > > > Regards, > > > > > > Neil G. Rasmussen > > TDP Oracle > > Phone: 408-256-8265, t/l 276-8265 > > E-mail: [EMAIL PROTECTED] > > > > > > Good Friend <[EMAIL PROTECTED]> on 09/18/2000 06:43:49 AM > > > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > > To: [EMAIL PROTECTED] > > cc:(bcc: Neil Rasmussen/Tivoli Systems) > > Subject: Oracle 64bit backups > > > > > > > > > > Hello, > > > > Is anyone using TSM for Oracle 8.1.6 running on hp clients? > > I've checked the Tivoli site but could not find any info on this. > > > > thanks, > > allwyn > > - Mark Saltzman Assistant Director UW-Extension Information Systems PH:608.263.3084/ FAX:608.262.2343
Solaris level numbers
I am attempting to sort out the support status of four Solaris client systems. I found a Web site related to Solaris support that states that Sun has two different conventions for Solaris 2 level numbers. Documentation and labels on distribution media use 'Solaris 2.x' for some value of 'x'. The uname command reports 'Sun OS 5.x'. I don't have accounts on all four Solaris systems, and hence I can't run the uname command myself in all cases. I have been checking the data my OS/390 3.1.2.50 server reports for these clients. It appears that the clever people who developed ADSM chose to split the difference between the two conventions. The 'Platform' field in the output from 'query node' with 'f=d' is 'SUN SOLARIS' for all four systems. The 'Client OS level' field is '5.6' for three of the systems and '5.5.1' for the fourth. Can I safely infer that the first three are really Solaris 2.6 and that the fourth is really Solaris 2.5.1? The ADSM client level is 3.1.0.6 on all four systems.
Re: TSM server 3.7.3.0 crashing
I am going to 3.7.3.8...as I type... My suspicion is that expiration is doing it to you see the following apar: 250- o IC27022 TSM SERVER CRASHES WITH DR. WATSON ERROR, EXCEPTION:ACCESS VIOL that's fixed in 3.7.3.8 (aix along with nt, etc, have seen this error/abend). This could be it.. Yes, by the way, nothing in the activity log other than to check if you had an expiration running (started but didn't finish/complete). FYI Thanks Tim "Loon, E.J. van - SPLXM" <[EMAIL PROTECTED]> 09/21/2000 05:57 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>@SMTP@Exchange To: [EMAIL PROTECTED]@SMTP@Exchange cc: Subject:TSM server 3.7.3.0 crashing Hi *SM-ers! My TSM 3.7.3.0 server is crashing at least once a day for the last 5 days. There no addition information in the Activity log. The only output is a core dump and some unclear messages in the dsmserv.err: 09/21/2000 10:14:28 ANR7834S Thread 49 (tid 3196) terminating on signal 11 (Segmentation violation). 09/21/2000 10:14:28 ANR7834S GPR 0: 0x, 1: 0x366c7c80, 2: 0x3012003c, 3: 0x 09/21/2000 10:14:28 ANR7834S GPR 4: 0x31a30fec, 5: 0x13711301, 6: 0x1102, 7: 0x 09/21/2000 10:14:28 ANR7834S GPR 8: 0x1000732b, 9: 0x1000732b, 10: 0x, 11: 0x34e0 09/21/2000 10:14:28 ANR7834S GPR 12: 0x0200, 13: 0x366cbf9c, 14: 0x35b2edf0, 15: 0x 09/21/2000 10:14:28 ANR7834S GPR 16: 0x018c, 17: 0x366cbc6c, 18: 0x366c9600, 19: 0x366c89c4 09/21/2000 10:14:28 ANR7834S GPR 20: 0x0002, 21: 0x, 22: 0x35fd4038, 23: 0x00041e19 09/21/2000 10:14:28 ANR7834S GPR 24: 0x35fd4020, 25: 0x35b205f0, 26: 0x, 27: 0x0001 09/21/2000 10:14:28 ANR7834S GPR 28: 0x079e, 29: 0x366c8dc4, 30: 0x366c80f8, 31: 0x35fd4000 09/21/2000 10:14:28 ANR7834S IAR: 0x100121fc LR: 0x10081d98 CONTEXT: 0x366c7900 09/21/2000 10:14:28 ANR7833S Server thread 1 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 2 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 3 terminated in response to program abort. etc. etc. Anybody seen this before? Kindest regards, Eric van Loon ** This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Slow restore for large NT client outcome.. appeal to Tivoli
AS/400 you say? It's probably the slowest *SM server out of the 9 supported. NT TSM server are typically much faster than their 400 counterparts. -- Joshua S. Bassi Senior Technical Consultant Symatrix Technology, Inc. [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Glassman - Admin Sent: Wednesday, September 20, 2000 11:58 PM To: [EMAIL PROTECTED] Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli Kelly, I don't know regarding Arcserve as you couldn't pay me to go near it, but BE I do know. Restore of a 600MB directory (talking small here) on ADSM to a Netware server takes up to (no exageration here) 6 hours. And this is after we made all sorts of changes (not me, our AS400 guy as that's where it sits, I just complain) to the system. Under BE, the same 600MB takes under 45 minutes. In both cases we are talking about a backup system sitting on another system and not the backed up one. Mike > -Original Message- > From: Kelly J. Lipp [SMTP:[EMAIL PROTECTED]] > Sent: ã ñôèîáø 20 2000 23:38 > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to > Tivoli > > Could someone with experience doing large restores with ArcServe or > BackupExec provide some performance numbers? I've been in shops where the > backups were taking a very long time. Longer than my TSM backup took. I > never witnessed a restore but how can it be better. > > I want the facts. I'm tired of hearing about how much faster ArcServe and > BackupExec are (in theory) compared to TSM in reality. > > I'm sick and tired of it and I won't take it anymore! > > This is what happens when you TSM 24 hours per day. Your brain. Your > brain > on TSM. Not a pretty picture. > > Kelly J. Lipp > Storage Solutions Specialists, Inc. > PO Box 51313 > Colorado Springs CO 80949-1313 > (719) 531-5926 > Fax: (719) 260-5991 > Email: [EMAIL PROTECTED] > www.storsol.com > www.storserver.com > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > Keith E. Pruitt > Sent: Wednesday, September 20, 2000 12:03 PM > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo > > > Jeff, we too have a problem with small files. At first I thought it was a > Netware thing because the servers we have the greatest amount of files on > reside > on the Netware servers. > But reading emails from several users I see that I may have a future > problem > on > the NT side. We store Word and WordPerfect docs on two Netware 5 machines > and > each server holds about 1.8 Million files apiece. Needless to say these > files > are not that big. It took over 11 hours to back each of the servers up and > they > total around 30GB per server. We were forced to perform a Full backup > because > our director and other new admins don't understand and feel comfortable > with > the > "incremental forever" logic. I would hate to see what a restore would look > like. > In contrast, we just backed up a directory on an NT server we are using > for > our > Backoffice conversion and that dir totals 35GB. That took 2h20m. We also > performed a large restore from one AIX machine to another one of about > 25GB. > Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM > server > according to performance guides and other suggestions and still have > issues > with > small files. > > We will be moving our documents from Netware to NT soon and our NT guys > like > to > refer to ADSM as crap. They are used to Arcserve but our now raving about > BackupExec. It is going to be extremely difficult to explain if our huge > machine > can't keep up with their backup server. I know that overall ADSM is a > better > and > more stable product but what do you do when you have a mixture of servers > with > large databases(ADSM's favorite) and (the more common) servers with small > files > that Arcserve and others like? I'm hoping another ADSM/TSM user has some > tricks > or tweaks that can help in this area. Anyone from any universities out > there? > > Reply Separator > Subject:Slow restore for large NT client outcome.. appeal to Tivoli > > Author: Jeff Connor <[EMAIL PROTECTED]> > Date: 09/20/2000 12:21 PM > > Our NT group was a hard sell for replacing Arcserve with TSM. > Since the switch, I have taken quite a beating about TSM restore > performance. Our NT admins take the position, "we'll try TSM but > if the performance doesn't improve we are going with a tried and > true solution like Compaq Enterprise Backup. TSM seems to us > like a UNIX product trying to make it in the NT space. It is not > typically selected by companies for NT backup and recovery". > Not a word for word quote but generally sums up their position. > The Compaq solution would use Arcserve from what I've been told. > > I know Tivoli/IBM have t
Re: MPTHREADING
We use the MPthreading option on ADSM V3.1.2.50, OS/390 V2.4. No problem with it ! Regards, René Lambelet Nestec S.A. / Informatique du Centre 55, av. Nestlé CH-1800 Vevey (Switzerland) *+41(021) 924 3543 7 +41 (021) 924 4589 * B 133 Visit our site: http://www.nestle.com This message is intended only for the use of the addressee and may contain information that is privileged and confidential. > -Original Message- > From: Brian Nick [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, September 21, 2000 4:05 PM > To: [EMAIL PROTECTED] > Subject: MPTHREADING > > Hello everyone, > > We are running ADSM V3.1.2.50 on OS/390 2.8 and I was wondering if anyone > out there is using the MPthreading option and if so how is it working? We > would like to boost ADSM BU/Archive performance any way that we can and I > want to make sure that this option won't cause us any problems. Any > information that you can provide to me on this topic would be appreciated. > > Brian L. Nick > System Programmer - Storage Solutions > Phoenix Home Life Mutual Ins. > 100 Bright Meadow Blvd > Enfield CT. 06082-1900 > > E-MAIL: [EMAIL PROTECTED] > PHONE: (860)403-2281
3.1 client support after January 2001
We are in the process of upgrading our OS/390 ADSM 3.1 server to TSM 3.7. We have a number of client systems for which no 3.7 clients are available (one Solaris 2.5.1, one SCO OpenServer, and a number of HP-UX 10.20 systems). We will end up with these clients using 3.1 clients to connect to the 3.7 server. Earlier postings to this list make it clear that this is a supported mode of operation at present. What happens at the end of January 2001? That is the end of support for ADSM 3.1. As far as I can tell from Tivoli's Web site, that date applies to all parts of ADSM 3.1: server code and client code alike. Am I correct in understanding that there will be no supported means of providing TSM backup coverage for the clients mentioned above after January 31, 2001?
TSM Upgrade
Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark RemetaSeligman Data Corp.100 Park AvenueNew York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: 3.1 client support after January 2001
>From what I understand the end of 3.7 support is based on your *SM server level. If you are having a problem with a 3.1 client and a 3.7 server you should be okay getting support. -- Joshua S. Bassi Senior Technical Consultant Symatrix Technology, Inc. [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Denier Sent: Thursday, September 21, 2000 8:48 AM To: [EMAIL PROTECTED] Subject: 3.1 client support after January 2001 We are in the process of upgrading our OS/390 ADSM 3.1 server to TSM 3.7. We have a number of client systems for which no 3.7 clients are available (one Solaris 2.5.1, one SCO OpenServer, and a number of HP-UX 10.20 systems). We will end up with these clients using 3.1 clients to connect to the 3.7 server. Earlier postings to this list make it clear that this is a supported mode of operation at present. What happens at the end of January 2001? That is the end of support for ADSM 3.1. As far as I can tell from Tivoli's Web site, that date applies to all parts of ADSM 3.1: server code and client code alike. Am I correct in understanding that there will be no supported means of providing TSM backup coverage for the clients mentioned above after January 31, 2001?
Re: Slow restore for large NT client outcome.. appeal to Tivoli
Ok, I tried to resist the thread. Arcserve on Netware5 SP5 can backup and restore across the wire 17Gigs an hour. Nothing spectacular but 10 times faster than what I can get out of TSM. I'm still looking for why TSM seems so slow. Whats more, TSM has a problem in getting long filename support while Arcserve is OK. On the other hand the stability of Arcserve on Netware is poor, but then so is dsmc on Netware. We use the Arcserve push-agents to get transfer rates from remote server to the Host server up, I wish TSM had something similiar. The killer for the TSM is that I refuse to put the TSM agents on the production servers due to the frequent abends, instead I put them on a high-horsepower box that does nothing else but run the TSM incrementals. Normal day to day TSM is great, but in a disaster recovery,. It scares the hell out of me. Then I would be glad I maintained Arcserve. Blair Mike Glassman - Admin <[EMAIL PROTECTED]> on 09/21/2000 12:57:47 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc:(bcc: Blair Wickstrand/Poco) Fax to: Subject: Re: Slow restore for large NT client outcome.. appeal to Tivoli Kelly, I don't know regarding Arcserve as you couldn't pay me to go near it, but BE I do know. Restore of a 600MB directory (talking small here) on ADSM to a Netware server takes up to (no exageration here) 6 hours. And this is after we made all sorts of changes (not me, our AS400 guy as that's where it sits, I just complain) to the system. Under BE, the same 600MB takes under 45 minutes. In both cases we are talking about a backup system sitting on another system and not the backed up one. Mike > -Original Message- > From: Kelly J. Lipp [SMTP:[EMAIL PROTECTED]] > Sent: ã ñôèîáø 20 2000 23:38 > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to > Tivoli > > Could someone with experience doing large restores with ArcServe or > BackupExec provide some performance numbers? I've been in shops where the > backups were taking a very long time. Longer than my TSM backup took. I > never witnessed a restore but how can it be better. > > I want the facts. I'm tired of hearing about how much faster ArcServe and > BackupExec are (in theory) compared to TSM in reality. > > I'm sick and tired of it and I won't take it anymore! > > This is what happens when you TSM 24 hours per day. Your brain. Your > brain > on TSM. Not a pretty picture. > > Kelly J. Lipp > Storage Solutions Specialists, Inc. > PO Box 51313 > Colorado Springs CO 80949-1313 > (719) 531-5926 > Fax: (719) 260-5991 > Email: [EMAIL PROTECTED] > www.storsol.com > www.storserver.com > > > -Original Message- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > Keith E. Pruitt > Sent: Wednesday, September 20, 2000 12:03 PM > To: [EMAIL PROTECTED] > Subject: Re: Slow restore for large NT client outcome.. appeal to Tivo > > > Jeff, we too have a problem with small files. At first I thought it was a > Netware thing because the servers we have the greatest amount of files on > reside > on the Netware servers. > But reading emails from several users I see that I may have a future > problem > on > the NT side. We store Word and WordPerfect docs on two Netware 5 machines > and > each server holds about 1.8 Million files apiece. Needless to say these > files > are not that big. It took over 11 hours to back each of the servers up and > they > total around 30GB per server. We were forced to perform a Full backup > because > our director and other new admins don't understand and feel comfortable > with > the > "incremental forever" logic. I would hate to see what a restore would look > like. > In contrast, we just backed up a directory on an NT server we are using > for > our > Backoffice conversion and that dir totals 35GB. That took 2h20m. We also > performed a large restore from one AIX machine to another one of about > 25GB. > Less than 2 hours to restore. We have tweaked our Netware and AIX ADSM > server > according to performance guides and other suggestions and still have > issues > with > small files. > > We will be moving our documents from Netware to NT soon and our NT guys > like > to > refer to ADSM as crap. They are used to Arcserve but our now raving about > BackupExec. It is going to be extremely difficult to explain if our huge > machine > can't keep up with their backup server. I know that overall ADSM is a > better > and > more stable product but what do you do when you have a mixture of servers > with > large databases(ADSM's favorite) and (the more common) servers with small > files > that Arcserve and others like? I'm hoping another ADSM/TSM user has some > tricks > or tweaks that can help in this area. Anyone from any universities out > there? > > Reply Separator > Subject:Slow restore for large NT client outcome.. appeal to Tivoli > > Author: Jef
Re: TSM server 3.7.3.0 crashing
>Hi *SM-ers! >My TSM 3.7.3.0 server is crashing at least once a day for the last 5 days. >There no addition information in the Activity log. The only output is a core >dump and some unclear messages in the dsmserv.err: > >09/21/2000 10:14:28 ANR7834S Thread 49 (tid 3196) terminating on signal 11 >(Segmentation violation). >09/21/2000 10:14:28 ANR7834S GPR 0: 0x, 1: 0x366c7c80, 2: >0x3012003c, 3: 0x >09/21/2000 10:14:28 ANR7834S GPR 4: 0x31a30fec, 5: 0x13711301, 6: >0x1102, 7: 0x >09/21/2000 10:14:28 ANR7834S GPR 8: 0x1000732b, 9: 0x1000732b, 10: >0x, 11: 0x34e0 >09/21/2000 10:14:28 ANR7834S GPR 12: 0x0200, 13: 0x366cbf9c, 14: >0x35b2edf0, 15: 0x >09/21/2000 10:14:28 ANR7834S GPR 16: 0x018c, 17: 0x366cbc6c, 18: >0x366c9600, 19: 0x366c89c4 >09/21/2000 10:14:28 ANR7834S GPR 20: 0x0002, 21: 0x, 22: >0x35fd4038, 23: 0x00041e19 >09/21/2000 10:14:28 ANR7834S GPR 24: 0x35fd4020, 25: 0x35b205f0, 26: >0x, 27: 0x0001 >09/21/2000 10:14:28 ANR7834S GPR 28: 0x079e, 29: 0x366c8dc4, 30: >0x366c80f8, 31: 0x35fd4000 >09/21/2000 10:14:28 ANR7834S IAR: 0x100121fc LR: 0x10081d98 CONTEXT: >0x366c7900 If you have dbx installed then from the server directory rename the core dump to something like core.dump then bring up dbx with dbx ./dsmserv core.dump Then under dbx use the command where to get a callback trace from the stack. This should be enough to know if this is a known problem. If not then call support so we can look at the core dump. If you need to go that route then they will need the core file, your dsmserv executable and the dsmserv.err file. David Bohm TSM server development email - [EMAIL PROTECTED]
Re: TSM Upgrade
Take a look in the server folder for file initsrv3.log...it may have some indication of what happened... maybe the upgradedb failed? -Original Message-From: Remeta, Mark [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 11:51 AMTo: [EMAIL PROTECTED]Subject: TSM Upgrade Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark RemetaSeligman Data Corp.100 Park AvenueNew York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: TSM Upgrade
I checked and that file is dated back from December of 99 and it is definitely from my last ADSM install. I manually ran the dsmserv from a command prompt and it complained that the database was from a downlevel version of the server and I needed to start it with the UPGRADEDB parameter which I did. It hasn't finished yet so I don't know if it is going to work but I thought that the upgrade was suppose to be automatic... Thanks for your help, Mark -Original Message-From: Susi, Scott T [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 12:09 PMTo: [EMAIL PROTECTED]Subject: Re: TSM Upgrade Take a look in the server folder for file initsrv3.log...it may have some indication of what happened... maybe the upgradedb failed? -Original Message-From: Remeta, Mark [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 11:51 AMTo: [EMAIL PROTECTED]Subject: TSM Upgrade Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark RemetaSeligman Data Corp.100 Park AvenueNew York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately. Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: TSM Upgrade
It may have a different name or folder...here is what I found in the Version 4 documentation: "If you have problems starting the server after installation, go to your server instance directory, for example tivoli\tsm\server1, and check the initserv.log file for error statements" I did have a problem when I upgraded to TSM 3.7.3 where the upgade of the database failed. When I ran the "DSMSERV UPGRADEDB" again, it worked. I never persued why the "automatic" update did not -Original Message-From: Remeta, Mark [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 12:20 PMTo: [EMAIL PROTECTED]Subject: Re: TSM Upgrade I checked and that file is dated back from December of 99 and it is definitely from my last ADSM install. I manually ran the dsmserv from a command prompt and it complained that the database was from a downlevel version of the server and I needed to start it with the UPGRADEDB parameter which I did. It hasn't finished yet so I don't know if it is going to work but I thought that the upgrade was suppose to be automatic... Thanks for your help, Mark -Original Message-From: Susi, Scott T [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 12:09 PMTo: [EMAIL PROTECTED]Subject: Re: TSM Upgrade Take a look in the server folder for file initsrv3.log...it may have some indication of what happened... maybe the upgradedb failed? -Original Message-From: Remeta, Mark [mailto:[EMAIL PROTECTED]]Sent: Thursday, September 21, 2000 11:51 AMTo: [EMAIL PROTECTED]Subject: TSM Upgrade Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark RemetaSeligman Data Corp.100 Park AvenueNew York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately. Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: TSM Upgrade
There is a known bug in the installation routine for 4.1.0 under NT4 server WITHOUT Internet Explorer 4. The fix is to either install IE4, or (better yet) install the 4.1.1 code immediately after installing 4.1.0. -Lloyd > "Remeta, Mark" wrote: > > Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into >the Server Utilities it says there is an error for Server1. When I try and configure >it in the Utilities wizard it doctor watsons out after I enter the username and >password. I am trying to manually start the service now but it looks like I will have >to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen >this behavior before??? > > Thanks for any help, > > Mark Remeta > Seligman Data Corp. > 100 Park Avenue > New York, NY 10017 > > Confidentiality Note: The information transmitted is intended only for the person or >entity to whom or which it is addressed and may contain confidential and/or >privileged material. Any review, retransmission, dissemination or other use of this >information by persons or entities other than the intended recipient is prohibited. >If you receive this in error, please delete this material immediately. > >Name: SeaMarbl.jpg >SeaMarbl.jpgType: JPEG Image (image/jpeg) >Encoding: base64 -- - Lloyd Dieter- Senior Technology Consultant Synergy, Inc. http://www.synergyinc.cc [EMAIL PROTECTED] Main:716-389-1260fax:716-389-1267 -
Re: Slow restore for large NT client outcome.. appeal to Tivoli
Blair, We can restore 13GB in one hour for a fairly medium amount of medium size file by using TSM. But not for a large amount of small files. Can you do 17GB/hr or what ever for a small file systems with ARCserver? What is your wire--LAN or SCSI? George
Novell TSM client performs worse than ADSM ?
Hi, We run 0S390 2.8.0 with TSM 3.7.20 We have recently converted our Novell 4 servers (service pack 8a) to TSM client 3.7.2 from ADSM client 3.1.0.8. We have seen that backups previously running in under 2 hours now take over 4 hours. Has anybody else seen this performance hit with Novell servers after "upgrading" to the TSM client Thanks, John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group **
FW: MPTHREADING
We turned it on and it did it's job, unfortunately it did too much. MPthreading ask for multi-processors on MVS and it got all of them. Subsequently that MVS image didn't do anything but ADSM. I submitted a requirement to IBM to allow the MPthreading to have a throttle of maybe 1, 2, etc. instead of just yes or no. Depending on your environment it can be helpful or cause problems. I did this in conjunction with performance testing and what I found was it didn't help for single transaction throughput, more for several processes at a time. We can talk environments and compare our with yours if you think it might help. OS/390 runs in a sysplex at Principal so your configuration should be considered when using this option. Scott -Original Message- From: Lambelet,Rene,VEVEY,FC-SIL/INF. [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 21, 2000 10:47 AM To: [EMAIL PROTECTED] Subject: Re: MPTHREADING We use the MPthreading option on ADSM V3.1.2.50, OS/390 V2.4. No problem with it ! Regards, René Lambelet Nestec S.A. / Informatique du Centre 55, av. Nestlé CH-1800 Vevey (Switzerland) *+41(021) 924 3543 7 +41 (021) 924 4589 * B 133 Visit our site: http://www.nestle.com This message is intended only for the use of the addressee and may contain information that is privileged and confidential. > -Original Message- > From: Brian Nick [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, September 21, 2000 4:05 PM > To: [EMAIL PROTECTED] > Subject: MPTHREADING > > Hello everyone, > > We are running ADSM V3.1.2.50 on OS/390 2.8 and I was wondering if anyone > out there is using the MPthreading option and if so how is it working? We > would like to boost ADSM BU/Archive performance any way that we can and I > want to make sure that this option won't cause us any problems. Any > information that you can provide to me on this topic would be appreciated. > > Brian L. Nick > System Programmer - Storage Solutions > Phoenix Home Life Mutual Ins. > 100 Bright Meadow Blvd > Enfield CT. 06082-1900 > > E-MAIL: [EMAIL PROTECTED] > PHONE: (860)403-2281
Re: Slow restore for large NT client outcome.. appeal to Tivoli
My experience here has been that Backups fly, Restores snore.
My best rate for a restore of files of mixed length, mainly
small, has been 1.5 GB /hr from tape. (We are using IBM
3590B drives, soon to become 3590E.)
In a test, a restore from the disk pool brought
me way up to 1.66 GB/ hour. Yee ha!
Another test I did was to FTP the same data
from my client to the server where ADSM lives and
bring it back again. That got me about 6 GB/hour,
both directions.
We are using ADSM on AIX, with NT clients.
Since the backup rate is acceptable, I feel I can
rule out network and hardware issues to a
large degree. (I suppose I could try tweaking
the read/write ratio on the RAID controller.)
We have found that ADSM is a decent solution
for 'ad-hoc' restores, (the everyday confusion users
suffer over the delete key) but large disaster
recovery type restores scare the heck outta us.
At one point when we thought we may have lost
a logical drive (don't ask!) we started a restore and
at the rates we were getting from a highly fragmented,
non-co-located library, we estimated that it was going
to take 3.4 weeks to restore 45 GB. Not the kind of
news mgmt likes to hear. We are now working on
turning co-location on. We hope that will bring it down
to a mere 30 hours. Yippee!
John Wiersma
Network Analyst
Rochester Gas & Electric Corporation
[EMAIL PROTECTED]
(716) 724-8053
RRR !! !!
R !! !!
RRR RRR !!! !!!
RRR RRR !!! A N D !!!
R !!! !!!
!!! !!!
RRRRRR!!!!!! !!!
RRR RRR !! !
RRRRRR ! !
Re: TSM Upgrade
In the tradition of ADSM, I would avoid the first release; we waited until 373 for the first TSM, now I recommend the 4.1.1 level, BUT only if you need a new feature only found in 4.1. We've been running 373 with 372.01 clients on Win2K servers for the past 6 weeks, on two separate environments. Did a 3rd server install on Win2k-Pro, all went (mostly) smoothly. The NT-device config for Dell-120T needed help setting the element number, but that was the only "glitch" we've seen, so far; the Dell-130T device-config was correct at the outset. Also, we've installed 2 AIX servers with 373, one has 30 Solaris 372 clients and 5 NT clients... all environments are installed and running okay. (Minor hang-ups due to inadequate handling of Win2K System Objects, we're planning to use NT-Backup to achieve "incremental" versions for restore, as in the old NT days!) Hope this helps. Don France Technical Architect, P.A.C.E. San Jose, CA mailto:[EMAIL PROTECTED] PACE - http://www.pacepros.com Bus-Ph: (408) 257-3037 -Original Message- From: Remeta, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 21, 2000 8:51 AM To: [EMAIL PROTECTED] Subject: TSM Upgrade Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark Remeta Seligman Data Corp. 100 Park Avenue New York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Slow restore for large NT client outcome.. appeal to Tivoli
Jeff, I'd begin by looking at your Raid array definition. I've found that when you use more then 4 drives in a single array the performance goes in toilet. if you can test it try runninthe same restore to a raid 0 configuration. - Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger.
Re: TSM Upgrade
Holy smokes! I figured out why the database was never upgraded... when you do the install about 3/4 of the way through it comes up with something about Active Directory and it says you need to restart your computer, do you want to do it now y/n... the first time I ran the installation I answered yes... this crapped out the rest of the install. I just re-ran the 4.1.0.0 install and answered no to the reboot question and it popped up a command prompt window saying it was updating TSM this may take a while... please wait. cyb! -Original Message- From: France, Don G (Pace) [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 21, 2000 1:11 PM To: [EMAIL PROTECTED] Subject: Re: TSM Upgrade In the tradition of ADSM, I would avoid the first release; we waited until 373 for the first TSM, now I recommend the 4.1.1 level, BUT only if you need a new feature only found in 4.1. We've been running 373 with 372.01 clients on Win2K servers for the past 6 weeks, on two separate environments. Did a 3rd server install on Win2k-Pro, all went (mostly) smoothly. The NT-device config for Dell-120T needed help setting the element number, but that was the only "glitch" we've seen, so far; the Dell-130T device-config was correct at the outset. Also, we've installed 2 AIX servers with 373, one has 30 Solaris 372 clients and 5 NT clients... all environments are installed and running okay. (Minor hang-ups due to inadequate handling of Win2K System Objects, we're planning to use NT-Backup to achieve "incremental" versions for restore, as in the old NT days!) Hope this helps. Don France Technical Architect, P.A.C.E. San Jose, CA mailto:[EMAIL PROTECTED] PACE - http://www.pacepros.com Bus-Ph: (408) 257-3037 -Original Message- From: Remeta, Mark [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 21, 2000 8:51 AM To: [EMAIL PROTECTED] Subject: TSM Upgrade Hello all, I just upgraded my ADSM 3.2.1.41 server to TSM 4.1.0.0. When I go into the Server Utilities it says there is an error for Server1. When I try and configure it in the Utilities wizard it doctor watsons out after I enter the username and password. I am trying to manually start the service now but it looks like I will have to go back to ADSM. It doesn't even log anything in the Event viewer. Has anyone seen this behavior before??? Thanks for any help, Mark Remeta Seligman Data Corp. 100 Park Avenue New York, NY 10017 Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately. Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
Re: Novell TSM client performs worse than ADSM ?
I've noticed this as well, as my previous post suggests. JC John Naylor <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 09/21/2000 11:35:37 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Novell TSM client performs worse than ADSM ? Hi, We run 0S390 2.8.0 with TSM 3.7.20 We have recently converted our Novell 4 servers (service pack 8a) to TSM client 3.7.2 from ADSM client 3.1.0.8. We have seen that backups previously running in under 2 hours now take over 4 hours. Has anybody else seen this performance hit with Novell servers after "upgrading" to the TSM client Thanks, John ** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric and Southern Electric are trading names of Scottish and Southern Energy Group **
Re: Slow restore for large NT client outcome.. appeal to Tivoli
With the new copper chips the AS/400s can hit and sustain 4000MIPS. Edward(Ed) J. Finnell, III Enterprise Systems/Proj. Mgr. url:www.ua.edu
TSM throughput.
Hello The landscape : WIN NT, IBM Netfinity servers, SAP 3.1 I, ORACLE 7.3.4 The maximum thorught we saw was 7mb/sec for TSM 3.7. On TSM 4 the maximum through put is 12 mb/sec for the database of size 400 GB. Can anyone please tell me that this is very low. What is the maximum throught any of you have seen with the almost same landscape. Thanks Raminder
Re: TSM throughput.
Landscape: RS6K S70 4.3.2 SAP 2.4 Oracle 7 7133 SSA Model 020 drawers (old!) Backint 2.4 RS6K S70 4.3.2 TSM 3.7.2 server 2 3590 B series drives in a 3494 Last year at a customer site I was achieving a daily 300GB SAP db backup in less than 6 hours across 2 tape drives. That is over an aggregated backup stream of over 50GBph. In this environment I was definitely being constrained by the db server's older disk technology. -- Joshua S. Bassi Senior Technical Consultant Symatrix Technology, Inc. [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Braich, Raminder Sent: Thursday, September 21, 2000 11:38 AM To: [EMAIL PROTECTED] Subject: TSM throughput. Hello The landscape : WIN NT, IBM Netfinity servers, SAP 3.1 I, ORACLE 7.3.4 The maximum thorught we saw was 7mb/sec for TSM 3.7. On TSM 4 the maximum through put is 12 mb/sec for the database of size 400 GB. Can anyone please tell me that this is very low. What is the maximum throught any of you have seen with the almost same landscape. Thanks Raminder
Re: Slow restore for large NT client outcome.. appeal to Tivoli
As the person who started this thread I'd like to thank everyone for their excellent feedback. I'd also like to hear, as Kelly and a few others requested, about and TSM'ers like Blair that also use other products or formally used another product for backing up/restoring Windows NT clients. It would be nice to know if our NT admins are correct in assuming that Arcserve's or Backup Execs's are faster for recovering large drives with lots of small files. If you could also share a little about your specific Arcserve/BackupExec/whatever setup, local tape versus over the network, etc. that would be helpful as well. To answer a couple questions folks had, we are using a DIRMC to DASD for the NT clients, we are using 3590E1A tape drives not DLT, and the TSM database is on an EMC 5930. I will let everyone know how I make out with the TSM performance team analysis as to why our restore for this server took so long. Thanks again, Jeff Connor Niagara Mohawk Power Corp.
Re: TSM throughput.
Is this through a network or directly to TSM on the same system as the application? 12 MB/Sec seems pretty good to me. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs CO 80949-1313 (719) 531-5926 Fax: (719) 260-5991 Email: [EMAIL PROTECTED] www.storsol.com www.storserver.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Braich, Raminder Sent: Thursday, September 21, 2000 12:38 PM To: [EMAIL PROTECTED] Subject: TSM throughput. Hello The landscape : WIN NT, IBM Netfinity servers, SAP 3.1 I, ORACLE 7.3.4 The maximum thorught we saw was 7mb/sec for TSM 3.7. On TSM 4 the maximum through put is 12 mb/sec for the database of size 400 GB. Can anyone please tell me that this is very low. What is the maximum throught any of you have seen with the almost same landscape. Thanks Raminder
Re: Slow restore for large NT client outcome
Somebody do the math here: how long would it take to restore 60 GB from a directly attached tape drive? Best case: assume 8 MB/sec, the restore should take a little over two hours. How many of us have seen that happen? None. So the rest if overhead setting up to read a file from tape and to set up the filesystem to lay down the restored file. I would think those two things will be pretty consistent no matter whose tool is used. Tapes with better start/stop performance will have shorter read setup times and some filesystems will be better than others, but the things that need to happen are the same. We need some real numbers here. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs CO 80949-1313 (719) 531-5926 Fax: (719) 260-5991 Email: [EMAIL PROTECTED] www.storsol.com www.storserver.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Kronstadt, Dan Sent: Wednesday, September 20, 2000 6:42 PM To: [EMAIL PROTECTED] Subject: Re: Slow restore for large NT client outcome I think we need the answers to Kelly Lipp's question - how fast is Arcserve really? But IF it is better, then I dont think we can get away with saying - its too many files, its NTFS that slows down TSM, etc. Those are the realities of our servers, and we need a RESTORE (notice I did not say backup) solution that isn't career ending. Now there was one response that said thay are MOVING towards mirroring - better late than never - and another response that said management doesn't like incremental forever - they need to get over that. All in all, TSM is great - but if any restore takes 48 hours - WB will be looking for a new tech support manager. Dan Kronstadt Warner Bros. "Who the hell wants to hear actors talk?" - H. M. Warner (1881-1958), founder of Warner Bros., in 1927 -Original Message- From: Richard Sims [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 20, 2000 12:56 PM To: [EMAIL PROTECTED] Subject: Re: Slow restore for large NT client outcome Jeff - I more than sympathize with your predicament as a storage administrator dealing with NT systems and their administrators. But be careful about going after a vendor to fix a problem you perceive to be with their product without first establishing baseline values for your configuration and otherwise analyzing it determine just where and what the problem is. Nick's posting today about NTFS performance and recommendations last week regarding FTP baseline tests regarding your problem will help to define it. Such measures will help you obtain baseline values, as close as possible to optimal values, against which you can compare performance with more involved applications like TSM, on top of that amalgam. Being a long-time ADSM guy I'm sure you remember back to postings where people would wail on IBM about poor performance backing up and restoring, asking "What's wrong with ADSM???" - when their implementation choices resulted in 20,000 or more files in one directory, which is deadly for anything entering such a directory. That is to say, the way in which systems are configured and implemented, plus networking problems and operating system defects and design shortcomings can thwart performance in any package implemented on them. Some customers unknowingly implement tape technologies with poor start-stop performance, see slow restoral performance, and then blame the restoral software. We have to be aware of what these things can do to and for us. Know thy technologies, lest they bite thee. It's a classic situation in data processing that users blame performance problems on the first thing between them and the computer system, but of course that's just convenient blame assignment. After all - they have to blame someone or something, and that's the one thing they know. This is not to say that TSM is perfect or necessarily blameless in this situation. But as customer technicians it's our responsibility to determine where the problem lies. And for that to succeed the various experts in the environment (networking, opsys, application) have to work together to analyze it. Your NT people say that TSM seems like a UNIX product trying to make it in the NT space. The irony is that it's a mainframe product that did even better in a Unix environment because of that environment's minimized overhead. You have the unenviable situation of an MVS server and NT clients, with a lineage and history of TCP/IP performance shortcomings, high overhead, and file system inefficiencies. Your shop is looking at an AIX-based TSM server system, which is a good move. Whether "TSM can make it in the NT space" is more up to NT than TSM: if Microsoft wants to be a serious contender, they have to make Windows a serious operating system. Many shops won't implement NTs as enterprise servers because their performance is ridiculously inferior. Tivoli gets blamed for numerous things not its fa
restoring files from another machine
Hi! I have problems trying to restore files from an AIX box to another. I'm following the instruccions given in "Using the Backup-Arching Clients", v 3.7, chapter 3 (Authorizing Another User to Restore/Retrive Your Files and Restoring or Retrieving Another User's Files). What I do is: 1) In the server from which I want to restore the files, in its main window, click Utilities. 2) Chose User Access List... 3 Enter the following data: * as Node, the node name of the client where I want to restore the information. * as User, a user name with owner privileges in the target server (the one given in Node above) * as Directory, *. * as Filename, *. 4) Then, In the target server, I click Utilities and select Access Another User... 5) Enter the following data: * as Node name: the name of the source server. * as User: the user name especified in the User Access List in the other machine. I believe that I'm doing what I have to do, step by step. However after that I select the SET button, I get the file level tree of the source server and just can see the file system names but not its contents (no files nor subdirectories within the file systems). Can anybody help me? Thanks in advance. Sergio R. Cherchyk Arquitectura Tecnológica - Midrange Banco Río de la Plata S.A. - Grupo BSCH Mire 480, 2do piso - 1036 Cap. Fed. Argentina Tel. (054)-11-4341-1643 Fax. (054)-11-4341-1264
TCPIP parameters for TSM on OS/390
I am in the process of replacing my ADSM 3.1.24 on AIX with TSM 4.1 on OS/390. I have the system up an running on the test LPAR and it is working quite well. However when we put TSM in the production LPAR and attempted to do some backups and restores we found the transfer rate had dropped tenfold. The OS/390 system is connected to the LAN via a 3172 (production - default), and two Cisco CIP cards (soon to be production). We found that even though the clients may point to an address associated with on of the Cisco CIP cards the path taken back to the client from the OS/390 system is via TCPIP's default path, the 3172. We will soon be changing the default to on of the Cisco CIP cards, but we will still be sharing the band with all of our end-users. This will not be a problem doing the night backups, but for the file restores the speed is less than desirable. So my question is, is there a parameter setting that I can point TSM to use a specified IP address for its communication back to the client? Thanks in advance, Peter Coles Pacific Gas and Electric Co.
Re: restoring files from another machine
May be you can probe to change your dsm.sys file Where you find NODENAME machine_where_backup change to NODENAME machine_where_restore For example, i want to restore files from node euler in node euler2, you must add/change line NODENAME euler with line NODENAME euler2 Also, you must verify that any session from euler machine be active Use q ses Cordially Diego Garcma Pontificia Universidad Javeriana Bogota, Colombia Sergio Cherchyk wrote: > Hi! > > I have problems trying to restore files from an AIX box to another. I'm > following the instruccions given in "Using the Backup-Arching Clients", > v 3.7, chapter 3 (Authorizing Another User to Restore/Retrive Your Files > and Restoring or Retrieving Another User's Files). > What I do is: > 1) In the server from which I want to restore the files, in its main > window, click Utilities. > 2) Chose User Access List... > 3 Enter the following data: > * as Node, the node name of the client where I want to restore the > information. > * as User, a user name with owner privileges in the target server (the > one given in Node above) > * as Directory, *. > * as Filename, *. > 4) Then, In the target server, I click Utilities and select Access > Another User... > 5) Enter the following data: > * as Node name: the name of the source server. > * as User: the user name especified in the User Access List in the other > machine. > > I believe that I'm doing what I have to do, step by step. However after > that I select the SET button, I get the file level tree of the source > server and just can see the file system names but not its contents (no > files nor subdirectories within the file systems). > > Can anybody help me? > > Thanks in advance. > > > Sergio R. Cherchyk > Arquitectura Tecnolsgica - Midrange > Banco Rmo de la Plata S.A. - Grupo BSCH > Mire 480, 2do piso - 1036 Cap. Fed. > Argentina > Tel. (054)-11-4341-1643 > Fax. (054)-11-4341-1264 >
Tivoli test vouchers (2) available
Hi, As a result of participating in the beta exam early this year, I received three (one of which I'm reserving for my boss in case she wants to write the exam) "pre-paid exam vouchers good at any Sylvan Testing Center worldwide. The vouchers, valued at $150.00 each, are valid for use with any published Tivolie exam and are transferable to a friend or colleague." So, if you're reading this on the adsm-l list, I'll consider you a colleague. If you can use one of these vouchers, please e-mail me at [EMAIL PROTECTED] and I'll provide you with the voucher number free of charge (but only to the first two respondants). No, you can't have my Tivoli Professional Certification Polo shirt. Regards, Ben Huber Data Support Analyst Kelman Technologies
Re: TCPIP parameters for TSM on OS/390
We are running TSM on a OS/390 platform. The LPAR that our production TSM runs in has four different connections. Two are reachable by different host names & 2 by IP address only. Clients connect in based on what network they are connecting in from. Three connections come in on a OSA/2 adapters, the fourth is the corporate FDDI. The fourth connection is only used for our non-critical AIX systems and desktop clients. -Original Message- From: Coles, Peter [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 21, 2000 1:35 PM To: [EMAIL PROTECTED] Subject: TCPIP parameters for TSM on OS/390 Sensitivity: Private I am in the process of replacing my ADSM 3.1.24 on AIX with TSM 4.1 on OS/390. I have the system up an running on the test LPAR and it is working quite well. However when we put TSM in the production LPAR and attempted to do some backups and restores we found the transfer rate had dropped tenfold. The OS/390 system is connected to the LAN via a 3172 (production - default), and two Cisco CIP cards (soon to be production). We found that even though the clients may point to an address associated with on of the Cisco CIP cards the path taken back to the client from the OS/390 system is via TCPIP's default path, the 3172. We will soon be changing the default to on of the Cisco CIP cards, but we will still be sharing the band with all of our end-users. This will not be a problem doing the night backups, but for the file restores the speed is less than desirable. So my question is, is there a parameter setting that I can point TSM to use a specified IP address for its communication back to the client? Thanks in advance, Peter Coles Pacific Gas and Electric Co.
Peter Schrijvers/BCS/BASF is out of the office.
I will be out of the office from 14/09/2000 until 02/10/2000. In the mean time Gerard Delaere will take over the responsibility concerning the central backup system TSM
how to detect backup error from tsm scheduler
Hi All, AIX Server v3.7.3 AIX/SUN client v3.7.2 I think I am hitting IC26775 on a SUN client and a few AIX machines on increment backup. (IC26675: CLIENT BACKUPS FAIL WITH RETURN CODE 195, AN UNKNOWN SYSTEM ERROR.) The worst thing is I don't get any error message on server and there is no ANS1512E message.Form q event, result is zero and there is no exception. e.g. ANS1512E Scheduled event 'SCHEDULE' failed. Return code = 4. I notice the error when checking dsmsched.log & dsmerror.log on each machine. My question is, how to detect these kind of error? Have I done something wrong in the setup? Apart from this particular case, From q event, I always get a zero result except - when a unix script that return non-zero code is scheduled via scheduler - type something wrong in options or object in "define schedule" - the schedule is not kicked off (maybe due to dsmc sched down or network problem) other than these, I never see a zero result even "ANE4959I Total number of objects failed: is non-zero" Thank you in advance. Below are dsm.sys, dsm.opt, dsmsched.log & dsmerror.log dsm.sys SErvername tsm COMMmethod TCPip TCPPort1500 TCPServeraddress 172.20.77.1 ERRORLOGName /dsmerror.log SCHEDLOGName /dsmsched.log SCHEDMODe prompted SCHEDLOGRetention 7 Domain all-local * InclExcl /opt/tivoli/tsm/client/ba/bin/inclexcl.lst CompressionYes TCPCLIENTaddress 172.20.65.7 Nodename s0007hks Password s0007hks Editor On Users root dsm.opt Servername tsm Scrollpromptyes Subdir yes MAKESPARSEFILE NO dsmsched.log 09/19/00 22:01:29 Successful incremental backup of '/bkup_dbpr01' 09/19/00 22:01:30 --- SCHEDULEREC STATUS BEGIN 09/19/00 22:01:30 Total number of objects inspected: 35,037 09/19/00 22:01:30 Total number of objects backed up: 22 09/19/00 22:01:30 Total number of objects updated: 0 09/19/00 22:01:30 Total number of objects rebound: 0 09/19/00 22:01:30 Total number of objects deleted: 0 09/19/00 22:01:30 Total number of objects expired: 0 09/19/00 22:01:30 Total number of objects failed: 0 09/19/00 22:01:30 Total number of bytes transferred:10.83 MB 09/19/00 22:01:30 Data transfer time:0.15 sec 09/19/00 22:01:30 Network data transfer rate:69,991.71 KB/sec 09/19/00 22:01:30 Aggregate data transfer rate:461.88 KB/sec 09/19/00 22:01:30 Objects compressed by: 89% 09/19/00 22:01:30 Elapsed processing time: 00:00:24 09/19/00 22:01:30 --- SCHEDULEREC STATUS END 09/19/00 22:01:30 Unknown system error Please check the TSM Error Log for any additional information 09/19/00 22:01:30 --- SCHEDULEREC OBJECT END S0007HKS 09/19/00 22:00:00 09/19/00 22:01:30 Scheduled event 'S0007HKS' completed successfully. 09/19/00 22:01:30 Sending results for scheduled event 'S0007HKS'. 09/19/00 22:01:30 Results sent to server for scheduled event 'S0007HKS'. dsmerror.log 09/19/00 22:01:30 Return code 195 unknown 09/19/00 22:01:30 Return code 195 unknown 09/19/00 22:01:30 Unknown system error Please check the TSM Error Log for any additional information Regards, Eric Tang
Re: TSM server 3.7.3.0 crashing
Hi There, Welcome to the 3.7.3.0 "crashing club". For us the situation improved with 3.7.3.7, but in the end we had to go upto 4.1.1 to get a stable system. Virtually all the crashes occured when there was some sort of I/O error. 4.1.1 must have better error handling. Regards -- Andrew Webster PC, NetApp Filer, TSM Sanno Move Project Deutsche Real Estate Consulting Ltd. - Tokyo Internal (but outside Tokyo): 88 408-7542 Tel. +81-3-5156-7542 Fax. +81-3--5156-4811 Mobile: 0907 184 8958 [EMAIL PROTECTED] Message History From: [EMAIL PROTECTED] on 21/09/2000 10:57 AM GMT Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: TSM server 3.7.3.0 crashing Hi *SM-ers! My TSM 3.7.3.0 server is crashing at least once a day for the last 5 days. There no addition information in the Activity log. The only output is a core dump and some unclear messages in the dsmserv.err: 09/21/2000 10:14:28 ANR7834S Thread 49 (tid 3196) terminating on signal 11 (Segmentation violation). 09/21/2000 10:14:28 ANR7834S GPR 0: 0x, 1: 0x366c7c80, 2: 0x3012003c, 3: 0x 09/21/2000 10:14:28 ANR7834S GPR 4: 0x31a30fec, 5: 0x13711301, 6: 0x1102, 7: 0x 09/21/2000 10:14:28 ANR7834S GPR 8: 0x1000732b, 9: 0x1000732b, 10: 0x, 11: 0x34e0 09/21/2000 10:14:28 ANR7834S GPR 12: 0x0200, 13: 0x366cbf9c, 14: 0x35b2edf0, 15: 0x 09/21/2000 10:14:28 ANR7834S GPR 16: 0x018c, 17: 0x366cbc6c, 18: 0x366c9600, 19: 0x366c89c4 09/21/2000 10:14:28 ANR7834S GPR 20: 0x0002, 21: 0x, 22: 0x35fd4038, 23: 0x00041e19 09/21/2000 10:14:28 ANR7834S GPR 24: 0x35fd4020, 25: 0x35b205f0, 26: 0x, 27: 0x0001 09/21/2000 10:14:28 ANR7834S GPR 28: 0x079e, 29: 0x366c8dc4, 30: 0x366c80f8, 31: 0x35fd4000 09/21/2000 10:14:28 ANR7834S IAR: 0x100121fc LR: 0x10081d98 CONTEXT: 0x366c7900 09/21/2000 10:14:28 ANR7833S Server thread 1 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 2 terminated in response to program abort. 09/21/2000 10:14:28 ANR7833S Server thread 3 terminated in response to program abort. etc. etc. Anybody seen this before? Kindest regards, Eric van Loon ** This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **
Re: Unknown Exchange API error
Del Hoobler [SMTP:[EMAIL PROTECTED]] wrote: > We have seen this a few times but cannot pinpoint it > without a trace... TDP for Exchange is calling > an Exchange API to do something and the Exchange Server > is giving an error that even it as no error message for... > ...which means the Exchange Server wasn't expecting > it to experience this error either... > Sorry to butt in, this may not be helpful, but a point of interpretation - I assume you're talking about messages in the event log that say (paraphrased) "I don't know what this error is but here are the strings it contains". That doesn't necessarily mean Exchange "wasn't expecting" the error - what it means is that the part of the system that interprets the error messages has got screwed up. I used to see it a lot when I was doing Exchange, reading the event log from my PC which had other questionable software installed. You might find that if you reinstall the Exchange Admin client, you might get the error messages back, and they will definitely make more sense. Another thing, Exchange has a HUGE number of things that be logged or not-logged depending on configuration settings. You really need to dig deeply into those settings to make sure you're getting the right level of information. (hoping I'm not teaching anyone to suck eggs here)
BACKUP DB to disk - questions
TSM 3.7.3 on Solaris 7, new implementation. command: backup db devclass=seqdisk Until my organisation gets its act together to give me access to the ACSLS server (it's a long story), I have no tape storage available. But I have a nice large chunk of EMC Symmetrix array to play in. So I have created a devclass with devtype=file, and I have used that as the destination for BACKUP DB, and it works just fine, and I'll go ahead and set up a schedule for it. But I do have some questions. Does TSM do anything about managing the database backup volumes? Or do I need to do that manually? (ie delete old versions before it runs out of space). As far as I can tell, the database doesn't see them as volumes, because they don't show up when I do Q VOL (although Q VOLHIST describes them as volumes. When I have to restore the database at a later date, will I actually need the volumehistory file? I figure I will be able to tell by the timestamps on the file, and the size, which one to use. And some more general questions: How likely is it that we'll need to restore the database anyhow - how often does a TSM database become corrupted, and under what circumstances? I'm assuming the media is 99.999% safe because it's in the Symmetrix array, in a mirrored configuration. The active database is in the same EMC, on a different LUN, also mirrored. So I'm betting that 2 x 2 mirrors are not going to fail all once. Barring the natural disaster scenario, is this adequate, or should I get more paranoid? I know these things are a trade-off between likelihood and impact - what I'm after is the size of the likelihood. Anyone have any experience they'd be willing to share? (Apologies for these newbie questions - I admit I'm a newbie at this, and there will be more. Feel free to point me at relevant docs - I have looked but there is SO much of it.) -- Lesley Walker Distributed Systems Services, EDS New Zealand [EMAIL PROTECTED] "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future by the year 2000, may have only 1,000 vacuum tubes and weigh only 1.5 tons" Popular Mechanics, March 1949
Re: 3.1 client support after January 2001
Is v2 client support with v3.7 server? Currently I have 2 HPUX10.01 machines running v2.1.0.8 client. Thanks Regards, Eric Tang
