Re: cleaning cart in IBM 3502-014 DLT lib
Same as we had with 7337-306. Use checkin libv lb0.0.0.1 search=yes volrange=cln001,cln001 to cheat the TSM. Have in mind Mark's remark. 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:cleaning cart in IBM 3502-014 DLT lib Dear colleagues, could anyone give a suggestion how to checkin the cleaning cart in the a.m. lib? When I try to checkin libv lb0.0.0.1 cln001 checklabel=no I always get the same message: library is full. There is one empty slot from TSM point of view and it is physically occupied by CLN001 (I even tried when the lib was completely empty!). Now I have to manually put this cart into library when a drive need cleaning, clean it from the lib panel and remove, because every checkin libv search=yes tries to load the cart into drive to read the label. Your advice is very much appreciated. Regards, Anton Gubarkov. IT Manager SONY CIS Tel. +7 095 258 7626 Fax +7 095 258 7650 My certificate can be obtained at ldap://koi8.sony.ru ó Õ×ÁÖÅÎÉÅÍ, áÎÔÏÎ ÷ÉËÔÏÒÏ×ÉÞ çÕÂÁÒØËÏ× îÁÞÁÌØÎÉË ÏÔÄÅÌÁ áóõ úáï óïîé óîç ôÅÌ. +7 095 258 7626 æÁËÓ. +7 095 258 7650 íÏÊ X.509 ÓÅÒÔÉÆÉËÁÔ ÍÏÖÎÏ ÐÏÌÕÞÉÔØ ÎÁ ldap://koi8.sony.ru
Re: Make Compression Client faster ??
MAXNUMMP takes place for direct to tape operations. For disk you can have more sessions but when disk pool gets full only maxnummp of them will continue to write to tape. 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:Re: Make Compression Client faster ?? Does it start multiple sessions as expected during a backup? As someone else already pointed out, this is tied to the # of filesystems you have and you're only specifying /.. I believe you also need to make sure the node (q node f=d) has a MAXNUMP of 4 (default is 1) to get more then 1 data session running on a node. Regards, Gerald Wichmann Senior Systems Development Engineer Zantaz, Inc. 925.598.3099 (w) -Original Message- From: Grems [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:52 AM To: [EMAIL PROTECTED] Subject: Re: Make Compression Client faster ?? this is my DSM.SYS -- SErvername TSM_SERVER COMMmethod TCPip TCPPort1500 TCPServeraddress 10.100.24.42 compression on passwordaccess generate resourceutilization 4 -- when i make a root:dsmc i / -sub=yes omly one processeurs is use for compression, why ? - Original Message - From: Gerald Wichmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 06, 2002 7:28 PM Subject: Re: Make Compression Client faster ?? You sure the process is cpu bound and that it even matters? One would think the operation is more I/O bound.. Otherwise from redbook using the ba client try adjusting the resourceutilization paramater: Resourceutilization Authorized User The resourceutilization option regulates the level of resources the Tivoli Storage Manager server and client can use during processing. When you request a backup or archive, the client can use more than one session to the server. The default is to use a maximum of two sessions; one to query the server and one to send file data. The client can use only one server session if you specify a resourceutilization setting of 1. The client is also restricted to a single session if a user who is not authorized invokes a UNIX client with passwordaccess=generate specified. A client can use more than the default number of sessions when connecting to a server that is Version 3.7 or higher. For example, resourceutilization=10 permits up to eight sessions with the server. Multiple sessions may be used for querying the server and sending file data. Multiple query sessions are used when multiple file specifications are used with a backup or archive command. For example, if you enter: inc filespaceA filespaceB and you specified resourceutilization=5, the client may start a second session to query files on file space B. Whether or not the second session starts depends on how long it takes to query the server about files backed up on file space A. The client may also try to read data from the file system and send it to the server on multiple sessions. The following factors can affect the throughput of multiple sessions: 6 The server's ability to handle multiple client sessions. Is there sufficient memory, multiple storage volumes, and CPU cycles to increase backup throughput? 6 The client's ability to drive multiple sessions (sufficient CPU, memory, etc.). 6 The configuration of the client storage subsystem. File systems that are striped across multiple disks, using either software striping or RAID-5 can better handle an increase in random read requests than a single drive file system. Additionally, a single drive file system may not see performance improvement if it attempts to handle many random concurrent read requests. 6 Sufficient bandwidth in the network to support the increased traffic. Potentially undesirable aspects of running multiple sessions include: 6 The client could produce multiple accounting records. 6 The server may not start enough concurrent sessions. To avoid this, the server maxsessions parameter must be reviewed and possibly changed. 6 A query node command may not summarize client activity. Note: The server can also define this option. Also from another section: Note: On occasion, the aggregate data transfer rate may be higher than the network data transfer rate. This is because the backup-archive client has multithreading capabilities. When multiple threads run during backup, the data transfer time represents the sum time from all threads running. In this case, aggregate data transfer time is mistakenly reported as higher. However, when running a single thread, the aggregate data transfer rate should always be reported as lower than the network data transfer rate. Regards, Gerald Wichmann Senior Systems Development Engineer Zantaz, Inc. 925.598.3099 (w) -Original Message- From: Grems [mailto:[EMAIL PROTECTED]] Sent:
Re: Directorie only
AFAIK we still do not have the include.dir option :-) But exclude /.../* left alone will do the trick. 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:Re: Directorie only From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of William Rosette I currently have a 3.1.0.8 TSM AIX SP node client (with 4.2.1 AIX) and want to back up a file system, but only the file structure. I do not need to back up the files. For DR purposes, I need the file/directory structure. I thought there was a parameter in the include for directories only, but I am not sure if it is 3.1.0.8 compatible. Any suggestions are always welcome. Aside from a desperate need to update both your TSM client *and* AIX OS out of unsupported levels ;o), you can add exclude /.../* include.dir /.../* to your TSM client option file. I know the .dir extension was available in 3.7; I think it works in 3.1 as well. Of course, as with all unsupported levels, YMMV. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Re: TSM v4.1 clients NOT compatible with V5.1 server?
you can have v4.1, v4.2 and v5.1 clients with v4.2 server and according to Tivoli all those are working *and* supported configurations. So you can upgrade your server to 4.2.x.x and everything ought to be fine. As Don said unsupported does not automatically mean broken. For old/rare OSes many are still using old v3.1 clients (the last available for my OS/2 is v3.7.2). Just IBM/Tivoli support will recommend you to upgrade before calling them. Be aware that v4.1 also will go out of support end of the month. The only reason which can force you to use v4.1 clients is client/OS incompatibility. The latter is real, i.e. v4.2 client would not work with Win95 and v5.1 would not with 9598. But you cannot sign a support contract with a maillist :-) 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:TSM v4.1 clients NOT compatible with V5.1 server? Hello all, If I am reading things correctly, all my v4.1 clients are NOT compatible with V5.1 server. Nor is a V5.1 client (where supported) compatible with a V4.1.5 server. Is this supposed to be a multi-step upgrade? Am I therefore supposed to tell management that the presence of WIN95 laptops will stop our ability to upgrade to V5.1, (because they do not have a v4.2 client) ? http://www.tivoli.com/support/storage_mgr/compatibility.html I am running v4.1.5 server on z/OS 1.1. I have WINxx (all of them ) clients, AIX, SUN, Novell, and MAC clients mostly v4.1. Has anyone gone this route already or can tell me what migration path I can take? Matt
Re: Troubles, troubles, troubles.
Are you having client connection severed messages in the actlog? How long is does this clients backup take compared with the idletimout setting on the server. You could be losing the control session, so even if the data session completes, it will not report correctly. I have also seen this problem hose the client scheduler. Eric -Original Message- From: Bern Ruelas [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 11:51 PM To: [EMAIL PROTECTED] Subject: Re: Troubles, troubles, troubles. Rick, We had the same problem that went away with 4.1.1.11. -Bern Ruelas Sr. Systems Engineer - Storage Cadence Design Systems -Original Message- From: Rushforth, Tim [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 8:44 PM To: [EMAIL PROTECTED] Subject: Re: Troubles, troubles, troubles. Try running manual backup, does client abend? Can you narrow down the directories backed up to determine if it is one bad file/location on disk Check for drwatson log files. I've seen this happen on a bad sector of disk which chkdsk fixed. -Original Message- From: Rick Harderwijk [mailto:[EMAIL PROTECTED]] Sent: June 6, 2002 7:11 AM To: [EMAIL PROTECTED] Subject: Troubles, troubles, troubles. Hi all, One of my servers is giving me a major headache at the moment. Every morning when I come in, I check, as anyone does, I presume, whether all scheduled backups completed succesfully. The past couple of days, one of my servers doesn't complete, nor does it fail. Or so it tells me, because the result of the scheduled backup is '(?)' . Nice, isn't it? Since I'm not going to lay awake all night because of one backup, I decided the first time it happened, to just let it go. 'It'll all be better tomorrow,', I told myself. Unfortunately, it didn't get better. Nope, the same thing happened the next night, and the one after. So, this morning, I started to check if there was a serious glitch. So I checked the dsmsched.log on the client. Strange thing... it sent a file, then it gets a new schedule. It feels as if something is missing here. Next, I checked the dsierror.log. Three entries here: 06-06-2002 03:52:27 sessOpen: Error 137 from signon authentication. 06-06-2002 03:53:30 sessOpen: Error 137 from signon authentication. 06-06-2002 03:54:33 sessOpen: Error 137 from signon authentication. Messages like that make me pop out a fresh browser window, call up www.adsm.org and go looking for that message... as it turns out 'this message just is there, can be ignored and will go away in the next couple of upgrades'. So, not very helpful *but* it also tells me this message occurs when the Scheduler service starts. Now there's something I can do something with. Opening up ye olde Eventlog on that same W2k-client tells me that indeed, at that time, the Scheduler Service was started - it had stopped just before, and since we've had some problems with earlier versions with services just quitting on us, the services are automatically restarted when they go down. As it turns out, the backup stopped when the service crashed and when the service came back, it just got a new schedule and the backup in progress stopped and never continued. It seems to me that all I have to fix is that darned Scheduler Service. But where to start? Why does it stop? Where to look for more clues? And ofcourse: why me? :-) Anyone care to join me and hunt this bugger down to fix it once and for all? You're most welcome - I feel like I'm on a dead end trail... and that headache is keeping me from thinking clearly... Kind regards, Rick Harderwijk Systems Administrator Factotum Media BV Oosterengweg 44 1212 CN Hilversum P.O. Box 335 1200 AH Hilversum The Netherlands Tel: +31-35-6881166 Fax: +31-35-6881199 E: [EMAIL PROTECTED]
unsubscripe
unsubscripe
