toasters

toasters@lists.teaparty.net

13523 discussions

Start a nNew thread

refund of 3.80
by service＠IRS.gov 21 Jun '06

21 Jun '06

1 0

Out of Office AutoReply: {Spam?} {Virus?} Returned mail: see transcript for details
by James, Alison 21 Jun '06

21 Jun '06

Thank you for your e-mail. I am out of the office on Wednesdays. However, my emails are being monitored so there is no need to resend your email. One of my colleagues will respond if you query is urgent. In all other cases, I will reply to your email as soon as possible when I return on Thursday. Thank you, Alison Alison James Customer Services Executive Benelux and Scandinavia Asia Pacific and Latin America Microfilm Specialist Proquest Information & Learning Barnwell Road Cambridge CB5 8SW United Kingdom Switchboard : +44 (0) 1223 215 512 Direct Dial : +44 (0) 1223 271 238 Facsimile : +44 (0) 1223 215 514 Get the latest news, case studies, technology tips, special offers, and more! You select the subject area. Sign up for a ProQuest enewsletter today at http://www.proquest.co.uk/enews ************************************************************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately by reply and immediately delete this message and any attachments. *************************************************************************************************************************

1 0

Warning: E-mail viruses detected
by MailScanner 21 Jun '06

21 Jun '06

Our e-mail content detector has just been triggered by a message you sent: To: alison.james(a)proquest.co.uk Subject: Returned mail: see transcript for details Date: Wed Jun 21 01:38:03 2006 One or more of the attachments (the entire message, mail.exe, mail1.zip) are on the list of unacceptable attachments for this site and will not have been delivered. Consider renaming the files to avoid this constraint. The virus detector said this about the message: Report: Report: MailScanner: Message contained archive nested too deeply Report: MailScanner: Executable DOS/Windows programs are dangerous in email (mail.exe) -- MailScanner Email Virus Scanner ProQuest Information and Learning Limited www.proquest.co.uk

1 0

Re: Move shelf between fiber loops.
by Tim McCarthy 20 Jun '06

20 Jun '06

The filer reads all disk labels at boot time. No matter what loops the disks are on, the filer will find them and associate them to the appropriate volume. For maximum performance, you could distribute half of your volume disks on one loop and the other half on the second loop. Mark Waddell wrote: > First post on list. > > I have a F760 with 8 FC-9 shelves. Running ONTAP 6.5.2R1. I want to add > one more shelf. I see 8 on a fiber channel is max so I need to first > install a second fiber loop. > > Instead of having 8 shelves on more fiber channel and 1 on the 2nd FC it > seems logical that I should distribute the disks shelves over the two fiber > channels. Question is if I move a disk shelf from one fiber loop to another > will the OS find all the volumes on boot. Or is there something I must do > configuration wise. > > Thanks > mark

1 0

Majordomo results: DELIVERY REPORTS ABOUT YOUR E-MAIL
by Majordomo＠Softimage.COM 20 Jun '06

20 Jun '06

