Re: RMM Question
I sent Steve a copy offline. It was on a Classic SMS Redbooks CD I found and the CD also contains the books in the conversion series. The -01 version was dated September 1999, updated February 2000. On Sat, 8 Oct 2022 at 12:25, Paul Gorlinsky wrote: > BTW There are other Redbooks in this same area. For example Converting to > DFSMSrmm from CA-1 ( SG24-6241-01 ) > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM Question
BTW There are other Redbooks in this same area. For example Converting to DFSMSrmm from CA-1 ( SG24-6241-01 ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: RMM Question
On 6/10/2022 19:07, Steve Beaver wrote: Does anyone in the group have the following Redbook on their PC or Laptop SG24-4998-01, Converting to Removable Media Manager: A Practical Guide I migth have it on a backup. Any idea of the date? Best regards. j@n. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FW: RMM Question
Here's the previous version. https://ibmdocs.pocnet.net/SG24-4998-00.pdf On Thu, Oct 6, 2022 at 12:08 PM Steve Beaver wrote: > > Does anyone in the group have the following Redbook on their PC or Laptop > > > > SG24-4998-01, Converting to Removable Media Manager: A Practical Guide > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: RMM Question
Does anyone in the group have the following Redbook on their PC or Laptop SG24-4998-01, Converting to Removable Media Manager: A Practical Guide -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
Good point Tom. The system where we have implemented this is on 2.2, but I don't have any of the 2.1 manuals to see if this was part of it or not. It was a pleasure deleting VRS's especially since they just tied back to an SMS management class. As for the other systems we are waiting until they are 2.3 before converting per IBMs recommendation. John Benik | Optum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Wednesday, February 14, 2018 1:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMM question On 2/14/2018 12:23 PM, Benik, John E wrote: > Yes I know that but our company is also moving away from VRS's in my opinion > doing something like this... > > MCATTR(ALL)/* USE SMS MANAGEMENT. */ - > RM(EXPDT(GDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - > NOGDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - > LASTREF(0) CATLGDAYS(0) RETAINBY(SET))) /* RET METHOD */ - > > In the RMM parms to get catalog control is just easier, and getting > much closer to CA-1 which so many of us are familiar with. In > addition RMM now has EDM for HSM data. In Z/OS 2.3 the default is > yes. But you can also use a parm of EDM(YES) and all HSM migrates and > backups will be externally data managed, also similar to CA-1. I have > been told a lot of the things that used to require modifications to > the UXTABLE will be moving to the parmlib in Z/OS 2.3 > > John Benik | Optum John, Nice work if you can get it my friend. I'm stuck on V2R1 for the time being. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
On 2/14/2018 12:23 PM, Benik, John E wrote: Yes I know that but our company is also moving away from VRS's in my opinion doing something like this... MCATTR(ALL)/* USE SMS MANAGEMENT. */ - RM(EXPDT(GDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - NOGDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - LASTREF(0) CATLGDAYS(0) RETAINBY(SET))) /* RET METHOD */ - In the RMM parms to get catalog control is just easier, and getting much closer to CA-1 which so many of us are familiar with. In addition RMM now has EDM for HSM data. In Z/OS 2.3 the default is yes. But you can also use a parm of EDM(YES) and all HSM migrates and backups will be externally data managed, also similar to CA-1. I have been told a lot of the things that used to require modifications to the UXTABLE will be moving to the parmlib in Z/OS 2.3 John Benik | Optum John, Nice work if you can get it my friend. I'm stuck on V2R1 for the time being. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
Yes I know that but our company is also moving away from VRS's in my opinion doing something like this... MCATTR(ALL)/* USE SMS MANAGEMENT. */ - RM(EXPDT(GDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - NOGDG(WHILECATALOG(UNTILEXPIRED),RETPD(0)) - LASTREF(0) CATLGDAYS(0) RETAINBY(SET))) /* RET METHOD */ - In the RMM parms to get catalog control is just easier, and getting much closer to CA-1 which so many of us are familiar with. In addition RMM now has EDM for HSM data. In Z/OS 2.3 the default is yes. But you can also use a parm of EDM(YES) and all HSM migrates and backups will be externally data managed, also similar to CA-1. I have been told a lot of the things that used to require modifications to the UXTABLE will be moving to the parmlib in Z/OS 2.3 John Benik | Optum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Wednesday, February 14, 2018 10:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMM question On 2/14/2018 11:18 AM, Benik, John E wrote: > From: Benik, John E > Sent: Tuesday, February 13, 2018 11:22 AM > To: 'IBM Mainframe Discussion List' > Subject: RE: RMM question > > We have been looking at changing from VRSEL to Retention Method processing. > However our understanding is that in Z/OS 2.3 a lot of the functionality > performed by the exits is being removed and we were told that we should wait > for this before we change to retention method. If you do an RMM LC All you > should be able to see if the exit is enabled. One of the big differences I > have found with RMM and CA-1 is that there is no default retention for > catalog control in RMM. If you don't code EXPDT=99000 you will not get > catalog control and that applies for GDGs as well. So that being said check > your RMM parms and see how long the retention is. This should give you an > idea of when these tapes will scratch. Retention Method processing however > allows you to set Catalog Control as the default. > > John Benik | Optum > John, You can make catalog control the default without Retention Method, with a VRS ** WHILECATALOG, or a UXTABLE default entry with 99000 and EDGUX100. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
On 2/14/2018 11:18 AM, Benik, John E wrote: From: Benik, John E Sent: Tuesday, February 13, 2018 11:22 AM To: 'IBM Mainframe Discussion List' Subject: RE: RMM question We have been looking at changing from VRSEL to Retention Method processing. However our understanding is that in Z/OS 2.3 a lot of the functionality performed by the exits is being removed and we were told that we should wait for this before we change to retention method. If you do an RMM LC All you should be able to see if the exit is enabled. One of the big differences I have found with RMM and CA-1 is that there is no default retention for catalog control in RMM. If you don't code EXPDT=99000 you will not get catalog control and that applies for GDGs as well. So that being said check your RMM parms and see how long the retention is. This should give you an idea of when these tapes will scratch. Retention Method processing however allows you to set Catalog Control as the default. John Benik | Optum John, You can make catalog control the default without Retention Method, with a VRS ** WHILECATALOG, or a UXTABLE default entry with 99000 and EDGUX100. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
From: Benik, John E Sent: Tuesday, February 13, 2018 11:22 AM To: 'IBM Mainframe Discussion List' Subject: RE: RMM question We have been looking at changing from VRSEL to Retention Method processing. However our understanding is that in Z/OS 2.3 a lot of the functionality performed by the exits is being removed and we were told that we should wait for this before we change to retention method. If you do an RMM LC All you should be able to see if the exit is enabled. One of the big differences I have found with RMM and CA-1 is that there is no default retention for catalog control in RMM. If you don't code EXPDT=99000 you will not get catalog control and that applies for GDGs as well. So that being said check your RMM parms and see how long the retention is. This should give you an idea of when these tapes will scratch. Retention Method processing however allows you to set Catalog Control as the default. John Benik | Optum -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Tuesday, February 13, 2018 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RMM question We recently converted from CA-1 to RMM. I am having an issue with some tape volumes containing GDGs not scratching after x days. I have determined it is due to EXPDT=99000, and I am now waiting for the person who performed the conversion to let me know if the EDGUX100 exit is installed and activated. I am now looking at the process to create the correct VDS records for these GDGs. Currently, using a LISTCAT GDG ALL, I can see that the number of versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. RMM has more versions in it's catalog. In creating the VDS in RMM, it appears that I will need to also tell it the number of GDGs to retain. Maybe I am looking at this wrong, but it looks like I will need to maintain the number of generations to retain in both locations? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
My main worry about using WHILECATALOG is that there was an old practice were some tapes were manually set in CA-1 to have extended retention periods because of something that happened 'special' the day they were created. On the other hand, all the people that used to know the why those versions were kept are long gone, so I might as well scratch them. I just need to do a trial run and check to make sure that no year-end tapes show up. Tony Thigpen Jesse 1 Robinson wrote on 02/13/2018 12:44 PM: RMM was designed around the assumption that tape datasets would be cataloged or else scratched. When we converted to it many years ago, we had to deal with a wholly different business practice: keep tape data sets, including 'GDG members', more or less forever. In the early days we had to install exit code to achieve the desired result. Today I believe that it can be done purely with parm values (I'm not an RMM guy). The important thing in a conversion is to make sure that tape handling is consistent across products, whatever that takes. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Tuesday, February 13, 2018 9:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RMM question On 2/13/2018 9:24 AM, Tony Thigpen wrote: Thanks Tom. Yes, I did mean VRS. No, IBM did not do the conversion. The output shows: Exit status: EDGUX100 = NONE Are you suggesting that I not use EDGUX100, but instead use: RMM ADDVRS DSNAME(’**’) WHILECATALOG Will this affect all existing volumes? Is there a way to see the effect without accidentally messing everything up? Tony Thigpen Tony, I'm not sure how RMM will interpret 99000 without EDGUX100. I've always implemented at least the default EDGUX100 and UXTABLE. Is there a retention date listed in the volume record? About that '**' VRS, that will essentially make WHILECATALOG the default retention for everything, but then you will also have the overhead of VRSEL processing for everything. There are better ways to set that up. I would recommend that with your current setup, you create a VRS for the GDG's that you want to be WHILECATALOG controlled. You can run VRSEL with the VERIFY option to see the effects without actually doing anything. Please contact me offline if you'd like to discuss other options. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
RMM was designed around the assumption that tape datasets would be cataloged or else scratched. When we converted to it many years ago, we had to deal with a wholly different business practice: keep tape data sets, including 'GDG members', more or less forever. In the early days we had to install exit code to achieve the desired result. Today I believe that it can be done purely with parm values (I'm not an RMM guy). The important thing in a conversion is to make sure that tape handling is consistent across products, whatever that takes. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Tuesday, February 13, 2018 9:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RMM question On 2/13/2018 9:24 AM, Tony Thigpen wrote: > Thanks Tom. > > Yes, I did mean VRS. > > No, IBM did not do the conversion. > > The output shows: > Exit status: > EDGUX100 = NONE > > Are you suggesting that I not use EDGUX100, but instead use: > RMM ADDVRS DSNAME(’**’) WHILECATALOG > > Will this affect all existing volumes? Is there a way to see the > effect without accidentally messing everything up? > > Tony Thigpen > Tony, I'm not sure how RMM will interpret 99000 without EDGUX100. I've always implemented at least the default EDGUX100 and UXTABLE. Is there a retention date listed in the volume record? About that '**' VRS, that will essentially make WHILECATALOG the default retention for everything, but then you will also have the overhead of VRSEL processing for everything. There are better ways to set that up. I would recommend that with your current setup, you create a VRS for the GDG's that you want to be WHILECATALOG controlled. You can run VRSEL with the VERIFY option to see the effects without actually doing anything. Please contact me offline if you'd like to discuss other options. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
On 2/13/2018 9:24 AM, Tony Thigpen wrote: Thanks Tom. Yes, I did mean VRS. No, IBM did not do the conversion. The output shows: Exit status: EDGUX100 = NONE Are you suggesting that I not use EDGUX100, but instead use: RMM ADDVRS DSNAME(’**’) WHILECATALOG Will this affect all existing volumes? Is there a way to see the effect without accidentally messing everything up? Tony Thigpen Tony, I'm not sure how RMM will interpret 99000 without EDGUX100. I've always implemented at least the default EDGUX100 and UXTABLE. Is there a retention date listed in the volume record? About that '**' VRS, that will essentially make WHILECATALOG the default retention for everything, but then you will also have the overhead of VRSEL processing for everything. There are better ways to set that up. I would recommend that with your current setup, you create a VRS for the GDG's that you want to be WHILECATALOG controlled. You can run VRSEL with the VERIFY option to see the effects without actually doing anything. Please contact me offline if you'd like to discuss other options. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
Thanks Tom. Yes, I did mean VRS. No, IBM did not do the conversion. The output shows: Exit status: EDGUX100 = NONE Are you suggesting that I not use EDGUX100, but instead use: RMM ADDVRS DSNAME(’**’) WHILECATALOG Will this affect all existing volumes? Is there a way to see the effect without accidentally messing everything up? Tony Thigpen Tom Conley wrote on 02/13/2018 09:04 AM: On 2/13/2018 8:19 AM, Tony Thigpen wrote: We recently converted from CA-1 to RMM. I am having an issue with some tape volumes containing GDGs not scratching after x days. I have determined it is due to EXPDT=99000, and I am now waiting for the person who performed the conversion to let me know if the EDGUX100 exit is installed and activated. I am now looking at the process to create the correct VDS records for these GDGs. Currently, using a LISTCAT GDG ALL, I can see that the number of versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. RMM has more versions in it's catalog. In creating the VDS in RMM, it appears that I will need to also tell it the number of GDGs to retain. Maybe I am looking at this wrong, but it looks like I will need to maintain the number of generations to retain in both locations? Tony, If you mean VRS, set it to WHILECATALOG for that GDG, and the other versions that RMM has will go to scratch. 99000 with EDGUX100 should do the same. Does TSO RMM LC ALL show EDGUX100 active? If IBM did your CA-1 to RMM conversion, this should have been done. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
On 2/13/2018 8:19 AM, Tony Thigpen wrote: We recently converted from CA-1 to RMM. I am having an issue with some tape volumes containing GDGs not scratching after x days. I have determined it is due to EXPDT=99000, and I am now waiting for the person who performed the conversion to let me know if the EDGUX100 exit is installed and activated. I am now looking at the process to create the correct VDS records for these GDGs. Currently, using a LISTCAT GDG ALL, I can see that the number of versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. RMM has more versions in it's catalog. In creating the VDS in RMM, it appears that I will need to also tell it the number of GDGs to retain. Maybe I am looking at this wrong, but it looks like I will need to maintain the number of generations to retain in both locations? Tony, If you mean VRS, set it to WHILECATALOG for that GDG, and the other versions that RMM has will go to scratch. 99000 with EDGUX100 should do the same. Does TSO RMM LC ALL show EDGUX100 active? If IBM did your CA-1 to RMM conversion, this should have been done. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM question
We recently converted from CA-1 to RMM. I am having an issue with some tape volumes containing GDGs not scratching after x days. I have determined it is due to EXPDT=99000, and I am now waiting for the person who performed the conversion to let me know if the EDGUX100 exit is installed and activated. I am now looking at the process to create the correct VDS records for these GDGs. Currently, using a LISTCAT GDG ALL, I can see that the number of versions to be retained is 7. And only 7 DGDs show up in the LISTCAT. RMM has more versions in it's catalog. In creating the VDS in RMM, it appears that I will need to also tell it the number of GDGs to retain. Maybe I am looking at this wrong, but it looks like I will need to maintain the number of generations to retain in both locations? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question
Richard, Just chanced upon this question from you . and cant see any reply yet, so will try to answer it. You cannot mix RETAINBY volume and RETAINBY set for VRS retention. However that does not really answer the question What rmm will do for a "set" of volumes depends on what is actually written to that set and how the files are retained. If you have a single file written on a "set" - i.e. multi-volume data set. and that is VRS retained - rmm retains all the volumes in that set. If multiple files are written to a multi-volume set, how many are retained by VRS in that set depends on each individual data sets' VRS retention - if all files (data sets) are retained by VRS the set should be retained. Mike (rmm - retired) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM question
Most of our tape are logical volumes residing in an IBM VTS and they are SMS managed. Our RMM EDGRMMxx parm of RETAINBY is set to volume and we use RETENTION METHOD of VRSEL. I want a certain set of volumes to be managed by RETAINBY SET. Can this be done? FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question about adding VRS
Thank you Mike I will give it a shot! Thank you, Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Wood Sent: Saturday, April 05, 2014 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RMM question about adding VRS ...small addendum to my reply re: step #2 Without checking the full flow of command processing I cant be absolutely certain any more of what rmm does. However, as I said, it should allow you to change the location information to reflect the actual situation via commands. You might have to add NOEJECT operand because rmm believes the volume is library resident - depends how you 'manually' ejected it. If RMM shows volume is 'in transit' you dont need NOEJECT. I know that when the TCDB is not connected or library is off-line you can even add FORCE operand that enables some subset of failing commands to work in any case. Hope that helps, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN [http://infonet.txfb-ins.com//images//email-signature-image.jpg] WWW.TXFB-INS.COMhttp://www.txfb-ins.com CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. Texas Farm Bureau Insurance Companies received the highest numerical score among auto insurance providers in Texas in the proprietary J.D. Power 2013 U.S. Auto Insurance Study(SM). Study based on 45,521 total responses measuring 8 providers in Texas and measures opinions of consumers with their auto insurance provider. Proprietary study results are based on experiences and perceptions of consumers surveyed March –April 2013. Your experiences may vary. Visit jdpower.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question about adding VRS
...small addendum to my reply re: step #2 Without checking the full flow of command processing I cant be absolutely certain any more of what rmm does. However, as I said, it should allow you to change the location information to reflect the actual situation via commands. You might have to add NOEJECT operand because rmm believes the volume is library resident - depends how you 'manually' ejected it. If RMM shows volume is 'in transit' you dont need NOEJECT. I know that when the TCDB is not connected or library is off-line you can even add FORCE operand that enables some subset of failing commands to work in any case. Hope that helps, Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM question about adding VRS
Wayne, You should not need to retrieve the volumes, re-insert them, and do it all again under VRS control. RMM should be smart enough to make sense of what it finds in the library and what the VRS policy decides. I suggest you 1. Add the rule that will cause rmm to identify what should be in the offsite location. 2. Get a list of the off-site volumes, and for each one issue rmm tso command: RMM CV volser LOCATION(offsite) CMOVE I would expect that rmm command processing will find the volume not in the library and allow the location change without an error msg. 3. run EDGHSKP VRSEL processing. As a result, as documented in the rmm IC Guide the 'required location' will be updated to show what VRS decides. 4. You can check the VRSEL decision against actual location using SEARCHVOLUME for example: RMM SV VOLUME(*) LOCATION(LIBATL1) REQUIRED(offsite) RMM SV VOLUME(*) LOCATION(offsite) REQUIRED(LIBATL1) 5. Run EDGHSKP DSTORE which initiates the movement by setting LOCATION from REQUIRED location. 6. Eject the volumes from the library and move them/return volumes from offsite if needed. 7. Confirm the moves to offsite to rmm / enter returning volumes into the library Normally you can run EDGHSKP options all in the same run, not step by step. Mike WoodRMM expert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM question about adding VRS
List, I have been archiving SMF/RMF data to a 3592 tape then manually ejecting it and carry it offsite therefor the location is still listed as LIBATL1 in the RMM database. I would like to automate this process and add a VRS rule to send it offsite. If I add a VRS rule for these datasets, what will RMM do during the Housekeeping phase as far as the LOCATION is concerned? Will RMM eject the tape even though it is not in the ATL and will he change the LOCATION to OFFSITE as per the rule? I have around 30 tapes in this scenario. Maybe I should just retrieve them from the OFFSITE vault location, insert them in the ATL then install the VRS rule and let RMM handle it the clean and proper way. Any help would be appreciated. Thank you, Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 [http://infonet.txfb-ins.com//images//email-signature-image.jpg] WWW.TXFB-INS.COMhttp://www.txfb-ins.com CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. Texas Farm Bureau Insurance Companies received the highest numerical score among auto insurance providers in Texas in the proprietary J.D. Power 2013 U.S. Auto Insurance Study(SM). Study based on 45,521 total responses measuring 8 providers in Texas and measures opinions of consumers with their auto insurance provider. Proprietary study results are based on experiences and perceptions of consumers surveyed March -April 2013. Your experiences may vary. Visit jdpower.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
