DASD Service Date

2009-10-08 Thread Dean, David (I/S)
Is there a command to see the date DASD was formatted?  Or placed in service?

David M. Dean
Information Systems
BlueCross BlueShield Tennnessee




-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: DASD Service Date

2009-10-08 Thread Dave Jones

Not to my knowledge, no, there isn't.

Dean, David (I/S) wrote:


Is there a command to see the date DASD was formatted?  Or placed in 
service?
 
David M. Dean

Information Systems
BlueCross BlueShield Tennnessee
 
 
 


-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


--
Dave Jones
V/Soft
www.vsoft-software.com
Houston, TX
281.578.7544


Re: TXT2PDF problem

2009-10-08 Thread Greg Preddy
Frank,

We had problems with TXT2PDF leaking storage, but it would take several
documents before it would run out for us.  Leland Lucius and I found that
 in
T2PNEVAL line 30 (comment) and 31 (AGO) were added to SKIP freeing storag
e
because someone had a problem with that at some point in time.  Delete th
ose
lines, and run T2PMACUP to rebuild the MACLIB and COMPASM to rebuild the
T2PCOMP module and it should fix the leak.

We also run it from a pipe and convert up to a 100,000 record limit, and
that is in an 8M VM.  I use 'COMPRESS 5'.

source_file = 'READER FILE' fileid 'HOLD'

/* CC varies based on SPOOL FILE characteristics */

/* Run TXT2PDF in pipe */
'PIPE' source_file '|',   /* Using RDR file */
  'REXX (TXT2PDF EXEC)',
  'ORIENT L COMPRESS 5' cc_opt,
  'PAPER LET/WHITEBAR PAGE n/SP',
  'CONFIRM NO',
  '|  OUTPUT PDF A'


zVM 'disk wiping'

2009-10-08 Thread Scott Rohling
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'

2009-10-08 Thread P S
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'

2009-10-08 Thread P S
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'

2009-10-08 Thread McKown, John
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'

2009-10-08 Thread Aria Bamdad
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: DASD Service Date

2009-10-08 Thread Rob van der Heij
On Thu, Oct 8, 2009 at 3:06 PM, Dave Jones d...@vsoft-software.com wrote:
 Not to my knowledge, no, there isn't.

You're probably right as far as exposed details on the S/390 I/O
architecture goes. But I was amazed to see how much the PC drives know
about me :-)

ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE
UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f   100   100   051Pre-fail
Always   -   0
  3 Spin_Up_Time0x0007   070   070   011Pre-fail
Always   -   9920
  4 Start_Stop_Count0x0032   100   100   000Old_age
Always   -   4
  5 Reallocated_Sector_Ct   0x0033   100   100   010Pre-fail
Always   -   0
  7 Seek_Error_Rate 0x000f   253   253   051Pre-fail
Always   -   0
  8 Seek_Time_Performance   0x0025   100   100   015Pre-fail
Offline  -   0
  9 Power_On_Hours  0x0032   100   100   000Old_age
Always   -   1242
 ...
190 Airflow_Temperature_Cel 0x0022   070   064   000Old_age
Always   -   30 (Lifetime Min/Max 18/36)
194 Temperature_Celsius 0x0022   070   063   000Old_age
Always   -   30 (Lifetime Min/Max 18/37)

This is one of the pair that I installed during the week before SHARE
when the old drive started to give me errors - that's when I learned
about smartctl to show the number of errors and things like that.

 Dean, David (I/S) wrote:

 Is there a command to see the date DASD was formatted?  Or placed in
 service?

Most likely the storage manager GUI of todays disk subsystems has some
kind of logging that reveals what has been done on the box.

Rob


Re: zVM 'disk wiping'

2009-10-08 Thread David Boyes
  -  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: DASD Service Date

2009-10-08 Thread Edward M Martin
You may be able to see if you have a VTOC date.

 

Ed Martin

Aultman Health Foundation

330-363-5050