-- >>>> This is a multi-part message in MIME format. **** Command 'this' not recognized. >>>> >>>> ------=_NextPart_000_0005_F84EEA3B.21E2CB35 **** Command '------=_nextpart_000_0005_f84eea3b.21e2cb35' not recognized. >>>> Content-Type: text/plain; charset=us-ascii **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: 7bit **** Command 'content-transfer-encoding:' not recognized. >>>> >>>> ------------------ Virus Warning Message (on softgate2.softimage.com) **** Command '------------------' not recognized. >>>> >>>> Found virus WORM_MYDOOM.BB in file softimage.com.doc .pif (in softimage.com.zip) **** Command 'found' not recognized. >>>> The uncleanable file is deleted. **** Command 'the' not recognized. >>>> >>>> --------------------------------------------------------- **** Command '---------------------------------------------------------' not recognized. >>>> >>>> ------=_NextPart_000_0005_F84EEA3B.21E2CB35 **** Command '------=_nextpart_000_0005_f84eea3b.21e2cb35' not recognized. >>>> Content-Type: text/plain; **** Command 'content-type:' not recognized. >>>> charset=us-ascii **** Command 'charset=us-ascii' not recognized. >>>> Content-Transfer-Encoding: base64 **** Command 'content-transfer-encoding:' not recognized. >>>> X-MIME-Autoconverted: from 8bit to base64 by softgate2.softimage.com id k5KJKMtt004677 **** Command 'x-mime-autoconverted:' not recognized. >>>> >>>> LtGn0ZnjsNr+c+/myeFKqG0ufnGvow0KulmHIqN7OD5gNNJplltr3m6t0FJKjM60q50+VfVg **** Command 'ltgn0znjsnr+c+/myefkqg0ufngvow0kulmhiqn7od5gnnjplltr3m6t0fjkjm60q50+vfvg' not recognized. >>>> zCf6Sq3yQw0KsIVtty5aYU1zvqelVKjmOyVsMe4ytu/tOuBn5yCJQ95R4kZlZcBjrNZn9Imu **** Command 'zcf6sq3yqw0ksivtty5ayu1zvqelvkjmoyvsme4ytu/toubn5ycjq95r4kzlzcbjrnzn9imu' not recognized. >>>> w07XRG137ZH8ZDMly2qaYXt82pfbZqxIiEXXne9xs2/GzePheWhB1C+N+npfVyJ3OGY8/oHA **** Command 'w07xrg137zh8zdmly2qayxt82pfbzqxiiexxne9xs2/gzephewhb1c+n+npfvyj3ogy8/oha' not recognized. >>>> Mb6OMp5HTZc3x6dgcWS1S5KW47iayS2j4UVIdUNjIdlt0ktY7LVs+4WGbLadjHy0KVjdn9S2 **** Command 'mb6omp5htzc3x6dgcws1s5kw47iays2j4uvidunjidlt0kty7lvs+4wgbladjhy0kvjdn9s2' not recognized. >>>> gYPhbkLyk/3emoNSzFS4JMNPd4xuS++NLvSOLlv7KGhKTpta2/Eqz8vuJ6khWOBpvHj+rcSz **** Command 'gyphbklyk/3emonszfs4jmnpd4xus++nlvsollv7kghktpta2/eqz8vuj6khwobpvhj+rcsz' not recognized. >>>> pHeSLZ1UfGWFiSmi/Ygzq2T6jSmbpO6Wda11hIR3+LafmLEyKXzEzUVdeoOP+CaMqd+zviiB **** Command 'pheslz1ufgwfismi/ygzq2t6jsmbpo6wda11hir3+lafmleykxzezuvdeoop+camqd+zviib' not recognized. >>>> qPq9KEnQu/yRalk+2g0K9G5xfLfgl1o60yfIj756RodVhE/QSpJgwb1um1DxnlxMvPmhPqz3 **** Command 'qpq9kenqu/yralk+2g0k9g5xflfgl1o60yfij756rodvhe/qspjgwb1um1dxnlxmvpmhpqz3' not recognized. >>>> DQoh3CJw5SUlU/64ndpi74a8jIWGdZCddnt3a6WVWtbCekOp6Us2lCPqV8DJwbyk4kZhyc7f **** Command 'dqoh3cjw5sulu/64ndpi74a8jiwgdzcddnt3a6wvwtbcekop6us2lcpqv8djwbyk4kzhyc7f' not recognized. >>>> MbaipQ0KzlYupIIyrzxdUbZpQcok8qzHYDhtcb2F35dhvyWbX6q9teC/UaWqjdi0/vFbJnvY **** Command 'mbaipq0kzlyupiiyrzxdubzpqcok8qzhydhtcb2f35dhvywbx6q9tec/uawqjdi0/vfbjnvy' not recognized. >>>> ug0K2CLe7sJPqKOZKqKmi9/sqLOuc0q/Q6ia+nou7Ns2hp+5NbiRaHngWNKiZMvkpLcNCueT **** Command 'ug0k2cle7sjpqkozkqkmi9/sqlouc0q/q6ia+nou7ns2hp+5nbirahngwnkizmvkplcncuet' not recognized. >>>> znFUTYpdoyOcnufDqJrJz8nURvnnpkUNCphkLjq4Ot3VOkFMeZCF6PtBxnMmaPiBODXE/GJr **** Command 'znfutypdoyocnufdqjrjz8nurvnnpkuncphkljq4ot3vokfmezcf6ptbxnmmapibodxe/gjr' not recognized. >>>> oEzgTDDK12LVS6/WTdLwlEG9fqBD6FaMwYujDQpBzI3gIA0K5UxU0mfJ4y7C5CZMkzNRW9vl **** Command 'oezgtddk12lvs6/wtdlwleg9fqbd6famwyujdqpbzi3gia0k5uxu0mfj4y7c5czmkznrw9vl' not recognized. >>>> vP0zyK9CJC6mUzbl3EL238+Bc7DCaMSDYWZlh7koMlkxgZCea7s3QrGG1qnvJUFMwXPoMOby **** Command 'vp0zyk9cjc6muzbl3el238+bc7dcamsdywzlh7komlkxgzcea7s3qrgg1qnvjufmwxpomoby' not recognized. >>>> t8Qj7MBTUSdw9/qt5rdYlDgNCtDx6oLpq5Ny+IWb17igjcjncw0K+vLy8muHxLbINo53neRU **** Command 't8qj7mbtusdw9/qt5rdyldgnctdx6olpq5ny+iwb17igjcjncw0k+vly8muhxlbino53neru' not recognized. >>>> ZoopcaLA0WJQd0RTu36yUEugsqu5XTLMnGMhszr1ud7w5jIiZbq8P6pj1IS3+y1zT/F0rKha **** Command 'zoopcala0wjqd0rtu36yueugsqu5xtlmngmhszr1ud7w5jiizbq8p6pj1is3+y1zt/f0rkha' not recognized. >>>> XFWj8jOLYDLmo314rpzkpbfRdTJC4Z707qLEqGHqeF41Jn78edNOuy6bMn02MrSF20hKM4Pv **** Command 'xfwj8jolydlmo314rpzkpbfrdtjc4z707qleqghqef41jn78ednouy6bmn02mrsf20hkm4pv' not recognized. >>>> nW06fLmbrZvESSckO2Slh2tRypEnMsMxZNA/KdjjRUjQ6irpSUU5wzwtPsIl2quZr3HX6Hmc **** Command 'nw06flmbrzvesscko2slh2trypenmsmxzna/kdjjrujq6irpsuu5wzwtpsil2quzr3hx6hmc' not recognized. >>>> vIT6eGn0++bQIr71Q7Jom0F1JN3vPGA7kNd6zP1zkdm0yJpWpSXAn8mzRSdSMNxWxju8jsT4 **** Command 'vit6egn0++bqir71q7jom0f1jn3vpga7knd6zp1zkdm0yjpwpsxan8mzrsdsmnxwxju8jst4' not recognized. >>>> 0jJ0TSyvqpzI/q1Q7XZC2a9vpfhVNw0KNPopaT92JsWjYjLRnkXOUrXHM8zY1l3m8kNsXuL0 **** Command '0jj0tsyvqpzi/q1q7xzc2a9vpfhvnw0knpopat92jswjyjlrnkxourxhm8zy1l3m8knsxul0' not recognized. >>>> arn0mYrKW/EpZ+FVT8iaxI4wgtLt/EZL5rk5w5/jjEzc2GdC1pW15Mk8o9d1kiWhoIJxL5KY **** Command 'arn0myrkw/epz+fvt8iaxi4wgtlt/ezl5rk5w5/jjezc2gdc1pw15mk8o9d1kiwhoijxl5ky' not recognized. >>>> gVCXh5Y4gQ0Ko7D+I2iIjqTcMfmCOU5qXaL8Pi+hLnmiTem1gtiMPm2sj1CBa+PPuCWQMfRX **** Command 'gvcxh5y4gq0ko7d+i2iijqtcmfmcou5qxal8pi+hlnmitem1gtimpm2sj1cba+ppucwqmfrx' not recognized. >>>> kE+6kkT2DQpjZGAko9bf5t122Mt47McNCtOEZW7L2tZwPNFy9+G+psbqpktr3WDlS+63hzyh **** Command 'ke+6kkt2dqpjzgako9bf5t122mt47mcnctoezw7l2tzwpnfy9+g+psbqpktr3wdls+63hzyh' not recognized. >>>> 2JN7IJVIbs31JW3NY+Dj6Ov0IOvAhj+N5aLtyeBOT36H5PabZlo3/W05qFPxQ6C3fFslWK+B **** Command '2jn7ijvibs31jw3ny+dj6ov0iovahj+n5altyebot36h5pabzlo3/w05qfpxq6c3ffslwk+b' not recognized. >>>> y6qVekpfkOGC6HOsKvzZ9UXW+SbLkereciEy/V2HW3KB4Q0KOJ2tZ8qMZLm2/kqdoDZeNfg7 **** Command 'y6qvekpfkogc6hoskvzz9uxw+sblkereciey/v2hw3kb4q0koj2tz8qmzlm2/kqdodzenfg7' not recognized. >>>> rC1epJtMSHViLoPISvmsecleitzJ/N9IdNqjwsGMceGxaOdVe/bf3sxCzqNM/Tm5YzCKTD+5 **** Command 'rc1epjtmshvilopisvmsecleitzj/n9idnqjwsgmcegxaodve/bf3sxczqnm/tm5yzcktd+5' not recognized. >>>> 2OJM3fim2dbr26ebyVlW3d7P/mUqPqmN4XnVxOyr9Gvv5b+zh5TLp/inpydD+bAhWmmq2Slo **** Command '2ojm3fim2dbr26ebyvlw3d7p/muqpqmn4xnvxoyr9gvv5b+zh5tlp/inpydd+bahwmmq2slo' not recognized. >>>> +Y3TeG6yIODiz3Ni7af7rkacMPvFVO5oLe1wX4TKe1l9T9QNCjBJk3JF2T6fDQrjm2k6NS2Y **** Command '+y3teg6yiodiz3ni7af7rkacmpvfvo5ole1wx4tke1l9t9qncjbjk3jf2t6fdqrjm2k6ns2y' not recognized. >>>> X/7MaJaRmq/TKpZLreNRsNWPaU9ZoP61Q/f9+3uxXt+rzur5scCtc6LExrRNNtwuY+INCpan **** Command 'x/7majarmq/tkpzlrenrsnwpau9zop61q/f9+3uxxt+rzur5scctc6lexrrnntwuy+incpan' not recognized. >>>> h1ukX/Ob6kn3j7tNP0JErM0NCvSWWs2bPNC5zSENCrJ4TcSUr3hx67Na1kN9tsomNf5nrSfh **** Command 'h1ukx/ob6kn3j7tnp0jerm0ncvswws2bpnc5zsencrj4tcsur3hx67na1kn9tsomnf5nrsfh' not recognized. >>>> nvwkJz6DlE9sTiWjgmDHRzokKUky6aiTOfrN97DR9Luez2bH48DNYmwppOpncEiTflnizqNU **** Command 'nvwkjz6dle9stiwjgmdhrzokkuky6aitofrn97dr9luez2bh48dnymwppopnceitflnizqnu' not recognized. >>>> ysjDqal9xXBRP4FUxDNHaYdY3JOYiZiZKZ/02LFWu+7J+0HbRzRqfoL6hetiVOUipmAg8615 **** Command 'ysjdqal9xxbrp4fuxdnhaydy3joyizizkz/02lfwu+7j+0hbrzrqfol6hetivouipmag8615' not recognized. >>>> iEVf/I5Ca+hYKl8mkFAvqqEsINn9dkOSQjRSdd2JY5TDvEivdGS0j/E3m121uXt9v1vxZ9OE **** Command 'ievf/i5ca+hykl8mkfavqqesinn9dkosqjrsdd2jy5tdveivdgs0j/e3m121uxt9v1vxz9oe' not recognized. >>>> iMxnrcdJStfkqeUpoe9FznRJ0K8qZGi9IZ32af1XYPU1Lg0KDQo= **** Command 'imxnrcdjstfkqeupoe9fznrj0k8qzgi9iz32af1xypu1lg0kdqo=' not recognized. >>>> ------=_NextPart_000_0005_F84EEA3B.21E2CB35 **** Command '------=_nextpart_000_0005_f84eea3b.21e2cb35' not recognized. >>>> Content-Type: text/plain; charset=us-ascii **** Command 'content-type:' not recognized. >>>> Content-Transfer-Encoding: 7bit **** Command 'content-transfer-encoding:' not recognized. >>>> >>>> >>>> ------------------ Virus Warning Message (on softgate2.softimage.com) **** Command '------------------' not recognized. >>>> >>>> softimage.com.zip is removed from here because it contains a virus. **** Command 'softimage.com.zip' not recognized. >>>> >>>> --------------------------------------------------------- **** Command '---------------------------------------------------------' not recognized. >>>> ------=_NextPart_000_0005_F84EEA3B.21E2CB35-- **** Command '------=_nextpart_000_0005_f84eea3b.21e2cb35--' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)Softimage.COM: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)Softimage.COM. This is version 1.94.4 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)Softimage.COM". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)Softimage.COM: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)Softimage.COM. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)Softimage.COM: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)Softimage.COM to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)Softimage.COM: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)Softimage.COM. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)Softimage.COM. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)Softimage.COM, you would send mail to demo-list-approval(a)Softimage.COM. To get another copy of this help message, send mail to Majordomo(a)Softimage.COM with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)Softimage.COM". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)Softimage.COM".

