Re: Migration problem
Hi TSM-ers! Just to let you all know, I found the cause of the storagepool migration issue: a show cont reveiled that all files in the diskpool belonged to just one (very large) client. That's why TSM only starts one migration. There doesn't seem to be a way to force TSM to do multiple migrations for one client, I don't know why, since the targetpool is not collocated. Anyway, I solved it for now by enlarging the diskpool. Thanks for all your help/suggestions! Kindest regards, Eric van Loon KLM Royal Dutch Airlines _ From: Loon, EJ van - SPLXM Sent: vrijdag 9 oktober 2009 16:27 To: Loon, EJ van - SPLXM Subject: Migration problem Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Migration problem
My only observation at this point is, something changed, therefore, something else changed. If you have not changed the level or configuration of the server or client software, then something outside of changed. I hope your reboot helps. George H. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Monday, October 05, 2009 6:46 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi George! I do not want to treat one client different that the other one. Years of experience with TSM taught me one thing: if you want to run a TSM environment with a minimum amount of people and attention, you should create an environment with as little management classes, policies an deviceclasses as possible! I have to mention that this TSM environment has been running fine for about two years now and nothing has changed. The strange migration behavior is something that started about a few days ago. I scheduled a stop/start of this server, so let's see what that brings. Thanks Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebschman, George J. Sent: maandag 5 oktober 2009 12:02 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem It sounds a lot like TSM is allocating space in your disk pool for a lot of data from many clients and finding itself maxed out. It is not always how much data is actually on the media, but how much space TSM has allocated per client. - Have you considered setting up larger clients to go directly to Virtual Tape? If you want data to go to VTL right away, send it there. If you have 30 VTL drives, find the 10 or 15 clients with the biggest sized files put them in a domain with a default management class that points directly to VTL...or edit the include statements of the clients (any client)to point the biggest files to a Virtual Tape management class. The second way does not require a new domain, but it requires more work with clients.) - I would also raise your threshold a bit so that you are not continually in migration. George Huebschman Media Librarian Legg Mason -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Monday, October 05, 2009 4:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time
Re: Migration problem
Hi George! I do not want to treat one client different that the other one. Years of experience with TSM taught me one thing: if you want to run a TSM environment with a minimum amount of people and attention, you should create an environment with as little management classes, policies an deviceclasses as possible! I have to mention that this TSM environment has been running fine for about two years now and nothing has changed. The strange migration behavior is something that started about a few days ago. I scheduled a stop/start of this server, so let's see what that brings. Thanks Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebschman, George J. Sent: maandag 5 oktober 2009 12:02 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem It sounds a lot like TSM is allocating space in your disk pool for a lot of data from many clients and finding itself maxed out. It is not always how much data is actually on the media, but how much space TSM has allocated per client. - Have you considered setting up larger clients to go directly to Virtual Tape? If you want data to go to VTL right away, send it there. If you have 30 VTL drives, find the 10 or 15 clients with the biggest sized files put them in a domain with a default management class that points directly to VTL...or edit the include statements of the clients (any client)to point the biggest files to a Virtual Tape management class. The second way does not require a new domain, but it requires more work with clients.) - I would also raise your threshold a bit so that you are not continually in migration. George Huebschman Media Librarian Legg Mason -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Monday, October 05, 2009 4:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message.
Re: Migration problem
Hi Stefan! Checked that, that was not the case... Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Stefan Folkerts Sent: maandag 5 oktober 2009 12:01 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Eric, Could it be that there were other sessions running to the next pool due to settings in the bcg's so there were no more mountpoints for 10 migrations but only for 2? Regards, Stefan -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Namens Loon, EJ van - SPLXM Verzonden: maandag 5 oktober 2009 10:47 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] Migration problem Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Migration problem
It sounds a lot like TSM is allocating space in your disk pool for a lot of data from many clients and finding itself maxed out. It is not always how much data is actually on the media, but how much space TSM has allocated per client. - Have you considered setting up larger clients to go directly to Virtual Tape? If you want data to go to VTL right away, send it there. If you have 30 VTL drives, find the 10 or 15 clients with the biggest sized files put them in a domain with a default management class that points directly to VTL...or edit the include statements of the clients (any client)to point the biggest files to a Virtual Tape management class. The second way does not require a new domain, but it requires more work with clients.) - I would also raise your threshold a bit so that you are not continually in migration. George Huebschman Media Librarian Legg Mason -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Monday, October 05, 2009 4:47 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: Migration problem
Eric, Could it be that there were other sessions running to the next pool due to settings in the bcg's so there were no more mountpoints for 10 migrations but only for 2? Regards, Stefan -Oorspronkelijk bericht- Van: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Namens Loon, EJ van - SPLXM Verzonden: maandag 5 oktober 2009 10:47 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] Migration problem Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Migration problem
Hi Remco! The high treshold is set to 5 because we want the data to go to virtual tape a.s.a.p. This weekend the diskpool went to 100% again because of the strange migration behavoir. The pool contained data from 100+ clients, but still no more than 2 migrations were running The tape deviceclass has mountlimit=drives which is 30 drives. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: vrijdag 2 oktober 2009 17:10 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622 ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Migration problem
Have you ever considered increasing the high threshold? IIRC TSM won't start new automig processes when migration is already running, and will only start as many processes as there are different clients having data in your pool. Also, check out your mountlimit on the tape devclass. Furthermore, your disk pool might not be fast enough to keep your drives streaming. -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Migration problem
Hi! This setting has always been this way and always did what it was supposed to do: we do want data to go to (virtual) tape a.s.a.p. But now the diskpool is filled more quickly than the migration empties it, because there are just two migrations running and they keep on finishing after just migrating one file at a time! This causes the overall migration performance to be lower that the rate new data is coming into the server, so the pool fills up. Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebschman, George J. Sent: vrijdag 2 oktober 2009 16:03 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem The diskpool was full, but high migration is 5%. A low highmig threshold could easily start off migrations that run just one file then quit, especially if there are large files...but how did you fill the disk pool with such a low percentage for the high mig threshold? -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Friday, October 02, 2009 9:17 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi Eric! Yes! Here are all settings for the storagepool: Storage Pool Name: DISKPOOL_LBU3_1 Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity: 983 G Space Trigger Util: 12.9 Pct Util: 12.8 Pct Migr: 12.6 Pct Logical: 100.0 High Mig Pct: 5 Low Mig Pct: 0 Migration Delay: 0 Migration Continue: Yes Migration Processes: 10 Reclamation Processes: Next Storage Pool: DL_LBU3_STB_1 Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate?: Reclamation Threshold: Offsite Reclamation Limit: Maximum Scratch Volumes Allowed: Number of Scratch Volumes Used: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 2,668,083.67 Elapsed Migration Time (seconds): 55,786 Reclamation in Progress?: Last Update by (administrator): KLM35757 Last Update Date/Time: 10/02/2009 10:50:25 Storage Pool Data Format: Native Copy Storage Pool(s): Continue Copy on Error?: CRC Data: No Reclamation Type: Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Eric Vaughn Sent: vrijdag 2 oktober 2009 15:01 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Do you have a high and low migration threshold set? Eric Vaughn Technical Administrator Stevenson University Office (443)334-2301 evau...@stevenson.edu >>> "Loon, EJ van - SPLXM" 10/2/2009 8:33 AM >>> Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** ** For information, services and offers, please visit our web site: http://www.klm.com. 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 par
Re: Migration problem
The diskpool was full, but high migration is 5%. A low highmig threshold could easily start off migrations that run just one file then quit, especially if there are large files...but how did you fill the disk pool with such a low percentage for the high mig threshold? -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Loon, EJ van - SPLXM Sent: Friday, October 02, 2009 9:17 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Migration problem Hi Eric! Yes! Here are all settings for the storagepool: Storage Pool Name: DISKPOOL_LBU3_1 Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity: 983 G Space Trigger Util: 12.9 Pct Util: 12.8 Pct Migr: 12.6 Pct Logical: 100.0 High Mig Pct: 5 Low Mig Pct: 0 Migration Delay: 0 Migration Continue: Yes Migration Processes: 10 Reclamation Processes: Next Storage Pool: DL_LBU3_STB_1 Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate?: Reclamation Threshold: Offsite Reclamation Limit: Maximum Scratch Volumes Allowed: Number of Scratch Volumes Used: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 2,668,083.67 Elapsed Migration Time (seconds): 55,786 Reclamation in Progress?: Last Update by (administrator): KLM35757 Last Update Date/Time: 10/02/2009 10:50:25 Storage Pool Data Format: Native Copy Storage Pool(s): Continue Copy on Error?: CRC Data: No Reclamation Type: Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Eric Vaughn Sent: vrijdag 2 oktober 2009 15:01 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Do you have a high and low migration threshold set? Eric Vaughn Technical Administrator Stevenson University Office (443)334-2301 evau...@stevenson.edu >>> "Loon, EJ van - SPLXM" 10/2/2009 8:33 AM >>> Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands
Re: Migration problem
Hi Eric! Yes! Here are all settings for the storagepool: Storage Pool Name: DISKPOOL_LBU3_1 Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity: 983 G Space Trigger Util: 12.9 Pct Util: 12.8 Pct Migr: 12.6 Pct Logical: 100.0 High Mig Pct: 5 Low Mig Pct: 0 Migration Delay: 0 Migration Continue: Yes Migration Processes: 10 Reclamation Processes: Next Storage Pool: DL_LBU3_STB_1 Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate?: Reclamation Threshold: Offsite Reclamation Limit: Maximum Scratch Volumes Allowed: Number of Scratch Volumes Used: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 2,668,083.67 Elapsed Migration Time (seconds): 55,786 Reclamation in Progress?: Last Update by (administrator): KLM35757 Last Update Date/Time: 10/02/2009 10:50:25 Storage Pool Data Format: Native Copy Storage Pool(s): Continue Copy on Error?: CRC Data: No Reclamation Type: Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Eric Vaughn Sent: vrijdag 2 oktober 2009 15:01 To: ADSM-L@VM.MARIST.EDU Subject: Re: Migration problem Do you have a high and low migration threshold set? Eric Vaughn Technical Administrator Stevenson University Office (443)334-2301 evau...@stevenson.edu >>> "Loon, EJ van - SPLXM" 10/2/2009 8:33 AM >>> Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Re: Migration problem
Do you have a high and low migration threshold set? Eric Vaughn Technical Administrator Stevenson University Office (443)334-2301 evau...@stevenson.edu >>> "Loon, EJ van - SPLXM" 10/2/2009 8:33 AM >>> Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
Migration problem
Hi TSM-ers! Today I came in the office and customers complained about failing backups. I checked the TSM server and noticed that the diskpool was full. Migration was running, but only two processes at the same time. A migration starts, migrates a file an then completes successfully, another one starts, migrates one file and finishes again and so on. The storagepool has migproc=10 and the nextpool is not collocated, but only two are running and they keep on finishing after just migrating one file! I was able to lower the storagepool usage manually by issuing move data commands against the physical diskpool volumes. This way I was able to move all the data from them manually, but I don't understand why migration is behaving like this. Has anybody seen this before? Thank you very much for your reply in advance! Kind regards, Eric van Loon ** For information, services and offers, please visit our web site: http://www.klm.com. 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **
NAS Migration Problem
Hello! We need to migrate NAS data from EMC Celerra to IBM NS5200. The network connection on the source is only 100 MB. We tried copying using Robocopy on CFS-mounted source and target filesystems using a Windows server. The transfer was painfully slow (about 60 GB in four days). There about about 10 million files in the filesystem. We then tried using TSM 5.3 to restore to the target from the source's NFS mounted backup on AIX. This runs much faster (300 GB in 20 hours). We aren't using TSM NDMP backups yet. We also have an issue syncing up our source and target after the restore since the backup and restore time might not fit in our application downtime. Anyone have experience migrating/copying NAS data with TSM or otherwise? +-- |This was sent by [EMAIL PROTECTED] via Backup Central. |Forward SPAM to [EMAIL PROTECTED] +--
Re: Migration problem
Hi Martha, nice to see you back on the list!
Not sure what OS you are running TSM on, but we still support TSM on MVS
(or OS/390, or whatever it's called today :-) You should consider opening
a call with IBM support to be certain, but off-hand this could be APAR
IC32423. You can look the APAR up by going to www.ibm.com and doing a
search on the APAR number.
Best regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Martha McConaghy <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
08/01/2003 15:42
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Migration problem
Its been a long time since I have posted to the list since I know that
support for mainframe based TSM is pretty non-existent at this point.
However, things have run well, so I haven't needed any help.
Unfortunately, that has changed. One of my servers is now coming up with
an error that is not documented in the books. What little I can find
tells
me to call support. I'm not sure that will help at this point, so I'm
hoping that one of you might recognize the situation.
Every time a migration kicks in for BACKUPPOOL to go to tape, it tries to
start, requests the tape and all. After it gets the tape, it gets the
following errors:
ANR0102E ASALLOC(3944): Error 1 inserting row in table "AS.Segments".
ANR1032W Migration process 2 terminated for storage pool BACKUPPOOL -
internal
server error detected.
I expanded the database in case it was out of space, but that didn't help.
Any suggestions?
Martha McConaghy
Mgr. Systems, Network and Operations
Marist College
Migration problem
Its been a long time since I have posted to the list since I know that support for mainframe based TSM is pretty non-existent at this point. However, things have run well, so I haven't needed any help. Unfortunately, that has changed. One of my servers is now coming up with an error that is not documented in the books. What little I can find tells me to call support. I'm not sure that will help at this point, so I'm hoping that one of you might recognize the situation. Every time a migration kicks in for BACKUPPOOL to go to tape, it tries to start, requests the tape and all. After it gets the tape, it gets the following errors: ANR0102E ASALLOC(3944): Error 1 inserting row in table "AS.Segments". ANR1032W Migration process 2 terminated for storage pool BACKUPPOOL - internal server error detected. I expanded the database in case it was out of space, but that didn't help. Any suggestions? Martha McConaghy Mgr. Systems, Network and Operations Marist College
Re: TSM migration problem & recovery log question???
Hi, Joni,
When was the last DBBackup? Did that finish successfully? If not, The log will not
empty.
Jane
%%
Jane Bamberger
IS Department
Bassett Healthcare
607-547-4750
- Original Message -
From: Joni Moyer
To: [EMAIL PROTECTED]
Sent: Tuesday, January 14, 2003 11:05 AM
Subject: Re: TSM migration problem & recovery log question???
I really don't know what is wrong with the recovery log. There are no
clients that have been connected to the server for more than 4 minutes. I
have a backup of a primary tape pool to a copy tape pool running 1 process.
Other than that everything is silent. I can't seem to get the log to clear
to 0% and soon I'll have to add more space which will take it to 6 GB for
the recovery log. I am still baffled about this.
We have TSM on the mainframe and it is attached to STK silos with 3590
magstar tapes. As far as I know communication wasn't lost because other
migrations/backups etc. were running. I was just having problems with 1
out of 3 of my disk storage pools migrating to tape. I looked through the
logs trying to find out what tape it might have been trying to migrate to,
but it never asked for a certain tape and I never received a mount request
either. I know this all seems very bizarre. I really don't know how to
justify what happened. Thanks!!!
Joni Moyer
Systems Programmer
[EMAIL PROTECTED]
(717)975-8338
"Cook, Dwight
E" To: [EMAIL PROTECTED]
Subject: Re: TSM migration problem &
recovery log question???
Sent by:
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
IST.EDU>
01/14/2003
09:20 AM
Please respond
to "ADSM: Dist
Stor Manager"
Because of internal locks that aren't being readily resolved.
Look for a client (or clients) that have been connected for a long time
(say
4-6+ hours)
Also look for other things like expiration, reclamation, migration, etc...
processes that might be running also.
Might only been client sessions though...
Anyway, generally (I've discovered) the log won't clear until those long
running clients either finish normally OR I cancel them.
We have had to increase some of our log sizes to 6 GB (6144 MB) in order to
allow things to run to completion and not have our log fill up and cause
sessions to die off due to log space being exhausted.
Now, media inaccessible, how is your library attached ?
I've noticed (in the past) that if the library manager can't talk to TSM
(or
tsm can't talk to the library manager) AND tsm requires a tape mount (which
fails because of lack of communication) even though I restored
communications to the library, I would still have to bounce TSM to get it
to
start talking to the library again...
Is there something that is causing a loss of communications with your
library prior to this "media not available" situation ?
When things fail due to media not available does it report a specific
volser
?
When things are bounced and start working again, does the problem volser
(if
identified) become accessible ?
Dwight E. Cook
Software Application Engineer III
Science Applications International Corporation
509 S. Boston Ave. Suite 220
Tulsa, Oklahoma 74103-4606
Office (918) 732-7109
-Original Message-
From: Joni Moyer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 14, 2003 7:23 AM
To: [EMAIL PROTECTED]
Subject: TSM migration problem & recovery log question???
The recovery log on TSM is 95% full. I do a full DB backup everyday, which
I thought would reset the log to 0%. It is in normal mode, not
rollforward. Why would it be so high when I just did a full backup last
night that ended at 9 PM. The log right now is 4.6 GB with 4.2 GB
utilized. Any suggestions?
We have TSM 4.1.3 on OS/390. My other problem is that our disk storage
pool filled to 100%, getting message anr1021w: media inaccessible. When
trying to force migration (which should've occurred automatically) the
processes still failed with the media inaccessible messages. We were not
in tape drive allocation and plenty of scratch volumes were available. No
messages in the logs even pointed to a specific tape that was being called
in. Bouncing the tsm server triggered one of four possible migration
processes. Around 8 hours after bouncing the server 4 migration processes
finally did kick off after hitting the set threshold. Any ideas or insight
as to what the problem could be???
Thanks for any help,
Joni Moyer
Systems Programmer
[EMAIL PROTECTED]
(717)975-8338
Re: TSM migration problem & recovery log question???
I really don't know what is wrong with the recovery log. There are no clients that have been connected to the server for more than 4 minutes. I have a backup of a primary tape pool to a copy tape pool running 1 process. Other than that everything is silent. I can't seem to get the log to clear to 0% and soon I'll have to add more space which will take it to 6 GB for the recovery log. I am still baffled about this. We have TSM on the mainframe and it is attached to STK silos with 3590 magstar tapes. As far as I know communication wasn't lost because other migrations/backups etc. were running. I was just having problems with 1 out of 3 of my disk storage pools migrating to tape. I looked through the logs trying to find out what tape it might have been trying to migrate to, but it never asked for a certain tape and I never received a mount request either. I know this all seems very bizarre. I really don't know how to justify what happened. Thanks!!! Joni Moyer Systems Programmer [EMAIL PROTECTED] (717)975-8338 "Cook, Dwight E" To: [EMAIL PROTECTED] Subject: Re: TSM migration problem & recovery log question??? Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] IST.EDU> 01/14/2003 09:20 AM Please respond to "ADSM: Dist Stor Manager" Because of internal locks that aren't being readily resolved. Look for a client (or clients) that have been connected for a long time (say 4-6+ hours) Also look for other things like expiration, reclamation, migration, etc... processes that might be running also. Might only been client sessions though... Anyway, generally (I've discovered) the log won't clear until those long running clients either finish normally OR I cancel them. We have had to increase some of our log sizes to 6 GB (6144 MB) in order to allow things to run to completion and not have our log fill up and cause sessions to die off due to log space being exhausted. Now, media inaccessible, how is your library attached ? I've noticed (in the past) that if the library manager can't talk to TSM (or tsm can't talk to the library manager) AND tsm requires a tape mount (which fails because of lack of communication) even though I restored communications to the library, I would still have to bounce TSM to get it to start talking to the library again... Is there something that is causing a loss of communications with your library prior to this "media not available" situation ? When things fail due to media not available does it report a specific volser ? When things are bounced and start working again, does the problem volser (if identified) become accessible ? Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -Original Message- From: Joni Moyer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 7:23 AM To: [EMAIL PROTECTED] Subject: TSM migration problem & recovery log question??? The recovery log on TSM is 95% full. I do a full DB backup everyday, which I thought would reset the log to 0%. It is in normal mode, not rollforward. Why would it be so high when I just did a full backup last night that ended at 9 PM. The log right now is 4.6 GB with 4.2 GB utilized. Any suggestions? We have TSM 4.1.3 on OS/390. My other problem is that our disk storage pool filled to 100%, getting message anr1021w: media inaccessible. When trying to force migration (which should've occurred automatically) the processes still failed with the media inaccessible messages. We were not in tape drive allocation and plenty of scratch volumes were available. No messages in the logs even pointed to a specific tape that was being called in. Bouncing the tsm server triggered one of four possible migration processes. Around 8 hours after bouncing the server 4 migration processes finally did kick off after hitting the set threshold. Any ideas or insight as to what the problem could be??? Thanks for any help, Joni Moyer Systems Programmer [EMAIL PROTECTED] (717)975-8338
Re: TSM migration problem & recovery log question???
Because of internal locks that aren't being readily resolved. Look for a client (or clients) that have been connected for a long time (say 4-6+ hours) Also look for other things like expiration, reclamation, migration, etc... processes that might be running also. Might only been client sessions though... Anyway, generally (I've discovered) the log won't clear until those long running clients either finish normally OR I cancel them. We have had to increase some of our log sizes to 6 GB (6144 MB) in order to allow things to run to completion and not have our log fill up and cause sessions to die off due to log space being exhausted. Now, media inaccessible, how is your library attached ? I've noticed (in the past) that if the library manager can't talk to TSM (or tsm can't talk to the library manager) AND tsm requires a tape mount (which fails because of lack of communication) even though I restored communications to the library, I would still have to bounce TSM to get it to start talking to the library again... Is there something that is causing a loss of communications with your library prior to this "media not available" situation ? When things fail due to media not available does it report a specific volser ? When things are bounced and start working again, does the problem volser (if identified) become accessible ? Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -Original Message- From: Joni Moyer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 7:23 AM To: [EMAIL PROTECTED] Subject: TSM migration problem & recovery log question??? The recovery log on TSM is 95% full. I do a full DB backup everyday, which I thought would reset the log to 0%. It is in normal mode, not rollforward. Why would it be so high when I just did a full backup last night that ended at 9 PM. The log right now is 4.6 GB with 4.2 GB utilized. Any suggestions? We have TSM 4.1.3 on OS/390. My other problem is that our disk storage pool filled to 100%, getting message anr1021w: media inaccessible. When trying to force migration (which should've occurred automatically) the processes still failed with the media inaccessible messages. We were not in tape drive allocation and plenty of scratch volumes were available. No messages in the logs even pointed to a specific tape that was being called in. Bouncing the tsm server triggered one of four possible migration processes. Around 8 hours after bouncing the server 4 migration processes finally did kick off after hitting the set threshold. Any ideas or insight as to what the problem could be??? Thanks for any help, Joni Moyer Systems Programmer [EMAIL PROTECTED] (717)975-8338
TSM migration problem & recovery log question???
The recovery log on TSM is 95% full. I do a full DB backup everyday, which I thought would reset the log to 0%. It is in normal mode, not rollforward. Why would it be so high when I just did a full backup last night that ended at 9 PM. The log right now is 4.6 GB with 4.2 GB utilized. Any suggestions? We have TSM 4.1.3 on OS/390. My other problem is that our disk storage pool filled to 100%, getting message anr1021w: media inaccessible. When trying to force migration (which should've occurred automatically) the processes still failed with the media inaccessible messages. We were not in tape drive allocation and plenty of scratch volumes were available. No messages in the logs even pointed to a specific tape that was being called in. Bouncing the tsm server triggered one of four possible migration processes. Around 8 hours after bouncing the server 4 migration processes finally did kick off after hitting the set threshold. Any ideas or insight as to what the problem could be??? Thanks for any help, Joni Moyer Systems Programmer [EMAIL PROTECTED] (717)975-8338
Re: Migration Problem
Gerald, maybe you already found the problem but there can be a real situation without any errors to force same behavior: 17.4% of the disk pool are free, i.e. 21 GB. And if the client attempts to write 25 GB file it would go direct to next primary pool. Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject:Migration Problem TSM Server 4.2.2.0 on Solaris 2.8 TSM Client 5.1.0 on Linux 2.4 Test system.. primary disk pool filled up almost but not quite to hit the hi threshold of 90 that would start a migration.. yet I notice backups are now going to tape instead of the diskpool. What gives? Theres no Max size threshold that would cause the files to go to tape due to size. Why are the backups going to tape instead of filling the disk pool up to it's hi of 90? Weird.. tsm: SERVER1>q stg Storage Device EstimatedPctPct High Low Next Stora- Pool NameClass NameCapacity Util Migr Mig Mig ge Pool (MB) Pct Pct --- -- -- - - --- --- ARCHIVEPOOL DISK 1,030.0 17.5 17.590 70 BACKUPPOOL DISK 122,891.0 82.6 82.690 70 TAPEPOOL SPACEMGPOOL DISK 0.00.00.090 70 TAPEPOOL DC.LIB_TA- 350,000.07.9 40.090 70 PE_1 tsm: SERVER1>q stg backuppool f=d Storage Pool Name: BACKUPPOOL Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity (MB): 122,891.0 Pct Util: 82.6 Pct Migr: 82.6 Pct Logical: 100.0 High Mig Pct: 90 Low Mig Pct: 70 Migration Delay: 0 Migration Continue: Yes Migration Processes: 1 Next Storage Pool: TAPEPOOL Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate: Reclamation Threshold: Maximum Scratch Volumes Allowed: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 0.00 Elapsed Migration Time (seconds): 110 Reclamation in Progress?: Volume Being Migrated/Reclaimed: Last Update by (administrator): ADMIN Last Update Date/Time: 06/07/02 01:42:37 Storage Pool Data Format: Native tsm: SERVER1> tsm: SERVER1>q sess f=d Sess Number: 317 Comm. Method: Tcp/Ip Sess State: Run Wait Time: 0 S Bytes Sent: 3.4 M Bytes Recvd: 107 Sess Type: Admin Platform: SUN SOLARIS Client Name: ADMIN Media Access Status: User Name: Date/Time First Data Sent: Sess Number: 12,105 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 1.1 K Bytes Recvd: 3.7 G Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.5 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.4. User Name: Date/Time First Data Sent: 06/06/02 21:43:58 Sess Number: 12,110 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 489 Bytes Recvd: 841.3 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.204.10 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.5. User Name: Date/Time First Data Sent: 06/06/02 22:47:14 Sess Number: 12,113 Comm. Method: Tcp/Ip Sess State: MediaW Wait Time: 2.8 H Bytes Sent: 378 Bytes Recvd: 16.1 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.6 Media Access Status: Waiting for mount point in device class more... ( to continue, 'C' to cancel) DC.LIB_TAPE_1 (10246 seconds). User Name: Date/Time First Data Sent: 06/06/02 22:53:52 Sess Number: 12,140 Comm. Method: Tcp/Ip Sess State: IdleW Wait Time: 1.8 H Bytes Sent: 2.7 K Bytes Recvd: 1.0 K Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI
Re: Migration Problem
Hi Gerald! Although you haven't specified the maxsize, it is possible that the client tries to send a file that's larger than 21.38 Gb. (17.4% * 122,891). That file will not fit in your diskpool and thus will go to the next stgpool. I remember reading somewhere that you hit the limit on your diskpool even earlier when the diskpool is fragmented. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Gerald Wichmann [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 01:57 To: [EMAIL PROTECTED] Subject: Migration Problem TSM Server 4.2.2.0 on Solaris 2.8 TSM Client 5.1.0 on Linux 2.4 Test system.. primary disk pool filled up almost but not quite to hit the hi threshold of 90 that would start a migration.. yet I notice backups are now going to tape instead of the diskpool. What gives? Theres no Max size threshold that would cause the files to go to tape due to size. Why are the backups going to tape instead of filling the disk pool up to it's hi of 90? Weird.. tsm: SERVER1>q stg Storage Device EstimatedPctPct High Low Next Stora- Pool NameClass NameCapacity Util Migr Mig Mig ge Pool (MB) Pct Pct --- -- -- - - --- --- ARCHIVEPOOL DISK 1,030.0 17.5 17.590 70 BACKUPPOOL DISK 122,891.0 82.6 82.690 70 TAPEPOOL SPACEMGPOOL DISK 0.00.00.090 70 TAPEPOOL DC.LIB_TA- 350,000.07.9 40.090 70 PE_1 tsm: SERVER1>q stg backuppool f=d Storage Pool Name: BACKUPPOOL Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity (MB): 122,891.0 Pct Util: 82.6 Pct Migr: 82.6 Pct Logical: 100.0 High Mig Pct: 90 Low Mig Pct: 70 Migration Delay: 0 Migration Continue: Yes Migration Processes: 1 Next Storage Pool: TAPEPOOL Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate: Reclamation Threshold: Maximum Scratch Volumes Allowed: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 0.00 Elapsed Migration Time (seconds): 110 Reclamation in Progress?: Volume Being Migrated/Reclaimed: Last Update by (administrator): ADMIN Last Update Date/Time: 06/07/02 01:42:37 Storage Pool Data Format: Native tsm: SERVER1> tsm: SERVER1>q sess f=d Sess Number: 317 Comm. Method: Tcp/Ip Sess State: Run Wait Time: 0 S Bytes Sent: 3.4 M Bytes Recvd: 107 Sess Type: Admin Platform: SUN SOLARIS Client Name: ADMIN Media Access Status: User Name: Date/Time First Data Sent: Sess Number: 12,105 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 1.1 K Bytes Recvd: 3.7 G Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.5 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.4. User Name: Date/Time First Data Sent: 06/06/02 21:43:58 Sess Number: 12,110 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 489 Bytes Recvd: 841.3 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.204.10 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.5. User Name: Date/Time First Data Sent: 06/06/02 22:47:14 Sess Number: 12,113 Comm. Method: Tcp/Ip Sess State: MediaW Wait Time: 2.8 H Bytes Sent: 378 Bytes Recvd: 16.1 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.6 Media Access Status: Waiting for mount point in device class more... ( to continue, 'C' to cancel) DC.LIB_TAPE_1 (10246 seconds). User Name: Date/Time First Data Sent: 06/06/02 22:53:52 Sess Number: 12,140 Comm. Method: Tcp/Ip Sess State: IdleW Wait Time: 1.8 H Bytes Sent: 2.7 K Bytes Recvd: 1.0 K Sess Type: No
Migration Problem
TSM Server 4.2.2.0 on Solaris 2.8 TSM Client 5.1.0 on Linux 2.4 Test system.. primary disk pool filled up almost but not quite to hit the hi threshold of 90 that would start a migration.. yet I notice backups are now going to tape instead of the diskpool. What gives? Theres no Max size threshold that would cause the files to go to tape due to size. Why are the backups going to tape instead of filling the disk pool up to it's hi of 90? Weird.. tsm: SERVER1>q stg Storage Device EstimatedPctPct High Low Next Stora- Pool NameClass NameCapacity Util Migr Mig Mig ge Pool (MB) Pct Pct --- -- -- - - --- --- ARCHIVEPOOL DISK 1,030.0 17.5 17.590 70 BACKUPPOOL DISK 122,891.0 82.6 82.690 70 TAPEPOOL SPACEMGPOOL DISK 0.00.00.090 70 TAPEPOOL DC.LIB_TA- 350,000.07.9 40.090 70 PE_1 tsm: SERVER1>q stg backuppool f=d Storage Pool Name: BACKUPPOOL Storage Pool Type: Primary Device Class Name: DISK Estimated Capacity (MB): 122,891.0 Pct Util: 82.6 Pct Migr: 82.6 Pct Logical: 100.0 High Mig Pct: 90 Low Mig Pct: 70 Migration Delay: 0 Migration Continue: Yes Migration Processes: 1 Next Storage Pool: TAPEPOOL Reclaim Storage Pool: Maximum Size Threshold: No Limit Access: Read/Write Description: Overflow Location: Cache Migrated Files?: No Collocate: Reclamation Threshold: Maximum Scratch Volumes Allowed: Delay Period for Volume Reuse: Migration in Progress?: Yes Amount Migrated (MB): 0.00 Elapsed Migration Time (seconds): 110 Reclamation in Progress?: Volume Being Migrated/Reclaimed: Last Update by (administrator): ADMIN Last Update Date/Time: 06/07/02 01:42:37 Storage Pool Data Format: Native tsm: SERVER1> tsm: SERVER1>q sess f=d Sess Number: 317 Comm. Method: Tcp/Ip Sess State: Run Wait Time: 0 S Bytes Sent: 3.4 M Bytes Recvd: 107 Sess Type: Admin Platform: SUN SOLARIS Client Name: ADMIN Media Access Status: User Name: Date/Time First Data Sent: Sess Number: 12,105 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 1.1 K Bytes Recvd: 3.7 G Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.5 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.4. User Name: Date/Time First Data Sent: 06/06/02 21:43:58 Sess Number: 12,110 Comm. Method: Tcp/Ip Sess State: RecvW Wait Time: 0 S Bytes Sent: 489 Bytes Recvd: 841.3 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.204.10 Media Access Status: Current output volume: LABEL.LIB_TAPE_1.5. User Name: Date/Time First Data Sent: 06/06/02 22:47:14 Sess Number: 12,113 Comm. Method: Tcp/Ip Sess State: MediaW Wait Time: 2.8 H Bytes Sent: 378 Bytes Recvd: 16.1 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.172.6 Media Access Status: Waiting for mount point in device class more... ( to continue, 'C' to cancel) DC.LIB_TAPE_1 (10246 seconds). User Name: Date/Time First Data Sent: 06/06/02 22:53:52 Sess Number: 12,140 Comm. Method: Tcp/Ip Sess State: IdleW Wait Time: 1.8 H Bytes Sent: 2.7 K Bytes Recvd: 1.0 K Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.204.8 Media Access Status: User Name: Date/Time First Data Sent: Sess Number: 12,141 Comm. Method: Tcp/Ip Sess State: MediaW Wait Time: 1.8 H Bytes Sent: 384 Bytes Recvd: 4.6 M Sess Type: Node Platform: Linux86 Client Name: CYGNUS-PRI-10.0.204.8 Media Access Status: Waiting for mount point in device class DC.LIB_TAPE_1 (6475 seconds).
Migration Problem Part 2
Forced a migration by lowering the hi threshold.. activity log fills up with nasty errors so I turned on contextmessaging to see if anything more cropped up.. Looks like the filesystem is having probs.. I/O related.. can't even umount the filesystem without it griping.. guess I found my problem.. 06/07/02 02:08:59 ANRD blkdisk.c(1794): ThreadId<37> Error reading from disk /tsm/data1/tsmdata.009. Expected=262144 Actual=4096, errno=0 (Error 0) 06/07/02 02:08:59 (37) Context report 06/07/02 02:08:59 (37) DiskServerThread : ANRD calling thread 06/07/02 02:08:59 (37) Generating TM Context Report: (struct=tmTxnDesc) (slots=256) 06/07/02 02:08:59 (37) *** no transactions found *** more... ( to continue, 'C' to cancel) 06/07/02 02:08:59 (37) Generating Database Transaction Table Context: 06/07/02 02:08:59 (37) *** no transactions found *** 06/07/02 02:08:59 (37) Generating SM Context Report: 06/07/02 02:08:59 (37) *** no sessions found *** 06/07/02 02:08:59 (37) Generating AS Vol Context Report: 06/07/02 02:08:59 (37) No mounted (or mount in progress) volumes. 06/07/02 02:08:59 (37) Generating ssSession Context Report: 06/07/02 02:08:59 (37) No storage service sessions active. 06/07/02 02:08:59 (37) Generating ssOpenSeg Context Report: 06/07/02 02:08:59 (37) No storage service segments found. 06/07/02 02:08:59 (37) Generating BF Copy Control Context Report: 06/07/02 02:08:59 (37) No global copy control blocks. 06/07/02 02:08:59 06/07/02 02:08:59 (37) End Context report 06/07/02 02:08:59 ANRD dsrtrv.c(538): ThreadId<15> Error on volume /tsm/data1/tsmdata.009: execRc=-1, summaryRc=-1. 06/07/02 02:08:59 ANRD dsrtrv.c(549): ThreadId<15> --> Volume /tsm/data1/tsmdata.009, Starting Logical Block 0, Blocks in Range 64. 06/07/02 02:08:59 ANRD blkdisk.c(1794): ThreadId<33> Error reading from disk /tsm/data1/tsmdata.012. Expected=262144 Actual=12288, errno=0 (Error 0) 06/07/02 02:08:59 ANRD dsrtrv.c(538): ThreadId<15> Error on volume /tsm/data1/tsmdata.012: execRc=-1, summaryRc=-1. 06/07/02 02:08:59 ANRD dsrtrv.c(549): ThreadId<15> --> Volume /tsm/data1/tsmdata.012, Starting Logical Block 0, Blocks in Range 64. 06/07/02 02:08:59 ANRD blkdisk.c(1794): ThreadId<39> Error reading from disk /tsm/data1/tsmdata.010. Expected=262144 Actual=-1, errno=5 (I/O error) 06/07/02 02:08:59 ANRD dsrtrv.c(538): ThreadId<15> Error on volume /tsm/data1/tsmdata.010: execRc=-1, summaryRc=-1. 06/07/02 02:08:59 ANRD dsrtrv.c(549): ThreadId<15> --> Volume /tsm/data1/tsmdata.010, Starting Logical Block 2125011, Blocks in Range 64. 06/07/02 02:08:59 ANRD blkdisk.c(1794): ThreadId<36> Error reading from disk /tsm/data1/tsmdata.001. Expected=262144 Actual=-1, errno=5 (I/O error) 06/07/02 02:08:59 ANRD dsrtrv.c(538): ThreadId<15> Error on volume /tsm/data1/tsmdata.001: execRc=-1, summaryRc=-1. 06/07/02 02:08:59 ANRD dsrtrv.c(549): ThreadId<15> --> Volume /tsm/data1/tsmdata.001, Starting Logical Block 1531031, Blocks in Range 64. 06/07/02 02:08:59 ANRD blkdisk.c(1794): ThreadId<38> Error reading from disk /tsm/data1/tsmdata.004. Expected=262144 Actual=-1, errno=5 (I/O error) 06/07/02 02:08:59 ANRD dsrtrv.c(538): ThreadId<15> Error on volume /tsm/data1/tsmdata.004: execRc=-1, summaryRc=-1. 06/07/02 02:08:59 ANRD dsrtrv.c(549): ThreadId<15> --> Volume /tsm/data1/tsmdata.004, Starting Logical Block 2530161, more... ( to continue, 'C' to cancel) Blocks in Range 64. 06/07/02 02:09:00 (33) Context report 06/07/02 02:09:00 (33) DiskServerThread : ANRD calling thread 06/07/02 02:09:00 (33) Generating TM Context Report: (struct=tmTxnDesc) (slots=256) 06/07/02 02:09:00 (33) *** no transactions found *** 06/07/02 02:09:00 (33) Generating Database Transaction Table Context: 06/07/02 02:09:00 (33) *** no transactions found *** 06/07/02 02:09:00 (33) Generating SM Context Report: 06/07/02 02:09:00 (33) *** no sessions found *** 06/07/02 02:09:00 (33) Generating AS Vol Context Report: 06/07/02 02:09:00 (33) No mounted (or mount in progress) volumes. 06/07/02 02:09:00 (33) Generating ssSession Context Report: 06/07/02 02:09:00 (33) No storage service sessions active. 06/07/02 02:09:00 (33) Generating ssOpenSeg Context Report: 06/07/02 02:09:00 (
Re: TSM 4.2 server migration problem on NT
U/G to IE 5 did the trick. Thanks for your help, Andy. Joerg Pohlmann Andrew Raibeck/Tucson/IBM@[EMAIL PROTECTED]> on 2001-08-22 17:55:21 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: TSM 4.2 server migration problem on NT The TSM 4.2 server requires Internet Explorer 5 or higher. Since you are running NT 4.0, SP 5, it is possible you do not have this on your system. Try installing IE5 (or higher), then try the install again. IE doesn't have to be your default browser, but it does have to be present. Regards, Andy Andy Raibeck IBM Tivoli Systems Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: [EMAIL PROTECTED] The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. Joerg Pohlmann/CanWest/IBM@IBMCA Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 08/22/2001 16:26 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject:Re: TSM 4.2 server migration problem on NT I have received the same error (Internal error 2738. caTestPtfLevel) with an English (US) language environment. NT is 4.0, SP5, the TSM server previously installed was 3.7.4. Upgrade to 4.1.3 was no problem, that's where we are right now. Any help would be appreciated as we would like to get to 4.2. Joerg Pohlmann tsm aloes <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 2001-08-22 07:30:36 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: TSM 4.2 server migration problem on NT Hi all, before deployment, I experience the migration of a TSM 4.1.3.0 server to a TSM 4.2.0.0 server on NT platform (NT 4 service pack 6). NLS is french. The readme provided with installation package (CDROM) tells the following: Upgrading from TSM 4.1.x.x to the current version 1) Write down the directory where the current release is installed 2) Use Add/Remove programs to uninstall the current version 3) Install the new version to the same location as the original Note that during step 3, the setup program will automatically upgrade your TSM database and Web Administrator. So, I do... and during installation (phase #3), a popup is displayed with: Erreur interne 2738. caTestPtfLevel (Internal error 2738. caTestPtfLevel) I tried again the installation with NLS English US: same popup is displayed. I looked into registry, searching about "TSM" or "ADSM". Some keys containing these strings remained and have been deleted. Then, I rebooted my system and retried installation : unsucceful, same popup is displayed. Thanks by advance for your help... Aloes consultant team. _ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day
Re: TSM 4.2 server migration problem on NT
Thank you very much Andy. After verifying prerequisite on the WEB, I saw my error. Indeed, after upgrading IE to version 5.0, TSM version 4.2 has been istalled succesfully. Best regards. --- Andrew Raibeck <[EMAIL PROTECTED]> wrote: > The TSM 4.2 server requires Internet Explorer 5 or > higher. Since you are > running NT 4.0, SP 5, it is possible you do not have > this on your system. > Try installing IE5 (or higher), then try the install > again. IE doesn't > have to be your default browser, but it does have to > be present. > > Regards, > > Andy > > Andy Raibeck > IBM Tivoli Systems > Tivoli Storage Manager Client Development > Internal Notes e-mail: Andrew > Raibeck/Tucson/IBM@IBMUS > Internet e-mail: [EMAIL PROTECTED] > > The only dumb question is the one that goes unasked. > The command line is your friend. > "Good enough" is the enemy of excellence. > > > > > Joerg Pohlmann/CanWest/IBM@IBMCA > Sent by: "ADSM: Dist Stor Manager" > <[EMAIL PROTECTED]> > 08/22/2001 16:26 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject:Re: TSM 4.2 server migration > problem on NT > > > > I have received the same error (Internal error 2738. > caTestPtfLevel) with > an English (US) language environment. NT is 4.0, > SP5, the TSM server > previously installed was 3.7.4. Upgrade to 4.1.3 was > no problem, that's > where we are right now. Any help would be > appreciated as we would like to > get to 4.2. > > Joerg Pohlmann > > > > tsm aloes <[EMAIL PROTECTED]>@VM.MARIST.EDU> on > 2001-08-22 07:30:36 > > Please respond to "ADSM: Dist Stor Manager" > <[EMAIL PROTECTED]> > > Sent by: "ADSM: Dist Stor Manager" > <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > cc: > Subject: TSM 4.2 server migration problem on NT > > > Hi all, > > before deployment, I experience the migration of a > TSM > 4.1.3.0 server to a TSM 4.2.0.0 server on NT > platform > (NT 4 service pack 6). NLS is french. > The readme provided with installation package > (CDROM) > tells the following: > Upgrading from TSM 4.1.x.x to the current version > >1) Write down the directory where the current > release is installed >2) Use Add/Remove programs to uninstall the > current > version >3) Install the new version to the same location > as > the original > >Note that during step 3, the setup program will > automatically >upgrade your TSM database and Web Administrator. > > > So, I do... and during installation (phase #3), a > popup is > displayed with: > > Erreur interne 2738. caTestPtfLevel > (Internal error 2738. caTestPtfLevel) > > I tried again the installation with NLS English US: > same popup is displayed. > I looked into registry, searching about "TSM" or > "ADSM". Some keys containing these strings remained > and have been > deleted. Then, I rebooted my system and retried > installation : unsucceful, same popup is displayed. > > Thanks by advance for your help... > > Aloes consultant team. > > > > _ > > http://shopping.yahoo.com.au - Father's Day Shopping > - Find the perfect gift for your Dad for Father's Day = Aloes consultant team http://www.aloes.fr --- Paris +33(1)60 11 70 10 Bordeaux +33(5)57 26 51 09 Toulouse +33(5)61 39 95 20 Nantes+33(2)40 89 21 80 Orlians +33(2)38 52 38 26 _ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day
Re: TSM 4.2 server migration problem on NT
The TSM 4.2 server requires Internet Explorer 5 or higher. Since you are
running NT 4.0, SP 5, it is possible you do not have this on your system.
Try installing IE5 (or higher), then try the install again. IE doesn't
have to be your default browser, but it does have to be present.
Regards,
Andy
Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Joerg Pohlmann/CanWest/IBM@IBMCA
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
08/22/2001 16:26
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: TSM 4.2 server migration problem on NT
I have received the same error (Internal error 2738. caTestPtfLevel) with
an English (US) language environment. NT is 4.0, SP5, the TSM server
previously installed was 3.7.4. Upgrade to 4.1.3 was no problem, that's
where we are right now. Any help would be appreciated as we would like to
get to 4.2.
Joerg Pohlmann
tsm aloes <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 2001-08-22 07:30:36
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: TSM 4.2 server migration problem on NT
Hi all,
before deployment, I experience the migration of a TSM
4.1.3.0 server to a TSM 4.2.0.0 server on NT platform
(NT 4 service pack 6). NLS is french.
The readme provided with installation package (CDROM)
tells the following:
Upgrading from TSM 4.1.x.x to the current version
1) Write down the directory where the current
release is installed
2) Use Add/Remove programs to uninstall the current
version
3) Install the new version to the same location as
the original
Note that during step 3, the setup program will
automatically
upgrade your TSM database and Web Administrator.
So, I do... and during installation (phase #3), a
popup is
displayed with:
Erreur interne 2738. caTestPtfLevel
(Internal error 2738. caTestPtfLevel)
I tried again the installation with NLS English US:
same popup is displayed.
I looked into registry, searching about "TSM" or
"ADSM". Some keys containing these strings remained
and have been
deleted. Then, I rebooted my system and retried
installation : unsucceful, same popup is displayed.
Thanks by advance for your help...
Aloes consultant team.
_
http://shopping.yahoo.com.au - Father's Day Shopping
- Find the perfect gift for your Dad for Father's Day
Re: TSM 4.2 server migration problem on NT
I have received the same error (Internal error 2738. caTestPtfLevel) with an English (US) language environment. NT is 4.0, SP5, the TSM server previously installed was 3.7.4. Upgrade to 4.1.3 was no problem, that's where we are right now. Any help would be appreciated as we would like to get to 4.2. Joerg Pohlmann tsm aloes <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 2001-08-22 07:30:36 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: TSM 4.2 server migration problem on NT Hi all, before deployment, I experience the migration of a TSM 4.1.3.0 server to a TSM 4.2.0.0 server on NT platform (NT 4 service pack 6). NLS is french. The readme provided with installation package (CDROM) tells the following: Upgrading from TSM 4.1.x.x to the current version 1) Write down the directory where the current release is installed 2) Use Add/Remove programs to uninstall the current version 3) Install the new version to the same location as the original Note that during step 3, the setup program will automatically upgrade your TSM database and Web Administrator. So, I do... and during installation (phase #3), a popup is displayed with: Erreur interne 2738. caTestPtfLevel (Internal error 2738. caTestPtfLevel) I tried again the installation with NLS English US: same popup is displayed. I looked into registry, searching about "TSM" or "ADSM". Some keys containing these strings remained and have been deleted. Then, I rebooted my system and retried installation : unsucceful, same popup is displayed. Thanks by advance for your help... Aloes consultant team. _ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day
TSM 4.2 server migration problem on NT
Hi all, before deployment, I experience the migration of a TSM 4.1.3.0 server to a TSM 4.2.0.0 server on NT platform (NT 4 service pack 6). NLS is french. The readme provided with installation package (CDROM) tells the following: Upgrading from TSM 4.1.x.x to the current version 1) Write down the directory where the current release is installed 2) Use Add/Remove programs to uninstall the current version 3) Install the new version to the same location as the original Note that during step 3, the setup program will automatically upgrade your TSM database and Web Administrator. So, I do... and during installation (phase #3), a popup is displayed with: Erreur interne 2738. caTestPtfLevel (Internal error 2738. caTestPtfLevel) I tried again the installation with NLS English US: same popup is displayed. I looked into registry, searching about "TSM" or "ADSM". Some keys containing these strings remained and have been deleted. Then, I rebooted my system and retried installation : unsucceful, same popup is displayed. Thanks by advance for your help... Aloes consultant team. _ http://shopping.yahoo.com.au - Father's Day Shopping - Find the perfect gift for your Dad for Father's Day