ext 35050

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Dean, David (I/S)
Sent: Thursday, October 08, 2009 9:03 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DASD Service Date

 

Is there a command to see the date DASD was formatted?  Or placed in
service?

 

David M. Dean

Information Systems

BlueCross BlueShield Tennnessee

 

 

 

 
-
Please see the following link for the BlueCross BlueShield of Tennessee
E-mail disclaimer:  http://www.bcbst.com/email_disclaimer.shtm


Re: zVM 'disk wiping'

2009-10-08 Thread Thomas Kern
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'

2009-10-08 Thread Scott Rohling
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'

2009-10-08 Thread Alan Altmark
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'

2009-10-08 Thread David Boyes
 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: DASD Service Date

2009-10-08 Thread Alan Altmark
On Thursday, 10/08/2009 at 10:13 EDT, Edward M Martin 
emar...@aultman.com wrote:
 You may be able to see if you have a VTOC date.

The VTOC does not contain a date.

http://www.vm.ibm.com/devpages/altmarka/vtoc.html

Alan Altmark
z/VM Development
IBM Endicott


OSA card replacement procedures

2009-10-08 Thread Marcy Cortes
1 port of an OSA card has died (the z/OS port).  IBM wants to replace the whole 
card.  The other port is in our VSWITCH  LACP group. 

