Re: Larger CMS Disk

[Les Koehler]

That's not quite the way I remember it. If the file doesn't 
fit in one block, then the first block contains a list of 
pointers to the blocks that make up the file, if all the 
pointers fit in one block. If they don't fit in one block, 
then the first block contains a list of pointers that 
contain another list of pointers to the file blocks. Also, 
I seem to recall that the FST for a recfm V file contains 
the first and last record number of the file, thus 
improving random access.


What you describe sounds like the old 800 byte block 
variable record format.


Like yourself however, this is without reference to any 
manuals!


Les

Mike Walter wrote:
PS, 

As Sue Farrell related in a previous post, if you have the PTF for APAR 
VM64513 applied you may not be subject to that lengthy delay as we are 
with one system still running z/VM 5.1


But to answer the question as best I can from memory.  DISCLAIMER: I'm not 
in the office today, so the exact details may be "slightly off" - just 
like me.  The general method should be pretty close, experts can correct 
the details if it's too far off. 

ECDK files have an entry in the File Status Table which resides on that 
MDISK.  The FST, along with other information contained therein, points to 
the first block of each file.  Each file block is chained by a pointer to 
the next block.  Erasing the file just turns off the pointer in the FST to 
the first file block (similar to Windows' FAT filesystem).  There's more 
to the ECKD filesystem than that, but the main point here is the speed of 
clearing a single pointer inside the already-in-storage FST.


In SFS, the SFS server manages a catalog mdisk.  That catalog has a 
pointer to every 4K block in the filepool.  When a (large or small) is 
erases, the block pointer for every file needs to be cleared, and IIRC, a 
bit in every block that the made up the block.   Without looking at the 
PTF, perhaps something in that process was updated to speed things up, 
just guessing.


Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.



"P S"  


Sent by: "The IBM z/VM Operating System" 
12/22/2009 01:49 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Larger CMS Disk






On Tue, Dec 22, 2009 at 2:45 PM, Mike Walter  
wrote:

The problem with bigger on SFS is that it is on SFS.

Try writing, say, a big honking (historically for CMS, but NOTHING to
Linux) 12G file into SFS.  No problem - writes are a little slower than to
a minidisk, but not enough to complain about (unless, perhaps, many others
are trying to do the same thing using the same SFS server!).

But when you erase that 12G file, SFS takes almost "forever".  Unlike an
ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS
has to go though each of the 4K blocks that constitute the file, turning
off its allocation bit.  For a large file that can take 15+ minutes (in
the case of one 12G file we were working with).  And CPU utilization due
to the server pretty much peaks out during that time, too.  The exact
details may be slightly off in that example, but the observable effect is
pretty accurate.

Even one of the original SFS authors, Scott Nettleship, said repeatedly of
SFS: "If you want minidisk performance, use minidisks".

Not understanding something: writing the file has to write each of the 4K 
blocks too. Are you saying that the ERASE is slower than the WRITE? Or 
just that while it feels reasonable for the original WRITE to take a 
while, the fact that the ERASE is so slow is anomalous? 




The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. 

Re: Larger CMS Disk

[David Boyes]

On 12/23/09 10:11 AM, "Mike Walter"  wrote:


> In SFS, the SFS server manages a catalog mdisk.  That catalog has a pointer to
> every 4K block in the filepool.  When a (large or small) is erases, the block
> pointer for every file needs to be cleared, and IIRC, a bit in every block
> that the made up the block.   Without looking at the PTF, perhaps something in
> that process was updated to speed things up, just guessing.

Don't forget also that SFS has to manage a APPC connection and a dispatch of
another virtual machine involved. Much longer code path for similar
operations. 

Re: Larger CMS Disk

[Suleiman Shahin]

Thanks to all of you. I went along with the simplest solution of a 32767 cyl 
Mdisk.

Going SFS would have created lots of overhead as this disk will be hodling 
thousands of little files that get individually deleted after 4 weeks of 
creation.

 

Suleiman Shahin 



From: kris.buel...@gmail.com
>   Glad to read this issue is solved.





  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

Re: Larger CMS Disk

[Kris Buelens]

CMS' EDF file system also has an allocation map (in fact, it is one of 2
hidden CMS files).  The freed blocks must be reflected there as well.  A bit
more work than just "turning off the first pointer".

Internally SFS though has much in derived from SQL/DS (now DB2/VM), it can
manage much more space than a single minidisk, and sometimes one pays a
price a bit too high for this.  Glad to read this issue is solved.

2009/12/23 Mike Walter 

>
> PS,
>
> As Sue Farrell related in a previous post, if you have the PTF for APAR
> VM64513 applied you may not be subject to that lengthy delay as we are
> with one system still running z/VM 5.1
>
> But to answer the question as best I can from memory.  DISCLAIMER: I'm not
> in the office today, so the exact details may be "slightly off" - just like
> me.  The general method should be pretty close, experts can correct the
> details if it's too far off.
>
> ECDK files have an entry in the File Status Table which resides on that
> MDISK.  The FST, along with other information contained therein, points to
> the first block of each file.  Each file block is chained by a pointer to
> the next block.  Erasing the file just turns off the pointer in the FST to
> the first file block (similar to Windows' FAT filesystem).  There's more to
> the ECKD filesystem than that, but the main point here is the speed of
> clearing a single pointer inside the already-in-storage FST.
>
> In SFS, the SFS server manages a catalog mdisk.  That catalog has a pointer
> to every 4K block in the filepool.  When a (large or small) is erases, the
> block pointer for every file needs to be cleared, and IIRC, a bit in every
> block that the made up the block.   Without looking at the PTF, perhaps
> something in that process was updated to speed things up, just guessing.
>
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
>
>
>  *"P S" *
>
> Sent by: "The IBM z/VM Operating System" 
>
> 12/22/2009 01:49 PM
>  Please respond to
> "The IBM z/VM Operating System" 
>
>
>   To
> IBMVM@LISTSERV.UARK.EDU
> cc
>   Subject
> Re: Larger CMS Disk
>
>
>
>
> On Tue, Dec 22, 2009 at 2:45 PM, Mike Walter 
> <*mike.wal...@hewitt.com*>
> wrote:
> The problem with bigger on SFS is that it is on SFS.
>
> Try writing, say, a big honking (historically for CMS, but NOTHING to
> Linux) 12G file into SFS.  No problem - writes are a little slower than to
> a minidisk, but not enough to complain about (unless, perhaps, many others
> are trying to do the same thing using the same SFS server!).
>
> But when you erase that 12G file, SFS takes almost "forever".  Unlike an
> ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS
> has to go though each of the 4K blocks that constitute the file, turning
> off its allocation bit.  For a large file that can take 15+ minutes (in
> the case of one 12G file we were working with).  And CPU utilization due
> to the server pretty much peaks out during that time, too.  The exact
> details may be slightly off in that example, but the observable effect is
> pretty accurate.
>
> Even one of the original SFS authors, Scott Nettleship, said repeatedly of
> SFS: "If you want minidisk performance, use minidisks".
>
> Not understanding something: writing the file has to write each of the 4K
> blocks too. Are you saying that the ERASE is slower than the WRITE? Or just
> that while it feels reasonable for the original WRITE to take a while, the
> fact that the ERASE is so slow is anomalous?
>
> --
>
> 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.




-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: Larger CMS Disk

[Mike Walter]

PS, 

As Sue Farrell related in a previous post, if you have the PTF for APAR 
VM64513 applied you may not be subject to that lengthy delay as we are 
with one system still running z/VM 5.1

But to answer the question as best I can from memory.  DISCLAIMER: I'm not 
in the office today, so the exact details may be "slightly off" - just 
like me.  The general method should be pretty close, experts can correct 
the details if it's too far off. 

ECDK files have an entry in the File Status Table which resides on that 
MDISK.  The FST, along with other information contained therein, points to 
the first block of each file.  Each file block is chained by a pointer to 
the next block.  Erasing the file just turns off the pointer in the FST to 
the first file block (similar to Windows' FAT filesystem).  There's more 
to the ECKD filesystem than that, but the main point here is the speed of 
clearing a single pointer inside the already-in-storage FST.

In SFS, the SFS server manages a catalog mdisk.  That catalog has a 
pointer to every 4K block in the filepool.  When a (large or small) is 
erases, the block pointer for every file needs to be cleared, and IIRC, a 
bit in every block that the made up the block.   Without looking at the 
PTF, perhaps something in that process was updated to speed things up, 
just guessing.

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.



"P S"  

Sent by: "The IBM z/VM Operating System" 
12/22/2009 01:49 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Larger CMS Disk






On Tue, Dec 22, 2009 at 2:45 PM, Mike Walter  
wrote:
The problem with bigger on SFS is that it is on SFS.

Try writing, say, a big honking (historically for CMS, but NOTHING to
Linux) 12G file into SFS.  No problem - writes are a little slower than to
a minidisk, but not enough to complain about (unless, perhaps, many others
are trying to do the same thing using the same SFS server!).

But when you erase that 12G file, SFS takes almost "forever".  Unlike an
ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS
has to go though each of the 4K blocks that constitute the file, turning
off its allocation bit.  For a large file that can take 15+ minutes (in
the case of one 12G file we were working with).  And CPU utilization due
to the server pretty much peaks out during that time, too.  The exact
details may be slightly off in that example, but the observable effect is
pretty accurate.

Even one of the original SFS authors, Scott Nettleship, said repeatedly of
SFS: "If you want minidisk performance, use minidisks".

Not understanding something: writing the file has to write each of the 4K 
blocks too. Are you saying that the ERASE is slower than the WRITE? Or 
just that while it feels reasonable for the original WRITE to take a 
while, the fact that the ERASE is so slow is anomalous? 



The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Re: Larger CMS Disk

[Mike Walter]

That PTF (and more) is another reason for us to finish migrating that CMS 
applications system from z/VM 5.1 to z/VM 5.4 (or 6.x whenever we get 
there)!

A nice Christmas present, indeed - Thanks!

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.



Sue Farrell  

Sent by: "The IBM z/VM Operating System" 
12/23/2009 08:06 AM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Larger CMS Disk






FYI, as noted at http://www.vm.ibm.com/perf/tips/prgapar.html, APAR 
VM64513 did improve performance when erasing large SFS files.






The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Re: Larger CMS Disk

[Sue Farrell]

FYI, as noted at http://www.vm.ibm.com/perf/tips/prgapar.html, APAR 
VM64513 did improve performance when erasing large SFS files.

Re: Larger CMS Disk

[P S]

On Tue, Dec 22, 2009 at 2:45 PM, Mike Walter  wrote:

> The problem with bigger on SFS is that it is on SFS.
>
> Try writing, say, a big honking (historically for CMS, but NOTHING to
> Linux) 12G file into SFS.  No problem - writes are a little slower than to
> a minidisk, but not enough to complain about (unless, perhaps, many others
> are trying to do the same thing using the same SFS server!).
>
> But when you erase that 12G file, SFS takes almost "forever".  Unlike an
> ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS
> has to go though each of the 4K blocks that constitute the file, turning
> off its allocation bit.  For a large file that can take 15+ minutes (in
> the case of one 12G file we were working with).  And CPU utilization due
> to the server pretty much peaks out during that time, too.  The exact
> details may be slightly off in that example, but the observable effect is
> pretty accurate.
>
> Even one of the original SFS authors, Scott Nettleship, said repeatedly of
> SFS: "If you want minidisk performance, use minidisks".
>

Not understanding something: writing the file has to write each of the 4K
blocks too. Are you saying that the ERASE is slower than the WRITE? Or just
that while it feels reasonable for the original WRITE to take a while, the
fact that the ERASE is so slow is anomalous?

Re: Larger CMS Disk

[Mike Walter]

The problem with bigger on SFS is that it is on SFS. 

Try writing, say, a big honking (historically for CMS, but NOTHING to 
Linux) 12G file into SFS.  No problem - writes are a little slower than to 
a minidisk, but not enough to complain about (unless, perhaps, many others 
are trying to do the same thing using the same SFS server!).

But when you erase that 12G file, SFS takes almost "forever".  Unlike an 
ECKD CMS filesystem minidisk where the FST is cleared for that file, SFS 
has to go though each of the 4K blocks that constitute the file, turning 
off its allocation bit.  For a large file that can take 15+ minutes (in 
the case of one 12G file we were working with).  And CPU utilization due 
to the server pretty much peaks out during that time, too.  The exact 
details may be slightly off in that example, but the observable effect is 
pretty accurate.

Even one of the original SFS authors, Scott Nettleship, said repeatedly of 
SFS: "If you want minidisk performance, use minidisks".

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.



"Marcy Cortes"  

Sent by: "The IBM z/VM Operating System" 
12/22/2009 01:19 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Larger CMS Disk






if you need bigger, there is SFS!
 

Marcy 

 
"This message may contain confidential and/or privileged information. If 
you are not the addressee or authorized to receive this for the addressee, 
you must not use, copy, disclose, or take any action based on this message 
or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this 
message. Thank you for your cooperation."

 



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Suleiman Shahin
Sent: Tuesday, December 22, 2009 11:12 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Larger CMS Disk


Thank you, John. 
 
I think you settled it!

Suleiman Shahin 


 



10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.

 But then a footnote says 'CMS is limited to 32767 cylinders'

 

 



Hotmail: Free, trusted and rich email service. Get it now. <
http://clk.atdmt.com/GBL/go/171222984/direct/01/> 






The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Re: Larger CMS Disk

[Suleiman Shahin]

> We are using 32767 cylinder mdisks at The Nielsen Company...
 
 

I think I will do the same.

 

Thanks.

 
  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

Re: Larger CMS Disk

[Suleiman Shahin]

I did think about that, but 32767 is sufficient.

 

Thanks.



> if you need bigger, there is SFS!
> 
> 
> Marcy 
> 

  
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/171222985/direct/01/

Re: Larger CMS Disk

[Marcy Cortes]

if you need bigger, there is SFS!
 

Marcy 

 
"This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation."

 



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Suleiman Shahin
Sent: Tuesday, December 22, 2009 11:12 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Larger CMS Disk


Thank you, John. 
 
I think you settled it!

Suleiman Shahin 


 



10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.

 But then a footnote says 'CMS is limited to 32767 cylinders'

 

 



Hotmail: Free, trusted and rich email service. Get it now. 
  

Re: Larger CMS Disk

[Suleiman Shahin]

Thank you, John. 

 

I think you settled it!

Suleiman Shahin 


 







10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.
 But then a footnote says 'CMS is limited to 32767 cylinders'
 


  
_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: Larger CMS Disk

[Tracy, David]

We are using 32767 cylinder mdisks at The Nielsen Company...
 



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Romanowski, John (OFT)
Sent: Tuesday, December 22, 2009 2:03 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Larger CMS Disk



10,017 cylinders is max CMS  3390 mdisk size according to section CMS
Restrictions in 'CMS Planning and Administration' manual.

 But then a footnote says 'CMS is limited to 32767 cylinders'

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Suleiman Shahin
Sent: Tuesday, December 22, 2009 1:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Larger CMS Disk

 

Greetings all,

A user has asked me to allocate a CMS full-volume mdisk of  4
cylinders and I'm wondering if that can be a source of problems.

What do you say?

Thanks.

Suleiman Shahin






Hotmail: Free, trusted and rich email service. Get it now.
<http://clk.atdmt.com/GBL/go/171222984/direct/01/> 




This e-mail, including any attachments, may be confidential, privileged
or otherwise legally protected. It is intended only for the addressee.
If you received this e-mail in error or from someone who was not
authorized to send it to you, do not disseminate, copy or otherwise use
this e-mail or its attachments. Please notify the sender immediately by
reply e-mail and delete the e-mail from your system.

Re: Larger CMS Disk

[Suleiman Shahin]

I currently have one twice that. It is used as a depository for files. Have not 
had a problem with it but 40034 is just nightmarish :(

 

 

I will lookup that manual.

 

Thank you.

Suleiman Shahin 

>








10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.
  
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/171222985/direct/01/

Re: Larger CMS Disk

[Romanowski, John (OFT)]

10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.
 But then a footnote says 'CMS is limited to 32767 cylinders'

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Suleiman Shahin
Sent: Tuesday, December 22, 2009 1:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Larger CMS Disk

Greetings all,

A user has asked me to allocate a CMS full-volume mdisk of  4 cylinders and 
I'm wondering if that can be a source of problems.

What do you say?

Thanks.

Suleiman Shahin



Hotmail: Free, trusted and rich email service. Get it 
now.


This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

Re: Larger CMS Disk

[Romanowski, John (OFT)]

10,017 cylinders is max CMS  3390 mdisk size according to section CMS 
Restrictions in 'CMS Planning and Administration' manual.

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Suleiman Shahin
Sent: Tuesday, December 22, 2009 1:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Larger CMS Disk

Greetings all,

A user has asked me to allocate a CMS full-volume mdisk of  4 cylinders and 
I'm wondering if that can be a source of problems.

What do you say?

Thanks.

Suleiman Shahin



Hotmail: Free, trusted and rich email service. Get it 
now.


This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.