Re: Long Displacement Facility (was: Fun with RXSBG)
The long-displacement facility has been part of the z/OS architecture level set since z/OS 2.1 (including the "high performance" variant). Mark B wrote: If you need to test a facility bit in the range of 0-31 then use the list of bits stored by the STORE FACILITY LIST instruction, which should have been placed in some common location by the OS you're running on, typically at location x'C8'. If you need to test a facility bit >=32 *and* you might possibly be running on a pre-z9 machine(!) then first test bit 7 of the result stored by STORE FACILITY LIST to see if STFLE is available, and if it is then issue the STFLE instruction (if the output isn't already available somewhere) and test the bit from the list of bits stored. For z/OS, the IPL-time output is "already available somewhere". If you are interested in the IPL-time state of facility bits (which in almost all cases is what you would care about), as opposed to the state "now": * For any bit in the first 256, you can look at the area located by x'C8' (FLCFACL/FLCFACLE in IHAPSA, or FlceFactilitiesList/FlceFacilitiesList1 in IHAPSAE). * For any bit at all you can look at the area mapped by IHAFACL and pointed to by ECVTFACL (you can also use IHAFACL to look at the PSA area, with a little manipulation to account for the header of the area pointed to by ECVTFACL) Peter Relson z/OS Core Technology Design
Re: Long Displacement Facility (was: Fun with RXSBG)
>> IHAFACL uops - I spoke too soon Am 04.03.22 um 19:44 schrieb Philippe Leite: Macro IHAFACL Regards, Philippe Leite LAB Services - IBM
Re: Long Displacement Facility (was: Fun with RXSBG)
and for the VSE people around z/VSE stores facility indications beginning at V=R location 200 (C8 hex), so you don't have to issue these instructions yourself.) and to IBM people supporting this: wouldn't it be nice to have a copy book such that you can simply code: TM my_feature_of_interest,L'my_feature_of_interestis my fav feature installed as it is with the copy-book for ADATA Martin Am 04.03.22 um 19:08 schrieb Dan Greiner: The presence of the facility is indicated facility indication bit 18 (facility installed) and bit 19 (facility installed in hardware) as stored by the STFL and STFLE instructions. (z/OS programmers take note: z/OS stores facility indications beginning at V=R location 200 (C8 hex), so you don't have to issue these instructions yourself.)
Re: Long Displacement Facility (was: Fun with RXSBG)
On 3/4/2022 12:38 PM, Charles Mills wrote: https://www-03.ibm.com/services/supline/products/ExtendedSupport/SystemZ_EOS.pdf would seem to support my assertion that V2R2 is still in extended support, until September 2023. Haha! We don't count the three-year service extensions. We code to announced EOS dates only. By that reckoning: 1. z/OS 2.2 went EOS in September 2020. 2. z/OS 2.3 will go EOS in September 2022. 3. z/OS 2.4 will go EOS in September 2024. 4. z/OS 2.5 will go EOS in September 2026. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
https://www-03.ibm.com/services/supline/products/ExtendedSupport/SystemZ_EOS.pdf would seem to support my assertion that V2R2 is still in extended support, until September 2023. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Friday, March 4, 2022 12:28 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Long Displacement Facility (was: Fun with RXSBG) On 3/4/2022 11:24 AM, Charles Mills wrote: > > ... My rule is to support the > oldest version of z/OS still in extended support, which I believe is > currently V2R2, and the oldest hardware that it supports, which is the z10. The oldest supported OS is currently z/OS 2.3 and the oldest hardware it supports is z12.
Re: Long Displacement Facility (was: Fun with RXSBG)
On 3/4/2022 11:24 AM, Charles Mills wrote: ... My rule is to support the oldest version of z/OS still in extended support, which I believe is currently V2R2, and the oldest hardware that it supports, which is the z10. The oldest supported OS is currently z/OS 2.3 and the oldest hardware it supports is z12. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
Others have well-addressed your central questions. Let me just address this one thing: > if developing software for distribution, > is it best to avoid using the "newer," fancier instructions I have been developing almost exclusively "product" software for distribution to multiple, unknown at the time of development, customers -- for about 50 years, most of it on the 360 and its successors. I used to avoid the "new" instructions (whatever "new" meant at the time). It took me a long time to embrace the S/370 enhancements to the original instruction set. I thought "what if some prospect has an older machine?" I'd hate to lose even one deal. Well, through years of commercial software product development and management I have learned the following: there may be shops out there with ancient hardware. But they are 100% shops that are "getting off the mainframe." (Some may be in the eighth year of a three-year project to get off the mainframe, but that is a different topic, and it has already been hashed to death here.) So they are not your prospects. They are not going to buy your product even if it DOES run on a z900 or whatever. So there is no need to eschew "new" instructions. My rule is to support the oldest version of z/OS still in extended support, which I believe is currently V2R2, and the oldest hardware that it supports, which is the z10. My theory is that any customer that considers the mainframe vital enough to warrant an investment in the product is not running an unsupported OS. So I would use decimal floating point and extended immediates, but eschew vector packed decimal. If you have *extremely* performance-sensitive portions of your code then dual-pathing may be appropriate. FWIW, most of my current development is in C++, and the great thing about compiled languages is that you can just "turn the dial" on the supported hardware. Some customer wants maximal performance and is willing to pay you for it? Do a custom build for them with ARCH(13). Some customer surfaces who is still running a z9? Do a custom build with ARCH(7). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, March 4, 2022 9:01 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Long Displacement Facility (was: Fun with RXSBG) "IBM Mainframe Assembler List" wrote on 03/03/2022 05:22:52 PM: > Not counting any branch following the determination, I had > previously managed to trim this down to three instructions. For > example, to determine if a prospective insertion crosses a 4 K-byte boundary: > 1. LAY S,-1(L,P) where "S" is a scratch register. > 2. XR S,P determine the difference > 3. NILF S,X'F000' Turn off insignificant bits. The second operand of the first instruction in this sequence caught my eye -- having not seen negative displacements -- before but immediately appreciating its applications. So, I first thought I would ask what are the benefits of doing it that way as opposed to the following more traditional approach (other than the obvious of simply "one less instruction")? LAS,0(L,P) AHI S,-1 Secondly... I missed the Y the first time and tried testing the following. That, of course, generated a syntax error (invalid displacement). LAS,-1(L,P) So, I looked at the original email again and did some research into the LAY instruction. That is when I read about the Long Displacement Facility (LDF) having to be installed for this instruction to work (otherwise: operation exception). So, other than just trying it, how would I determine if the box we are on (2818) has the LDF? Further, if developing software for distribution, is it best to avoid using the "newer," fancier instructions and just stick with the more traditional approaches?
Re: Long Displacement Facility (was: Fun with RXSBG)
> What is the macro to generate facility bit EQUs? In TPF, it's IZARCH. For the z/OS macro, I'd have to phone a friend. Actually I just did a Google search and found IHAPSAE, which itself points you to IHAFACL. - mb
Re: Long Displacement Facility (was: Fun with RXSBG)
Macro IHAFACL Regards, Philippe Leite LAB Services - IBM
Re: Long Displacement Facility (was: Fun with RXSBG)
What is the macro to generate facility bit EQUs? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Boonie [boo...@us.ibm.com] Sent: Friday, March 4, 2022 1:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Long Displacement Facility (was: Fun with RXSBG) > I went back and checked: > > > o Long-displacement facility was first documented in SA22-7832-02 > > o STFLE was first documented in SA22-7832-04 If you need to test a facility bit in the range of 0-31 then use the list of bits stored by the STORE FACILITY LIST instruction, which should have been placed in some common location by the OS you're running on, typically at location x'C8'. If you need to test a facility bit >=32 *and* you might possibly be running on a pre-z9 machine(!) then first test bit 7 of the result stored by STORE FACILITY LIST to see if STFLE is available, and if it is then issue the STFLE instruction (if the output isn't already available somewhere) and test the bit from the list of bits stored. (More logic is required to ensure the bit you're checking is actually stored by STFLE; refer to Principles of Operation for details.) - mb -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Friday, March 4, 2022 12:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Long Displacement Facility (was: Fun with RXSBG) On 3/4/2022 9:31 AM, Dave Clark wrote: > "IBM Mainframe Assembler List" wrote on > 03/04/2022 12:19:51 PM: >> IIRC, STFLE is newer than the Long Displacement Facility. LOL > It wouldn't appear so. STFLE is facility 7 and LDF is facility 18. I went back and checked: o Long-displacement facility was first documented in SA22-7832-02 o STFLE was first documented in SA22-7832-04 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1DL9l0sIek3RCGGrMkPCIedAfeUjyQTMmykcYxTTsZ6gfr01W05Ih2_VyC_UUbcy5XKL1CaHxPMVynzWg4_jYc795y5rmZHh7bxX32zvVc5tfBuyYQWP6ZR39WI2TI5fUQ5nadljaJd-dJkOIWyjwWpy-sbWdurenQa-Omhecksk4Jy4rzNPtpQSI0JBJJ39zVQjmvjXnl2k4KVCtxWd_u6IcUYyV8_sn4xudhf3DGtEkfXG7Ks-D3UqMzKEuteu7BGDAlA8tuxnAlf4Zg8jXln1DKyf6wu5zubFCM9pP_eqpDhnvRHY2J9_m96hCCOGX-R6af4kGEPrijPEjPnUNGedAl_IDJEvX62yaKnPzdfhxDo9X8UDhNfp4Vj4b62FjXjwa4aSO8u3FusTCZJvZ-SUv4eJPMCa0L7TQllWykwRUbAxbA5M_goXXlxs5rHwq/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
> I went back and checked: > > > o Long-displacement facility was first documented in SA22-7832-02 > > o STFLE was first documented in SA22-7832-04 If you need to test a facility bit in the range of 0-31 then use the list of bits stored by the STORE FACILITY LIST instruction, which should have been placed in some common location by the OS you're running on, typically at location x'C8'. If you need to test a facility bit >=32 *and* you might possibly be running on a pre-z9 machine(!) then first test bit 7 of the result stored by STORE FACILITY LIST to see if STFLE is available, and if it is then issue the STFLE instruction (if the output isn't already available somewhere) and test the bit from the list of bits stored. (More logic is required to ensure the bit you're checking is actually stored by STFLE; refer to Principles of Operation for details.) - mb -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ed Jaffe Sent: Friday, March 4, 2022 12:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Long Displacement Facility (was: Fun with RXSBG) On 3/4/2022 9:31 AM, Dave Clark wrote: > "IBM Mainframe Assembler List" wrote on > 03/04/2022 12:19:51 PM: >> IIRC, STFLE is newer than the Long Displacement Facility. LOL > It wouldn't appear so. STFLE is facility 7 and LDF is facility 18. I went back and checked: o Long-displacement facility was first documented in SA22-7832-02 o STFLE was first documented in SA22-7832-04 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
The long-displacement facility wasn't in the first z/Architecture machine, but it followed soon thereafter. The first implementation was done in firmware — primarily to allow IBM internal testing of new software. It was implemented in hardware in any z/Architecture machine shipped after June 2003. The presence of the facility is indicated facility indication bit 18 (facility installed) and bit 19 (facility installed in hardware) as stored by the STFL and STFLE instructions. (z/OS programmers take note: z/OS stores facility indications beginning at V=R location 200 (C8 hex), so you don't have to issue these instructions yourself.) Descriptions of newer facilities added to the architecture can be found in Chapter 1 of the PoO. Additional information as to the operation of the long-displacement facility can be found in the discussion of operand-address generation in Chapter 5, programming note 5 on p. 7-9, and elsewhere.
Re: Long Displacement Facility (was: Fun with RXSBG)
On 3/4/2022 9:31 AM, Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 03/04/2022 12:19:51 PM: IIRC, STFLE is newer than the Long Displacement Facility. LOL It wouldn't appear so. STFLE is facility 7 and LDF is facility 18. I went back and checked: o Long-displacement facility was first documented in SA22-7832-02 o STFLE was first documented in SA22-7832-04 -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
If I have to support really old boxen then I encapsulate alternate code sequences in a macro. That approach does require some configuration control if a shop has a mix of old and new. I don't expect to see anybody running production on a box too old to have long displacements. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dave Clark [dlcl...@winsupplyinc.com] Sent: Friday, March 4, 2022 12:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Long Displacement Facility (was: Fun with RXSBG) "IBM Mainframe Assembler List" wrote on 03/03/2022 05:22:52 PM: > Not counting any branch following the determination, I had > previously managed to trim this down to three instructions. For > example, to determine if a prospective insertion crosses a 4 K-byte boundary: > 1. LAY S,-1(L,P) where "S" is a scratch register. > 2. XR S,P determine the difference > 3. NILF S,X'F000' Turn off insignificant bits. The second operand of the first instruction in this sequence caught my eye -- having not seen negative displacements -- before but immediately appreciating its applications. So, I first thought I would ask what are the benefits of doing it that way as opposed to the following more traditional approach (other than the obvious of simply "one less instruction")? LAS,0(L,P) AHI S,-1 Secondly... I missed the Y the first time and tried testing the following. That, of course, generated a syntax error (invalid displacement). LAS,-1(L,P) So, I looked at the original email again and did some research into the LAY instruction. That is when I read about the Long Displacement Facility (LDF) having to be installed for this instruction to work (otherwise: operation exception). So, other than just trying it, how would I determine if the box we are on (2818) has the LDF? Further, if developing software for distribution, is it best to avoid using the "newer," fancier instructions and just stick with the more traditional approaches? Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Long Displacement Facility (was: Fun with RXSBG)
There is another way to test facility bits: We can use field FLCFACL on PSA+x'C8'. Regards, Philippe Leite LAB Services - IBM
Re: Long Displacement Facility (was: Fun with RXSBG)
On 3/4/2022 9:31 AM, Dave Clark wrote: It wouldn't appear so. STFLE is facility 7 and LDF is facility 18. Thanks for the clarification. For the record, I would never, Ever, EVER test the long-displacement facility bit and code two different paths in my code. Doing so would be ridiculous... This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
"IBM Mainframe Assembler List" wrote on 03/04/2022 12:19:51 PM: > IIRC, STFLE is newer than the Long Displacement Facility. LOL It wouldn't appear so. STFLE is facility 7 and LDF is facility 18. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Long Displacement Facility (was: Fun with RXSBG)
IIRC, STFLE is newer than the Long Displacement Facility. LOL On 3/4/2022 9:16 AM, Philippe Leite wrote: -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Long Displacement Facility (was: Fun with RXSBG)
Re: Long Displacement Facility (was: Fun with RXSBG)
"IBM Mainframe Assembler List" wrote on 03/04/2022 12:06:26 PM: > Every other box (z800, z900 GA2, and beyond) > has had this feature standard. There is no reasonable > rationale for not using this 22 year-old facility. Thank you. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Long Displacement Facility (was: Fun with RXSBG)
On 3/4/2022 9:01 AM, Dave Clark wrote: So, I looked at the original email again and did some research into the LAY instruction. That is when I read about the Long Displacement Facility (LDF) having to be installed for this instruction to work (otherwise: operation exception). So, other than just trying it, how would I determine if the box we are on (2818) has the LDF? Further, if developing software for distribution, is it best to avoid using the "newer," fancier instructions and just stick with the more traditional approaches? Every IBM Z box ever produced has the long-displacement facility. The original z900 (2064) from 1999 got it as an RPQ at GA2 and thus it is implemented via millicode. Every other box (z800, z900 GA2, and beyond) has had this feature standard. There is no reasonable rationale for not using this 22 year-old facility. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