1 0

rep
by Susan Bryan 20 Jun '06

20 Jun '06

Hello, My name is Susan Bryan,I am an artist together with my husband Anthony Bryan,We are the Owners of Prima Art Works in London(United Kingdon)Ilive in London United Kingdom,with my two kids,our cat and dog, and the love of my life my husband Anthony Bryan. It is definitely a full house, I have been doing artworks since I was a small child That gives me about 23 years of experience I majored in art in higher school and took a few college art courses Most of my work is done in either pencil or airbrush mixed with colored pencils. I have recently added designing and creating artwork on the computer. I have been selling my arts for the last 3 years and have had my work featured on trading cards, prints and in magazines,I have sold in galleries and to private collectors from all around the world.I am always facing serious difficulties when it comes to selling my art works to americans,they are always offering to pay with MONEY ORDER,which is difficult for me to cash herein London United Kingdom. I am looking for a reliable representative in the states who will be working for us on partime basis and i will be willing to pay 10% for every transaction,which wouldnt affect your present job,someone who would help me recieve payments from my customers in the states,i mean someonethat is responsible and reliable because the cost of coming to the states and getting payments is very expensive and time consuming,i am working on setting up a branch in the states for now i need a representative in the united states who will be handling the payment aspect for our company untill we are able to set up a USA branch. These payments are in money order and they would come to you in your name if you are willing to assist as a representative, all you need to do is cash the money order, deduct your percentage and Western Union Charges then wire the rest back to us in the UK. But the problem i have is trust,even though i have my way of getting anyone that tries to get away with our money,i mean the FBI branch in Washington gets involved. It wouldnt cost youany amount,you are to receive payments which will be sent to you by fedex or upsfrom my business partners, which will come in form of money order or cashier check then u are to cash it and send the cash to me via Western Union or Money Gram. NOTE:All charges will be deducted from the money sent to you.you are therefore rest assured that you wouldnt send a dime out of your personal money. If you are interested,please get back to me by sending the following to my private e-mail address at prima_art(a)excite.com 1.Full Name 2.Home Address 3.Mobile and Home Phone Number Regards Susan Bryan. ______________________________________ Přátelství, flirt nebo láska? Seznamte se! TISCALI Seznamka. http://seznamka.tiscali.cz

