You can LINK to MAINT's 123, 124, and 125 as long as you have not deleted them from the directory after the installation is complete.
I do. Once long ago, some IBM product EXEC (installation or service, I do not remember the details any longer) summarily and without any notice ahead of time LINKed to one of the IBM-provided full-pack minidisks. IIRC it caused some amount of production problems. Once burned, always shy of fires. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Frank M. Ramaekers" <framaek...@ailife.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 09/28/2010 03:07 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice Oh, LINK to MAINT's 123, 124, 125, ... Frank M. Ramaekers Jr. -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Tuesday, September 28, 2010 2:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Applying Maintenance - Best Practice Or, add directory entries for those (and other DASD you wish) to the CP Directory such as: USER -540RES- xxxxxxxx 64M 1G G 64 *UI=Server, Disaster Recovery support GRP=IS * MDISK A00 3390 0000 0001 540RES R MDISK F00 3390 0000 END 540RES R Every DASD we have (other than spares waiting to be allocated) as a userid following that format. Sysprogs can LINK to any of them to perform their work. You could also use CP DEFINE MDISK, but that requires a little more work getting all the privileges and directory options straight. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "George Henke/NYLIC" <george_he...@newyorklife.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 09/28/2010 02:11 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice If I am DDR copying 540RES, 540W01, 540W02 to another set of disks I believe I will need to cprelease the CPOWNED volumes to do the DDR. But that will impact Level 1. I suppose I could invoke DDR outside of CMS to get around this. Mike Walter <mike.wal...@hewitt.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/28/2010 02:36 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice I'm not saying it's perfect mind you, but it has grown over the years and is "just what we need" as sysprogs. YMMV. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. * Prolog; See Epilog for additional information ******************** * Exec Name - DDR EXEC * * Unit Support - OSS/VM * * Status - Version 2, Release 1.0 * ********************************************************************/ address COMMAND parse source xos xct xfn xft xfm xcmd xenvir . parse upper arg parms 1 operands '(' options ')' parmrest parse upper var operands invdev outvdev startcyl endcyl cyls . If invdev='?' then SIGNAL Explain If find(options,3390)>0 then Dtype=3390 else Dtype=3390 If endcyl='FOR' then Do endcyl=startcyl+(cyls-1) cyls='' End If invdev<>'' then /* More to do than just execute DDR MODULE */ Do If outvdev='' then Do say xfn'; Output vdev required if input vdev is' , 'specified.' Call Exit 20 End If startcyl<>'' & endcyl='' then Do say xfn'; Ending cylinder required if Starting cylinder', 'is specified.' Call Exit 20 End /* E.g. CP QUERY VIRTUAL 019E */ /* DASD 019E 3390 VMR51H R/O 500 CYL ON DASD 1953 */ /* SUBCHANNEL = 0007 */ /* */ /* E.g. CP QUERY VIRTUAL 09E6 */ /* DASD 09E7 ON DASD 09E7 R/W VO09E7 SUBCHANNEL = 000C */ parse value diag(08,'QUERY VIRTUAL' invdev) with inreply , 1 . . inDtype involser inrw incyls . . inrdev . parse value diag(08,'QUERY VIRTUAL' outvdev) with outreply , 1 . . outDtype outvolser outrw outcyls . . outrdev . /* e.g. CP QUERY DASD DETAILS rdev */ /* 09E6 CUTYPE = 3990-E9, DEVTYPE = 3390-0A, VOLSER = */ /* VOLSER = VO09E6, CYLS = 3339 */ /* And several more lines of results we don't need. */ If inDtype='ON' then Do parse var inreply . . . . inrdev inrw involser . parse value diag(08,'CP QUERY DASD DETAILS' inrdev) with , . 'DEVTYPE' '=' inDtype'-' . , 'VOLSER' '=' involser . , 'CYLS' '=' incyls . '15'x . End If outDtype='ON' then Do parse var outreply . . . . outrdev outrw outvolser . parse value diag(08,'CP QUERY DASD DETAILS' outrdev) with , . 'DEVTYPE' '=' outDtype'-' . , 'VOLSER' '=' outvolser . , 'CYLS' '=' outcyls . '15'x . End If outrw<>'R/W' then Do say 'Output DASD' outvdev '=' outrw', not = R/W.' Call Exit 20 End If inDtype<>outDtype then Do say xfn'; Input device type =' inDtype say xfn'; or Output device type =' outDtype say xfn'; Input and Output DASD must be the same' , 'device device type.' Call Exit 16 End If endcyl||startcyl<>''then If verify(endcyl||startcyl,0123456789)=0 then copycyls = endcyl-(startcyl+1) Else Do say 'Start and end cylinders are not all numeric:' , '"'startcyl endcyl'".' Call Exit 24 End If incyls<>outcyls & copycyls>outcyls then Do say xfn'; Input device cylinder size:' incyls say xfn'; Output device cylinder size:' outcyls say xfn'; Are not equal.' Call Exit 20 End If startcyl > incyls-1 then Do say xfn'; Starting cyl ('startcyl') is greater than the', 'highest input cylinder ('incyls-1').' Call Exit 24 End If endcyl > incyls-1 then Do say xfn'; Ending cyl ('endcyl') is greater than the', 'highest input cylinder ('incyls-1').' Call Exit 38 End If copycyls > outcyls then Do say xfn'; Number of cylinders requested to copy ('copycyls, ||') greater than output device size ('outcyls').' Call Exit 32 End freemd=freemode() /* Get volsers if possible */ 'PIPE COMMAND ACCESS' invdev freemd If rc=100 then involser='SCRATCH' Else If rc<>0 then involser='' Else Do 'PIPE COMMAND QUERY DISK' freemd , '| DROP 1' , '| SPECS 1.6 1' , '| VAR involser' If involser='INVOLSER' then involser='' End 'PIPE COMMAND RELEASE' freemd 'PIPE COMMAND ACCESS' outvdev freemd If rc=100 then outvolser='SCRATCH' Else If rc<>0 then outvolser='' Else Do 'PIPE COMMAND QUERY DISK' freemd , '| DROP 1' , '| SPECS 1.6 1' , '| VAR outvolser' If involser='OUTVOLSER' then outvolser='' End 'PIPE COMMAND RELEASE' freemd /* See if the real 3390 models are the same size. */ /* If not, DDR wants a 'YES' to go ahead with copy. */ invdev=strip(invdev,'L',0) /* DDR gets fussy */ outvdev=strip(outvdev,'L',0) /* DDR gets fussy */ 'MAKEBUF' /* Buffer for DDR commands */ brc=rc If invdev <>'' & incyls <>'' then queue 'INPUT ' invdev inDtype involser If outvdev <>'' & outcyls <>'' then queue 'OUTPUT' outvdev inDtype outvolser If startcyl<>'' then queue 'COPY' startcyl endcyl 'TO 0' Else queue 'COPY 0' incyls-1 'TO 0' queue '' If incyls > outcyls & , outvol<>'(TEMP)' then queue 'YES' /* Yes DDR, OK to copy to a smaller dev.*/ /* From a triple down is OK, */ /* only from Double down is a problem! */ queue ' ' /* That's all of our EXTENTS, DDR */ queue 'YES' /* We want to overlay this volser */ queue ' ' /* We'd like to wrap things up now, thanks */ End push 'SYSPRINT CONS' 'PIPE (END ? NAME ShowDDRstack)' , '| STACK' , '| fout: FANOUT' , '| STACK' , '? fout:' , '| INSERT /'xfn xft 'stacked for DDR MODULE: / BEFORE' , '| CONSOLE' say time() 'beginning DDR MODULE execution...' 'DDR' ddrrc=rc say time() 'DDR MODULE execution complete, rc='ddrrc If brc<>'BRC' then 'DROPBUF' brc /*We built a buffer for DDR cmds*/ 'PIPE COMMAND RELEASE X' Call Exit ddrrc /********************************************************************/ /* Sub-Routines below this point */ /********************************************************************/ Exit: parse arg exitrc todo If todo='?' then say 'For more help, enter:' xfn '?' If verify(exitrc,'-0123456789')>0 then Exit 999999 Exit exitrc Error: etxt.1='+++ "ERROR:" error rtn entered in:' xfn xft xfm', rc='rc etxt.2='+++ from line:' sigl', which reads:' etxt.3='+++'sourceline(sigl) cmdline=strip(sourceline(sigl),'B') If symbol(value('CMDLINE'))='VAR' /* e.g cmd='CP FAIL'; cmd */ then cmdline=value( value('CMDLINE') ) else cmdline=value('CMDLINE') /* e.g. 'CP FAIL' */ etxt.4='+++ which translates to:' cmdline etxt.0=4 'PIPE STEM etxt. | CONS' Call Exit 20 Syntax: etxt.1='+++ "SYNTAX:" error rtn entered in:' xfn xft xfm', rc='rc etxt.2='+++ from line:' sigl', which reads:' etxt.3='+++'sourceline(sigl) cmdline=strip(sourceline(sigl),'B') cmdline=value('CMDLINE') etxt.4='+++ which translates to:' cmdline etxt.0=4 'PIPE STEM etxt. | CONS' Call Exit 20 NoValue: etxt.1='+++ "NoValue:" error rtn entered in:' xfn xft xfm', rc='rc etxt.2='+++ from line:' sigl', which reads:' etxt.3='+++'sourceline(sigl) etxt.4='+++ Variable with no value is:' condition('Description') etxt.0=4 'PIPE STEM etxt. | CONS' Call Exit 24 Explain: 'PIPE (NAME Explain)' , '| <' xfn xft xfm , '| INSIDE /ExplainBegin:/ /ExplainEnd:/' , '| PREFACE STRLITERAL /'xfn xft xfm 'help.../' , '| CONSOLE' Call Exit 0 /* ExplainBegin: A handy dandy DDR EXEC permits quick copy of MINIDISKs or whole DASD between similar device types. Syntax: +-?------+ >>-DDR--+-invdev-+--outvdev--+-----------------------+---| Options |--->< +-StartCyl-+-EndCyl-----+ +-FOR cyls---+ |Options| |-(-+-----------+-----+-| +-NOVFY-----+-----+ +-NOVERIFY--+-+---+ +-)-+ NOVFY NOVERIFY Do not verify that the input and output vdevs are exactly equal in size (i.e. permit the output to be larger). Usage notes: The input and output vdevs must have been LINKed, ATTACHed, or DEFINEd before the DDR command is executed. Examples: DDR 100 101 <- Copies all cyls of vaddr 100 to 200 DDR f00 100 1501 1510 <- Copies cyls 1501-1510 of F00 to 100 DDR f00 100 1501 FOR 10 <- Copies cyls 1501-1510 of F00 to 100 DDR <- Queues: SYSPRINT CONS and calls DDR ExplainEnd: */ Call Exit 0 /* Epilog *********************************************************** * Function - Quick DDR syntax * * Component of - VM Sysprog's Tool Box * * Command format- See Explain, above. * * Called by - VM Sysprogs * * Dependencies - VM/SP 3 or higher. * * - e.g. LISTFILE, COPYFILE, etc. * * Program Lang. - CMS REXX * * Date Written - Long ago. * * Author - Michael R. Walter * * Changed | By | Description of Change * * --------+-----+------------------------------------------------- * * 20080422 mrw - Add to 'say' commands: xfn'; ...' * * 20091117 mrw - Capture inrdev and outrdev, and * * and incyls and outcyls w/o linking to F00 mdisk * * * ********************************************************************/ "George Henke/NYLIC" <george_he...@newyorklife.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 09/28/2010 01:31 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Applying Maintenance - Best Practice Just wondering if anyone out there has some REXX code to DDR disks so that I can modify Frank's FLASHCOPY EXEC to accommodate DDR. "Frank M. Ramaekers" <framaek...@ailife.com> 09/28/2010 11:54 AM To "George Henke/NYLIC" <george_he...@newyorklife.com> cc Subject RE: Applying Maintenance - Best Practice 1) !.=?? Initializes my global variables (prefixed with !.) to null 2) Yes, and it will IPL (as is), but you will have to FORCE it up (because of SPOOL file that are in-flight 3) Usable (see #2 above). Frank M. Ramaekers Jr. From: George Henke/NYLIC [mailto:george_he...@newyorklife.com] Sent: Tuesday, September 28, 2010 10:44 AM To: Frank M. Ramaekers Subject: RE: Applying Maintenance - Best Practice tyvm, Frank. This is a pretty fancy piece of REXX. I have a few questions. The null (!.="") before the terms. I suppose it is a delimiter to insure no syntax errors. FLASHCOPY: I do not have the hardware to support it. So I am thinking of using DDR to accomplish the same result. Can I DDR from our Level 1 z/VM volumes to our Level 2 "to be" volumes while z/VM is active without impacting our "live" system? Will the resulting copy be usable? It just needs to be iplable, it need not insure integrity of appliation data. "Frank M. Ramaekers" <framaek...@ailife.com> 09/27/2010 12:38 PM To "George Henke/NYLIC" <george_he...@newyorklife.com> cc Subject RE: Applying Maintenance - Best Practice Attached? Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Monday, September 27, 2010 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Applying Maintenance - Best Practice Frank, Your approach is quick and reliable and we would like to implement it here. How can I obtain a copy of your FLASH2ND EXEC? "Frank M. Ramaekers" <framaek...@ailife.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/24/2010 11:02 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice Sure, I?d recommend reviewing the EXEC before using it. There is a small configuration section, which SHOULD be all you need to modify. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Friday, September 24, 2010 9:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Applying Maintenance - Best Practice ty again. May I have a copy of your FLASH2ND EXEC? "Frank M. Ramaekers" <framaek...@ailife.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/24/2010 10:38 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice I think the answer to your question is yes? I assume, that any problem discovered are not insurmountable that they have to be backed out (instead additional fixes may need to be applied). This is correct. From my FLASH2ND EXEC: /*--------------------------------------------------------------------*/ /* FLASH2ND - FLASHCOPYs the 1st level VM DASD */ /* */ /* 1) Verify all flash drives are available (!._rDest variable) */ /* 2) Show a confirmation list of source & destination drives */ /* 3) FLASHCOPY CP_OWNED drives and rename destination drives */ /* 4) Create a copy of current direct and modify for 2nd level */ /* (2USER DIRECT) changing CP_OWNED volumes and updating the */ /* 2nd level directory (Uses F123 as 123 for DIRECTXA). */ /* (This also places a copy of this new directory source on */ /* second level MAINT's 191 disk, this MAINT's F191 disk.) */ /* 5) Modify the SYSTEM CONFIG modfying the CP_OWNED volumes */ /* */ /* Note: This can also be used to make a backup of the system for */ /* quick recovery (this set of DASD is IPL w/o change). */ /*--------------------------------------------------------------------*/ Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Friday, September 24, 2010 9:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Applying Maintenance - Best Practice ty for sharing this. One question though: It is ok to apply the maintenance to the production system, Level 1, your 1st step, as long as you do not run PUT2PROD at that time there? Also I noticed you do not use the SYSTEM CONFIGURATION parm disk fallback, but just point to the FLASH COPIED disks if there is a problem. "Frank M. Ramaekers" <framaek...@ailife.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/24/2010 10:26 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice Here?s what I do: 1) Apply Maintenance to production system 2) Flash production DASD to test packs (using different naming conventions) Actually, I have a REXX program I wrote that not only changes the name, but updates the SYSTEM CONFIG, directory and updates the directory on the test packs. 3) Bring up the 2nd level VM 4) Run PUT2PROD on 2nd level 5) Test 2nd level If satisfied with the testing: 1) Flash production DASD to backup packs (can be the same as the test packs, again using a different naming convention) 2) PUT2PROD on the production system 3) IPL the updated system 4) Any problems, I can immediately IPL the ?backup? system (copy prior to PUT2PROD) Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Friday, September 24, 2010 9:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Applying Maintenance - Best Practice Is there a procedure for applying maintenance selectively such that a full system backup is not necessary beforehand? In other words, save the old CPLOAD and just point to the new CPLOAD at IPL and if need be simply fallback to the old CPLOAD. I know the CF1 Parm Disk backup supports this. But is there a way of applying maintenance so that it hits only a new CPLOAD and not the current CPLOAD. Perhaps the answer is to save the current CPLOAD in the CF1 Parm Disk configuration before applying the maintenance. It is probably not "best practice", but is there such a procedure of avoiding a full system backup before putting on any maintenance, or is that taboo? Marcy Cortes <marcy.d.cor...@wellsfargo.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/23/2010 04:00 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice We put it on 2nd level first. Check that it IPLs, basically... not a lot we can do there. Then our vm test lpar. Make sure everything comes up. Maybe start a Linux there. Then our 2 Linux test/dev lpars, which run lots of servers. Gets a lot of exercise there. Let it cook a few weeks. Roll to the 6 production LPARs, starting usually with the 2 that don't run Linux. Then 2 Linux on a weekend and the other 2 on another weekend. We have the z196 maint with RSU 1002 on all of test dev now (3 lpars). On both a z196 and a z10. All is well, YMMV;) Marcy ________________________________ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of George Henke/NYLIC Sent: Thursday, September 23, 2010 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Applying Maintenance - Best Practice I suppose RSU maintenance gets burned-in at Level 2, whereas COR maintenance goes right in to Level 1. But , what bout PSP COR? Level 1 or Level 2. Scott Rohling <scott.rohl...@gmail.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 09/23/2010 10:58 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice I'd say it depends on the purpose of your 2nd level system. Do what you would normally do when applying maintenance... do you put it on 1st or 2nd level first? If your 2nd level system is meant to be a z/VM 'test' system, then it seems like you're already committed to that level of effort. Scott Rohling On Thu, Sep 23, 2010 at 8:30 AM, George Henke/NYLIC <george_he...@newyorklife.com <mailto:george_he...@newyorklife.com> > wrote: Would you recommend putting this 5.4 zEnterprise compatibility maintenance on at Level 1 or Level 2. We currently have both environments for 5.4. I suppose the quickest and easiest (maybe dirtiest too?) way is just to put it on at Level 1 and fall back to CPOLD if there is a problem. "Best practice" may call for putting it on at Level 2 first, but the nature of the change may not warrant that level of effort. There are, however, 45 or more prereq fixes also going on with these 2 APARs, VM64879 VM64881. Just interested in what everyone thinks. Marcy Cortes <marcy.d.cor...@wellsfargo.com < mailto:marcy.d.cor...@wellsfargo.com> > Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU < mailto:IBMVM@LISTSERV.UARK.EDU> > 09/22/2010 11:01 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU < mailto:IBMVM@LISTSERV.UARK.EDU> > To IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU> cc Subject Re: What is the z/VM 5.4 Compatibility PTF for z196? Also you want to check PSP on IBMLink and look for 2817DEVICE and see what recent stuff is needed for that system type (or whatever one you are installing). ________________________________ From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU < mailto:IBMVM@LISTSERV.UARK.EDU> ] On Behalf Of Bruce Hayden Sent: Wednesday, September 22, 2010 7:27 AM To: IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU> Subject: Re: [IBMVM] What is the z/VM 5.4 Compatibility PTF for z196? Look at the page http://www.vm.ibm.com/service/vmreqze.html for the complete list of z/VM APARS for the zEnterprise. On Wed, Sep 22, 2010 at 10:07 AM, George Henke/NYLIC <george_he...@newyorklife.com> wrote: Marcy, Thank you for this information. Do you happen to know what PTF is needed to run z/VM 5.4 on the z196. We will probably take your advice. We will probably bring up the z196 with 5.4 first and then move 6.1 up to Level 1 afterwards. -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY <http://www.vm.ibm.com/service/vmreqze.html> _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. [attachment "flash2nd.zip" deleted by George Henke/NYLIC] _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. 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. 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. _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com. 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.
