Re: z/VM 5.2 Dumps
On Tue, 15 Aug 2006 08:28:47 -0600, Lee Stewart [EMAIL PROTECTED] wrote: This reminds me of my first week or so working for IBM as a PSR (those were kind of software CEs for those of you too young to know). I was working in Dayton, OH and they sent me out to Wright Patterson air base to pick up a dump. It turned out it was at FTD (the Foreign Technology Division) and a very secretive bunch. I got to the lobby of the bank vault like building and waited for them to bring me the dump. When they did, it was like swiss cheese. Someone had gone through it with an Exacto and excised all the data or hints of data that were in it. The big pile of paper only weighed about half of what it normally would. . Lee (much happier with electronic dumps) Stewart On a somewhat related topic, in the early 1990s when I was at IBM and working on VM performance related studies with the WSC, we needed CP moni tor data from customers who considered the data confidential because of useri ds and dasd volsers it contained. Because we needed the raw monitor data for the studies, I wrote two programs (one for VM/SP HPO data, and one for VM/ESA ESA feature data) that would sanitize the monitor data consistentl y throughout by changing all userids and DASD volsers contained in the moni tor records to generic USER and Vn values. The customer was left wit h a listing to map the edited values to the real values. We could call them u p and ask Who the heck was USER0081? It was driving the system nuts at 9am . They could look at the listing corresponding to the data we were analysi ng and know Oh. That was MIDEAST or COMMIE1 and decide what (if anything) they might tell us. I recall I included a tailorable exclude list so that if they did not care about certain names (VTAM, RACF, OPERATOR, etc) they co uld list them in the exclude file and they would not be edited in the monito r data. That feature could make for a more meaningful study with less confusion on our part and less need to ask questions. The programs were written in VS/PASCAL because we needed to be able to provide one module to the customers to edit their data with no need for additional run time libraries. Pipelines were not an option at the time a s it was not a standard part of the VM products customers were running. It had to be able to read both tapes and disk files where the monitor data was recorded, too.
Re: z/VM 5.2 Dumps
This reminds me of my first week or so working for IBM as a PSR (those were kind of software CEs for those of you too young to know). I was working in Dayton, OH and they sent me out to Wright Patterson air base to pick up a dump. It turned out it was at FTD (the Foreign Technology Division) and a very secretive bunch. I got to the lobby of the bank vault like building and waited for them to bring me the dump. When they did, it was like swiss cheese. Someone had gone through it with an Exacto and excised all the data or hints of data that were in it. The big pile of paper only weighed about half of what it normally would.. Lee (much happier with electronic dumps) Stewart Schuh, Richard wrote: Here, the security folks would require us to edit any dump, removing any sensitive information, that is to be seen by an outsider if user storage were to be included. We would also have to encrypt any unedited dump that is stored on dasd or tape. Not to mention that 56GB dumps are larger than we would ever want to store for very long, anyway :-) Regards, Richard Schuh -- Lee Stewart, Senior SE Sirius Enterprise Systems Group Phone: (303) 798-2954 Fax: (720) 228-2321 [EMAIL PROTECTED] www.siriuscom.com
Re: z/VM 5.2 Dumps
That's probably preferable to seeing newspaper headlines talking about a privacy leak at Visa with the accompanying article saying Richard Shuh, who was fired for sending a Visa customer's SSN to IBM :-) Jim At 12:32 PM 8/14/2006, you wrote: Here, the security folks would require us to edit any dump, removing any = sensitive information, that is to be seen by an outsider if user storage = were to be included. We would also have to encrypt any unedited dump = that is stored on dasd or tape. Not to mention that 56GB dumps are = larger than we would ever want to store for very long, anyway :-) Regards, Richard Schuh Jim Bohnsack Cornell Univ. (607) 255-1760
Re: z/VM 5.2 Dumps
Reminds me of a dump I sent in shortly after we put Charlotte up on VM oh about 10 years ago?!. IBM L2 politely informed me that one of our users may have been reading some non-banking business related stuff :o) I know our z/OS guys are having to send them in encrypted now and I was waiting on our IBM person to come back with the story about VM. We have the same requirement (or I'll be in the paper with Richard). Marcy Cortes 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:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Monday, August 14, 2006 09:50 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] z/VM 5.2 Dumps That's probably preferable to seeing newspaper headlines talking about a privacy leak at Visa with the accompanying article saying Richard Shuh, who was fired for sending a Visa customer's SSN to IBM :-) Jim At 12:32 PM 8/14/2006, you wrote: Here, the security folks would require us to edit any dump, removing any = sensitive information, that is to be seen by an outsider if user storage = were to be included. We would also have to encrypt any unedited dump = that is stored on dasd or tape. Not to mention that 56GB dumps are = larger than we would ever want to store for very long, anyway :-) Regards, Richard Schuh Jim Bohnsack Cornell Univ. (607) 255-1760
Re: z/VM 5.2 Dumps
Personally, I prefer just dumping CP storage. I can't recall ever having to examine user storage when working on a CP problem. Neither can I remember ever having to send a VMDUMP of user storage to IBM or any other vendor. Besides, the potential for really large CP dumps is there in the 5.2 system. The last problem we had when converting to 5.2 had the same general symptom as a problem reported by another customer. When I tried sending our dump to the vendor, the receiving disk filled up 3 hours into the FTP. Luckily, the vendor was able to process partial dumps, and was able to confirm that our problem matched the bug reported earlier by IBM, so we were able to get a ready-made fix. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Marcy Cortes Sent: Monday, August 14, 2006 9:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.2 Dumps Reminds me of a dump I sent in shortly after we put Charlotte up on VM oh about 10 years ago?!. IBM L2 politely informed me that one of our users may have been reading some non-banking business related stuff :o) I know our z/OS guys are having to send them in encrypted now and I was waiting on our IBM person to come back with the story about VM. We have the same requirement (or I'll be in the paper with Richard). Marcy Cortes 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:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Monday, August 14, 2006 09:50 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] z/VM 5.2 Dumps That's probably preferable to seeing newspaper headlines talking about a privacy leak at Visa with the accompanying article saying Richard Shuh, who was fired for sending a Visa customer's SSN to IBM :-) Jim At 12:32 PM 8/14/2006, you wrote: Here, the security folks would require us to edit any dump, removing any = sensitive information, that is to be seen by an outsider if user storage = were to be included. We would also have to encrypt any unedited dump = that is stored on dasd or tape. Not to mention that 56GB dumps are = larger than we would ever want to store for very long, anyway :-) Regards, Richard Schuh Jim Bohnsack Cornell Univ. (607) 255-1760
Re: z/VM 5.2 Dumps
Does Standalone Dump use the same formula? Is it smart enough to understand CP control blocks, or does it just dump all of storage? Standalone Dump dumps all resident, non-zero pages. This includes both CP and non-CP pages. The VM Dump Tool recognizes that CP has been dumped and allows the same commands to be issued as it does in hard abend dumps. John Franciscovich z/VM Development
Re: z/VM 5.2 Dumps
Most obvious reason is that 5.2 now dumps more than 2G. 4.4 only dumped the 1st 2G regardless of how much real storage was there. David Boyes Sine Nomine Associates -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 09, 2006 2:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/VM 5.2 Dumps IIRC, there was a discussion, either at SHARE or in this forum, in which it was stated that dumps of z/VM 5.2 would not be significantly larger than those from what were then the current systems (mine was 4.4). Would somebody like to recant? Our dumps are much, much larger. When I used VMARC to compress a 5.2 dump, it is reduced to approximately 18% of its former size. That compressed dump is larger than the uncompressed dumps I used to get from 4.4. Same h/w, same everything except for VM CP. Regards, Richard Schuh
Re: z/VM 5.2 Dumps
The default is CP, there is no longer an ALL: .-CP-. .-IPL---. --Set--DUMP--.-.-DASD---.--''--+---+--..-. | | | '-NOIPL-' '-XF-' | | 'rdev'| '-OFF---' Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Stracka, James (GTI) Sent: Wednesday, August 09, 2006 12:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.2 Dumps It appears IBM changed the SET DUMP command by removing the ALL option. SET DUMP aeb9 ALL IPL HCPDMR003E Invalid option - ALL Must now be: SET DUMP aeb9 cp IPL DASD AEB9 dump unit CP IPL pages 52052 Why did IBM remove the ALL option in 5.2? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Wednesday, August 09, 2006 2:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.2 Dumps Most obvious reason is that 5.2 now dumps more than 2G. 4.4 only dumped the 1st 2G regardless of how much real storage was there. David Boyes Sine Nomine Associates -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 09, 2006 2:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/VM 5.2 Dumps IIRC, there was a discussion, either at SHARE or in this forum, in which it was stated that dumps of z/VM 5.2 would not be significantly larger than those from what were then the current systems (mine was 4.4). Would somebody like to recant? Our dumps are much, much larger. When I used VMARC to compress a 5.2 dump, it is reduced to approximately 18% of its former size. That compressed dump is larger than the uncompressed dumps I used to get from 4.4. Same h/w, same everything except for VM CP. Regards, Richard Schuh If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: z/VM 5.2 Dumps
I posted this as part of another discussion several months ago: Dumps will be larger in 5.2.0, and can be larger than 2 GB due to the increased size of the frame table and other control structures. But it will not be as large as the amount of storage you might have on your system. The rule of thumb is to allow twice as much space for dumps in 5.2.0 than you did in 5.1.0. There is a more detailed (new) explanation of how to estimate the amount of space you'll need for dumps in Chapter 20 of the z/VM 5.2.0 CP Planning and Administration manual, under heading Allocating Space for CP Hard Abend Dumps. John Franciscovich z/VM Development Ah, but the dump only includes CP storage and not that belonging to the users. That was the reasoning behind the statement, again IIRC.=20 Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Wednesday, August 09, 2006 11:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.2 Dumps =20 =20 Most obvious reason is that 5.2 now dumps more than 2G. 4.4=20 only dumped the 1st 2G regardless of how much real storage was there.=20 =20 David Boyes Sine Nomine Associates =20 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 09, 2006 2:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/VM 5.2 Dumps =20 IIRC, there was a discussion, either at SHARE or in this forum, in which it was stated that dumps of z/VM 5.2 would not be=20 significantly larger than those from what were then the current systems (mine was 4.4). Would somebody like to recant? Our dumps are much, much larger.=20 When I used VMARC to compress a 5.2 dump, it is reduced to approximately 18% of its former size. That compressed dump is larger than the uncompressed dumps I used to get from 4.4. Same h/w, same everything except for VM CP. =20 Regards, Richard Schuh =20 =20 =20
Re: z/VM 5.2 Dumps
Does Standalone Dump use the same formula? Is it smart enough to understand CP control blocks, or does it just dump all of storage? Dennis There are 10 kinds of people in the world; those that understand binary and those that don't. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of John Franciscovich Sent: Wednesday, August 09, 2006 14:25 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] z/VM 5.2 Dumps I posted this as part of another discussion several months ago: Dumps will be larger in 5.2.0, and can be larger than 2 GB due to the increased size of the frame table and other control structures. But it will not be as large as the amount of storage you might have on your system. The rule of thumb is to allow twice as much space for dumps in 5.2.0 than you did in 5.1.0. There is a more detailed (new) explanation of how to estimate the amount of space you'll need for dumps in Chapter 20 of the z/VM 5.2.0 CP Planning and Administration manual, under heading Allocating Space for CP Hard Abend Dumps. John Franciscovich z/VM Development Ah, but the dump only includes CP storage and not that belonging to the users. That was the reasoning behind the statement, again IIRC.=20 Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Wednesday, August 09, 2006 11:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: z/VM 5.2 Dumps =20 =20 Most obvious reason is that 5.2 now dumps more than 2G. 4.4=20 only dumped the 1st 2G regardless of how much real storage was there.=20 =20 David Boyes Sine Nomine Associates =20 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, August 09, 2006 2:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: z/VM 5.2 Dumps =20 IIRC, there was a discussion, either at SHARE or in this forum, in which it was stated that dumps of z/VM 5.2 would not be=20 significantly larger than those from what were then the current systems (mine was 4.4). Would somebody like to recant? Our dumps are much, much larger.=20 When I used VMARC to compress a 5.2 dump, it is reduced to approximately 18% of its former size. That compressed dump is larger than the uncompressed dumps I used to get from 4.4. Same h/w, same everything except for VM CP. =20 Regards, Richard Schuh =20 =20 =20