1 0

YOUR URGENT RESPONSE IS NEEDED
by Jennifer Leary 20 Jun '06

20 Jun '06

FROM: Sgt. Jennifer Leary To whom it may concern. I am an American soldier, I am serving in the military of the 1st Armored Division in Iraq, as you know we are being attacked by insurgents everyday and car bombs. We managed to move funds belonging to Saddam Hussein's family. The total amount is US$7.2Million dollars in cash, mostly 100 dollar bills. We want to move this money to you, so that you may invest it for us and keep our share for banking.We will take 60%, my partner and I. You take the other 40%. No strings attached, just help us move it out of Iraq, Iraq is a war zone. We plan on using diplomatic courier and shipping the money out in one large silver box, using diplomatic immunity. If you are interested I will send you the full details, my job is to find a good partner that we can trust and that will assist us. Can I trust you? When you receive this letter, kindly send me an e-mail signifying your interest including your most confidential telephone/fax numbers for quick communication also your contact details. This business is risk free. The box can be shipped out in 48hrs. Respectfully, Sgt. Jennifer Leary Private Email: jenniferleary25(a)aim.com SPANISH LANGUAGE DE: Sgt. Jennifer Leary A quien pueda interesar. Soy soldado americano, Estoy desempen'ando servicios en los militares del Primero División armada en Iraq, como usted sabe cerca nos están atacando insurrectos diarios y bombas de coche. Manejamos mover los fondos que pertenecían a la familia de Saddam Hussein. la cantidad total es dólares de US$7.2Million en efectivo, sobre todo 100 cuentas de dólar. Deseamos mover este dinero a usted, de modo que usted pueda invertirlo para nosotros y guarde nuestra parte para las actividades bancarias.Tomaremos el 60%, mi socio y yo. Usted toma el otro 40%. Ningunas secuencias unidas, justo ayúdenos a moverlo de Iraq, Iraq es una zona de la guerra. Planeamos en usar el mensajero diplomático y enviar el dinero hacia fuera en una caja de plata grande, usar inmunidad diplomática. Si usted soy interesado le enviaré los detalles completos, mi trabajo está al hallazgo a buen socio a que podemos confiar en y que nos asistirá. ¿Puedo confiarle en? Cuando usted recibe esta letra, amablemente envíeme significar del E-mail su interés incluyendo su teléfono más confidencial números de fax para comunicación rápida también sus detalles del contacto. Este negocio es riesgo libremente. La caja se puede enviar hacia fuera en 48hrs. Respetuosamente, Sgt. Jennifer Leary Email Privado: jenniferleary25(a)aim.com FRENCH LANGUAGE DE : Sgt. Jennifer Leary À qui de droit. Je suis un soldat américain, Je sers dans les militaires du 1er Division blindée en Irak, comme vous savez nous sommes attaqués près insurgés journaliers et bombes de voiture. Nous sommes parvenus à déplacer des fonds appartenant à la famille de Saddam Hussein. le montant total est des dollars d'USS7.2Million comptant, la plupart du temps 100 billets d'un dollar. Nous voulons déplacer cet argent à vous, de sorte que vous puissiez l'investir pour nous et gardez notre part pour des opérations bancaires.Nous prendrons 60%, mon associé et I. Vous prenez l'autre 40%. Aucunes cordes jointes, juste aidez-nous à le déplacer hors de l'Irak, L'Irak est une zone de guerre. Nous projetons sur employer le courier diplomatique et l'expédition l'argent dehors dans une grande boîte argentée, employer l'immunité diplomatique. Si vous suis intéressé je vous enverrai les détails complets, mon travail est à la trouvaille a bon associé au lequel nous pouvons faire confiance et qui nous aidera. Est-ce que je peux vous faire confiance ? Quand vous recevez cette lettre, nous vous saurions gré de m'envoyer signifier de E-mail votre intérêt comprenant votre téléphone plus confidentielnuméros de fax pour communication rapide aussi vos détails de contact. Ces affaires sont risque librement. La boîte peut être embarquée dehors dans 48hrs. Avec respect, Sgt. Jennifer Leary Email Privé : jenniferleary25(a)aim.com

