Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Or make local twins, then copy one tape-to-remote tape.. problem solved, always at least two backups. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Mark Post Sent: Thursday, June 05, 2008 5:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit On Thu, Jun 5, 2008 at 4:44 PM, in message [EMAIL PROTECTED], Hughes, Jim [EMAIL PROTECTED] wrote: The auditors may have a stroke when they realize there is a larger window where no copies exist. Auditors can have all the strokes they want, if management is willing to sign off on the exposure. The technical deficiencies of catalogs not matching is far more of a problem. Mark Post
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Thinking laterally about this, there is always another solution. Have you thought about long-distance remote PPRC for your DASD. I am not sure if the official IBM PPRC-XD product can cope with 3000 miles but there are solutions that can. Colin Allinson Amadeus Data Processing GmbH
Re: Install RACF without HLASM???
In the VM/SP days we decided to use a single CP nucleus for all our VM systems, one of which still ran RACF in warningmode. So I coded a RACDEFER EXEC to zap HCPRWA in storage to set the LINK permission flags. As it proved to be useful at some times, I updated it to VM/ESA and even z/VM. I'll send it to Leland. 2008/6/4 Alan Altmark [EMAIL PROTECTED]: On Tuesday, 06/03/2008 at 06:08 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I just checked and I am wrong. The ZAP command does not work against individual TEXT files. But the CMS LOAD command accepts VER and REP statements at the end of a TEXT file. Does the process used to generate the CPLOAD MODULE use that LOAD command? You can use ZAPTEXT, my second development assignment after hiring on with IBM. :-) Of course, the thought of using a zap against a text deck that is so critical to the security subsystem kind of rubs me the wrong way, but I can get over it. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Getting DMSOPN3362E Imbedded blanks found in file name
On Thursday, 06/05/2008 at 12:27 EDT, Horlick, Michael [EMAIL PROTECTED] wrote: DMSOPN3362E Imbedded blanks found in file name I have opened an issue with CA and I have tried doing an SVCTRACE ON to find out where the problem is. From looking at the book it seems something should have received a return code of 20 but it is not visible in the output from SVCTRACE. Any other commands, etc.. that can be used to find out what this ?file name? would be? CP TRACE DIAG CA RUN CMD D T0.50;base1 CP TRACE DIAG CC RUN CMD D T0.50;base1 Alan Altmark z/VM Development IBM Endicott
Re: Real device number assignments
Even though my customer's MVS systems are becoming short of UCB's, each device has a single device number here, be it shared or not. And, even though the VM and MVS support groups are (or I should say were) different, this uniqueness is maintained across VM and MVS systems. 2008/6/1 Fox Blue [EMAIL PROTECTED]: Also in our organisation we have the same real device numbers on all CECs and LPARs. In order to reduce the number of addresses we are consolidating data on bigger volumes. Best regards, Fox -- Kris Buelens, IBM Belgium, VM customer support
How to stop PIPE STARMON
Hello list, I'd like to replace the MONWRITE service we use now with a way to only save selected monitor records to disk. So I use 'PIPE STARMON MONDCSS SHARED | COLLECT' to collect and write selected records to disk. But in order to stop I must issue #CP EXT. I have been testing with other ways to stop STARMON in some way, such as GATE or PIPMOD but so far I am not able to stop the PIPE other than with #CP EXT. I would like to have some way to stop the machine in a more controlled manner with some command like MSG userid STOP or with a secondary console command. Currently we use SECUSER to MONWRITE and then issue MONWSTOP to stop the monwrite machine. According to the doc's I could use GATE or PIPMOD in some way to stop the pipeline and therefore to stop STARMON. And the PIPELINE package also states HMONITOR to stop the STARMON stage. Based on the GATE stage description I coded a pipeline but it still doesn't end. PIPE literal +10 | delay | a: gate strict \ starmon mondcss shared | a: | collect So how would I adjust this to be able to end the STARMON stage? TIA. Berry.
Re: Move multiple minidisks via dirmaint
If you install DFSMS (free feature of VM), you can do massive moves: - with ISPF you can for example request that volume xyz be migrated to some other volume - without ISPF, you get a linemode DFSMS MOVE command to move a single minidisk Both methods internally use the DFSMS COPY command when migrating to same or bigger size minidisks, and DFSMS COPY is much faster than what DIRMAINT uses by default (FORMAT COPYFILE); DFSMS COPY can even outperform DDR. 2008/5/26 Fox Blue [EMAIL PROTECTED]: Dear all, I would like to move multiple minidisks from several userids to another physical volume. I used DIRMAINT CMDISK operator for doing this. However what makes me wondering is, if there is a possibility not to re-specify the size of the respective minidisk. I want only to move the minidisk and not to change the size. To specify t he size can cause mistakes as one has to refere to the DIRMAP in order to en ter this parameter. Is there an easy way such as to specify a '=' or '*' in order to keep t he same size of the minidisk? I didn't find it in the documentation or what would be the best procedure. Thank you very much in advance. Best regards, Fox -- Kris Buelens, IBM Belgium, VM customer support
Re: Backup: Twinning Tapes to Remote Tape Unit
I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup: Twinning Tapes to Remote Tape Unit
Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] duTo Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: Backup: Twinning Tapes to Remote Tape Unit
Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler
Re: Afterthought on Trying to Learn z/Linux ISHELL Scripting
Can you write it up and post it? Sounds great! Shimon Original message Date: Mon, 2 Jun 2008 08:31:02 -0600 From: Jack Woehr [EMAIL PROTECTED] Subject: Afterthought on Trying to Learn z/Linux ISHELL Scripting To: IBMVM@LISTSERV.UARK.EDU Dave Wade wrote: For most UNIX commands (and many other features of UNIX) the man pages are a great reference. Afterthought in a new week: I'd love to give a seminar or webinar sometime on Unix Bull that Every VM Weenie Should Know. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: Getting DMSOPN3362E Imbedded blanks found in file name
Horlick, Michael [EMAIL PROTECTED] wrote: We have an interesting problem. We are using CA-VMLIB and have been getting an error on the VMLIB service machine comme ca: snip DMSOPN3362E Imbedded blanks found in file name Apologies if this has been answered already (I get the list digested). Best guess: some configuration item is empty, code isn't checking for it, so it's trying to read CONFIG A or some such. This is admittedly the geeky way, but here's how I'd diagnose it: cp d 6F4 cp per i rthe address displayed above cmd d u8.12;base1 cp per I rthe address displayed above+x'20 cmd d u8.12;base1 cp set pf12 nodisp b Then start it and hit PF12 each time it stops. When it issues the message, look at the previous item displayed. Hopefully it will make some sense, e.g., R03F3DE80 *VMLIB CONFIG 2*E6 (blank filemode) or some such, or maybe you'll recognize the filename and find that the configuration file entry needs filename AND filemode, or some such. HTH ...phsiii
Re: Backup: Twinning Tapes to Remote Tape Unit
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 8:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: HiperSockets Setup
Terry, What statement did you specify the MTU on - Gateway or Link? And what was the error you got? Peggy Williams z/VM - TCP/IP Development Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] To .hhs.gov IBMVM@LISTSERV.UARK.EDU Sent by: The IBM cc z/VM Operating SystemSubject [EMAIL PROTECTED] Re: HiperSockets Setup ARK.EDU 06/06/2008 09:42 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU Yes, Thanks Alan. In the TCPIP PROFILE I did specify 16K but I received an error so I changed it to 1500 which I new would get around the error. When I did the NETSTAT displays I saw a MFS of 4096 and MTU of 32768. So I guess the question is why did I get the error in the TCPIP PROFILE specifying 16K? Am I missing something? Thanks.. Terry Terry Martin Lockheed Martin - CITIC z/OS Performance and Tuning (410) 786-0386 - Office (443) 632-4191 - Cell [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, June 06, 2008 12:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSockets Setup On Thursday, 06/05/2008 at 05:14 EDT, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: Basically once I got the filename correct and added the PASSWORD for the TCPMAINT 198 disk I was able to get the OBEYFILE command to work. I did receive an error on my first good try. It was balking about the MTU size being invalid. I was using 16384. I changed it to 1500 and tried the OBEYFILE command again and it worked. I noticed on the NETSTAT displays that the MTU actually was 32768 with a Frame Size of 4096. I used a HIPERSOCKETS device that was GENed with CHPARM=40. So basically it did not use the MTU size that I had defined in the PROFILE TCPIP. CHPARM=40 is a MFS of 24K, not 4096. The MTU = MFS - 8K, so the MTU is 16K. (Doc'd in the IOCP book.) Be sure everyone using the same HiperSocket chpid has the same MTU. If you don't, a PING will work, but a large data transfer won't. Alan Altmark z/VM Development IBM Endicott
Re: HiperSockets Setup
Yes, Thanks Alan. In the TCPIP PROFILE I did specify 16K but I received an error so I changed it to 1500 which I new would get around the error. When I did the NETSTAT displays I saw a MFS of 4096 and MTU of 32768. So I guess the question is why did I get the error in the TCPIP PROFILE specifying 16K? Am I missing something? Thanks.. Terry Terry Martin Lockheed Martin - CITIC z/OS Performance and Tuning (410) 786-0386 - Office (443) 632-4191 - Cell [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, June 06, 2008 12:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSockets Setup On Thursday, 06/05/2008 at 05:14 EDT, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: Basically once I got the filename correct and added the PASSWORD for the TCPMAINT 198 disk I was able to get the OBEYFILE command to work. I did receive an error on my first good try. It was balking about the MTU size being invalid. I was using 16384. I changed it to 1500 and tried the OBEYFILE command again and it worked. I noticed on the NETSTAT displays that the MTU actually was 32768 with a Frame Size of 4096. I used a HIPERSOCKETS device that was GENed with CHPARM=40. So basically it did not use the MTU size that I had defined in the PROFILE TCPIP. CHPARM=40 is a MFS of 24K, not 4096. The MTU = MFS - 8K, so the MTU is 16K. (Doc'd in the IOCP book.) Be sure everyone using the same HiperSocket chpid has the same MTU. If you don't, a PING will work, but a large data transfer won't. Alan Altmark z/VM Development IBM Endicott
Re: Backup: Twinning Tapes to Remote Tape Unit
And after having run into the (barely) shorter-output-tape situation after a major, self-induced problem with VM:Backup here (accidentally scratching hundreds of tapes, but of those none from the same twin set), I opened an enhancement request (now called a DAR) with perhaps then Systems Center (been a long time) asking for such a capability It was never implemented. I don't recall any more if it was canned, or still sits there queued in DAR limbo. BTW, someone suggested in this thread the idea of making manual copies after the backup completes, but then only being able to restore them with VMBRITS and VMBSAR. Warning: VMBSAR does not support 3590+ tapes. VM:Backup will happily make physical backups to 3590 tapes, but there's no way to restore them without a running VMBACKUP svm, and access to the VM:Backup catalog containing the physical tape backups. A chicken-and-egg problem. Works for us, but you really need to think of all the aspects to make it work. HiDRO is the alternative which circumvents the lack of 3590 support in VMBSAR. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Mark Wheeler [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/06/2008 08:50 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Backup: Twinning Tapes to Remote Tape Unit
That is a good point that I had not completely thought thru about the tape lengths. So forget about what I said. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 9:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] du To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: IBM LINK Web Site.
Go here: https://www-304.ibm.com/usrsrvc/account/userservices/jsp/login.jsp?persistPage=true and there is a point to register and see if this helps -Original Message- From: Howard Rifkind <[EMAIL PROTECTED]>Sent: Jun 5, 2008 12:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: IBM LINK Web Site. All the organization I've worked for who had mainframes have all had IBMLink access (contracts) Unfortunately we don't have that now and I was wondering if IBMLink has some sort of free access level where you don't need a contract. All I need is to get the latest update for DIRMAINT...and look at the buckets. I there any IBM web site I can go to and register for free access even at a minimal level. Thanks. _LEGALNOTICEUnlessexpresslystatedotherwise,thismessageisconfidentialandmaybeprivileged.Itisintendedfortheaddressee(s)only.AccesstothisE-mailbyanyoneelseisunauthorized.Ifyouarenotanaddressee,anydisclosureorcopyingofthecontentsofthisE-mailoranyactiontaken(ornottaken)inrelianceonitisunauthorizedandmaybeunlawful.Ifyouarenotanaddressee,pleaseinformthesenderimmediately,thendeletethismessageandemptyfromyourtrash. Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We do it and have been doing it for years. Works well. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. Physical tape shipment is scrutinized here. Tapes must either be encrypted or hand-carried by a Bank employee to their destination. We'll probably be moving to an all-VTS environment in a year or two, which makes shipment even more of a problem. When I implemented the remote DR process, I added the capability to fall back to local tapes. After a few years of never using it, I took the code out and we freed up the tape range for something else. If the channel extension is down, the offsite backups just wait for it to come back up. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup: Twinning Tapes to Remote Tape Unit
Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup: Twinning Tapes to Remote Tape Unit
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 10:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? Well, it doesn't really __know__. It does know the approprimate length of the tape from a sense command. The drive knows what type of tape medium is mounted on it. It then estimates how many blocks it should write. The 3490 and later drives will tell, via a sense command, the current block id (this accounts for compression on the drive). When the current block id is greater than the estimate, then the utility does an FEOV to force an end-of-volume switch. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. In fact, our remote site has a VTS for DR backups. Our local backups are still in an STK silo. My comment about tape movement was in context with David's suggestion of a fallback when the channel extension link is down: make a second local backup and send the tapes offsite. A VTS at the DR site doesn't help there. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTS) Sent: Friday, June 06, 2008 08:25 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit Put a VTS in your DR site connected to you as the site for the twin tapes. No movement of tapes now. Physical tape shipment is scrutinized here. Tapes must either be encrypted or hand-carried by a Bank employee to their destination. We'll probably be moving to an all-VTS environment in a year or two, which makes shipment even more of a problem. When I implemented the remote DR process, I added the capability to fall back to local tapes. After a few years of never using it, I took the code out and we freed up the tape range for something else. If the channel extension is down, the offsite backups just wait for it to come back up. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Backup: Twinning Tapes to Remote Tape Unit
There is a round about way of doing this. Fran and I came up with it about 4 years ago. VMBACKUP can backup to DASD. With that, you need to specify the size of a tape file that will exist on disk. Then, you do, in my case, a twin backup specifying a disk file and tape. When the disk file is full, it will start a new disk and a new tape file. I do believe there is a triple option of running a backup against 3 output devices. So this may help with a twin. Anyway, if you are running twin backups from VMBACKUP both copies will be the same size as the smallest media. You shouldn't have a problem there. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Mark Wheeler [EMAIL PROTECTED] 6/6/2008 8:50 AM Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. Not that I'm aware of. Mark Wheeler
Re: Backup: Twinning Tapes to Remote Tape Unit
My enhancement request suggested to writing until EOV, then back up to the beginning of that VM:Backup domain, close the tape (with all the usual EOV, and cross-linked User Header and Trailer Labels), and re-write that domain on the fresh tape. It got more complex when a single domain would not fit on a single tape, but with newer tape technologies that may no longer be a significant problem. Food for fresh thoughts. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Stracka, James (GTS) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/06/2008 10:35 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Backup: Twinning Tapes to Remote Tape Unit Now that is interesting. How does that OS/390 utility know where the EOT reflector is located unless it spins the entire tape first? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Friday, June 06, 2008 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Curiousity question, because I don't know VM:Backup, is there a way to tell VM:Backup to only use n% of a tape? Our z/OS backup utility can be told to do this. If this is possible, then you could fill a tape up to, say, 80% and be fairly confident that the second tape would be long enough to hold that data. This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/ . By messaging with Merrill Lynch you consent to the foregoing. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VSWITCH VLAN-aware not connecting
Alan, here's where we are with your suggestions. 1. I used the HMC OSA Advanced Facilities to validate that the CHPID is enabled, and there are no anomalies. 2. NETSTAT ARP ALL TCP DTCVSW1 reveals that only my two guest IPs are in the ARP cache. The gateway address isn't there. 3. I went through a process of taking Linuxes down, DETACH'd the Vswitch, toggled the CHPID offline, even unplugged the cable, waited 20 minutes, reconnected and rebuilt everything, and still got the same results. 4. Guess we'll have to pursue some hardware support. Dick Alan Altmark [EMAIL PROTECTED] 6/4/2008 3:48 PM On Wednesday, 06/04/2008 at 04:48 EDT, Richard Clapper [EMAIL PROTECTED] wrote: Brian, this all sounds essentially the same as my set up. The TRSOURCE shows packets coming in to DTCVSW1 (my controller), going to Linux, coming back from Linux, going into DTCVSW1, and going out of DTCVSW1 headed for the OSA. Packets do not enter the controller. I would: 1. Use OSA/SF and/or the HMC OSA Facilities to look at the adapter for any anomalies. Since you are (I think) using a Layer 3 VSWITCH, the local IP addresses are registered in the OSA. If, somehow, you caused the gateway address to be registered with the OSA, the packet will go nowhere. 2. Use NETSTAT ARP ALL TCP DTCVSW1 and see if there is anything unexpected. 3. Reset the chpid and try again. 4. If that doesn't work, get a PMR open with OSA support so that they can collect diagnostics. Alan Altmark z/VM Development IBM Endicott The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you.
Re: Afterthought on Trying to Learn z/Linux ISHELL Scripting
Shimon Lebowitz wrote: Can you write it up and post it? Sounds great! In my copious spare time! -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: Afterthought on Trying to Learn z/Linux ISHELL Scripting (tongue in cheek)
I think Eric Thomas got there first when he worked for CERN:- Go to the VM Share Archives at:- http://vm.marist.edu/~vmshare/browse?fn=TOOLKITft=MEMO and search for his append :- Append on 08/26/92 at 11:03 by Eric Thomas [EMAIL PROTECTED]: There is nice tutorial (or is it a rant) on using VI plus some essential information on command naming standards... Dave -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Shimon Lebowitz Sent: 06 June 2008 14:54 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Afterthought on Trying to Learn z/Linux ISHELL Scripting Can you write it up and post it? Sounds great! Shimon Original message Date: Mon, 2 Jun 2008 08:31:02 -0600 From: Jack Woehr [EMAIL PROTECTED] Subject: Afterthought on Trying to Learn z/Linux ISHELL Scripting To: IBMVM@LISTSERV.UARK.EDU Dave Wade wrote: For most UNIX commands (and many other features of UNIX) the man pages are a great reference. Afterthought in a new week: I'd love to give a seminar or webinar sometime on Unix Bull that Every VM Weenie Should Know. -- Jack J. Woehr# Self-delusion is http://www.well.com/~jax # half the battle! http://www.softwoehr.com # - Zippy the Pinhead
Re: Backup: Twinning Tapes to Remote Tape Unit
Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. That's yet another complication for us if were to use twins. We use 9840 (STK high capacity) tapes for our local backups and 3490 (in a VTS) for our remote backups. We'd have to change our local backups to 3490 tapes, and we don't have enough silo slots to do that. A full backup for us is 6 9840 tapes, or 145 virtual tapes. I tested a small backup of 11 3390-3 volumes with twins. It took seven 3490E cartridges, and seven 9840 cartridges. Mark is right, both streams get a new tape when the first one hits EOT, even if they have vastly different capacities. Dennis Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier
2105 config change questions
I've got a 2105-800 coming in to replace a 9393 and 2105-F20. The 9393 needs to be pulled to make room for the 2105-800, so I am squishing what I need from it onto the 2105-F20 for now. The F20 is currently defined with 8 LCU's of 40 3390-9s each, leaving an extra 88,456 cylinders in each LCU. I need some 3390-3s. I'd like to stick them onto the end of LCU7 so that it doesn't trash my addressing, but there is stuff in LCU7 that I need. 1) I can mix 3390-9 and 3390-3 within an LCU, right? 2) When I add volumes to an existing LCU (say 26 3390-3s to the existing 40 3390-9s in LCU7) is it going to nuke the existing 3390-9s? Unfortunately, the data that I _don't_ need is in LCU0-4. I suppose I can deal with it and just readdress it in the IOCP by LCU to make it as painless as possible, but it sure would be nice if I could just tack 26 3390-3s onto the end for a couple days until the 2105-800 is in place.
Re: 2105 config change questions
You can mix any thing with anythingexcept you can't mix ficon and scsi (FCP) on the same LCU. (You can physically LPAR a DS6800 and you can logically LPAR a DS8000). When you add volumes to a LCU, you specify the device number (IOCP translates device numbers to our 390 addresses). I would test adding one device and check the address produced. I always get it confused as on one panel, the number entered is in decimal, and on the other panel, the number entered is in hex. Sometimes it takes a while to find the drive I just created. You are not going to damage any existing volumes. Except when you start deleting the wrong addresses G. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Dave Reinken [EMAIL PROTECTED] 6/6/2008 12:38 PM I've got a 2105-800 coming in to replace a 9393 and 2105-F20. The 9393 needs to be pulled to make room for the 2105-800, so I am squishing what I need from it onto the 2105-F20 for now. The F20 is currently defined with 8 LCU's of 40 3390-9s each, leaving an extra 88,456 cylinders in each LCU. I need some 3390-3s. I'd like to stick them onto the end of LCU7 so that it doesn't trash my addressing, but there is stuff in LCU7 that I need. 1) I can mix 3390-9 and 3390-3 within an LCU, right? 2) When I add volumes to an existing LCU (say 26 3390-3s to the existing 40 3390-9s in LCU7) is it going to nuke the existing 3390-9s? Unfortunately, the data that I _don't_ need is in LCU0-4. I suppose I can deal with it and just readdress it in the IOCP by LCU to make it as painless as possible, but it sure would be nice if I could just tack 26 3390-3s onto the end for a couple days until the 2105-800 is in place.
Re: HiperSockets Setup
Hi Peggy, I specified the MTU on the Gateway statement! The error was DTCPRS051E - Line 24: Invalid Packet Size in Gateway Command: 16384 Thanks.. Terry Terry Martin Lockheed Martin - CITIC z/OS Performance and Tuning (410) 786-0386 - Office (443) 632-4191 - Cell [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Peggy Williams Sent: Friday, June 06, 2008 10:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSockets Setup Terry, What statement did you specify the MTU on - Gateway or Link? And what was the error you got? Peggy Williams z/VM - TCP/IP Development Inactive hide details for Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED]Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/06/2008 09:42 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: HiperSockets Setup Yes, Thanks Alan. In the TCPIP PROFILE I did specify 16K but I received an error so I changed it to 1500 which I new would get around the error. When I did the NETSTAT displays I saw a MFS of 4096 and MTU of 32768. So I guess the question is why did I get the error in the TCPIP PROFILE specifying 16K? Am I missing something? Thanks.. Terry Terry Martin Lockheed Martin - CITIC z/OS Performance and Tuning (410) 786-0386 - Office (443) 632-4191 - Cell [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, June 06, 2008 12:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSockets Setup On Thursday, 06/05/2008 at 05:14 EDT, Martin, Terry R. (CMS/CTR) (CTR) [EMAIL PROTECTED] wrote: Basically once I got the filename correct and added the PASSWORD for the TCPMAINT 198 disk I was able to get the OBEYFILE command to work. I did receive an error on my first good try. It was balking about the MTU size being invalid. I was using 16384. I changed it to 1500 and tried the OBEYFILE command again and it worked. I noticed on the NETSTAT displays that the MTU actually was 32768 with a Frame Size of 4096. I used a HIPERSOCKETS device that was GENed with CHPARM=40. So basically it did not use the MTU size that I had defined in the PROFILE TCPIP. CHPARM=40 is a MFS of 24K, not 4096. The MTU = MFS - 8K, so the MTU is 16K. (Doc'd in the IOCP book.) Be sure everyone using the same HiperSocket chpid has the same MTU. If you don't, a PING will work, but a large data transfer won't. Alan Altmark z/VM Development IBM Endicott
Re: Backup: Twinning Tapes to Remote Tape Unit
Copying tapes is fraught with enough potential issues (many illuminated here) that we are not going to consider it... -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Friday, June 06, 2008 6:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backup: Twinning Tapes to Remote Tape Unit Can't do that, unless you can guarantee that the tapes at the remote site are longer than the local copy (which would be unlikely). When the backup runs, writing to a given pair of tapes ends when the first one hits EOT. You would also need to a complete copy of the tapes, labels and all, because the tapes are chained together with user labels. If you couldn't do that, then the copy utility would have have to be smart enough to generate the user label records according to VM:Backup specs. Since the VMBACKUP catalog wouldn't know about these tapes, any restores would have to be done using VMBRITS or VMBSAR. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Dodds, Jim [EMAIL PROTECTED] du To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Backup: Twinning Tapes to Remote Tape Unit 06/06/2008 08:29 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I think in the case of having to run 2 backups jobs I would run one backup job and then run a utility job to copy the 1st set of tapes to the remote set of tapes. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Llewellyn Sent: Thursday, June 05, 2008 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Backup: Twinning Tapes to Remote Tape Unit Greetings, We are ramping up our Technical Recovery Plan, and intend to use channel- extended tape units at a remote location when performing our regular full and incremental backups. We use CA's VM:BACKUP for file-level backups, and will be using VM:HiDRO to capture the system image. We're curious as to whether any other CA customers are using the synchronous tape twinning feature with one local tape unit and one remote. We've been cautioned by our network folks that the response time from the remote tape unit would be quite a limiting factor affecting the speed of a synchronous, twinned backup. Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. Any anecdotes or insight would be most welcome! Mark Llewellyn VM Systems Support Visa, Inc.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Same here - we are operating on the scenario of our primary data center being destroyed and not coming back. If the offsite copy is a few hours older than the onsite, it's not a show-stopper. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, June 05, 2008 7:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit No one has told us that the two backup runs have to be the same. The DR backups are only used if the primary data center is a pile of rubble. Who cares if they're a few hours older or newer than a set of tapes that is now unusable, and may be irrecoverable? The disaster time is unpredictable. The backup tapes may be 2 hours old or 22 hours old. In either case, the users get what they get. We don't make backups when most of the users are doing their work, but beyond that, it really doesn't matter when they're made. The other advantage of separate onsite and offsite backup jobs is that your onsite backups aren't held up when your channel extension equipment is down. I'm certainly not advocating BLP. I was just pointing out one of the issues with a tape copy solution. Dennis O'Brien Don't worry about biting off more than you can chew. Your mouth is bigger than you think. -- CVW-11 chaplain, Carrier -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, June 05, 2008 18:24 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This concept was considered, but is really last on the list - it's a bit of a mine field. Running two VM:Backup service machines has potential, though, instead of running two backups serially on the same machine. And how...there be dragons, big time. Two VM:Backup runs (even simultaneous runs) have a high probability of being different enough to drive auditors berserk. The system isn't the same as it was with the first set, and you can't stand up and give evidence that the two backups contain the same data, particularly if the system is live during the backup runs. Also, anything that uses BLP tape options is pretty much automatically suspect (and your tape librarians are probably going to get hostile as well -- things like that tend to mess with their worldview of having One True Identifier That Is Immutable In the Whole Enterprise).
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Another option would be a peered VTS. At the moment that's how we're getting all the linux volumes there (although z/OS is doing the dumping and restoring of those w/DFDSS and not us using vm utilities). Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Friday, June 06, 2008 4:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This was actually our first option - remote shadow imaging. The high cost involved and the fundamental requirements of an actual disaster recovery eliminated the proposal. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Friday, June 06, 2008 1:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Thinking laterally about this, there is always another solution. Have you thought about long-distance remote PPRC for your DASD. I am not sure if the official IBM PPRC-XD product can cope with 3000 miles but there are solutions that can. Colin Allinson Amadeus Data Processing GmbH
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Mark Llewellyn wrote on 06/05/2008 03:12:50 PM: Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. The (I/O) performance hit on this might not be as high as you think. If you ran the two backup jobs concurrently (allowed by VM:Backup), the second job (they won't be exactly in sync) can benefit by drafting (for all you NASCAR fans) behind the other through the magic of minidisk caching. In such a scenario, VMBACKUP should probably have OPTION NOMDCFS in its directory definition. This is also assuming that: 1) one job doesn't get too far out of sync with the other (ex remote tape drives much slower than local) 2) you have sufficient storage for MDC, to make it worthwhile as a tradeoff for I/O. That said, I would still avoid this option. Restores will be based (generally) on the last backup in the catalog, which will likely be associated with the slowest-running backup job. Meaning tapes at the remote (aka slowest) location will be used. You could adjust for this (could casual users?), but it would be a PITA. Alternatively, you could configure two VMBACKUP machines (ex VMBACKUP and VMBREMOT), but that wouldn't be pretty either. Best regards, Mark Wheeler, 3M Company
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
We're doing similarly with a Sun/STK peered VTS for VM:Archiver. It creates the duplicate virtual volsers in the other campus without any work by VM:Backup (which does VM:Archiver tape I/O). Makes tape access for D.R. painlessly automatic. VM:Backup tapes are still twinned to external 3590 magStar carts in both data centers because z/OS has primary rights to the dual, peered VTS's. BTW, one thing to consider is dual data centers. It *is* costly to set up, but if you have nearly equal development/test vs production resource requirements, the cost justification becomes much simpler given that there is no D.R. provider cost, and recovery (assuming mirrored DASD) is very, very quick. Our z/VM system is ready for use about 15 minutes after we have the LPAR. The myriad z/OS systems are up in a few hours (DB2 recovery slows that down). Compare that to restore at a D.R. provider - presuming that it's just your data center that's lost. If it's a regional disaster and you're not first to declare the disaster, or the others have a contractual first dibbs - well, it could be 'a while'. Food for thought. Mike Walter Hewitt Associates - Original Message - From: Marcy Cortes [EMAIL PROTECTED] Sent: 06/06/2008 06:44 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Another option would be a peered VTS. At the moment that's how we're getting all the linux volumes there (although z/OS is doing the dumping and restoring of those w/DFDSS and not us using vm utilities). Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Llewellyn, Mark Sent: Friday, June 06, 2008 4:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM:Backup: Twinning Tapes to Remote Tape Unit This was actually our first option - remote shadow imaging. The high cost involved and the fundamental requirements of an actual disaster recovery eliminated the proposal. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Friday, June 06, 2008 1:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Thinking laterally about this, there is always another solution. Have you thought about long-distance remote PPRC for your DASD. I am not sure if the official IBM PPRC-XD product can cope with 3000 miles but there are solutions that can. Colin Allinson Amadeus Data Processing GmbH The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: VM:Backup: Twinning Tapes to Remote Tape Unit
Use of the VM:Tape command exit provides a means to automagically swap the mount command volsers in any order you desire. Works great for us after most operators moved to the remote campus. Now, without swapping onsite and offsite tape vaults, read mounts are swapped to the remote site where tape operators have moved. For D.R. the command exit automatically detects which campus we're running in, and mount the tape at that campus. Cool! Mike Walter Hewitt Associates - Original Message - From: Mark Wheeler [EMAIL PROTECTED] Sent: 06/06/2008 06:48 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM:Backup: Twinning Tapes to Remote Tape Unit Mark Llewellyn wrote on 06/05/2008 03:12:50 PM: Our other option is to simply run two backup jobs, one to the local drive and one to the remote, but that effectively doubles the hit of the backup jobs. The (I/O) performance hit on this might not be as high as you think. If you ran the two backup jobs concurrently (allowed by VM:Backup), the second job (they won't be exactly in sync) can benefit by drafting (for all you NASCAR fans) behind the other through the magic of minidisk caching. In such a scenario, VMBACKUP should probably have OPTION NOMDCFS in its directory definition. This is also assuming that: 1) one job doesn't get too far out of sync with the other (ex remote tape drives much slower than local) 2) you have sufficient storage for MDC, to make it worthwhile as a tradeoff for I/O. That said, I would still avoid this option. Restores will be based (generally) on the last backup in the catalog, which will likely be associated with the slowest-running backup job. Meaning tapes at the remote (aka slowest) location will be used. You could adjust for this (could casual users?), but it would be a PITA. Alternatively, you could configure two VMBACKUP machines (ex VMBACKUP and VMBREMOT), but that wouldn't be pretty either. Best regards, Mark Wheeler, 3M Company The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Tom Burgess/Comag/HearstUK is out of the office.
I will be out of the office starting 07/06/2008 and will not return until 16/06/2008. I will respond to your message when I return. Please consider the environment before deciding to print this email. This email and any attachments are confidential and may be legally privileged or protected by copyright. If you are not the intended recipient of this email you must not act on it, copy it or show it to anyone. If you have received this in error, please notify the sender immediately and then delete this email.The views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the Company unless specifically stated. The Company accepts no responsibility for personal emails, or emails unconnected with the Company's business.This email and any attachments have been scanned for viruses, but it is the responsibility of the recipient to conduct their own security measures and no responsibility is accepted by the Company for the loss or damage arising from the receipt or use of this email. Internet email is not a 100% secure communications medium and you should be aware of this when emailing us. Company Name: Conde Nast and National Magazine Distributors Limited Registered Address: Unit 3, Tavistock Road, West Drayton, Middlesex UB7 7QE Registered in England - Company Number: 01319853
