Re: SET DRMDBBACKUPEXPIREDAYS
Running out of database space and drm retention. Seems I am the only one that is missing the relation between those 2. Op 18 jun. 2014 18:35 schreef "Plair, Ricky" : > Question, I am running TSM 6.3 and running out of database space with > nowhere to get more at the moment. > > My DRMDBBACKUPEXPIREDAYS is set to 60 days. I really don't think I need 60 > days. I would like to change this number to 30 days and get some space > back. What is a norm or an expected amount of days for this parameter? > > Ricky M. Plair > Storage Engineer > HealthPlan Services > Office: 813 289 1000 Ext 2273 > Mobile: 757 232 7258 > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > CONFIDENTIALITY NOTICE: This email message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information and/or Protected Health Information (PHI) > subject to protection under the law, including the Health Insurance > Portability and Accountability Act of 1996, as amended (HIPAA). If you are > not the intended recipient or the person responsible for delivering the > email to the intended recipient, be advised that you have received this > email in error and that any use, disclosure, distribution, forwarding, > printing, or copying of this email is strictly prohibited. If you have > received this email in error, please notify the sender immediately and > destroy all copies of the original message. >
Re: SET DRMDBBACKUPEXPIREDAYS
We have our DRMDBBACKUPEXPIREDAYS set to 7. We do a backup daily. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Karel Bos Sent: Thursday, June 19, 2014 7:51 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] SET DRMDBBACKUPEXPIREDAYS Running out of database space and drm retention. Seems I am the only one that is missing the relation between those 2. Op 18 jun. 2014 18:35 schreef "Plair, Ricky" : > Question, I am running TSM 6.3 and running out of database space with > nowhere to get more at the moment. > > My DRMDBBACKUPEXPIREDAYS is set to 60 days. I really don't think I > need 60 days. I would like to change this number to 30 days and get > some space back. What is a norm or an expected amount of days for this > parameter? > > Ricky M. Plair > Storage Engineer > HealthPlan Services > Office: 813 289 1000 Ext 2273 > Mobile: 757 232 7258 > > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ CONFIDENTIALITY NOTICE: This email message, including any > attachments, is for the sole use of the intended recipient(s) and may > contain confidential and privileged information and/or Protected > Health Information (PHI) subject to protection under the law, > including the Health Insurance Portability and Accountability Act of > 1996, as amended (HIPAA). If you are not the intended recipient or the > person responsible for delivering the email to the intended recipient, > be advised that you have received this email in error and that any > use, disclosure, distribution, forwarding, printing, or copying of > this email is strictly prohibited. If you have received this email in > error, please notify the sender immediately and destroy all copies of the > original message. >
Cancelling REPLICATION Processes via script.
I have an admin script that issues several node replicate commands, with WAIT=YES on each to control bandwidth/processor burden. If I issue CANCEL REPLICATION, only the currently running process is cancelled. The next REPLICATE NODE (pending via the script) then starts. Is there a way to cancel all of those pending processes? I tried a DELETE TYPE=A (it did delete the schedule), followed by CANCEL PRO (on the currently running process), but the next REPLICATION immediately started. The only solution coming to mind is to write a script that would repeatedly issue "Q REPLICATION *" with a CANCEL REPLICATION issued if one is active. Then exiting when none are found. Any of you TSM wizards have a solution you're willing to share? ... thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
Backup job status
Folks: What is the best way to track a TSM backup job's status? We are currently using TSM 6.2, working on the upgrade to TSM 7.1, and have a business user that desires a simple interface with which to check status of a backup job. "Green-light/red-light" sort of display, with the ability to drill-in if necessary. And I don't mean just the status of the job completion (did the job reach the end?) but covering the status of all the files backed up (Job completed, but "failed" because it was unable to backup one of the drives...) Is there anything built into TSM to provide such reporting? I'm happy to read on my own if someone is willing to point me in the right direction, but would love to gather practical advice and experience as well. Thanks! Best regards, Mike, x7942 RMD IT Client Services
Re: Cancelling REPLICATION Processes via script.
Back in the day we used to do something like this to be able to bail out of long-running house-keeping scripts: repl node node1,node2,node3 wait=yes select * from scripts where name='CANCEL_REPLI' if(rc_ok) goto cancel repl node node4,node5,node6 wait=yes select * from scripts where name='CANCEL_REPLI' if(rc_ok) goto cancel cancel: cancel replication del script CANCEL_REPLI Then it was just a matter of defining a script "CANCEL_REPLI" ... - Bent -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, June 19, 2014 3:22 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cancelling REPLICATION Processes via script. I have an admin script that issues several node replicate commands, with WAIT=YES on each to control bandwidth/processor burden. If I issue CANCEL REPLICATION, only the currently running process is cancelled. The next REPLICATE NODE (pending via the script) then starts. Is there a way to cancel all of those pending processes? I tried a DELETE TYPE=A (it did delete the schedule), followed by CANCEL PRO (on the currently running process), but the next REPLICATION immediately started. The only solution coming to mind is to write a script that would repeatedly issue "Q REPLICATION *" with a CANCEL REPLICATION issued if one is active. Then exiting when none are found. Any of you TSM wizards have a solution you're willing to share? ... thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
Re: Cancelling REPLICATION Processes via script.
Thanks Bent I'll give that a try. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Bent Christensen Sent: Thursday, June 19, 2014 9:23 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Cancelling REPLICATION Processes via script. Back in the day we used to do something like this to be able to bail out of long-running house-keeping scripts: repl node node1,node2,node3 wait=yes select * from scripts where name='CANCEL_REPLI' if(rc_ok) goto cancel repl node node4,node5,node6 wait=yes select * from scripts where name='CANCEL_REPLI' if(rc_ok) goto cancel cancel: cancel replication del script CANCEL_REPLI Then it was just a matter of defining a script "CANCEL_REPLI" ... - Bent -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [BS] Sent: Thursday, June 19, 2014 3:22 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cancelling REPLICATION Processes via script. I have an admin script that issues several node replicate commands, with WAIT=YES on each to control bandwidth/processor burden. If I issue CANCEL REPLICATION, only the currently running process is cancelled. The next REPLICATE NODE (pending via the script) then starts. Is there a way to cancel all of those pending processes? I tried a DELETE TYPE=A (it did delete the schedule), followed by CANCEL PRO (on the currently running process), but the next REPLICATION immediately started. The only solution coming to mind is to write a script that would repeatedly issue "Q REPLICATION *" with a CANCEL REPLICATION issued if one is active. Then exiting when none are found. Any of you TSM wizards have a solution you're willing to share? ... thanks. Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***
3584 upgrade: 3592-E05 to 3592-E07
Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - 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.
AW: Backup job status
Hallo Mike, you could have a look to our "Power Administrator for TSM" Freeware version ( www.tsmpoweradmin.com), where you are able to see graphically the current and past backup/schedule status of all your backup jobs and in addition you could use our free adjustable "out of the box Operational Reporting" report and send it to your e-mail address every day if you want. Have a try ( If you try and have questions, pls contact me directly). Rgds Michael Michael.Malitz@ tsmpoweradmin.com -Ursprüngliche Nachricht- Von: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] Im Auftrag von Ryder, Michael S Gesendet: Donnerstag, 19. Juni 2014 15:42 An: ADSM-L@VM.MARIST.EDU Betreff: Backup job status Folks: What is the best way to track a TSM backup job's status? We are currently using TSM 6.2, working on the upgrade to TSM 7.1, and have a business user that desires a simple interface with which to check status of a backup job. "Green-light/red-light" sort of display, with the ability to drill-in if necessary. And I don't mean just the status of the job completion (did the job reach the end?) but covering the status of all the files backed up (Job completed, but "failed" because it was unable to backup one of the drives...) Is there anything built into TSM to provide such reporting? I'm happy to read on my own if someone is willing to point me in the right direction, but would love to gather practical advice and experience as well. Thanks! Best regards, Mike, x7942 RMD IT Client Services
Re: 3584 upgrade: 3592-E05 to 3592-E07
I would automate the check out process and run it before the check in process. That will keep the old tapes at the bottom of the scratch list. Provided there is enough scratch then the older tapes will not make it to the top. TSM will reuse a tape immediately if it is mounted and becomes scratch. I suspect TSM will not know the full barcode and may not be able to know which type of media. Being a read-only tape it should have an error and try another tape. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 11:19 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - 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: 3584 upgrade: 3592-E05 to 3592-E07
I'm not sure the problem is as bad as you think. Automatic tape libraries tend to manage scratch tapes first-in first-out in an effort to distribute tape wear evenly. My guess is that your library will use all of the JC volumes inserted at the start of the conversion before using any of the JA or JB volumes scratched after that. If you later clean out scratched JA and JB volumes and add JC scratch volumes, my guess is that the new batch of JC volumes will be used before any JA or JB volumes scratched after that. For storage pool volumes you could eject JA and JB volumes in PENDING status to eliminate any worries about the volumes being reused. You could temporarily increase the reuse delay to give you a bigger window of opportunity for ejecting volumes and/or maintain the normal degree of readiness for restoring older versions of the TSM database. Thomas Denier Thomas Jefferson University Hospital -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - 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. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
Re: 3584 upgrade: 3592-E05 to 3592-E07
I agree. As long as there are lots of JC tapes on the scratch list, I believe the default algorithm is to round-robin the scratch list, so the old tapes that free up will likely be at the bottom of the scratch list and will likely not get used before you check them out. And I like the idea of increasing the reusedelay, that should give you even more leeway. If you still have problems, there is a software solution: Update your storage pools to maxscratch=0 Use the DEFINE VOLUME command to bind JC tapes to the storage pools, and check them in as PRIVATE. That way no pools will be grabbing scratch tapes at all. When all your JA/JB tapes are removed, update the stgpools to maxscratch= and go back to using a scratch pool again. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Thomas Denier Sent: Thursday, June 19, 2014 2:46 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 I'm not sure the problem is as bad as you think. Automatic tape libraries tend to manage scratch tapes first-in first-out in an effort to distribute tape wear evenly. My guess is that your library will use all of the JC volumes inserted at the start of the conversion before using any of the JA or JB volumes scratched after that. If you later clean out scratched JA and JB volumes and add JC scratch volumes, my guess is that the new batch of JC volumes will be used before any JA or JB volumes scratched after that. For storage pool volumes you could eject JA and JB volumes in PENDING status to eliminate any worries about the volumes being reused. You could temporarily increase the reuse delay to give you a bigger window of opportunity for ejecting volumes and/or maintain the normal degree of readiness for restoring older versions of the TSM database. Thomas Denier Thomas Jefferson University Hospital -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rhodes, Richard L. Sent: Thursday, June 19, 2014 12:19 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 3584 upgrade: 3592-E05 to 3592-E07 Hi, This weekend we are upgrading all of our tape drives (in 2 libraries) from 3592-E05 (TS1120) to 3592-E07 (TS1140). The libraries currently have a mix of JA and JB media. We will be migrating over time to all new JC media. JA tapes are READONLY on 3592-E07 drives. JB tapes are READ/WRITE on 3592-E07 drives. The plan is to: - Export out of the lib all current scratch JA/JB media. - Mark all existing JA/JB media ReadOnly. - Insert lots of new JC media. - TSM will write to the new JC tapes. - As JA/JB tapes drop to scratch, export them out of the Library, and insert more JC media. When JA/JB tapes drop to SCRATCH status, I'm not sure I will always be able to export them before TSM might try and reuse them. If TSM tries to use a JB tape, that is OK - it will work. But what if TSM selects a JA tape and tries to use it. That would fail since 3592-E07 drives can READ JA media but NOT WRITE to them. Q) Is TSM smart enough to not load a JA media into a 3592-E07 drive for writing? TSM has the media_type of all tapes (q libvol f=d), so I would think it should know not to do this. Thanks Rick - 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. The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
Re: Backup job status
Install the TSM Operations Center 7.1 when you install the 7.1 server. (Not available with 6.2) Very small footprint, free with the server. Here's a video demo: https://www.youtube.com/watch?v=5l0wtmCmwkA -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ryder, Michael S Sent: Thursday, June 19, 2014 9:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backup job status Folks: What is the best way to track a TSM backup job's status? We are currently using TSM 6.2, working on the upgrade to TSM 7.1, and have a business user that desires a simple interface with which to check status of a backup job. "Green-light/red-light" sort of display, with the ability to drill-in if necessary. And I don't mean just the status of the job completion (did the job reach the end?) but covering the status of all the files backed up (Job completed, but "failed" because it was unable to backup one of the drives...) Is there anything built into TSM to provide such reporting? I'm happy to read on my own if someone is willing to point me in the right direction, but would love to gather practical advice and experience as well. Thanks! Best regards, Mike, x7942 RMD IT Client Services
Re: Backup job status
And here's a live demo : https://demo.tsm.ibmserviceengage.com:11090/TSMLiveDemo/ -- Best regards / Cordialement / مع تحياتي Erwann SIMON - Mail original - De: "Wanda Prather" À: ADSM-L@VM.MARIST.EDU Envoyé: Vendredi 20 Juin 2014 05:54:26 Objet: Re: [ADSM-L] Backup job status Install the TSM Operations Center 7.1 when you install the 7.1 server. (Not available with 6.2) Very small footprint, free with the server. Here's a video demo: https://www.youtube.com/watch?v=5l0wtmCmwkA -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Ryder, Michael S Sent: Thursday, June 19, 2014 9:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backup job status Folks: What is the best way to track a TSM backup job's status? We are currently using TSM 6.2, working on the upgrade to TSM 7.1, and have a business user that desires a simple interface with which to check status of a backup job. "Green-light/red-light" sort of display, with the ability to drill-in if necessary. And I don't mean just the status of the job completion (did the job reach the end?) but covering the status of all the files backed up (Job completed, but "failed" because it was unable to backup one of the drives...) Is there anything built into TSM to provide such reporting? I'm happy to read on my own if someone is willing to point me in the right direction, but would love to gather practical advice and experience as well. Thanks! Best regards, Mike, x7942 RMD IT Client Services