1 0

RE: moving a flex vol to a new aggr ?
by Fox, Adam 20 Jun '06

20 Jun '06

Okay, I get what you are asking. It's a bit hairy, but I get why you'd want to do it. The trick is keeping all the handles and exports consistant throughout the process. It's worth calling in and filing an RFE. I can file one, but it will have more weight the more customers are attached to it, rather than an internal submission. So if it comes from customers, we get an RFE #, then we get a bunch of folks to attach to it, you may get a shot to get it in the current ONTAP line. No promises, though. I can't speak for Engineering. Of course, the newly released ONTAP GX does this plus more. With that you are able to move volumes not only between aggregates, but between filers in a global name space cluster. Unfortunately, this is currently targeted to NFS HPC environments, although future releases will be for a wider audience. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Tuesday, June 20, 2006 10:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by Glenn Dekhayser 20 Jun '06

20 Jun '06

If you want that control, and I agree that some circumstances and desires warrant that, then the manual process is great if your application is allowed to be brought down. But the process of doing that can sometimes kill an SLA, especially if policies of the business demand that, say, the page file be wiped upon host system shutdown- a process that takes forEVER. Some systems simply don't have the luxury of downtime. I'm sure there are other ways of accomplishing the uptime for the server, but an automated process that is transparent to the application is a great example of a benefit of storage virtualization- accomplishing all tasks at the storage layer of the infrastructure without any work or knowledge of the operation at the host layer. It's a religion thing. ;) If you've ever experienced the rush of Vmotion, which moves virtual servers from one physical device to another with no interruption of service, you know what I mean. I understand that GX alreadyu has a functionality like this....I'd like to see it in regular ONTap! Glenn (the other one) -----Original Message----- From: Callaway, Michael [mailto:Mcallaway@ntta.org] Sent: Tuesday, June 20, 2006 11:06 AM To: Glenn Dekhayser; Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? This is easily accomplished with what Glen wrote. I know I would rather have control of the copy of data, make sure it's over there and then to a one-time reconnect of the lun than just start the process up and have it complete without me knowing. SnapMirror accomplishes this move pretty easily, and while the data is live. When you look at it, whether your data is on 1 head or separate head, it doesn't matter. The point is your data is on separate disks and you are going to have to copy it over one block at a time. Moving your "enterprise" data of a few terabytes is not something you should be taking lightly. Which is why I don't mind the SnapMirror, update, quiesce, break. You are in control of the move and most importantly, you decide when your data is in and your lun can be re-homed. Thanks, Michael Server Administrator NTTA/IT 214-461-2033 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Tuesday, June 20, 2006 9:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

