Re: zVM 'disk wiping'
If you are talking about reassigning disks to another system, a CMS format is good enough. If you are decommissioning the drives then talk to the vender or have them crushed. A DASD subsystem isn't easy to destroy anymore. 1. You have pools of extents, and not all extents may be used, but they may have been used (and the drive deleted). 2. Parity shouldn't be a problem. 3. Spare drives can be a problem. From my research, the vender has a product/method, of meeting DOD specifications for destruction of the data. Else they would never sell to the government. Tom Duerbusch THD Consulting David Boyes dbo...@sinenomine.net 10/8/2009 9:10 AM - I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. Nope, not silly at all. The idea is that repeating the writes with different patterns of data blurs the magnetic image on the disk of the original data, making it progressively harder (but not impossible) to recover the data via laboratory means. The DSF INSPECT command is pretty effective for decommissioning disks, but it's not good enough if you have milspec erasure requirements. Melting is pretty much safe. Use of old disks as live-fire ordnance test targets is also popular (and much more fun). 8-) - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data? No. At minimum, DSF INSPECT, more common: destroy the platters completely. Anyway, to your real question: there is allegedly/apparently latent magnetism in a bit, such that it's at least *theoretically* possible to recover data from a formatted drive. More than theoretical. It's not easy, but a good forensics lab can do it. Has anyone ever actually done this? Not that I know of, but I haven't really looked. Obviously they'd need physical access to the disks and a fair bit of time. Yes. One *past* (I don't do that stuff any more) client of mine manufactured instruments of policy -- aka military weapons. One of their other contractors wiped an important pack several times and they had to send it to a secured forensics lab for recovery. 4 months and several million dollars later, they were able to read about 80% of the data. -- db
Re: zVM 'disk wiping'
On Thu, Oct 8, 2009 at 9:28 AM, Scott Rohling scott.rohl...@gmail.com wrote: Working with a customer running Linux on zSeries under zVM... discussing clean up of disk areas when a Linux server is removed. The 'norm' according to the customer is to use anywhere from 3 to 35 'passes' to erase data, depending on sensitivity. I'm wondering if anyone can provide input about how this relates to various cleanup available... I'm confused on a couple of fronts: - I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data? Same for CPFMTXA FORMAT and any other utilities used from zVM to 'clean' DASD... does anyone actually run these more than once? I'm sure I'm not understanding the context of 'passes' and just want to be able to talk intelligently as I can about how their concept of passes relates to how mainframe DASD is dealt with - especially at the zVM level. This is always where I come to hear several points of view and get useful insight -- so any input would be most welcome! First, that would be Linux on System z under z/VM. zSeries has been dead for four years, it's time to let it go. Anyway, to your real question: there is allegedly/apparently latent magnetism in a bit, such that it's at least *theoretically* possible to recover data from a formatted drive. Think of it like this. If a given byte's bits *were* 10001000, and you've formatted it to all zeroes, the actual magnetic values for the bits won't be quite all zero. That is, we consider a bit to be 1 if its Gauss value (not the right term, but close enough) is at least, say, 100 (on some scale that I'm making up), A single format might push a 1 from 115 down to 45. But a bit that was previously zero (and was at 50 on my scale) might get pushed down to 10. So -- again, *in theory* -- you could read those values and infer that the 45 was a 1 and the 10 was a 0. Now you have a couple of bits. Repeat until done. Has anyone ever actually done this? Not that I know of, but I haven't really looked. Obviously they'd need physical access to the disks and a fair bit of time. HTH
Re: zVM 'disk wiping'
Forgot to add: by repeated formats, you lower the actual values until they disappear into the noise floor -- a 5 is pretty hard to tell from a 4, and a repeatedly rewritten 0 might go to a 5, whereas a repeatedly rewritten 1 might go to a 4, so at some point entropy takes over. If you've used SpinRite, you can sort of see this in the display -- the values aren't all high or all low.
Re: zVM 'disk wiping'
IMO, more than 1 pass is likely overkill. However, from a auditing standpoint, there are NSA guidelines about how many passes and the bit patterns necessary to make the data truly unrecoverable. Using advanced technology (like Abby on NCIS usesgrin), it is possible to read ghost images of previous bit patterns underneath the live data on the disk. That is because changing the data does not change 100% of all the underlying ferro-magnetic material. But, again, this requires specialized equipment. However, such equipment is out there in the commerical world for doing disaster recovery of damaged media. So, it would be theoritically possible to sell a DASD array to another company which would then contract to one of these recovery specialists to recover the data. What likelihood is that? Minimal. It is more likely to be done on PC type DASD on a stolen laptop or some such. And, in that case, the solution is to use full DASD encryption. That is what we do on all the company laptops. That pretty much guarantees security. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Thursday, October 08, 2009 8:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: zVM 'disk wiping' Working with a customer running Linux on zSeries under zVM... discussing clean up of disk areas when a Linux server is removed. The 'norm' according to the customer is to use anywhere from 3 to 35 'passes' to erase data, depending on sensitivity. I'm wondering if anyone can provide input about how this relates to various cleanup available... I'm confused on a couple of fronts: - I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data?Same for CPFMTXA FORMAT and any other utilities used from zVM to 'clean' DASD... does anyone actually run these more than once? I'm sure I'm not understanding the context of 'passes' and just want to be able to talk intelligently as I can about how their concept of passes relates to how mainframe DASD is dealt with - especially at the zVM level. This is always where I come to hear several points of view and get useful insight -- so any input would be most welcome! Scott p.s. Considered posting this in Linux-390 .. but it's really more of a zVM thing to me - especially since I plan to use DIRMAINT CLEAN functions to remove Linux servers from zVM.
Re: zVM 'disk wiping'
Scott, The ‘passes’ cover the entire disk. That is, you would write varying patterns of bits over the entire disk over and over again, each time picking a different bit pattern. According to strict security standards, if you were to just format the drive a few times, writing the same pattern of bits each time, you can still read the previously written data from the drive if you tried hard enough. If you are using ICKDSF, you can use TRKFMT function with the CYCLES and ERASEDATA to do multiple passes. Aria From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Thursday, October 08, 2009 9:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: zVM 'disk wiping' Working with a customer running Linux on zSeries under zVM... discussing clean up of disk areas when a Linux server is removed. The 'norm' according to the customer is to use anywhere from 3 to 35 'passes' to erase data, depending on sensitivity. I'm wondering if anyone can provide input about how this relates to various cleanup available... I'm confused on a couple of fronts: - I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data?Same for CPFMTXA FORMAT and any other utilities used from zVM to 'clean' DASD... does anyone actually run these more than once? I'm sure I'm not understanding the context of 'passes' and just want to be able to talk intelligently as I can about how their concept of passes relates to how mainframe DASD is dealt with - especially at the zVM level. This is always where I come to hear several points of view and get useful insight -- so any input would be most welcome! Scott p.s. Considered posting this in Linux-390 .. but it's really more of a zVM thing to me - especially since I plan to use DIRMAINT CLEAN functions to remove Linux servers from zVM.
Re: zVM 'disk wiping'
- I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. Nope, not silly at all. The idea is that repeating the writes with different patterns of data blurs the magnetic image on the disk of the original data, making it progressively harder (but not impossible) to recover the data via laboratory means. The DSF INSPECT command is pretty effective for decommissioning disks, but it's not good enough if you have milspec erasure requirements. Melting is pretty much safe. Use of old disks as live-fire ordnance test targets is also popular (and much more fun). 8-) - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data? No. At minimum, DSF INSPECT, more common: destroy the platters completely. Anyway, to your real question: there is allegedly/apparently latent magnetism in a bit, such that it's at least *theoretically* possible to recover data from a formatted drive. More than theoretical. It's not easy, but a good forensics lab can do it. Has anyone ever actually done this? Not that I know of, but I haven't really looked. Obviously they'd need physical access to the disks and a fair bit of time. Yes. One *past* (I don't do that stuff any more) client of mine manufactured instruments of policy -- aka military weapons. One of their other contractors wiped an important pack several times and they had to send it to a secured forensics lab for recovery. 4 months and several million dollars later, they were able to read about 80% of the data. -- db
Re: zVM 'disk wiping'
In this discussion there should be a differentiation between reusing a DA SD allocation while still under your physical control (giving the mdisk to another user), and relinquishing physical control (return to vendor durin g an upgrade or selling it to 3rd-party or turning it over to the federal excess list). I use one pass of format by DIRMAINT to clean an allocation before allowi ng reuse withing my own installation. But it the DASD has to leave the building, I use ICKDSF or FDR/Erase several times before it gets powered off. And if the data was really sensitive, the platters get removed (fun job on real 3380s), shredded into confetti and then melted. /Tom Kern /301-903-2211 On Thu, 8 Oct 2009 07:28:48 -0600, Scott Rohling scott.rohl...@gmail.com wrote: Working with a customer running Linux on zSeries under zVM... discussin g clean up of disk areas when a Linux server is removed. The 'norm' according to the customer is to use anywhere from 3 to 35 'passes' to er ase data, depending on sensitivity. I'm wondering if anyone can provide in put about how this relates to various cleanup available... I'm confused on a couple of fronts: - I'm probably not understanding -- but writing 1's or 0's more than on ce to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any Do D rules, etc concerning securely wiping data?Same for CPFMTXA FORMAT a nd any other utilities used from zVM to 'clean' DASD... does anyone actua lly run these more than once? I'm sure I'm not understanding the context of 'passes' and just want to be able to talk intelligently as I can about how their concept of passes relates to how mainframe DASD is dealt with - especially at the zVM leve l. This is always where I come to hear several points of view and get usefu l insight -- so any input would be most welcome! Scott p.s. Considered posting this in Linux-390 .. but it's really more of a zVM thing to me - especially since I plan to use DIRMAINT CLEAN functions to remove Linux servers from zVM.
Re: zVM 'disk wiping'
I think that's why I hadn't given this much thought prior to this -- I'm used to the idea of redeploying the same DASD and just formatting it once to erase previous guests data. So I agree there's a difference between doing this - where the customer has only logical access to the data - and where physical access is changing. When storage units leave a data center - 'then' I think multiple wipes make sense -- but outside of that, I'm not seeing it's applicability on a mainframe supplying a virtual Linux environment (maybe cleaning up after a DR exercise/realdeal if sensitive data was used). Very interesting discussion - I had not understood (or thought very hard about) the physics and why multiple passes with different bit patterns would be done -- but now I get it. Thanks for educating a 'software' guy on the mechanics! Scott On Thu, Oct 8, 2009 at 8:29 AM, Thomas Kern tlk_sysp...@yahoo.com wrote: In this discussion there should be a differentiation between reusing a DASD allocation while still under your physical control (giving the mdisk to another user), and relinquishing physical control (return to vendor during an upgrade or selling it to 3rd-party or turning it over to the federal excess list). I use one pass of format by DIRMAINT to clean an allocation before allowing reuse withing my own installation. But it the DASD has to leave the building, I use ICKDSF or FDR/Erase several times before it gets powered off. And if the data was really sensitive, the platters get removed (fun job on real 3380s), shredded into confetti and then melted. /Tom Kern /301-903-2211
Re: zVM 'disk wiping'
On Thursday, 10/08/2009 at 09:49 EDT, McKown, John john.mck...@healthmarkets.com wrote: But, again, this requires specialized equipment. However, such equipment is out there in the commerical world for doing disaster recovery of damaged media. So, it would be theoritically possible to sell a DASD array to another company which would then contract to one of these recovery specialists to recover the data. What likelihood is that? Minimal. It is more likely to be done on PC type DASD on a stolen laptop or some such. And, in that case, the solution is to use full DASD encryption. That is what we do on all the company laptops. That pretty much guarantees security. If you have a DS 8000 with encrypting disk drives, a data security erase (DSE) is performed when you delete the RAID array in the HMC. (This is not performed for non-encrypted drives, however.) IBM offers secure disk erasure services as well. Isn't it strange that I can find no requirements for the CMS TAPE command to support a DSE option? And nothing about DSE for minidisk or tdisk deallocation? Apparently home-grown erasure solutions and shredding are good enough. Alan Altmark z/VM Development IBM Endicott
Re: zVM 'disk wiping'
Isn't it strange that I can find no requirements for the CMS TAPE command to support a DSE option? And nothing about DSE for minidisk or tdisk deallocation? Apparently home-grown erasure solutions and shredding are good enough. There were several a few years back, but IBM rejected them all because there were IPLable z/OS utilities (DSF was deemed good enough) and third-party apps that performed the same task. I can fix that lack if you prefer. -- db
Re: zVM 'disk wiping'
It would be nice if the CMS TAPE command had a DSE option. I pass tapes through a degausser but would feel a lot better if I ran a DSE command where the tape was erased from beginning to end. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Thursday, October 08, 2009 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zVM 'disk wiping' Isn't it strange that I can find no requirements for the CMS TAPE command to support a DSE option? And nothing about DSE for minidisk or tdisk deallocation? Apparently home-grown erasure solutions and shredding are good enough. There were several a few years back, but IBM rejected them all because there were IPLable z/OS utilities (DSF was deemed good enough) and third-party apps that performed the same task. I can fix that lack if you prefer. -- db
Re: zVM 'disk wiping'
DITTO/VM does that: Process View Options Help -- DITTO/ESA for VM Task Selection Menu Select the desired task or enter a DITTO function code, then press Enter. Use the Menu key to display the menu panel with DITTO function groups. 12 1. Browse data 2. Edit or update data 3. Work with VTOC 4. Work with VSAM catalog 5. Backup/restore CMS files 6. Print data 7. Copy data 8. Locate data 9. Change data 10. Create data 11. Position a tape 12. - Tape Specific Functions -- 13. | | 14. | Select the desired function: | | | | 1. Summarize tape contents | | 2. Print label summary | | 3. Compare two tapes | | | | 4. Write tape marks | | 5. Initialize tape | | 6. Erase tape | | | | F1=Help F3=Exit F12=Cancel | -- Regards, Roland --- On Thu, 10/8/09, Aria Bamdad a...@bsc.gwu.edu wrote: From: Aria Bamdad a...@bsc.gwu.edu Subject: Re: zVM 'disk wiping' To: IBMVM@LISTSERV.UARK.EDU Received: Thursday, October 8, 2009, 5:54 PM It would be nice if the CMS TAPE command had a DSE option. I pass tapes through a degausser but would feel a lot better if I ran a DSE command where the tape was erased from beginning to end. --- snipped ---
Re: zVM 'disk wiping'
On Thursday, 10/08/2009 at 01:55 EDT, Aria Bamdad a...@bsc.gwu.edu wrote: It would be nice if the CMS TAPE command had a DSE option. I pass tapes through a degausser but would feel a lot better if I ran a DSE command where the tape was erased from beginning to end. Yes, it would be. But it won't ever be done if people don't submit requirements or get their names attached to existing ones. :-) The one thing you must not to do a tape cartridge is degauss it. If you do, the servo tracks are destroyed and must be re-initialized before the tape can be used. z/OS will prompt you and ask if it is ok to initialize a scrogged tape. z/VM will not. (Another opportunity for a requirement.) Alan Altmark z/VM Development IBM Endicott
Re: zVM 'disk wiping'
DITTO does that [snip] Except that DITTO takes a special-bid for IFL use
Re: zVM 'disk wiping'
Thanks Alan. Yes, I know that degaussing will mess the tape up. In my case, I do this when I want to retire the tapes and send them for recycling. Where do one go to submit a requirement? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Thursday, October 08, 2009 2:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zVM 'disk wiping' On Thursday, 10/08/2009 at 01:55 EDT, Aria Bamdad a...@bsc.gwu.edu wrote: It would be nice if the CMS TAPE command had a DSE option. I pass tapes through a degausser but would feel a lot better if I ran a DSE command where the tape was erased from beginning to end. Yes, it would be. But it won't ever be done if people don't submit requirements or get their names attached to existing ones. :-) The one thing you must not to do a tape cartridge is degauss it. If you do, the servo tracks are destroyed and must be re-initialized before the tape can be used. z/OS will prompt you and ask if it is ok to initialize a scrogged tape. z/VM will not. (Another opportunity for a requirement.) Alan Altmark z/VM Development IBM Endicott
Re: zVM 'disk wiping'
Isn't it strange that I can find no requirements for the CMS TAPE command to support a DSE option? And nothing about DSE for minidisk or tdisk deallocation? Apparently home-grown erasure solutions and shredding are good enough. I just submitted WAVV requirements: WRIBDB05 Auto reinitialization for degaussed or damaged tapes (CMS TAPE) WRIBDB06 DSE option for CMS TAPE WRIBDB07 DSE capability for user disk on deallocation (DIRMAINT) WRIBDB08 DSE for CP temp disk (z/VM CP)
Re: zVM 'disk wiping'
CA VM:Tape has an exit that can instruct the service machine to perform a DSE on scratch mounts. If you have the product, you could just enable the exit and scratch mount all of the tapes that you want to discard. Dennis My computer beat me at chess, but it was no match for me in kickboxing. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Aria Bamdad Sent: Thursday, October 08, 2009 10:54 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] zVM 'disk wiping' It would be nice if the CMS TAPE command had a DSE option. I pass tapes through a degausser but would feel a lot better if I ran a DSE command where the tape was erased from beginning to end. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Thursday, October 08, 2009 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zVM 'disk wiping' Isn't it strange that I can find no requirements for the CMS TAPE command to support a DSE option? And nothing about DSE for minidisk or tdisk deallocation? Apparently home-grown erasure solutions and shredding are good enough. There were several a few years back, but IBM rejected them all because there were IPLable z/OS utilities (DSF was deemed good enough) and third-party apps that performed the same task. I can fix that lack if you prefer. -- db
Re: zVM 'disk wiping'
On 10/8/09 5:04 PM, Rob van der Heij rvdh...@gmail.com wrote: And I'm sure you just blow those requirements away since It's just David again like you do with my list of things that Endicott should do ;-) Hey, don't include me there. I have never failed to get *some* response. It's not always the response I wanted, but they do respond. Although I do seem to get the high cackly voice of Chuckie fairly often... -- db
Re: zVM 'disk wiping'
IMO, more than 1 pass is likely overkill. However, from a auditing standpoint, there are NSA guidelines about how many passes and the bit patterns necessary to make the data truly unrecoverable. Using advanced technology (like Abby on NCIS usesgrin), it is possible to read ghost images of previous bit patterns underneath the live data on the disk. That is because changing the data does not change 100% of all the underlying ferro-magnetic material. But, again, this requires specialized equipment. However, such equipment is out there in the commerical world for doing disaster recovery of damaged media. So, it would be theoritically possible to sell a DASD array to another company which would then contract to one of these recovery specialists to recover the data. What likelihood is that? Minimal. It is more likely to be done on PC type DASD on a stolen laptop or some such. And, in that case, the solution is to use full DASD encryption. That is what we do on all the company laptops. That pretty much guarantees security. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Thursday, October 08, 2009 8:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: zVM 'disk wiping' Working with a customer running Linux on zSeries under zVM... discussing clean up of disk areas when a Linux server is removed. The 'norm' according to the customer is to use anywhere from 3 to 35 'passes' to erase data, depending on sensitivity. I'm wondering if anyone can provide input about how this relates to various cleanup available... I'm confused on a couple of fronts: - I'm probably not understanding -- but writing 1's or 0's more than once to a disk area seems, well, silly. Do 'passes' imply that each pass is covering more 'area' or something? Whenever I do things like 0 a disk using the dd command -- I assume the entire disk is being written to and any subsequent dd commands are unnecessary and redundant. - If we do a DIRM PURGE user CLEAN -- is that sufficient to meet any DoD rules, etc concerning securely wiping data?Same for CPFMTXA FORMAT and any other utilities used from zVM to 'clean' DASD... does anyone actually run these more than once? I'm sure I'm not understanding the context of 'passes' and just want to be able to talk intelligently as I can about how their concept of passes relates to how mainframe DASD is dealt with - especially at the zVM level. This is always where I come to hear several points of view and get useful insight -- so any input would be most welcome! Scott p.s. Considered posting this in Linux-390 .. but it's really more of a zVM thing to me - especially since I plan to use DIRMAINT CLEAN functions to remove Linux servers from zVM.
