Re: TSM server automation products
You describe an environment like our own, and is why we are moving off of this product. I would say no, it doesn't fit your environment. Rick Thomas Denier [EMAIL PROTECTED] FFERSONHOSPITAL.O To RG ADSM-L@VM.MARIST.EDU Sent by: ADSM:cc Dist Stor Manager Subject [EMAIL PROTECTED] Re: TSM server automation products .EDU 04/05/2006 12:29 PM Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] .EDU - Richard Rhodes wrote: - We have successfully used StorServer Manager for automation for a number of years. It works well as long as your processing follows standard way TSM want's to run. At times it gets confused, but in general we have been happy with it. It's worth a look and demo try. Our environment has several features that arguably fall outside the bounds of the standard way TSM want's to run: 1.We have 64 sets of storage pools with a disk pool, a primary tape pool, and a copy tape pool in each set (we are still at 5.2, so we do not have the option of using collocation groups). 2.We find it necessary to have tape reclamation run concurrently with inventory expiration. 3.We have an unusual approach to vaulting recovery plan files: 'prepare' command, 'dsmc' to back up the recovery plan file, 'generate backupset' to create a backup set containing the recovery plan file, and 'checkout libvol' to eject the tape containing the backup set. Is StorServer Manager flexible enough support these features of our environment? - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: TSM server automation products
- Richard Rhodes wrote: - We have successfully used StorServer Manager for automation for a number of years. It works well as long as your processing follows standard way TSM want's to run. At times it gets confused, but in general we have been happy with it. It's worth a look and demo try. Our environment has several features that arguably fall outside the bounds of the standard way TSM want's to run: 1.We have 64 sets of storage pools with a disk pool, a primary tape pool, and a copy tape pool in each set (we are still at 5.2, so we do not have the option of using collocation groups). 2.We find it necessary to have tape reclamation run concurrently with inventory expiration. 3.We have an unusual approach to vaulting recovery plan files: 'prepare' command, 'dsmc' to back up the recovery plan file, 'generate backupset' to create a backup set containing the recovery plan file, and 'checkout libvol' to eject the tape containing the backup set. Is StorServer Manager flexible enough support these features of our environment?
Re: TSM server automation products
Background to my $.02 - in my former life as the main TSM admin in the frozen north of Michigan, our management was frankly too tight to waste money on 3rd party tools that only allowed me to do my job more effectively. Consequently, my only option was to code it myself. By the time I left, we had totally automated the daily processing of all admin functions, complete with tape checkin/out, with offsite tape slot management and other niceties. Beyond that, we had an entire menu of custom ad-hoc reports we could run at will, and a problem detection system that scanned all our potential problem areas in TSM every 10 minutes, generating emails, pages, and/or helpdesk tickets depending on how we setup our config file. Not too shabby, especially since it was all developed using Rexx running on our z/os mainframe (althought I was the TSM Admin, another group owned AIX where TSM lived, and were reluctant to give me any access beyond the bare minimum). When I moved down to sunny Tennessee, I swore I would not get locked into supporting that complex of a home-grown system ever again. I intended to use whatever was in place or the TSM Admin could convince mgmt to buy (I only deal with the Intel client side of TSM now). They bought a 3rd party tool from a vendor who shall remain nameless. When I was invited to meet with this vendor to discuss any additional reporting needs I had, I gave him printouts and source code from my most-used and I felt very needed ad-hoc report. This report presented daily session data in html and included logic to filter and/or sort the data so it could be used in a wide variety of troubleshooting scenarios. As soon as I finished my description, his reply was I'll build you a static html report, but nothing dynamic, because I'm not interested in becoming a web developer. He was not impressed with my comment that I thought he should become interested in anything his customers were interested in buying. Needless to say, I'm back to coding. Thankfully, because Rexx is so darned portable, the move from z/os to Windows has been fairly painless, so we should have what we need relatively soon. Now if I could only rake in some of the thousands of $$$ we paid for our reporting package... My biggest drawbacks to self-developed code are: 1. I'm never satisfied, so I constantly enhance it, which takes time 2. Changes to TSM, such as message formats, break my code and require time to fix I personally feel that most of the arguments about self-developed code being cursed by future generations can be eased by: 1. More documentation in the code than you think you really need 2. Putting as much of the custom stuff in config and setup files as possible, rather than being hard-coded 3. I love the open-source suggestion Steve Schaub Systems Engineer, WNI BlueCross BlueShield of Tennessee 423-752-6574 (desk) 423-785-7347 (cell) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Monday, April 03, 2006 1:10 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM server automation products On Sun, 2 Apr 2006 09:52:52 +0200, Jurjen Oskam [EMAIL PROTECTED] said: On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote: Speaking as someone buried in my own PERL up to my nose: [snip: quite a good argument] I don't think I could be as effective with a third-party product as I am with my own stuff. I do think that the person who gets my job after I get hit by a truck will curse me for years. Thanks, those are good points. But it does beg the question: how bad is your current situation? :) I'll allude to a bit of logical pedantry by suggesting a google of 'beg the question' :) In any case, the question is an excellent one. I mean, is it such a spaghetti that nobody, except you as the developer, can *really* get it? Isn't *that* something you could change, so that your successor can as effective as you are? The philosophical / design / practical problem here is very complex. I'd guess the average TSM clue of those admins writing their own automation code is at least a standard deviation higher than that of the larger TSM-admin population. How much of that clue may be implicit in the code, and how much must be explicit, accessible to a newcomer? Designing your code for maintainability is one thing, and we mostly think we're trying to do that. Designing your code so that a domain novice (or domain much-less-clued) can debug it is a totally different question. It may simply be an impossible task. Unfortunately, that's the problem we're talking about. I mean, issues of arrogance and modesty aside, I've been working with TSM since 1998, and with PERL since before 1992. The person hired after I get hit by a truck is in all probability going to be less experienced in both of these areas, perhaps profoundly so. But it gets worse: our automation code reflects a somewhat smeary snapshot
Re: TSM server automation products
We have successfully used StorServer Manager for automation for a number of years. It works well as long as your processing follows standard way TSM want's to run. At times it gets confused, but in general we have been happy with it. It's worth a look and demo try. http://www.storserver.com/main.cfm?menu=2submenu=ssmdetail=include/SSMOverview.cfm - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: TSM server automation products
At 12:34 AM 4/1/2006 +0200, Jurjen Oskam wrote: Uhm, may I ask *why* you'd want an off-the-shelf product instead of your own code? Is the Perl-code not functioning correctly? What problem are you trying to solve? I can't speak for the original poster, but I've worked for shops that preferred not to depend on locally written software. That way, staff turnover wasn't nearly as much an issue; whoever was the SysAdmin of the month merely needed to know what vendors to call if something started acting up. Besides, commercial software *must* be better than any locally written code, right? (Don't answer that; that was thinly disguised sarcasm, tinged with disgust.) Speaking only for myself, Nick
Re: TSM server automation products
- Jurjen Oskam wrote: - Uhm, may I ask *why* you'd want an off-the-shelf product instead of your own code? Is the Perl-code not functioning correctly? What problem are you trying to solve? Management objections to the current script seem to center on two issues: 1.None of the other staff know Perl really well. 2.I am spending significant amounts of time on enhancements to the script.
Re: TSM server automation products
On Sun, 2 Apr 2006 09:52:52 +0200, Jurjen Oskam [EMAIL PROTECTED] said: On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote: Speaking as someone buried in my own PERL up to my nose: [snip: quite a good argument] I don't think I could be as effective with a third-party product as I am with my own stuff. I do think that the person who gets my job after I get hit by a truck will curse me for years. Thanks, those are good points. But it does beg the question: how bad is your current situation? :) I'll allude to a bit of logical pedantry by suggesting a google of 'beg the question' :) In any case, the question is an excellent one. I mean, is it such a spaghetti that nobody, except you as the developer, can *really* get it? Isn't *that* something you could change, so that your successor can as effective as you are? The philosophical / design / practical problem here is very complex. I'd guess the average TSM clue of those admins writing their own automation code is at least a standard deviation higher than that of the larger TSM-admin population. How much of that clue may be implicit in the code, and how much must be explicit, accessible to a newcomer? Designing your code for maintainability is one thing, and we mostly think we're trying to do that. Designing your code so that a domain novice (or domain much-less-clued) can debug it is a totally different question. It may simply be an impossible task. Unfortunately, that's the problem we're talking about. I mean, issues of arrogance and modesty aside, I've been working with TSM since 1998, and with PERL since before 1992. The person hired after I get hit by a truck is in all probability going to be less experienced in both of these areas, perhaps profoundly so. But it gets worse: our automation code reflects a somewhat smeary snapshot of our TSM operations philosophy, including aspects we might not have been able to state when we coded them. Much of my migration automation is still kicked off by manipulations of HIGHMIG and LOWMIG; I am gradually changing to use MIGRATE STGPOOL. When I wrote the existing code, MIGRATE STGPOOL didn't exist, there was no reason to discuss its' use. But it's the obvious tactic today, and my use of the archaic method would be confusing to an observer. So even an expert in TSM and PERL who comes in behind me might be short on critical context to understand why SERVER-A is migrating fine, but SERVER-B is having problems. So at every turn, you weigh improved effectiveness, maintainability, fidelity to your architecture, the forthcoming changes in your architecture... For your successor to be as effective, or even close, they need most of that context. (Implementing and migrating to a third party product costs time and money, wouldn't that better be spent cleaning up the custom code?) Oh, I'm in complete agreement: I think that local code is a superior solution all around, once you've paid the overhead to get the novice sufficiently clued. The best would be something -like- a Servergraph or a TSMManager, but open-source (duck from the third-party vendor slings and arrows) so we would -all- (most) be familiar with the -same- codebase. Third-party programs are indeed spread more widely, but this also means they must be more complex because they must support configurations which you don't even use. Homegrown code has only the complexity you need. I have to disagree with you there. There's stuff I need, which I haven't written yet. There's stuff I have (which represents time spent), which is no longer relevant. Worst of all, there's stuff I'm too dense or nearsighted to have figured out I need. When I eventually learn I need it, it's going to be painful. And -that- is the function folks hope to get out of the third-party tool, for which they're willing to sustain complexity and render up many dollars. - Allen S. Rout
Re: TSM server automation products
On Mon, Apr 03, 2006 at 10:48:13AM -0400, Thomas Denier wrote: 2.I am spending significant amounts of time on enhancements to the script. Yes, that would be a reason to consider an off-the-shell solution. The Perl-automation here runs more or less autonomic and doesn't require much maintenance. A nice side note is that in a former job, the TSM admin used Rexx to automate his Windows (then) ADSM server. Since I come from an Amiga background I had experience with ARexx, but all the other Windows admins had no clue about Rexx. :) I guess a lot depends on the specifics of each installation. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TSM server automation products
On Mon, Apr 03, 2006 at 01:09:35PM -0400, Allen S. Rout wrote: I'll allude to a bit of logical pedantry by suggesting a google of 'beg the question' :) Darn, I /thought/ I got that right. From a Google search: If you're not comfortable with formal terms of logic, it's best to stay away from this phrase, or risk embarrassing yourself. Serves me right trying to look smart. :) And -that- is the function folks hope to get out of the third-party tool, for which they're willing to sustain complexity and render up many dollars. I've tried the demo version of TSMManager, and it was indeed a nice experience to be able to fire up a report here and a graph there without much trouble. Our TSM environment is too small to justify that niceness, since the Perl-code keeps everything running virtually maintenance-free. But yes, I think there are many installations where these off-the-shelf products really are quite benificial to have. (I guess the vendors are quite happy with the ISC/AC-behemoth :) ) -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TSM server automation products
Back in the days of VM, my favorite automation tool for ADSM was Host Management Facility. Unix cron is a poor substitute, but it's what we've got to work with. I do a majority of my scheduling from within the TSM server with administrative schedules that trigger TSM Scripts. This is a rather poor tool, and I'm moving more and more things to Unix scripts, including one that will simply sit there and watch everything coming from the console. Sometimes it's hard to keep track of what is started from TSM Schedules and what is started from Unix crontab. STEP ONE in developing your own bowl of spaghetti is to define your own standard API for entering TSM server commands. Call it anything, such as tsmdoit. Then you've got to religiously use tsmdoit everywhere. Even if you only have one server now, be sure to include a server name option, because you might have more than one someday. The whole point is that once we get a real, secure, API to dsmadmc that doesn't expose passwords in clear test, or that doesn't involve convoluted hacks, hashes, excryptions, and whatever to partly and inadequately hide them, then you can change tsmdoit easily in one place to use the new API, and you won't have to change any of the rest of your own code. And yes, we really need this; dsmadmc is a huge security hole that inhibits development of better and more creative tools to manage TSM. Roger Deschner ACCC Basic Systems Group [EMAIL PROTECTED] On Sun, 2 Apr 2006, Jurjen Oskam wrote: On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote: Speaking as someone buried in my own PERL up to my nose: [snip: quite a good argument] I don't think I could be as effective with a third-party product as I am with my own stuff. I do think that the person who gets my job after I get hit by a truck will curse me for years. Thanks, those are good points. But it does beg the question: how bad is your current situation? :) I mean, is it such a spaghetti that nobody, except you as the developer, can *really* get it? Isn't *that* something you could change, so that your successor can as effective as you are? (Implementing and migrating to a third party product costs time and money, wouldn't that better be spent cleaning up the custom code?) Third-party programs are indeed spread more widely, but this also means they must be more complex because they must support configurations which you don't even use. Homegrown code has only the complexity you need. As a side note: it would really *really* be nice to have a documented API to enter dsmadmc commands -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TSM server automation products
On Mon, 3 Apr 2006 22:00:52 +0200, Jurjen Oskam [EMAIL PROTECTED] said: Our TSM environment is too small to justify that niceness, since the Perl-code keeps everything running virtually maintenance-free. But yes, I think there are many installations where these off-the-shelf products really are quite benificial to have. (I guess the vendors are quite happy with the ISC/AC-behemoth :) ) The thing about the 3rd-party packages is: they can give a novice TSM admin the utility of an experienced apprentice. This is a HUGE front-loaded win. Many installations never need more than apprentice level clue, and if they can replace training a resource who might leave, with purchasing a product, that's good. The long term cost is that, in order to become a journeyman, the admin must go back and learn all the crystalized clue that the admin package put at her disposal. To the operator-novice, this feels like a huge waste of time: every 'next hour' could be better spent using the interface at apprentice effectiveness, rather than going back and being a novice. [generalization of rant to GUIs in general and Windows in particular] This is why I feel that an open-source admin toolset, which would eventually accrete some of the crystalized clue of this august body, would be a Good Thing. The hood wouldn't be welded shut, as proprietary packages must be to make their nickel. This would make it that much easier to move from a novice-operating-an-interface through apprentice clue (What -really- happens when I push the 'Health Check' button?) into journeyman status (Dangit, I want to check that the veblefetzers are renoberated, too! code.. code.. code..) - Allen S. Rout
Re: TSM server automation products
On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote: Speaking as someone buried in my own PERL up to my nose: [snip: quite a good argument] I don't think I could be as effective with a third-party product as I am with my own stuff. I do think that the person who gets my job after I get hit by a truck will curse me for years. Thanks, those are good points. But it does beg the question: how bad is your current situation? :) I mean, is it such a spaghetti that nobody, except you as the developer, can *really* get it? Isn't *that* something you could change, so that your successor can as effective as you are? (Implementing and migrating to a third party product costs time and money, wouldn't that better be spent cleaning up the custom code?) Third-party programs are indeed spread more widely, but this also means they must be more complex because they must support configurations which you don't even use. Homegrown code has only the complexity you need. As a side note: it would really *really* be nice to have a documented API to enter dsmadmc commands -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TSM server automation products
On Sat, 1 Apr 2006 00:34:21 +0200, Jurjen Oskam [EMAIL PROTECTED] said: Uhm, may I ask *why* you'd want an off-the-shelf product instead of your own code? Is the Perl-code not functioning correctly? What problem are you trying to solve? Speaking as someone buried in my own PERL up to my nose: Your homegrown code is uniquely adapted to your brain and thinking. Unless you've been developing it with others, chances are good that nobody else can make it work even 60% as effectively as you can. Further, it reflects and amplifies your worldview, strengths, and blind spots. This means that (if we're honest with ourselves) there are gaps in our own code we're uniquely ill-qualified to find. Most third-party code has undergone substantial tomato-throwing from a variety of environments, and so might be reasonably assumed to have been idiot-proofed by a variety of idiots. If you're lucky enough to have more than one TSM-qualified person in shouting range, and you consort on the topics of architecture and design, then you might have armored yourself against the worst of the risks. I don't think I could be as effective with a third-party product as I am with my own stuff. I do think that the person who gets my job after I get hit by a truck will curse me for years. - Allen S. Rout
TSM server automation products
My site has a rather large Perl script that controls the daily housekeeping cycle (storage pool backups, database backups, tape movement, and so on). The script also detects a variety of error conditions and reports them to our operations staff. My management is convinced that we can buy an off the shelf product that will replace 80 percent of the Perl code. Does such a product exist? In particular, does ServerGraph provide this kind of functionality? Their Web site mentions automation, but does not seem to have any information on the automation features beyond the assertion that they exist.
Re: TSM server automation products
I believe ServerGraph and TSMManager both say they have the functionality. We have a pretty sizable TSM environment here...3 TSM servers 10TB b/u a night, 3584 1700 slots 60 drives and we do not have scripts to do any of the daily housekeeping. We use tsm scripts and scheduler and it runs fine. What do you have that is so complex that it has to be scripted outside of TSM's functionality. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: Friday, March 31, 2006 12:23 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM server automation products My site has a rather large Perl script that controls the daily housekeeping cycle (storage pool backups, database backups, tape movement, and so on). The script also detects a variety of error conditions and reports them to our operations staff. My management is convinced that we can buy an off the shelf product that will replace 80 percent of the Perl code. Does such a product exist? In particular, does ServerGraph provide this kind of functionality? Their Web site mentions automation, but does not seem to have any information on the automation features beyond the assertion that they exist. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
Re: TSM server automation products
We run the DRM product for TSM. That controls the offsite tape rotation and generates daily DR plans. With the Operational reporting that comes with TSM 5.2, it is a start. The overall reporting structure within TSM is bad to say the least. The operational reporting tool will email you various different reports based on node activity, session details, missed and open files, schedules etc. If you want some samples, will email them to you. . Servergraph does do a lot in the TSM environment. We had them recently at our TSM user's group meeting. Bob Martoncik Lucas County Information Services 419-213-4633 [EMAIL PROTECTED] 3/31/2006 1:23:11 PM My site has a rather large Perl script that controls the daily housekeeping cycle (storage pool backups, database backups, tape movement, and so on). The script also detects a variety of error conditions and reports them to our operations staff. My management is convinced that we can buy an off the shelf product that will replace 80 percent of the Perl code. Does such a product exist? In particular, does ServerGraph provide this kind of functionality? Their Web site mentions automation, but does not seem to have any information on the automation features beyond the assertion that they exist.
Re: TSM server automation products
On Fri, Mar 31, 2006 at 01:23:11PM -0500, Thomas Denier wrote: error conditions and reports them to our operations staff. My management is convinced that we can buy an off the shelf product that will replace 80 percent of the Perl code. Does such a product exist? Uhm, may I ask *why* you'd want an off-the-shelf product instead of your own code? Is the Perl-code not functioning correctly? What problem are you trying to solve? -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: TSM server automation.
Here's how i wait on a process to finish, i check every 10 minutes. i like to backup the DB first thing just incase /*DAILY*/ /*backup db*/ delete schedule chkproc type=admin q process if(rc_notfound) goto cont def schedule chkproc cmd=run daily active=yes startd=today startt=now+00:10 exp=today exit cont: backup db dev=bakdrive type=full wait=yes def schedule chkproc cmd=run Script1 active=yes startd=today startt=now+00:10 exp=today exit /* End of DAILY*/ /*SCRIPT1*/ /*Expire data bkup stg backup\archive pools*/ delete schedule chkproc type=admin q process if(rc_notfound) goto cont def schedule chkproc cmd=run script1 active=yes startd=today startt=now+00:10 exp=today exit cont: def schedule chkproc cmd=run backupstg active=yes startd=today startt=now+00:10 exp=today expire inventory exit /*End of SCRIPT1*/ /*Backupstg*/ delete schedule chkproc type=admin q process if(rc_notfound) goto cont def schedule chkproc cmd=run backupstg active=yes startd=today startt=now+00:10 exp=today exit cont: backup stg backuppool copypool /*End of Backupstg*/ -Original Message- From: Jason Liang [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 8:07 AM To: [EMAIL PROTECTED] Subject: TSM server automation. Hi *SMers, My environment: TSM 4.2.1.11 IBM LTO 3584 with 8 drives and 10 I/O stations. I want to implement such TSM server automation: 1. If there is no migration running, then backup stg tapepool copypool; 2. When backup stg finishes, backup db dev=lto type=full 3. When backup db finished, change the volumes of copypool to offsite, and then checkout these volumes and the DB volumes; Notify tape operators; If the numbers of volumes exceed 10, then checkout the first 10 volumes, wait for the I/O stations becomes empty and then checkout the others; Any help will be appreciated. Jason Liang
Re: TSM server automation.
Do you have an external scheduler that you can do job a before job b, before job c, etc? -Original Message- From: Jason Liang [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 8:07 AM To: [EMAIL PROTECTED] Subject: TSM server automation. Hi *SMers, My environment: TSM 4.2.1.11 IBM LTO 3584 with 8 drives and 10 I/O stations. I want to implement such TSM server automation: 1. If there is no migration running, then backup stg tapepool copypool; 2. When backup stg finishes, backup db dev=lto type=full 3. When backup db finished, change the volumes of copypool to offsite, and then checkout these volumes and the DB volumes; Notify tape operators; If the numbers of volumes exceed 10, then checkout the first 10 volumes, wait for the I/O stations becomes empty and then checkout the others; Any help will be appreciated. Jason Liang
Re: TSM server automation.
Hi Williams,
I don't have any external scheduler except cron.
Jason Liang
- Original Message -
From: Williams, Tim P {PBSG} [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 22, 2002 9:24 AM
Subject: Re: TSM server automation.
Do you have an external scheduler that you can do job a before job b,
before
job c, etc?
-Original Message-
From: Jason Liang [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 8:07 AM
To: [EMAIL PROTECTED]
Subject: TSM server automation.
Hi *SMers,
My environment: TSM 4.2.1.11 IBM LTO 3584 with 8 drives and 10 I/O
stations.
I want to implement such TSM server automation:
1. If there is no migration running, then backup stg tapepool copypool;
2. When backup stg finishes, backup db dev=lto type=full
3. When backup db finished, change the volumes of copypool to offsite, and
then checkout these volumes and the DB volumes; Notify tape operators;
If the numbers of volumes exceed 10, then checkout the first 10
volumes, wait for the I/O stations becomes empty and then
checkout the others;
Any help will be appreciated.
Jason Liang
Re: TSM server automation.
Jason,
You can use a product like Tivoli Workload Scheduler. There is a
redbook on integrating it with TSM.
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246030.pdf
Implementing TWS Extended agent for Tivoli Storage Manager, SG24-6030-00
Redbook, published March-14-2001
Thanks,
Mooney
Advanced Integrated Solutions
(562) 795-7740
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Liang
Sent: Friday, March 22, 2002 09:44
To: [EMAIL PROTECTED]
Subject: Re: TSM server automation.
Hi Williams,
I don't have any external scheduler except cron.
Jason Liang
- Original Message -
From: Williams, Tim P {PBSG} [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 22, 2002 9:24 AM
Subject: Re: TSM server automation.
Do you have an external scheduler that you can do job a before job b,
before
job c, etc?
-Original Message-
From: Jason Liang [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 8:07 AM
To: [EMAIL PROTECTED]
Subject: TSM server automation.
Hi *SMers,
My environment: TSM 4.2.1.11 IBM LTO 3584 with 8 drives and 10 I/O
stations.
I want to implement such TSM server automation:
1. If there is no migration running, then backup stg tapepool
copypool; 2. When backup stg finishes, backup db dev=lto type=full
3. When backup db finished, change the volumes of copypool to offsite,
and then checkout these volumes and the DB volumes; Notify tape
operators;
If the numbers of volumes exceed 10, then checkout the first 10
volumes, wait for the I/O stations becomes empty and then
checkout the others;
Any help will be appreciated.
Jason Liang
Re: TSM server automation.
search the www.adsm.org site for my name. I put all the scripts required that you are looking for in a message. Joe -Original Message- From: Jason Liang [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 9:07 AM To: [EMAIL PROTECTED] Subject: TSM server automation. Hi *SMers, My environment: TSM 4.2.1.11 IBM LTO 3584 with 8 drives and 10 I/O stations. I want to implement such TSM server automation: 1. If there is no migration running, then backup stg tapepool copypool; 2. When backup stg finishes, backup db dev=lto type=full 3. When backup db finished, change the volumes of copypool to offsite, and then checkout these volumes and the DB volumes; Notify tape operators; If the numbers of volumes exceed 10, then checkout the first 10 volumes, wait for the I/O stations becomes empty and then checkout the others; Any help will be appreciated. Jason Liang