RE: moving a flex vol to a new aggr ?
by Callaway, Michael 20 Jun '06

20 Jun '06

This is easily accomplished with what Glen wrote. I know I would rather have control of the copy of data, make sure it's over there and then to a one-time reconnect of the lun than just start the process up and have it complete without me knowing. SnapMirror accomplishes this move pretty easily, and while the data is live. When you look at it, whether your data is on 1 head or separate head, it doesn't matter. The point is your data is on separate disks and you are going to have to copy it over one block at a time. Moving your "enterprise" data of a few terabytes is not something you should be taking lightly. Which is why I don't mind the SnapMirror, update, quiesce, break. You are in control of the move and most importantly, you decide when your data is in and your lun can be re-homed. Thanks, Michael Server Administrator NTTA/IT 214-461-2033 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Tuesday, June 20, 2006 9:11 AM To: Carl Howell; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would think that this would be a fairly common need, especially for larger shops with big Netapps. Given the new 6000 series that can have thousands of drives, and that different volumes (especially ones containing luns) have vastly different I/O requirements, you would definitely want to be able to transparently move a flexvol from a smaller aggregate with fewer available iops to a larger aggregate where the flexvol can benefit from more or different RPM spindles. Currently this operation requires unacceptable levels of application downtime for a 24/7 global enterprise. One can extend this feature by having multiple filers communicate with one another, handing off FC/iSCSI target responsibility for migrated luns to another head altogether. This of course would be trickier and require coordination with the host initiator, but hey, isn't that why we have SnapDrive? :) Within a single filer head I would imagine this would not be required. Across heads it would. I smell a great RFE! Glenn (the other one). -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Tuesday, June 20, 2006 9:57 AM To: Glenn Dekhayser; toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What Glenn is suggesting below is what I'm looking for. We have quite a few FlexVol's that live in FC aggregates today that I would like to move to SATA aggregates and don't want to have to SnapMirror or copy them to get it done. - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, June 19, 2006 9:08 PM To: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I would have imagined is something like VMWare's Vmotion, which moves an entire system from one physical system to another. Since the aggregates are on the same system, we wouldn't have the issue of snapmirror making a 'new' volume. The process would be as such: 1) Make baseline copy to new volume on new aggregate with separate name (snapshot will suffice); 2) Do a once/min snapshot until lag < 60 sec. 3) Change to a semi-sync snapmirror 4) Change to a sync mirror 5) Once in sync, in the OS 'swap' the handles for the primary and mirror volumes (since they are in effect the same data now) so that data is now served from the mirror. 6) Once swap is complete, break the mirror and (optionally) remove the old volume. I think this is what everyone wants! Heck, combine this with FlexShare and you've got automatic load balancing! Glenn (the other one) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Monday, June 19, 2006 8:00 PM To: John Clear; Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Err...I would have thought syncmirror would have been the way to go in that case I'd rather manually move the connections anyway rather than rely on an automated process And I'd especially not like to see the old copy getting deleted before I've had a chance to make sure the customers are happy -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Clear Sent: Tuesday, 20 June 2006 9:06 AM To: Fox, Adam; Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? What I'd like to see is a way to move a live volume between aggregates. This would be especially useful on my R200s, since the aggregates and volumes are quite large. Ideally, something like 'vol move volname aggr0 aggr1' would move the volume without any interruptions on the client side. My understanding is that vol copy takes a snapshot, and then transfers that, which means any changes that occur after the copy is started are not transferred. The only way around that is to make sure the volume isn't mounted/accessed, which is often an unacceptable amount of down time. Between snapmirror and vol clone/copy, the code to do this appears to be mostly there already. The only piece missing is doing the live cutover between the old volume and new volume. John -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Fox, Adam Sent: Monday, June 19, 2006 8:43 AM To: Carl Howell; Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? Perhaps the toaster community could better define what you want from a proposed vol move command that you aren't getting currently from vol copy? -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Carl Howell [mailto:chowell@uwf.edu] Sent: Monday, June 19, 2006 9:35 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: RE: moving a flex vol to a new aggr ? I would like to see a move operation added to the vol command. Does anyone know if this will ever be available? Thanks, - Carl -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Thursday, June 15, 2006 12:23 AM To: toasters(a)mathworks.com Subject: moving a flex vol to a new aggr ? hey all i need to move a flex vol from one aggregate to another aggregate on the same filer is there a really simple command like vol move <volname> aggr1 aggr2 if not what would be the easiest way to move the flex vol to a new aggregate? vol copy ? thanks gw -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters