Tom, you,re close....the real name is VM/Encrypt-Tape; more information about it can be found here: http://www.vsoft-software.com/products.html
Mike, the amount of CPU cycles VM/Encrypt-Tape consumes is a function of the zSeries processor it runs on. If the processor supports the (new) KM/KMC instrunctions for the encryption algorithm you want to use, VM/Encrypt-Tape will use that hardware to do the encryption (very fast). If the processor does not support the KM/KMC instrunctions for the choosen algorithm, then it falls back to a software implementation of the encryptioon algorithm. As an example, the z990 has hardware sypport for the AES algotithm with a key size of 128 bits, while the new z10 hardware supports AES with a key size up to 256 bits. If you request a AES 256 bit key length encryption operation on a z990, VM/Encrypt-Tape will do it in the software, on a z10, it will do it in the hardware. What this means is that tapes can be moved back and forth between production and DR sites without the requirement that both sites have the same types of hardware tape encryption devices and support software (IBM, third party, etc.) installed. It's very flexible.... Thanks for the kind words, too. DJ Original Message: ----------------- From: Michael Coffin [EMAIL PROTECTED] Date: Tue, 17 Jun 2008 13:38:01 -0400 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Tom, Yep, we were also looking at Dave's VM/Encrypt product and I REALLY loved what I saw, but we didn't have the cycles available on the IBM 2066-0B1 to use it in production. Then it was "decided" that the TS1120 would be the "approved means" of encrypting mainframe tapes so...... :( -Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, June 17, 2008 1:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I have looked at your Backup/Recovery code, quite extensive. 1) With the use of a software encryption product (I think it is currently called VM/Encrypt, Dave, help), and a modified PIPEDDR, I was able to write encrypted backup tapes and restore them at our DR exercise last summer. Just about when DOE decided on a hardware only solution. 2) So true. I was actually thinking of a PIPEDDR type server to run at both sides of a DR connection, that acted like a backup server at production, with scheduled jobs that fired off workers to read each minidisk, full-volume, snapshot volume and send compressed data across the net to the recovery server at the hotsite which would fire off workers to receive each stream and write the data back to disk. I was thinking of a VM based server but it could be a linux server with some VM workers to handle snapshot requests and SVM shutdown/xautolog requests from a linux scheduler. But both would require more effort than I can give it. (Anyone got a product development team that needs some work?) /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 12:49:39 -0400, Michael Coffin <[EMAIL PROTECTED]> wrote: >Hi Tom, > >Yep, I have that all covered. This is actually a DR process that I >developed about 8 years ago (and have been improving over the years) >that is a complete "soup to nuts" system, automating both the backups >AND the recovery. The system assumes a "worst case scenario" where >computer center is gone, and all of the people having detailed >knowledge of the system are likewise "gone", it allows someone with >virtually no knowledge about the specifics of the system being >recovered and very minimal mainframe knowledge to fully recover the >system. When we conduct DR drills we typically recruit a management >type that has minimal computing skills and little specific knowledge >about the system (someone we affectionately refer to as the "monkey >boy", with the understanding that a slightly trained monkey could >actually complete this task) to actually conduct the recovery. The >programming staff provides no input to the "monkey boy", instead taking >notes of anything in the documentation that they found unclear and/or >any technical problems that may arise. The entire process is >menu-driven and pretty slick (including a Recovery Monitor that reports >what each DDR slave is doing, what's it's ETA to completion of the >current task is, what the total ETA to full system recovery is, the >ability to quiesce and restart slaves/streams/devices, etc.). > >In 2006 there was a massive flood in Washington DC that required >implementation of this DR Plan. I'm pleased to say it worked without a >hitch, and from the time we got the green light to start spinning tapes >we were back up in running in something like 3 or 4 hours (I think we >had about 20 DDR slaves running simultaneously). While this process >works extremely well, I now want to remove tapes from the process - >there are a number of reasons why this makes sense: > >1. There is a Federal mandate to encrypt all removable media which >this site is subject to, and we don't presently have TS1120 tape >drives/cartridges. > >2. Tapes can be lost and/or damaged (damage used to happen with >ALARMING frequency!), one bad tape and your entire recovery could be >jeapordized. > >Ultimately, I'd like to have our production DASD replicate (either in >realtime or via a nightly batch job) to a remote DASD array using PPRC >- but until such time as I get funding to do that (perhaps never!) I >need to eliminate the darned tapes. :) > >-Mike -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web