What should be the procedure for taking it out without any network impact (we 
have an app that really can't tolerate much of any pause)?
Do we just let Link Aggregation do its thing or issue something from VM to take 
it out nicely?  


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.


Re: zVM 'disk wiping'

2009-10-08 Thread Aria Bamdad
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'

2009-10-08 Thread Roland P. Chung
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'

2009-10-08 Thread Alan Altmark
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'

2009-10-08 Thread David Boyes
 DITTO does that
 [snip]

Except that DITTO takes a special-bid for IFL use


Re: OSA card replacement procedures

2009-10-08 Thread Alan Altmark
On Thursday, 10/08/2009 at 01:36 EDT, Marcy Cortes 
marcy.d.cor...@wellsfargo.com wrote:
 1 port of an OSA card has died (the z/OS port).  IBM wants to replace 
the whole 
 card.  The other port is in our VSWITCH  LACP group.
 
 What should be the procedure for taking it out without any network 
impact (we 
 have an app that really can't tolerate much of any pause)?
 Do we just let Link Aggregation do its thing or issue something from VM 
to take 
 it out nicely?

Look at the SET PORT GROUP command. 

1. SET PORT GROUP  LEAVE rdev.Pnn
2. Vary the devices and the chpid offline
3. Replace OSA
4. Vary the chpid and the devices online
5. SET PORT GROUP  ADD rdev.Pnn

Alan Altmark
z/VM Development
IBM Endicott


Re: zVM 'disk wiping'

2009-10-08 Thread Aria Bamdad
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'

2009-10-08 Thread David Boyes
   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)


PROP question

2009-10-08 Thread Jihad K Kawkabani
Greetings all,
I cannot seem to get PROP to react to a message:
The message appears in the log as follows: 09/10/08 15:02:12 userid
VMNODE:  HCPCQU045E OPSVM not logged on

I have coded in the RTABLE the following:
|...+1+2+3+4+5+6+7...
$HCPCQU045EDMSPOS   userid
/HCPMSG045EDMSPOS   userid

The HCPMSG045E message has the same format as the CQU message.
userid never receives the message. I also coded an exec a placed its name
in the Action column. The exec never received control.

In the Programmable Operator Facility manual it says that CP responses
from the programmable Operator CMD command are not Logged when LOGGING is
set to ON. I have LOGGING ALL LOWER set.
Plus I have the Message Column blank, so  I do not specify a specific
class.

Can anyone shed any light on this. Thanks in advance.

Regards,

Jihad K. Kawkabani
IT Systems Engineer Consultant
Voice: 440.395.0740
Network: 575.0740
Cell: 440.465.2969



CP TRACE question....

2009-10-08 Thread Dave Jones

Hi, gang.

I have a question about the CP TRACE command.what are the 
ramifications, if any, on using the TRACE command to monitor and debug 
an application running in a virtual machine that has multiple virtual 
CPUs defined? The application is aware of the multiple virtual 
processors and can dispatch work on multiple processors at the same time.


Does this configuration have any impact on the ability of the TRACE 
command to trap machine operations, set breakpoints, etc.?


Thanks and have a good one.
--
Dave Jones
V/Soft
www.vsoft-software.com
Houston, TX
281.578.7544


Re: zVM 'disk wiping'

2009-10-08 Thread O'Brien, Dennis L
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: PROP question

2009-10-08 Thread Kris Buelens
OPSVM: isn't that the logical operator?  If PROP were to intercept logical
operator not logged on and maybe pass that to the logical operator (as it
isn't filtered by the RTABLE), one'd have an endless loop.

2009/10/8 Jihad K Kawkabani jihad_k_kawkab...@progressive.com

 Greetings all,
 I cannot seem to get PROP to react to a message:
 The message appears in the log as follows: 09/10/08 15:02:12 userid
 VMNODE:  HCPCQU045E OPSVM not logged on

 I have coded in the RTABLE the following:
 |...+1+2+3+4+5+6+7...
 $HCPCQU045EDMSPOS   userid
 /HCPMSG045EDMSPOS   userid

 The HCPMSG045E message has the same format as the CQU message.
 userid never receives the message. I also coded an exec a placed its name
 in the Action column. The exec never received control.

 In the Programmable Operator Facility manual it says that CP responses
 from the programmable Operator CMD command are not Logged when LOGGING is
 set to ON. I have LOGGING ALL LOWER set.
 Plus I have the Message Column blank, so  I do not specify a specific
 class.

 Can anyone shed any light on this. Thanks in advance.

 Regards,

 Jihad K. Kawkabani
 IT Systems Engineer Consultant
 Voice: 440.395.0740
 Network: 575.0740
 Cell: 440.465.2969




-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: CP TRACE question....

2009-10-08 Thread Rob van der Heij
On Thu, Oct 8, 2009 at 9:44 PM, Dave Jones d...@vsoft-software.com wrote:

 Does this configuration have any impact on the ability of the TRACE command
 to trap machine operations, set breakpoints, etc.?

Did you remember to use CPU ALL to activate PER for all CPUs (unless
you know where to look for it)

Rob


Re: CP TRACE question....

2009-10-08 Thread P S
On Thu, Oct 8, 2009 at 4:46 PM, Rob van der Heij rvdh...@gmail.com wrote:
 Did you remember to use CPU ALL to activate PER for all CPUs (unless
 you know where to look for it)

Good point:

CPU ALL TRACE ...

(in case it wasn't obvious)


Re: CP TRACE question....

2009-10-08 Thread Dave Jones

Thanks, Rob and PSso I need to issue the TRACE command like so:


CPU ALL CMD TRACE ...  . . . . . . . . .

correct?

Rob van der Heij wrote:

On Thu, Oct 8, 2009 at 9:44 PM, Dave Jones d...@vsoft-software.com wrote:


Does this configuration have any impact on the ability of the TRACE command
to trap machine operations, set breakpoints, etc.?


Did you remember to use CPU ALL to activate PER for all CPUs (unless
you know where to look for it)

Rob


--
Dave Jones
V/Soft
www.vsoft-software.com
Houston, TX
281.578.7544


Re: CP TRACE question....

2009-10-08 Thread P S
On Thu, Oct 8, 2009 at 5:14 PM, Dave Jones d...@vsoft-software.com wrote:
 Thanks, Rob and PSso I need to issue the TRACE command like so:

    CPU ALL CMD TRACE ...  . . . . . . . . .

 correct?

The CMD is optional, but sure.


Re: zVM 'disk wiping'

2009-10-08 Thread David Boyes
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: CP TRACE question....

2009-10-08 Thread Dave Jones

Excellent, PS; thanks a lot.

P S wrote:

On Thu, Oct 8, 2009 at 4:46 PM, Rob van der Heij rvdh...@gmail.com wrote:

Did you remember to use CPU ALL to activate PER for all CPUs (unless
you know where to look for it)


Good point:

CPU ALL TRACE ...

(in case it wasn't obvious)


--
Dave Jones
V/Soft
www.vsoft-software.com
Houston, TX
281.578.7544


Re: CP TRACE question....

2009-10-08 Thread Rob van der Heij
On Thu, Oct 8, 2009 at 11:14 PM, Dave Jones d...@vsoft-software.com wrote:

    CPU ALL CMD TRACE ...  . . . . . . . . .

Sure, the CMD is probably optional unless the CP command would look
like a CPU address... (not in your case)

I did not want to go into the commands because you just should be ware
that this is per cpu (no 00D intended). The CPU ALL is only for the
CPUs you had at that time (and may not even include the quiesced ones,
dunno).

Your haircut may also be seriously impacted when you forget this when
the trace hits. Like display the registers of the default CPU when you
try to understand the reason for the program check (iirc the command
after the CMD option on the TRACE command itself does go for the right
one). When you issue the commands by hand, the CPU command can be used
to point to another CPU for the unqualified commands.

Rob


Re: zVM 'disk wiping'

2009-10-08 Thread McKown, John
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: OSA card replacement procedures

2009-10-08 Thread Marcy Cortes
Close - that ADD is really JOIN. 
But it worked, no bumps in the night.
Thanks Alan.


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.


-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Alan Altmark
Sent: Thursday, October 08, 2009 11:31 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] OSA card replacement procedures

On Thursday, 10/08/2009 at 01:36 EDT, Marcy Cortes 
marcy.d.cor...@wellsfargo.com wrote:
 1 port of an OSA card has died (the z/OS port).  IBM wants to replace 
the whole 
 card.  The other port is in our VSWITCH  LACP group.
 
 What should be the procedure for taking it out without any network 
impact (we 
 have an app that really can't tolerate much of any pause)?
 Do we just let Link Aggregation do its thing or issue something from VM 
to take 
 it out nicely?

Look at the SET PORT GROUP command. 

1. SET PORT GROUP  LEAVE rdev.Pnn
2. Vary the devices and the chpid offline
3. Replace OSA
4. Vary the chpid and the devices online
5. SET PORT GROUP  ADD rdev.Pnn

Alan Altmark
z/VM Development
IBM Endicott


Cannot find msg explaination

2009-10-08 Thread Graeme Moss

Hello Listers,

I am working on a new z/VM 5.4 rsu 0902 system. To prove the hardware I have 
set up a second TCPIP with a new OSA owned by TCPIP2. I am getting this 
message but cannot track down any information about it.


DTCOSD223E OSD device d...@0900: Return code E080 from STRTLAN for IPv4

I have done searches on DTCOSD223E, E080 and STRTLAN.

I would like to find out the meaning of the message AND how to find the 
meaning of the message


Thanks in Advance
Graeme 


Re: Cannot find msg explaination

2009-10-08 Thread Kris Buelens
Try this great web page for messages:
http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/
As opposed to what the URL suggests, it not only finds z/OS messages.

2009/10/9 Graeme Moss ib...@mossaustralia.com

 Hello Listers,

 I am working on a new z/VM 5.4 rsu 0902 system. To prove the hardware I
 have set up a second TCPIP with a new OSA owned by TCPIP2. I am getting this
 message but cannot track down any information about it.

 DTCOSD223E OSD device d...@0900: Return code E080 from STRTLAN for IPv4

 I have done searches on DTCOSD223E, E080 and STRTLAN.

 I would like to find out the meaning of the message AND how to find the
 meaning of the message

 Thanks in Advance
 Graeme




-- 
Kris Buelens,
IBM Belgium, VM customer support