Mike Rizzi Information Technology - Security Support First Federal of Charleston 2440 Mall Drive Suite 100 Charleston, SC 29406-6544 (843) 529-5774 (voice) (843) 529-5664 (fax)
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of IBMVM automatic digest system Sent: Wednesday, September 19, 2007 1:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IBMVM Digest - 17 Sep 2007 to 18 Sep 2007 (#2007-242) There are 11 messages totalling 892 lines in this issue. Topics of the day: 1. zVM 5.3 TCPIP memory problem (2) 2. Multiple Certificates on One VM System 3. ACCESS empty RR disk fails (8) ---------------------------------------------------------------------- Date: Tue, 18 Sep 2007 09:08:17 -0400 From: "Edward M. Martin" <[EMAIL PROTECTED]> Subject: Re: zVM 5.3 TCPIP memory problem Hello Tom, We have CA-WEBGATEWAY being used by a product called UltraQuest from Select Systems. UltraQuest and Nomad (4gl) use the CA-WEBGATEWAY as the=20 transfer mechanism to get ad-hoc reports from our VSE/ESA VSAM file. I started at 32 Meg, had some storage problems that went away with the 64 Meg. The programmers come in via TN3270 to get to all the various VSE systems. I do a lot of email (sendfile) of files/reports created by UltraQuest.=20 I could lower that amount now, but it is working very well. Ed Martin=20 Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Duerbusch > Sent: Monday, September 17, 2007 4:46 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: zVM 5.3 TCPIP memory problem >=20 > Hi Ed >=20 > I'm always interested in the whys and wheres.... >=20 > I'm on z/VM 5.2 and my stack is 32MB (I did have to up it from the earlier > release). > However, my "res=3D" from indicate user, shows 1,313 pages used. >=20 > I do know about the 5 MB hit, due to LE. Which I thought was a hit to > clients, and not the stack. >=20 > I was wondering what your "res" usage was for your 64 MB machine? > Now that we have vswitch, TCPIP does quite a bit less here. Very seldom > does it pop up in the performance monitor <G>. >=20 > I'm really the only CMS user (and using TN3270). > But I have some 66 service machines, VSE guests and still some Linux > guests (that haven't been migrated over to the IFL), with the guests using > TCP/IP (but not the TCPIP stack). >=20 > Not that virtual storage costs much (anything), but what caused you to go > to 64 MB? >=20 > Thanks >=20 > Tom Duerbusch > THD Consulting > (trying to head off a rude awaking if 32 MB isn't sufficient) >=20 > FELINE PHYSICS: > Law of Cat Inertia >=20 > A cat at rest will tend to remain at rest, unless acted upon by > some outside force - such as the opening of cat food, or a nearby > scurrying mouse. >=20 >=20 > >>> "Edward M. Martin" <[EMAIL PROTECTED]> 9/17/2007 3:33 PM >>> > Hello Mike, >=20 > I am working on upgrading to z/VM5.3 from z/VM 4.3. In the > process, I am reading lots of info. > The program directory indicates that with Host/domain name resolution > being performed by LE you need a minimum of > 16m of virtual storage. >=20 > And for 5.3 most server machines will need 32 meg and probably > more. >=20 > I have our z/VM 4.3 TCPIP at 64m already. > Ed Martin > Aultman Health Foundation > 330-588-4723 > [EMAIL PROTECTED] > ext. 40441 > ________________________________ >=20 > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Mark Bodenstein > Sent: Monday, September 17, 2007 4:01 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: zVM 5.3 TCPIP memory problem >=20 > Mike, >=20 > Thanks for the information. I work with Jim and am also trying to > understand the differences in memory use of the z/VM 5.3 TCP/IP clients > compared to the z/VM 4.4 ones. >=20 > The web page you reference talks about C sockets library changes, but > says these were already present in z/VM 4.4. The difference we're > seeing is between 4.4 and 5.3. So does this apply? I also wonder > because we're seeing this with ftp and telnet, which aren't mentioned on > your web page as using the C socket library. (Do they?) >=20 > I've done some more testing, and find that the 5MB or so additional > memory use that we're seeing only happens when there is a DNS lookup > involved. So if I do "ftp cornellc.cit.cornell.edu" I see the > additional memory use, but if I do "ftp 132.236.98.12" I don't. > Similarly "ftp loopback" doesn't cause the additional memory use. I see > the same thing for lpr: lpr profile exec (p raw at > cornellc.cit.cornell.edu causes the additional memory use, while lpr > profile exec (p raw at 132.236.98.12 does not. >=20 > So what is there about DNS lookup that causes this memory use, while > otherwise the clients don't suck up virtual storage? >=20 > Thanks, >=20 > Mark Bodenstein ([EMAIL PROTECTED]) > Cornell University >=20 > At 01:08 PM 9/14/2007, you wrote: >=20 >=20 >=20 > Jim, >=20 > There are several reasons for the increased use of virtual storage when > running > the TCP/IP functions and utilities. You can read about some of these at >=20 > http://www.vm.ibm.com/devpages/donovanm/zvmle.html >=20 > and specifically look at >=20 > http://www.vm.ibm.com/devpages/donovanm/zvmle.html#LEstor >=20 > The 5M "feechur" you mention is an unfortunate artifact of sockets being > defined > as POSIX file descriptors in the Byte File System client code. "Fixing" > this > involves a significant rewrite of a BFS client storage management and > will > most likely not happen any time soon. >=20 > Mike Donovan > --- > zVM 5.3 TCPIP memory problem >=20 > I remember back in zVM 5.1 or 5.2 days seeing on the list that there > were memory problems or memory size issues. I probably didn't follow it >=20 > because I was using 4.4 and probably just thought it would be fixed. > Now I see that it wasn't fixed. I've just been told by IBM it's a > "feechur". I'm seeing it with the TCPIP clients, FTP and LPR. They > grab about 5M and don't release it. I didn't see it in putting the > release together because whoever runs the MAINT id in installation with > a small machine size. >=20 > Does anyone have any ideas or a solution or is that just the way it is? > Jim >=20 > -- > Jim Bohnsack > Cornell University > (607) 255-1760 > [EMAIL PROTECTED] ------------------------------ Date: Tue, 18 Sep 2007 10:06:24 -0400 From: Alan Altmark <[EMAIL PROTECTED]> Subject: Re: Multiple Certificates on One VM System On Monday, 09/17/2007 at 06:29 EDT, Alan Ackerman <[EMAIL PROTECTED]> wrote: > There doesn't appear to be anything in SSLADMIN to import or export key > pairs, though. You're right, the SSL server does not have a way to export certificates (with the private key) and has no way to import them. (The public key is in the certificate.) Alan Altmark z/VM Development IBM Endicott ------------------------------ Date: Tue, 18 Sep 2007 10:35:00 -0400 From: Mark Bodenstein <[EMAIL PROTECTED]> Subject: Re: zVM 5.3 TCPIP memory problem Thanks Alan and Michael for your explanations, and thanks Rick for looking on the bright side. :-) Mark Bodenstein ([EMAIL PROTECTED]) Cornell University ------------------------------ Date: Tue, 18 Sep 2007 17:20:14 +0100 From: "Ian S. Worthington" <[EMAIL PROTECTED]> Subject: ACCESS empty RR disk fails I've come across this a few times but never understood *why* accessing an= empty disk I've linked RR should fail (rc=3D28, iirc). Any good reason f= or that? And any way to *prevent* it from failing? (I'm not after the files I'm a= fter the disk stats I can only get when the disk is accessed.) ian =2E.. ------------------------------ Date: Tue, 18 Sep 2007 12:40:58 -0400 From: Rich Greenberg <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails On: Tue, Sep 18, 2007 at 05:20:14PM +0100,Ian S. Worthington Wrote: } I've come across this a few times but never understood *why* accessing an } empty disk I've linked RR should fail (rc=28, iirc). Any good reason for } that? Since there are no files to access, and no possibility to add files, an access would make no sense, so the designers of CP-67 decided this should be an error. You can access a r/w empty minidisk because there is the ability to add files. } And any way to *prevent* it from failing? (I'm not after the files I'm after } the disk stats I can only get when the disk is accessed.) Not that I know of. You just have to catch the rc=28 and handle that as an error. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only. VM'er since CP-67 Canines:Val, Red, Shasta & Casey (RIP), Red & Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L ------------------------------ Date: Tue, 18 Sep 2007 14:12:42 -0400 From: Bruce Hayden <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails One other trick or tactic is to put a file (very frequently called "DUMMY FILE", or if you're more clever, "Dummy File") that is 1 block with a single line of anything in it. Using the mixed case file name makes it a little harder to erase and it allows a successful read only access. On 9/18/07, Rich Greenberg <[EMAIL PROTECTED]> wrote: > } And any way to *prevent* it from failing? (I'm not after the files I'm after > } the disk stats I can only get when the disk is accessed.) > > Not that I know of. You just have to catch the rc=28 and handle that as > an error. -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY ------------------------------ Date: Tue, 18 Sep 2007 15:50:11 -0400 From: David Kreuter <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails Ian: You can roll your own/fend for yourself. Start by using DDR. Say = your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3 =20 cyl 0 head 0 record 3 has the label information. You can decode the = info there and get the numbers you need. =20 Or if its a small sized disk, and you have sufficient tdisk, define a = tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila = you can access and then see your stats. This would even work by creating = a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and = somewhat dangerous ....=20 =20 David ________________________________ From: The IBM z/VM Operating System on behalf of Ian S. Worthington Sent: Tue 9/18/2007 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] ACCESS empty RR disk fails I've come across this a few times but never understood *why* accessing = an empty disk I've linked RR should fail (rc=3D28, iirc). Any good reason = for that? And any way to *prevent* it from failing? (I'm not after the files I'm = after the disk stats I can only get when the disk is accessed.) ian ... ------------------------------ Date: Tue, 18 Sep 2007 15:56:12 -0400 From: "Stracka, James (GTI)" <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails The disk can have files but if they are all MODE 0, you do not get to ACCESS it either. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, September 18, 2007 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ACCESS empty RR disk fails Ian: You can roll your own/fend for yourself. Start by using DDR. Say your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3 =20 cyl 0 head 0 record 3 has the label information. You can decode the info there and get the numbers you need. =20 Or if its a small sized disk, and you have sufficient tdisk, define a tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila you can access and then see your stats. This would even work by creating a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and somewhat dangerous ....=20 =20 David ________________________________ From: The IBM z/VM Operating System on behalf of Ian S. Worthington Sent: Tue 9/18/2007 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] ACCESS empty RR disk fails I've come across this a few times but never understood *why* accessing an empty disk I've linked RR should fail (rc=3D28, iirc). Any good = reason for that? And any way to *prevent* it from failing? (I'm not after the files I'm after the disk stats I can only get when the disk is accessed.) ian ... -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or = proprietary, and if you are not an intended recipient, please notify the = sender, do not use or share it and delete it. Unless specifically = indicated, this message is not an offer to sell or a solicitation of any = investment products or other financial product or service, an official = confirmation of any transaction, or an official statement of Merrill = Lynch. Subject to applicable law, Merrill Lynch may monitor, review and = retain e-communications (EC) traveling through its networks/systems. The = laws of the country of each sender/recipient may impact the handling of = EC, and EC may be archived, supervised and produced in countries other = than the country in which you are located. This message cannot be = guaranteed to be secure or error-free. This message is subject to terms = available at the following link: = http://www.ml.com/e-communications_terms/. By messaging with Merrill = Lynch you consent to the foregoing. -------------------------------------------------------- ------------------------------ Date: Tue, 18 Sep 2007 15:15:56 -0500 From: Mike Walter <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails This is a multipart message in MIME format. --=_alternative 006F51508625735A_= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian, If you could explain more about what you're really trying to do, then perhaps we can help with some alternate solutions. It it's just that you get an rc=28 (the "File not found" return code; justifiable for a R/O disk with no files or only filemode 0 files unless the MODE0 options is used), then it's working as designed. As stated earlier, just adding a "Dummy File" is a simple action. But without knowing that you are really trying to do, we can't provide a correct answer. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Stracka, James (GTI)" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 09/18/2007 02:56 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: ACCESS empty RR disk fails The disk can have files but if they are all MODE 0, you do not get to ACCESS it either. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, September 18, 2007 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ACCESS empty RR disk fails Ian: You can roll your own/fend for yourself. Start by using DDR. Say your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3 cyl 0 head 0 record 3 has the label information. You can decode the info there and get the numbers you need. Or if its a small sized disk, and you have sufficient tdisk, define a tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila you can access and then see your stats. This would even work by creating a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and somewhat dangerous .... David ________________________________ From: The IBM z/VM Operating System on behalf of Ian S. Worthington Sent: Tue 9/18/2007 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] ACCESS empty RR disk fails I've come across this a few times but never understood *why* accessing an empty disk I've linked RR should fail (rc=28, iirc). Any good reason for that? And any way to *prevent* it from failing? (I'm not after the files I'm after the disk stats I can only get when the disk is accessed.) ian ... -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/ . By messaging with Merrill Lynch you consent to the foregoing. -------------------------------------------------------- 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. Emails 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 email. --=_alternative 006F51508625735A_= Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <br><font size=2 face="sans-serif">Ian,</font> <br> <br><font size=2 face="sans-serif">If you could explain more about what you're really trying to do, then perhaps we can help with some alternate solutions.</font> <br> <br><font size=2 face="sans-serif">It it's just that you get an rc=28 (the "File not found" return code; justifiable for a R/O disk with no files or only filemode 0 files unless the MODE0 options is used), then it's working as designed. </font> <br> <br><font size=2 face="sans-serif">As stated earlier, just adding a "Dummy File" is a simple action. But without knowing that you are <b>really </b>trying to do, we can't provide a <b>correct</b> answer.</font> <br><font size=2 face="sans-serif"><br> Mike Walter <br> Hewitt Associates <br> Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates.<br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=36%><font size=1 face="sans-serif"><b>"Stracka, James (GTI)" <[EMAIL PROTECTED]></b> </font> <br> <br><font size=1 face="sans-serif">Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU></font> <p><font size=1 face="sans-serif">09/18/2007 02:56 PM</font> <table border> <tr valign=top> <td bgcolor=white> <div align=center><font size=1 face="sans-serif">Please respond to<br> "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU></font></div></table> <br> <br> <td width=63%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">IBMVM@LISTSERV.UARK.EDU</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">Re: ACCESS empty RR disk fails</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2><tt>The disk can have files but if they are all MODE 0, you do not get to<br> ACCESS it either.<br> <br> -----Original Message-----<br> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On<br> Behalf Of David Kreuter<br> Sent: Tuesday, September 18, 2007 3:50 PM<br> To: IBMVM@LISTSERV.UARK.EDU<br> Subject: Re: ACCESS empty RR disk fails<br> <br> <br> Ian: You can roll your own/fend for yourself. Start by using DDR. Say<br> your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3<br> <br> cyl 0 head 0 record 3 has the label information. You can decode the<br> info there and get the numbers you need.<br> <br> Or if its a small sized disk, and you have sufficient tdisk, define a<br> tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila<br> you can access and then see your stats. This would even work by creating<br> a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and<br> somewhat dangerous .... <br> <br> David<br> <br> ________________________________<br> <br> From: The IBM z/VM Operating System on behalf of Ian S. Worthington<br> Sent: Tue 9/18/2007 12:20 PM<br> To: IBMVM@LISTSERV.UARK.EDU<br> Subject: [IBMVM] ACCESS empty RR disk fails<br> <br> <br> <br> I've come across this a few times but never understood *why* accessing<br> an empty disk I've linked RR should fail (rc=28, iirc). Any good reason<br> for that?<br> <br> And any way to *prevent* it from failing? (I'm not after the files I'm<br> after the disk stats I can only get when the disk is accessed.)<br> <br> ian<br> ...<br> --------------------------------------------------------<br> <br> This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.<br> --------------------------------------------------------<br> <br> </tt></font> <br> <P><pre wrap></pre><hr><font size=2 face="serif"> 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. Emails 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 email. </font> </pre></P> --=_alternative 006F51508625735A_=-- ------------------------------ Date: Tue, 18 Sep 2007 16:51:03 -0400 From: David Kreuter <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails DDRing from r/o source disk to r/w tdisk will show all stats and all = files ________________________________ From: The IBM z/VM Operating System on behalf of Stracka, James (GTI) Sent: Tue 9/18/2007 3:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] ACCESS empty RR disk fails The disk can have files but if they are all MODE 0, you do not get to ACCESS it either. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, September 18, 2007 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ACCESS empty RR disk fails Ian: You can roll your own/fend for yourself. Start by using DDR. Say your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3 cyl 0 head 0 record 3 has the label information. You can decode the info there and get the numbers you need. Or if its a small sized disk, and you have sufficient tdisk, define a tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila you can access and then see your stats. This would even work by creating a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and somewhat dangerous .... David ________________________________ From: The IBM z/VM Operating System on behalf of Ian S. Worthington Sent: Tue 9/18/2007 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] ACCESS empty RR disk fails I've come across this a few times but never understood *why* accessing an empty disk I've linked RR should fail (rc=3D28, iirc). Any good = reason for that? And any way to *prevent* it from failing? (I'm not after the files I'm after the disk stats I can only get when the disk is accessed.) ian ... -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or = proprietary, and if you are not an intended recipient, please notify the = sender, do not use or share it and delete it. Unless specifically = indicated, this message is not an offer to sell or a solicitation of any = investment products or other financial product or service, an official = confirmation of any transaction, or an official statement of Merrill = Lynch. Subject to applicable law, Merrill Lynch may monitor, review and = retain e-communications (EC) traveling through its networks/systems. The = laws of the country of each sender/recipient may impact the handling of = EC, and EC may be archived, supervised and produced in countries other = than the country in which you are located. This message cannot be = guaranteed to be secure or error-free. This message is subject to terms = available at the following link: = http://www.ml.com/e-communications_terms/. By messaging with Merrill = Lynch you consent to the foregoing. -------------------------------------------------------- ------------------------------ Date: Wed, 19 Sep 2007 05:50:30 +0200 From: Kris Buelens <[EMAIL PROTECTED]> Subject: Re: ACCESS empty RR disk fails ------=_Part_17210_29731405.1190173830482 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My QDSK EXEC contains logic to get quite some information from the CMS header records when a disk cannot be accessed as it is empty or has only FM0 files (the information you can get includes things like when was the disk formatted, last accessed in R/W). It uses RxDASD or DDR PRINT to read header records from the minidisk (so no need for modern pipes, ad no DDR to copy the whole -maybe large- minidisk). Ask and you it'll be sent (as I did to Ian). -- Kris Buelens, IBM Belgium, VM customer support 2007/9/18, David Kreuter <[EMAIL PROTECTED]>: > > DDRing from r/o source disk to r/w tdisk will show all stats and all > files > > ________________________________ > > From: The IBM z/VM Operating System on behalf of Stracka, James (GTI) > Sent: Tue 9/18/2007 3:56 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: [IBMVM] ACCESS empty RR disk fails > > > > The disk can have files but if they are all MODE 0, you do not get to > ACCESS it either. > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of David Kreuter > Sent: Tuesday, September 18, 2007 3:50 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: ACCESS empty RR disk fails > > > Ian: You can roll your own/fend for yourself. Start by using DDR. Say > your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3 > > cyl 0 head 0 record 3 has the label information. You can decode the > info there and get the numbers you need. > > Or if its a small sized disk, and you have sufficient tdisk, define a > tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila > you can access and then see your stats. This would even work by creating > a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and > somewhat dangerous .... > > David > > ________________________________ > > From: The IBM z/VM Operating System on behalf of Ian S. Worthington > Sent: Tue 9/18/2007 12:20 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: [IBMVM] ACCESS empty RR disk fails > > > > I've come across this a few times but never understood *why* accessing > an empty disk I've linked RR should fail (rc=28, iirc). Any good reason > for that? > > And any way to *prevent* it from failing? (I'm not after the files I'm > after the disk stats I can only get when the disk is accessed.) > > ian > ... > ------=_Part_17210_29731405.1190173830482 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My QDSK EXEC contains logic to get quite some information from the CMS header records when a disk cannot be accessed as it is empty or has only FM0 files (the information you can get includes things like when was the disk formatted, last accessed in R/W). It uses RxDASD or DDR PRINT to read header records from the minidisk (so no need for modern pipes, ad no DDR to copy the whole -maybe large- minidisk). <br><br> Ask and you it'll be sent (as I did to Ian). <br>-- <br>Kris Buelens,<br>IBM Belgium, VM customer support<br><br><div><span class="gmail_quote">2007/9/18, David Kreuter <<a href="mailto:[EMAIL PROTECTED]"> [EMAIL PROTECTED]</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">DDRing from r/o source disk to r/w tdisk will show all stats and all files <br><br>________________________________<br><br>From: The IBM z/VM Operating System on behalf of Stracka, James (GTI)<br>Sent: Tue 9/18/2007 3:56 PM<br>To: <a href="mailto:IBMVM@LISTSERV.UARK.EDU";>IBMVM@LISTSERV.UARK.EDU</a> <br>Subject: Re: [IBMVM] ACCESS empty RR disk fails<br><br><br><br>The disk can have files but if they are all MODE 0, you do not get to<br>ACCESS it either.<br><br>-----Original Message-----<br>From: The IBM z/VM Operating System [mailto: <a href="mailto:IBMVM@LISTSERV.UARK.EDU";>IBMVM@LISTSERV.UARK.EDU</a>] On<br>Behalf Of David Kreuter<br>Sent: Tuesday, September 18, 2007 3:50 PM<br>To: <a href="mailto:IBMVM@LISTSERV.UARK.EDU";>IBMVM@LISTSERV.UARK.EDU</a><br> Subject: Re: ACCESS empty RR disk fails<br><br><br>Ian: You can roll your own/fend for yourself. Start by using DDR. Say<br>your mdisk is at vaddr 1B0. DDR INPUT 1B0 DASD TYPE 0 0 3<br><br>cyl 0 head 0 record 3 has the label information. You can decode the <br>info there and get the numbers you need.<br><br>Or if its a small sized disk, and you have sufficient tdisk, define a<br>tdisk of the same size, ddr the r/o over to the r/w tdisk and et voila<br>you can access and then see your stats. This would even work by creating <br>a 1 cylinder tdisk (and then just copy cyl 0), but ... it's weird and<br>somewhat dangerous ....<br><br>David<br><br>________________________________<br><br>From: The IBM z/VM Operating System on behalf of Ian S. Worthington <br>Sent: Tue 9/18/2007 12:20 PM<br>To: <a href="mailto:IBMVM@LISTSERV.UARK.EDU";>IBMVM@LISTSERV.UARK.EDU</a><br>Sub ject: [IBMVM] ACCESS empty RR disk fails<br><br><br><br>I've come across this a few times but never understood *why* accessing <br>an empty disk I've linked RR should fail (rc=28, iirc). Any good reason<br>for that?<br><br>And any way to *prevent* it from failing? (I'm not after the files I'm<br>after the disk stats I can only get when the disk is accessed.) <br><br>ian<br>...<br></blockquote></div> ------=_Part_17210_29731405.1190173830482-- ------------------------------ End of IBMVM Digest - 17 Sep 2007 to 18 Sep 2007 (#2007-242) ************************************************************ The information in this message, along with any attachments, is confidential and intended solely for the addressee(s). First Federal disclaims any responsibility for the contents of this message and attachments, if any. If you are not the intended recipient of this message, please contact the sender by reply e-mail and destroy all copies of the original message. Unauthorized review, use, disclosure or distribution is prohibited.
