Re: Recommendation on Backup product for z/VM
On 12/16/09 11:07 PM, "Alan Altmark" wrote: >> Yes, I wrote requirements. IBM even read them. SMOP. Someday. Play the > Alan >> "show us the business case" tape. Curtain. Two encores. Film at 11. > > Putting RACROUTE REQUEST=AUTH calls in the IBM subsystems is, in fact, on > the to-do list. Guess why? 8-) > Not for the faint of heart, or for the n00b. > We, having never installed zSecure before, got it running in an afternoon. Getting it running isn't the hard part. Getting it to do something useful in a context is not trivial if you don't want to do a lot of trial and error. -- db
Re: Recommendation on Backup product for z/VM
On Wednesday, 12/16/2009 at 09:21 EST, David Boyes
wrote:
> :grump.
>
> On 12/16/09 5:03 PM, "Alan Altmark" wrote:
>
>
> > So. You had to push the Do Not Push button? ;-) You are painting
with a
> > too-wide brush. "Better" is in the eye of the beholder. When
choosing an
> > ESM, you need to assess, aside from cost:
>
> *sigh*
>
> While your points are well argued, I spend a lot of time actually using
both
> product suites, and have recently done a point-by-point examination of
both
> the IBM suite and the CA suite in question. I'm not out to bash either
> company -- I have no great love for CA or CA products -- but this is one
> case where the IBM offering is just not yet as well integrated nor as
> complete. CA (as the last in a chain of companies) has had a lot longer
to
> actually get VM:Manager working and polished during the time while IBM
was
> pretty much ignoring CMS management tooling, and it really, really
shows.
>
> It's possible to implement anything with either one, but I would measure
> "better" in this case by how much additional stuff I need to layer on
top of
> a product to make it easy to use and understand. I need to write or
purchase
> a lot more additional stuff to make the IBM suite easy to use and
> understand.
>
> To your specific point about ESMs, for my recent comparison, I needed to
> write about 2200 lines of EXECs to do a set of functions using
VM:Secure.
> Providing the same checklist of functions with DIRM and RACF required
more
> than 27,000 lines of additional code, and two additional program
products,
> both of which required a special bid process to run on IFLs.
Well, sure, if you're trying to write a Grand Unification program for the
IBM toolset, then I would expect a far larger bill than for CA. They have
done an admirable job of creating a *suite* of tools. No arguments there.
> > - Functionality. If you need mandatory access controls, then RACF is,
to
> > the best of my knowledge, the only choice.
>
> Except the IBM backup and tape products don't pay any attention to RACF
> whatsoever. Neither does DIRMAINT for authorization. You're in a maze of
> twisty little config files, none alike.
True, but that's not the functionality I was talking about. I meant the
functionality of the ESM itself.
> Yes, I wrote requirements. IBM even read them. SMOP. Someday. Play the
Alan
> "show us the business case" tape. Curtain. Two encores. Film at 11.
Putting RACROUTE REQUEST=AUTH calls in the IBM subsystems is, in fact, on
the to-do list.
> I'd also question how much effort it takes to implement zSecure in a
usable
> way -- it needs a LOT of extra effort and thought to reach any kind of
> configuration simplicity. Been there, done that, got the glitter jacket
with
> the diamond piano ring. Not for the faint of heart, or for the n00b.
We, having never installed zSecure before, got it running in an afternoon.
I did discover that they failed to document how to start it with ISPF
(not ISPF/PDF!): ISPSTART CMD(%CKV)
In fact, I modified my CKV exec as follows:
:
arg fname . '(' parms ')'
"ISPQRY"
if rc <> 0 then
do
"ISPSTART CMD(%CKV)"
exit rc
end
:
This information will be fed back to the zSecure folks. I'm not sure how
they missed that.
Alan Altmark
z/VM Development
IBM Endicott
Re: Recommendation on Backup product for z/VM
:grump. On 12/16/09 5:03 PM, "Alan Altmark" wrote: > So. You had to push the Do Not Push button? ;-) You are painting with a > too-wide brush. "Better" is in the eye of the beholder. When choosing an > ESM, you need to assess, aside from cost: *sigh* While your points are well argued, I spend a lot of time actually using both product suites, and have recently done a point-by-point examination of both the IBM suite and the CA suite in question. I'm not out to bash either company -- I have no great love for CA or CA products -- but this is one case where the IBM offering is just not yet as well integrated nor as complete. CA (as the last in a chain of companies) has had a lot longer to actually get VM:Manager working and polished during the time while IBM was pretty much ignoring CMS management tooling, and it really, really shows. It's possible to implement anything with either one, but I would measure "better" in this case by how much additional stuff I need to layer on top of a product to make it easy to use and understand. I need to write or purchase a lot more additional stuff to make the IBM suite easy to use and understand. To your specific point about ESMs, for my recent comparison, I needed to write about 2200 lines of EXECs to do a set of functions using VM:Secure. Providing the same checklist of functions with DIRM and RACF required more than 27,000 lines of additional code, and two additional program products, both of which required a special bid process to run on IFLs. > - Functionality. If you need mandatory access controls, then RACF is, to > the best of my knowledge, the only choice. Except the IBM backup and tape products don't pay any attention to RACF whatsoever. Neither does DIRMAINT for authorization. You're in a maze of twisty little config files, none alike. Yes, I wrote requirements. IBM even read them. SMOP. Someday. Play the Alan "show us the business case" tape. Curtain. Two encores. Film at 11. > - Command syntax. Not. :-) I give high marks to VM:Secure for CMS > bigots. RACF is definitely MVS-centric in that respect, though mechanisms > are available to let you alter the syntax of the commands. If you add an > admin front-end like Tivoli zSecure, you significantly reduce your contact > with raw RACF commands and utilities. But command syntax should be the > last thing you worry about. (EXECs can hide a lot of sins.) I *can* do all those things, but for something that commands the price of either set of products, I shouldn't have to write or rewrite the user interface to make it consistent and comprehensible. If I wanted to invent a wheel, I'd be chipping at wood blocks, not buying software. I'd also question how much effort it takes to implement zSecure in a usable way -- it needs a LOT of extra effort and thought to reach any kind of configuration simplicity. Been there, done that, got the glitter jacket with the diamond piano ring. Not for the faint of heart, or for the n00b. > Here's > a good Best Practice: Buy the one that best fits your needs! :-) Buy the one that violates the Principle of Least Astonishment in the fewest ways. :egrump.
Re: Recommendation on Backup product for z/VM
I thought that being a CMS bigot was the first prerequisite for being on this list :-) Regards, Richard Schuh > - Command syntax. Not. :-) I give high marks to VM:Secure > for CMS bigots.
Re: Recommendation on Backup product for z/VM
Hi, Barbara. I've had good luck with the IBM system management products, with the exception of the Archive Manager, which I haven't used at all. IBM Support is also very good, imho. I'd be more than happy to discuss this with you in more detail off-list, if you'd like. Happy Holidays. On 12/16/2009 12:53 PM, Barbara Andrews wrote: We are looking for a replacement to our current backup methods and are looking for recommendations. We are currently running several Linux virtual machines on two VM LPARs and have been backing these up, as well as our VM system volumes, via our z/OS system using ADRDSSU. We also use TSM to give us database file level restores for data within our linux systems. However, things are changing and we need to find a replacement method for the ADRDSSU backups. Our z/OS system is very outdated (V1.3) and is slated to be decommissioned soon. We are considering purchasing either IBM's Backup and Restore Manager for z/VM, or CA's VM:Backup to server our immediate needs. And in the future perhaps other VM Management products offered by IBM (Operations Manager, Tape Manager) or CA (VM:Tape, VM:Schedule, VM:Operator, etc.). Has anyone evaluated these products, especially for backup, and have a recommendation on which is better to use? Are there any other options we should be considering? TIA. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Recommendation on Backup product for z/VM
On Wednesday, 12/16/2009 at 02:13 EST, David Boyes wrote: > The CA products are significantly more expensive, but are substantially more > polished and functional. If you go CA, seriously consider VM:Secure as well > -- it's dramatically better than RACF/VM if you don't need to share a > database with z/OS any more. So. You had to push the Do Not Push button? ;-) You are painting with a too-wide brush. "Better" is in the eye of the beholder. When choosing an ESM, you need to assess, aside from cost: - Your skill set. If you have z/OS RACF, then z/VM RACF is a no-brainer. If you have ACF2 or Top Secret on z/OS, then the z/VM equivalents are more palatible. But watch out for functional differences between z/OS and z/VM versions. This applies to both IBM and CA. - Functionality. If you need mandatory access controls, then RACF is, to the best of my knowledge, the only choice. - Security policy. Creation of virtual machines vs. authorization to use them may need to be managed separately. VM:Secure's combination of security and directory management is convenient, but may violate local security policy. - Certifications. z/VM with RACF has received Common Criteria certification to EAL 4+ under both CAPP and LSPP. - Command syntax. Not. :-) I give high marks to VM:Secure for CMS bigots. RACF is definitely MVS-centric in that respect, though mechanisms are available to let you alter the syntax of the commands. If you add an admin front-end like Tivoli zSecure, you significantly reduce your contact with raw RACF commands and utilities. But command syntax should be the last thing you worry about. (EXECs can hide a lot of sins.) The IBM and CA offerings are robust, commercial-grade products with their fans clubs and detractors. There are, contrary to what any salesman might say, plusses and minuses with each. As it turns out (wait for it...), people like best what they know best. (An awesome surprise, right?) Technical comparisons can be difficult without bringing in CA since they do not provide product documentation to the general public. (Product documentation from ca.com is only available after you login, and that requiresa CA customer number.) :-( While I specifically responded to your point about ESM, similar analysis needs to be performed for any system management products you buy. Here's a good Best Practice: Buy the one that best fits your needs! :-) Alan Altmark z/VM Development IBM Endicott
Re: Recommendation on Backup product for z/VM
I did the same thing, but I coded an SVC202 to an external REXX exec, makes it a lot simpler to test and maintain, and we can use CMS commands to tell VM:Tape to mount the next SCRATCH volume, update the job log, validate the tape (rewriting the header label if necessary), and position the tape past the SL with TAPE DVOL1 (LEAVE. I'm surprised in ALL these years IBM hasn't provided a simple external exit for DDR. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of peter.w...@ttc.ca Sent: Wednesday, December 16, 2009 3:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Recommendation on Backup product for z/VM Hi David, Here's the mod to HCPDDR in all it's glory: ./ I 56317202 $ 56317702 500 11/28/07 15:19:06 * TORONTO TRANSIT COMMISSION MODIFICATIONS START HERE PART 1/2 * THE TWO STATEMENTS THAT PRECEDE THIS MODIFICATION ARE: * CKDEOV DS0H * BAL R14,MSG005 GO PRINT THE END OF VOL MS TMDDRCMSF,DDRCMS RUNNING UNDER CMS? BZTTC1NO, THEN DO NOT CALL DMSTVS CMSCALL PLIST=TTCTVS,ERROR=* CALL DMSTVS FOR NEW TAPE TTC1 DS0H * TORONTO TRANSIT COMMISSION PART 1 MODIFICATIONS END HERE ./ I 58447802 $ 58448202 400 11/28/07 15:19:06 * TORONTO TRANSIT COMMISSION MODIFICATIONS START HERE PART 2/2 * THE TWO STATEMENTS THAT PRECEDE THIS MODIFICATION ARE: * SIORET7 DS0H * BRANCH SIOEP,SIORET TTCTVS DCCL8'DMSTVS' COMMAND TO MOUNT NEXT TAPE DCCL8'SCRATCH'DMSTVS PARAMETERS DCXL2'0181',CL6' ' DCCL8'18TR' COULD CHANGE FOR NEW DRIVES DCCL8'NL' DC8X'FF' END OF DMSTVS PARAMETER LIST * TORONTO TRANSIT COMMISSION PART 2 MODIFICATIONS END HERE -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: December 16, 2009 14:56 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Recommendation on Backup product for z/VM > What you use for backup depends on how you use the system. Do you have > lots of CMS users, or do you just use CMS for VM and Linux > administration? With lots of CMS users, you will need a file level > backup program, such as VM:Backup. Or if you plan to use any of the newer goodies in VM like the LDAP server or IMAP or some of the other nice things. IBM only supports use of SFS and/or BFS for these services, and if you think DDR sucks, wait until you meet FILEPOOL BACKUP. > Note that to use multiple > tape volumes for a disk volume backup with DDR and a tape manager, you > need to do a small mod to DDR so that it will call the tape manager to > mount the next scratch tape. Peter, can you describe that mod in more detail? I think that should be a requirement (you can also use the pipe-friendly DDR stage that supports writing output to a pipe stage so you can just feed it directly into the TAPn stage and GET STANDARD LABELS (woo hoo)). The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: Recommendation on Backup product for z/VM
CA's VMBackup HiDRO does everything except Linux file-level backups. We use it here to backup CMS minidisks, SFS, and full DASD images. As a bonus, it has a standalone module for bare metal DR restores. It will backup and restore whole Linux volumes but as stated before, the Linux instance better be shut down for the duration of the backup. For Linux file systems we use FDR/Upstream, taking advantage of the z/OS infrastructure and proven tape management. The client software is easy to install and manage, and their tech support has been superior. Upstream doesn't look like a possibility for you now but can you piggy-back on some existing open systems backup facility (Netbackup, etc) that has an agent for zLinux? Depending on business requirements, you can perhaps do without the file level backups, but they are definitely nice to have since they don't require shutting down the Linux instance. Ray Mrohs U.S. Dept. of Justice
Re: Recommendation on Backup product for z/VM
Hi David, Here's the mod to HCPDDR in all it's glory: ./ I 56317202 $ 56317702 500 11/28/07 15:19:06 * TORONTO TRANSIT COMMISSION MODIFICATIONS START HERE PART 1/2 * THE TWO STATEMENTS THAT PRECEDE THIS MODIFICATION ARE: * CKDEOV DS0H * BAL R14,MSG005 GO PRINT THE END OF VOL MS TMDDRCMSF,DDRCMS RUNNING UNDER CMS? BZTTC1NO, THEN DO NOT CALL DMSTVS CMSCALL PLIST=TTCTVS,ERROR=* CALL DMSTVS FOR NEW TAPE TTC1 DS0H * TORONTO TRANSIT COMMISSION PART 1 MODIFICATIONS END HERE ./ I 58447802 $ 58448202 400 11/28/07 15:19:06 * TORONTO TRANSIT COMMISSION MODIFICATIONS START HERE PART 2/2 * THE TWO STATEMENTS THAT PRECEDE THIS MODIFICATION ARE: * SIORET7 DS0H * BRANCH SIOEP,SIORET TTCTVS DCCL8'DMSTVS' COMMAND TO MOUNT NEXT TAPE DCCL8'SCRATCH'DMSTVS PARAMETERS DCXL2'0181',CL6' ' DCCL8'18TR' COULD CHANGE FOR NEW DRIVES DCCL8'NL' DC8X'FF' END OF DMSTVS PARAMETER LIST * TORONTO TRANSIT COMMISSION PART 2 MODIFICATIONS END HERE -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: December 16, 2009 14:56 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Recommendation on Backup product for z/VM > What you use for backup depends on how you use the system. Do you have > lots of CMS users, or do you just use CMS for VM and Linux > administration? With lots of CMS users, you will need a file level > backup program, such as VM:Backup. Or if you plan to use any of the newer goodies in VM like the LDAP server or IMAP or some of the other nice things. IBM only supports use of SFS and/or BFS for these services, and if you think DDR sucks, wait until you meet FILEPOOL BACKUP. > Note that to use multiple > tape volumes for a disk volume backup with DDR and a tape manager, you > need to do a small mod to DDR so that it will call the tape manager to > mount the next scratch tape. Peter, can you describe that mod in more detail? I think that should be a requirement (you can also use the pipe-friendly DDR stage that supports writing output to a pipe stage so you can just feed it directly into the TAPn stage and GET STANDARD LABELS (woo hoo)). The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: Recommendation on Backup product for z/VM
> What you use for backup depends on how you use the system. Do you have > lots of CMS users, or do you just use CMS for VM and Linux > administration? With lots of CMS users, you will need a file level > backup program, such as VM:Backup. Or if you plan to use any of the newer goodies in VM like the LDAP server or IMAP or some of the other nice things. IBM only supports use of SFS and/or BFS for these services, and if you think DDR sucks, wait until you meet FILEPOOL BACKUP. > Note that to use multiple > tape volumes for a disk volume backup with DDR and a tape manager, you > need to do a small mod to DDR so that it will call the tape manager to > mount the next scratch tape. Peter, can you describe that mod in more detail? I think that should be a requirement (you can also use the pipe-friendly DDR stage that supports writing output to a pipe stage so you can just feed it directly into the TAPn stage and GET STANDARD LABELS (woo hoo)).
Re: Recommendation on Backup product for z/VM
Hi Barbara, I can't comment on the IBM products, since I have no exposure to them. We have used the CA products, and are very happy with them. What you use for backup depends on how you use the system. Do you have lots of CMS users, or do you just use CMS for VM and Linux administration? With lots of CMS users, you will need a file level backup program, such as VM:Backup. If you use CMS only for administration, then you can probably get by with volume level backups using something like DDR, which comes with VM, or VM:Backup Hidro. Remember that ANY full volume backups on Linux disks MUST be done with Linux down, otherwise you will not get usable backups. Do you do frequent backups? If yes, you definitely want a tape manager. If your backups are infrequent, then you could make do with manual tape management, although I would not recommend it (unless you are using something like 3592 tapes, you will have multiple backup tape volumes, and it is SO easy to mount the wrong one). Note that to use multiple tape volumes for a disk volume backup with DDR and a tape manager, you need to do a small mod to DDR so that it will call the tape manager to mount the next scratch tape. Peter -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Barbara Andrews Sent: December 16, 2009 13:53 To: IBMVM@LISTSERV.UARK.EDU Subject: Recommendation on Backup product for z/VM We are looking for a replacement to our current backup methods and are looking for recommendations. We are currently running several Linux virtual machines on two VM LPARs and have been backing these up, as well as our VM system volumes, via our z/OS system using ADRDSSU. We also use TSM to give us database file level restores for data within our linux systems. However, things are changing and we need to find a replacement method for the ADRDSSU backups. Our z/OS system is very outdated (V1.3) and is slated to be decommissioned soon. We are considering purchasing either IBM's Backup and Restore Manager for z/VM, or CA's VM:Backup to server our immediate needs. And in the future perhaps other VM Management products offered by IBM (Operations Manager, Tape Manager) or CA (VM:Tape, VM:Schedule, VM:Operator, etc.). Has anyone evaluated these products, especially for backup, and have a recommendation on which is better to use? Are there any other options we should be considering? TIA. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: Recommendation on Backup product for z/VM
The CA products are significantly more expensive, but are substantially more polished and functional. If you go CA, seriously consider VM:Secure as well -- it's dramatically better than RACF/VM if you don't need to share a database with z/OS any more. Too bad TSM/VM isn't really viable any more. The combination of VM:Tape, TSM/VM and local GLANs is really super.
