Re: DFSMSrmm basic question
Pommier, Rex R. wrote: Actually according to the guys at my shop that actually configure and maintain it, you can set up NetBackup to work just like this. I should have been more clear in my comments. There is an optional piece to NetBackup that allows the NetBackup server on one box to function as the owner of the library and tapes. I think it's called the shared storage option. Each of the client NetBackup pieces running on the various other boxes has direct access to the tape drives and their own storage. They ask the server for a tape drive and a scratch tape, the server hands out the resources (in our library, it mounts the tape on behalf of the client) and tells the client to proceed. Once the client is done backing up the datasets it relinquishes control of the tape drive and media back to the server. You are right, basic NetBackup pulls all the client data across the network to the server which then writes it all to tape. This is absolutely NOT what I want to do. Yuck. Omniback (now called data protector) from HP works the same way, and it was pretty slick. I forgot about new features in NetBackup. Indeed, it can use SAN as data path to the drive and LAN+backup server as command path to the robot. However it's still NOT the way as RMM works. vbg Let's assume you have STK/Sun tape environment. In such case every system have STK client (SMC) and one of the system also has server (HSC) Every client sends data directly to the drive, using FICON path. However mount command is sent via LAN path to the HSC and from HSC to the robot. (In IBM ATL commands are sent inband - over FICON). In such scenario you still have a choice: use RMM in classic mode or client-server mode. It has nothing to do with mount commands. On the other hand, NetBackup covers more than RMM. It is equivalent of RMM and data mover (HSM+DSS) and ATL support (SMC/HSC or OAM). Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFSMSrmm basic question
This is probably a dumb question, but I'll ask it anyway, and ask pre-forgiveness. :-) We are running 3 LPARs on a small z9-BC (production, development/test, and a sandbox). Each of the LPARs is stand-alone, with no SYSPLEX sharing of anything, nor do I have anything like GRS implemented. When the system was set up years ago, there was no need for any tape on the test LPARs. Now, the developers are clamoring for the ability to run extended batch on the test LPARs and so they want access to tape. My question is, what is required (or is it even possible) to use a single DFSMSrmm tape pool across multiple LPARs? What I would like would be for the tape catalog to remain on the production LPAR, and have DFSMSrmm on the test LPAR make a call across to the production LPAR for verification of scratch status, and updating of tape information into the production LPAR RMM catalog. The implementation guide indicates that I should be able to do this, but I didn't have much luck finding specifics. Right now I'm just looking for a general can it be done, and what kind of effort would be required to 'make it happen'. TIA. Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
On Wed, 2008-04-02 at 14:21 -0500, Pommier, Rex R. wrote: what is required (or is it even possible) to use a single DFSMSrmm tape pool across multiple LPARs? The CDS can be shared between systems easily, though you might not be able to do this without GRS. Mike Wood ought to be able to give you an authoritative answer on that. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
Pommier, Rex R. wrote: This is probably a dumb question, but I'll ask it anyway, and ask pre-forgiveness. :-) This is wise question and I'm trying to give not-so-dumb answer :-) You can use RMM in multi-host configuration. This is available for years. The systems need not to be sysplexed. You have to share RMM CDS and journal datasets. Those datasets can be on shared disk, GRS RING is recommended, but not necessary. Caution: regardless of sharing method you have to configure your RMM environment for multisystem use. I mean unique system names, volume ranges, etc. It can be easy or hard - depending on your needs (and wishes). BTW: Recently - AFAIK it was z/OS 1.7 - new option was introduced. In general it is client-server solution, where client RMM tasks communicate to server RMM over IP network. I have never used it, so I can't say anything more. HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
Thanks, Radoslaw (and David); I will have to check out the client-server solution because that is exactly what I'm looking for. I am using that type of setup for NetBackup on my *IX boxes and would like the same setup on my z. I don't want to go through the hassle of dividing the tapes up into separate volume ranges for each of the LPARs. Putting 1.7 on the production LPAR in less than 2 weeks (finally). Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, April 02, 2008 3:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFSMSrmm basic question Pommier, Rex R. wrote: This is probably a dumb question, but I'll ask it anyway, and ask pre-forgiveness. :-) This is wise question and I'm trying to give not-so-dumb answer :-) You can use RMM in multi-host configuration. This is available for years. The systems need not to be sysplexed. You have to share RMM CDS and journal datasets. Those datasets can be on shared disk, GRS RING is recommended, but not necessary. Caution: regardless of sharing method you have to configure your RMM environment for multisystem use. I mean unique system names, volume ranges, etc. It can be easy or hard - depending on your needs (and wishes). BTW: Recently - AFAIK it was z/OS 1.7 - new option was introduced. In general it is client-server solution, where client RMM tasks communicate to server RMM over IP network. I have never used it, so I can't say anything more. HTH -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
Pommier, Rex R. wrote: Thanks, Radoslaw (and David); I will have to check out the client-server solution because that is exactly what I'm looking for. I am using that type of setup for NetBackup on my *IX boxes and would like the same setup on my z. I don't want to go through the hassle of dividing the tapes up into separate volume ranges for each of the LPARs. Putting 1.7 on the production LPAR in less than 2 weeks (finally). To be clear: This is NOT like Netbackup. It's rather like Tantia, aka Harbor or FDR Upstream. Each system still writes data over FICON/ESCON/BUSTAG to tape drive. Only RMM task updates CDS and journal over network in client-server mode. In other words remote RMM doesn't open datasets, it opens network connection to RMM server which manages datasets. BTW: I wouldn't like LAN-type backup although having such option would be interesting in some cases. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
Actually according to the guys at my shop that actually configure and maintain it, you can set up NetBackup to work just like this. I should have been more clear in my comments. There is an optional piece to NetBackup that allows the NetBackup server on one box to function as the owner of the library and tapes. I think it's called the shared storage option. Each of the client NetBackup pieces running on the various other boxes has direct access to the tape drives and their own storage. They ask the server for a tape drive and a scratch tape, the server hands out the resources (in our library, it mounts the tape on behalf of the client) and tells the client to proceed. Once the client is done backing up the datasets it relinquishes control of the tape drive and media back to the server. You are right, basic NetBackup pulls all the client data across the network to the server which then writes it all to tape. This is absolutely NOT what I want to do. Yuck. Omniback (now called data protector) from HP works the same way, and it was pretty slick. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, April 02, 2008 4:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DFSMSrmm basic question Pommier, Rex R. wrote: Thanks, Radoslaw (and David); I will have to check out the client-server solution because that is exactly what I'm looking for. I am using that type of setup for NetBackup on my *IX boxes and would like the same setup on my z. I don't want to go through the hassle of dividing the tapes up into separate volume ranges for each of the LPARs. Putting 1.7 on the production LPAR in less than 2 weeks (finally). To be clear: This is NOT like Netbackup. It's rather like Tantia, aka Harbor or FDR Upstream. Each system still writes data over FICON/ESCON/BUSTAG to tape drive. Only RMM task updates CDS and journal over network in client-server mode. In other words remote RMM doesn't open datasets, it opens network connection to RMM server which manages datasets. BTW: I wouldn't like LAN-type backup although having such option would be interesting in some cases. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm basic question
Rex, With all the good answers provided by others I almost dont need to reply anymore. You have the choice to either share the CDS via DASD or via IP network. Using rmm client/server via IP has been available since z/OS V1.6. It does avoid using hardware reserves on our CDS volume which many people dont want nowadays (yes, sysplex and GRS can convert reserves, but does not apply in this case). Whether you use DASD sharing or client/server you can share everything that your tape hardware allows you to share; volumes, drives, policies etc.. Depending on your libraries you may need to consider partitioning, but hopefully not. Client/Server implementation is covered in the Implementation Customization Guide. You will also need to implement CATSYNCH function because of the unshared user catalogs (if using catalog retention for tapes). Mike WoodRMM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
