Re: Disaster Recovery question
We have 1 VM and 20 MVS. At DR site we have a IBM VM used to restore our VM hypervisor. The VM volumes for the hypervisor are the same DASD we used into prod. We say that all the cpowned dasd are absolutely required for our DR VM. (Us, we use Hidro to restore, so the catalog is on a cpowned dasd). We omit TDIS K and PAGE from the backup. They are formated at DR site. The VM in prod sees all the DASD volumes. Before each DDR backup, we exec ute a rexx pipe to create a map of all the rdev with the corresponding volser . The rexx updates all the VM MVS directories. VMIMAGE contains all t he MDISK, all the directories have a link to this userid. At DR site, just after restoring our VM, we IPL it at 1st level. We reexecute our rexx tool which is used to query all the dasd available an d do the fastidious work to map DASD volumes at model level : input is 3380 -3, output is 3380-3 not something else. Then the dasd is labeled. When all this work is done, we execute the restore. We do the mapping address this manner. Because everything was labeled as it was when we were in prod, we never meet a problem when we restore. - We always do our DR on the same site, VTAM and TCPIP configs are hardcoded. The proper config is applied to them by testing the cpuid. - We use vtctc to communicate between the mvs. We used this method for 5 years twice per year. Alain Benveniste Paris, France
Re: Disaster Recovery question
In addition to all the good advice already, I will add: Do not try to run your VM system 2nd level if you have Linux guests. Performance of the Linux guests will be terrible. There are only two levels of hardware virtualization. That leaves your Linux guests being virtualized in software simulation -- which is way slow... Either run your VM in their LPAR, or if you have a small number of guests, just run your Linux machines in their VM. Most DR vendors should know better than recommending VM under VM if you have Linux guests, but Lee Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: Disaster Recovery question
VM is volume id based. (Many years ago, it was not). That being said, VM, when it is IPL'ed, will go and look at all of the dasd that it can touch and find out, among other things, what the volid is. Only if it can't find a volid will inform you. It's up to you how to handle that situation. The DR site will most likely give you the real address of the OSA cards. Depending on how you have yours defined, i.e, DEDICATE statement, etc. you just change the real address on the statement to point to their real address. You leave the virtual address, the address that you apps know it as, alone. To echo your DR site provider recommendations, you do not want to run VM 2nd level in a production or DR situation. Yes, it will run, but not as well as natively. We restore our base system,(about 12 tapes) 2nd level, then IPL that 1st level and start restoring everything else. Steve G. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Karl Kingston Sent: Monday, March 10, 2008 1:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Disaster Recovery question We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks!
Re: Disaster Recovery question
On Tuesday, 03/11/2008 at 10:41 EDT, Lee Stewart [EMAIL PROTECTED] wrote: In addition to all the good advice already, I will add: Do not try to run your VM system 2nd level if you have Linux guests. Performance of the Linux guests will be terrible. There are only two levels of hardware virtualization. That leaves your Linux guests being virtualized in software simulation -- which is way slow... The Interpretive Execution Facility (SIE) is not really simulated so much as there is a pancake effect as the description of the nth level virtual machine is transformed by each layer of CP into a successively smaller SIE descriptor. E.g. 50% of the 3rd-level guest pages appear to be resident, as far as the 2nd-level CP is concerned. But not really. Only half of the 2nd level CP's pages are, in fact, resident. Maybe that means only 25% of the 3rd level guest pages are really resident. Add to that, the 3rd level guest is getting a slice of a slice of the CPU. And, finally, I/O is going through multiple address translations. So if you want to use z/VM only as a thin RDEV translator you need to very specifically size and configure the 1st-level system to do that. This could mean each hosting z/VM LPAR has only a single second-level z/VM, with locked pages, dedicated XSTORE, dedicated CPUs, elongated time slices, and so on. These kinds of thing don't eliminate the pancake effect, of course, but they can help minimize shrinkage (ahem) of the virtual machine as it glides towards the hardware. Alan Altmark z/VM Development IBM Endicott
Disaster Recovery question
We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks!
Re: Disaster Recovery question
Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
You could use the volume serial in any DEDICATE statements in place of the real address (DEDICATE vdev volid or DEDICATE vdev VOLID volid). That could save you from having to make that kind of directory change. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, March 10, 2008 10:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Disaster Recovery question snip Your ATTACHes or DEDICATEs have a virtual address and a real address. You will need to update the real addresses to match your DR config. Leave the virtual addresses alone. Remember, ATTACH and DEDICATE have significantly different syntax: ATTACH rdev vdev DEDICATE vdev rdev Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:52 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You could use the volume serial in any DEDICATE statements in place of the real address (DEDICATE vdev volid or DEDICATE vdev VOLID volid). That could save you from having to make that kind of directory change. Cool. I did not know that. But for OSAs and FCPs, you still need to do the reconfig. Using a VSWITCH instead of dedicating OSAs reduces the effort even further. Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
Right. Not a problem using DEDICATE nn VOLID VOLSER. We also have hipersockets and OSA devices defined with DEDICATE statements. That's where the big question comes into play. How do we handle these. Marcy Cortes [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery question Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
For the TCPIP machines, it's not too difficult. You have an alternate machine or config files and in the dtcparms something like :nick.TCPIPDR :type.server :class.stack :attach.3000-3002 And you can bring up that service machine instead. Or change the system netids to make it something like DRSYS and instead of picking up say PROFILE TCPIP it will pick up DRSYS TCPIP with appropriate DRSYS DTCPARMs. Marcy Cortes Team Lead, http://ehs.homestead.wellsfargo.com/Mainframe/zSS/zSE/zVM-zLinux/Pages/defa ult.aspx Enterprise Virtualization - z/VM and z/Linux Enterprise Hosting Services w. (415) 243-6343 c. (415) 517-0895 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 Karl Kingston Sent: Monday, March 10, 2008 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Right. Not a problem using DEDICATE nn VOLID VOLSER. We also have hipersockets and OSA devices defined with DEDICATE statements. That's where the big question comes into play. How do we handle these. Marcy Cortes [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 01:50 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Disaster Recovery question Ooo, wait. You said Linux devices are DEDICATE. Does that mean DASD too? Do you have duplicate VOLSERS on your system? If not, you can probably change the DEDICATEs to MDISK 000 END and be OK, or if you'd like DEDICATE nnn VOLID VOLXXX ... That'll get you around that use of real addresses. Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Cortes, Marcy D. Sent: Monday, March 10, 2008 10:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Not necessarily. All you really need is SYSTEM NETID based on the CPU of the hotsite that triggers TCPIP to use different config files. We run different OSA addresses and routing configs in our hotsite env (in house, but same concept). (Don't use ATTACH and DEDICATE - have your attach instructs in TCPIPs dtcparm files and you won't have anything to update when you get there :) Marcy Cortes 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Frazier Sent: Monday, March 10, 2008 10:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Disaster Recovery question Unless the hotsite is willing to reconfigure their machine to match your addresses you must run second level. I have never known of a hotsite that will do that. Define a guest on their VM with all the right addresses. Bring your system up second level on that guest. Karl Kingston wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Disaster Recovery question
We do ours via NAT translation in the router. The network people make it transparent to the OS be it z/VM or z/OS. On the systems we maintain the same IP addresses as production. Then when we go to the DR site (which is an internal site) we translate 10.9 to 10.25. Then no need to change anything on the local systems in DR mode. Andy Internet: Mailto:[EMAIL PROTECTED] We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: Disaster Recovery question
On Monday, 03/10/2008 at 01:23 EDT, Karl Kingston [EMAIL PROTECTED] wrote: We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? If you're going to come up 1st level, you will HAVE to make config changes. Your ATTACHes or DEDICATEs have a virtual address and a real address. You will need to update the real addresses to match your DR config. Leave the virtual addresses alone. Remember, ATTACH and DEDICATE have significantly different syntax: ATTACH rdev vdev DEDICATE vdev rdev Alan Altmark z/VM Development IBM Endicott
Re: Disaster Recovery question
Company* * Command format- n/a * * Called by - TCPIP DTCPARMS file on TCPMAINT 198 disk. * * Program Lang. - CMS REXX * * Date Written - 20010626 * * Author- Anon E. Mouse* * Changed | By | Description of Change* * +-+- * * mmdd iii - Added attaching D.R. OSA's at prod addresses * * * / The same code: parse value diag(08,'QUERY USERID') with . . ConfigSysId . '15'x . /* The above is the SYSTEM CONFIG value */ ?home=(ConfigSysId='MYHOMEID')/* --- Change to your nodename */ ?recover=(ConfigSysId='RECOVERY') /* We use this for on-site D.R. */ ?disaster=(ConfigSysId='DISASTER') /* This for off-site D.R. */ can be used by various service machines (maybe AUTOLOG1?) to decide what should be done automatically based on where they are being started. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Karl Kingston [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/10/2008 12:20 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Disaster Recovery question We are in the process of planning our first disaster recovery of our z/VM system. We have access to an LPAR at our DR hotsite. 1) how do I account for differences in OSA addresses, Hipersocket addresses, and DASD addresses?The only DASD ww have that are VM only us the 530RES, 530SPL and 3 page volumes.All other devices are for z/Linux and are dedicated by directory entries. My take was to bring up z/VM 2nd level on the hotsite's floor system and run with that. But they are not recommending it. What can I do to avoid making config changes because of DR? Thanks! 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.
