AW: DB/2 z/VM moving to DB/2 UDB on z/Linux
Hi Ed, the major problem (when you detect it, you'll be deep into your project) are some incompatibilities between SQL/DS and DB2/UDB. There are SQL-Codes which are different (but meaning the same), there are new codes and old ones that aren't used any more. Sometimes you'll have to use the SQLSTATE, not the SQL-Code - and so on. That means you HAVE to rewrite your own code - there is NO way around that! Then there are the discrepancies regarding functions - minimal, but causing errors nevertheless. Another problem is the translation between EBCDIC and ASCII. Fortunately, as long as you use English, there aren't such mean things as Umlauts :-) But there are other problems. I can search through our docus if you want. You are right saying ...is not something I could accomplish in a short period of time. This could easily be the understatement of the week ;-) With kind regards, Willy -Ursprüngliche Nachricht- Von: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Im Auftrag von Ed Zell Gesendet: Dienstag, 11. November 2008 18:07 An: IBMVM@LISTSERV.UARK.EDU Betreff: Re: DB/2 z/VM moving to DB/2 UDB on z/Linux Has anyone converted their DB/2 for z/VM environment to DB/2 UDB on z/Linux? If so, would you be willing to take my call for 10 minutes? Thanks. Well, I was a bit too fast with the send button. We needed 3.5 years because we had around 1500 big bad self-written PL/1-programs which had to be adapted in part. Then there were some equally bad errors in the code - oh well. If you'd like to contact me, use my e-mail-address: mailto:[EMAIL PROTECTED] Thanks Willy. I appreciate the offer. I am coming to the conclusion that a move from DB/2 on z/VM to DB/2 on z/Linux is not something I could accomplish in a short period of time. And considering that I won't have the luxury of doing any code re-writes, it further complicates the situation. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
help with an error code
This morning when I came in I was informed we couldn't get to our Linux servers. The problem was on the HMC, VM was in a 912 disabled wait state. I have looked all over,but obviously not everywhere or I would have found it, and can't find where this code is hiding. Asking for a little help in finding it, Thanks Mace - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: help with an error code
Macioce, Larry wrote: This morning when I came in I was informed we couldn't get to our Linux servers. The problem was on the HMC, VM was in a 912 disabled wait state. I have looked all over,but obviously not everywhere or I would have found it, and can't find where this code is hiding. Asking for a little help in finding it, Thanks Mace Mace, If you take a look at 'CP Messages and Codes' it says: For a description of what the disabled wait state code means and suggested actions to take, look up the CP message that has the same number as the wait state code. HCP912 says: HCP912W System recovery failure; volid volid not mounted -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: help with an error code
Use HELP, the waitcode plus a W, hence: HELP HCP912W which tells you: HCP912W System recovery failure; volid volid not mounted Explanation: A volume necessary for checkpointing the system is not mounted. The volid refers to the volume ID of the volume that is not mounted. When CP issues this message, the volid should be the volume ID specified on either the SYSCKP or SYSWRM parameters of the SYSRES macro in HCPSYS, or the CHECKPOINT or WARMSTART operands of the SYSTEM_RESIDENCE statement in the SYSTEM CONFIG file. etc... Additionally: have a look in the reader of OPERATNS, maybe CP produced a dump 2008/11/13 Macioce, Larry [EMAIL PROTECTED] This morning when I came in I was informed we couldn't get to our Linux servers. The problem was on the HMC, VM was in a 912 disabled wait state. I have looked all over,but obviously not everywhere or I would have found it, and can't find where this code is hiding. Asking for a little help in finding it, Thanks Mace - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. -- Kris Buelens, IBM Belgium, VM customer support
Re: help with an error code
Thanks I am use to looking in MVS system codes to find a wait state. Mace -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Thursday, November 13, 2008 8:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: help with an error code Macioce, Larry wrote: This morning when I came in I was informed we couldn't get to our Linux servers. The problem was on the HMC, VM was in a 912 disabled wait state. I have looked all over,but obviously not everywhere or I would have found it, and can't find where this code is hiding. Asking for a little help in finding it, Thanks Mace Mace, If you take a look at 'CP Messages and Codes' it says: For a description of what the disabled wait state code means and suggested actions to take, look up the CP message that has the same number as the wait state code. HCP912 says: HCP912W System recovery failure; volid volid not mounted -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Header file to COBOL copybook?
Anyone have any tools for converting C header (H) files to COBOL copybook files? Or experience doing so? I can spell COBOL 2 out of three times. COBALL. (See?) ...phsiii
Re: help with an error code
On Thursday, 11/13/2008 at 07:56 EST, Macioce, Larry [EMAIL PROTECTED] wrote: This morning when I came in I was informed we couldn't get to our Linux servers. The problem was on the HMC, VM was in a 912 disabled wait state. I have looked all over,but obviously not everywhere or I would have found it, and can't find where this code is hiding. Asking for a little help in finding it, While others have answered your question about finding VM wait state codes (HELP HCPW), take Kris' advice and look further: Unless someone re-IPLed VM manually, your system abended and the system couldn't restart automatically. If it did abend, you need to solve that problem, too. Of course, don't let that stop you from fixing whatever is causing the 912. Alan Altmark z/VM Development IBM Endicott
Re: Redbook or Whitepaper For Deploying SSL on z/VM
For those of us currently using SSL on z/VM 5.2 and migrating to z/VM 5.4, what are our options? On Fri, Oct 24, 2008 at 12:29 PM, Alan Altmark [EMAIL PROTECTED]wrote: On Friday, 10/24/2008 at 12:13 EDT, Michael Coffin [EMAIL PROTECTED] wrote: We're running 5.4, so Enabler won't help. :( I think I agree with your assessment of an initial deployment being a giant pain. Since the z/VM 5.4 SSL support is not yet available to the public, there is no configuration information available. We expect to supply hints tips in the usual place: http://www.vm.ibm.com/related/tcpip/vmsslinf.html Alan Altmark z/VM Development IBM Endicott -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: Redbook or Whitepaper For Deploying SSL on z/VM
Hi, Mark. As things stand right this moment, you will have to wait until December sometime (no specific date has been given yet by IBM) for the new CMS-based SSL server to be available for 5.4. The Linux-based SSL server for 5.3 will not work on 5.4, I've been told. But, since it's already the middle of November, it might not be too much of a problem for you to simply wait a bit. Have a good one. Mark Pace wrote: For those of us currently using SSL on z/VM 5.2 and migrating to z/VM 5.4, what are our options? On Fri, Oct 24, 2008 at 12:29 PM, Alan Altmark [EMAIL PROTECTED]wrote: On Friday, 10/24/2008 at 12:13 EDT, Michael Coffin [EMAIL PROTECTED] wrote: We're running 5.4, so Enabler won't help. :( I think I agree with your assessment of an initial deployment being a giant pain. Since the z/VM 5.4 SSL support is not yet available to the public, there is no configuration information available. We expect to supply hints tips in the usual place: http://www.vm.ibm.com/related/tcpip/vmsslinf.html Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Redbook or Whitepaper For Deploying SSL on z/VM
If you need SSL on z/VM 5.4 right now, please contact me offline. We have a solution available that can provide it (as well as some additional features like firewalling and auditing). On 11/13/08 9:17 AM, Dave Jones [EMAIL PROTECTED] wrote: Hi, Mark. As things stand right this moment, you will have to wait until December sometime (no specific date has been given yet by IBM) for the new CMS-based SSL server to be available for 5.4. The Linux-based SSL server for 5.3 will not work on 5.4, I've been told.
Re: Redbook or Whitepaper For Deploying SSL on z/VM
On Thursday, 11/13/2008 at 09:13 EST, Mark Pace [EMAIL PROTECTED] wrote: For those of us currently using SSL on z/VM 5.2 and migrating to z/VM 5.4, what are our options? If you require the use of SSL, then delay your 5.4 migration until the SSL support is available. I say that because a. The FL540 SSL server will not work with a pre-FL540 TCPIP. b. A pre-FL540 SSL server will not work TCPIP FL540. Those are hard functional dependencies, not attorney-generated weasel words. If you want to wander off the farm, outside the safety net, you can bring your TCP/IP FL520 suite forward into your 5.4 system. If you run MPROUTE, that may necessitate having the old LE and CMS. Dunno. If you go this way, test thoroughly. Alan Altmark z/VM Development IBM Endicott
Re: Header file to COBOL copybook?
On Nov 13, 2008, at 7:53 AM, Phil Smith III wrote: Anyone have any tools for converting C header (H) files to COBOL copybook files? Or experience doing so? Does a bottle of Scotch and another bottle of aspirin count as a tool? (MicroFocus COBOL for Unix had a tool to do this: H2cpy) Adam
Re: Redbook or Whitepaper For Deploying SSL on z/VM
I'll wait for the functionality. I've plenty of other things to keep me busy. ;-) Thanks for the info, gang. On Thu, Nov 13, 2008 at 9:40 AM, Alan Altmark [EMAIL PROTECTED]wrote: On Thursday, 11/13/2008 at 09:13 EST, Mark Pace [EMAIL PROTECTED] wrote: For those of us currently using SSL on z/VM 5.2 and migrating to z/VM 5.4, what are our options? If you require the use of SSL, then delay your 5.4 migration until the SSL support is available. I say that because a. The FL540 SSL server will not work with a pre-FL540 TCPIP. b. A pre-FL540 SSL server will not work TCPIP FL540. Those are hard functional dependencies, not attorney-generated weasel words. If you want to wander off the farm, outside the safety net, you can bring your TCP/IP FL520 suite forward into your 5.4 system. If you run MPROUTE, that may necessitate having the old LE and CMS. Dunno. If you go this way, test thoroughly. Alan Altmark z/VM Development IBM Endicott -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
IND$FILE fails through CA-TPX and TCP/IP for VM
Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Header file to COBOL copybook?
On Nov 13, 2008, at 7:53 AM, Phil Smith III wrote: Anyone have any tools for converting C header (H) files to COBOL copybook files? Or experience doing so? There's an Irish company called Risaris that markets a tool to convert various kinds of data structures from different environments (assembler, COBOL, C/C++). I think Software AG resells it too, but you might check them out. www.risaris.com.
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Header file to COBOL copybook?
ISTR a Austrian RexxLA member developed some tools for doing that sort of thing, but I don't know if it was TO copybook, or FROM copybook. Drop Thomas Schneider a note at [EMAIL PROTECTED] and see if he can't help you. He specializes in conversion tools like that. -Chip- On 11/13/08 13:53 Phil Smith III said: Anyone have any tools for converting C header (H) files to COBOL copybook files? Or experience doing so? I can spell COBOL 2 out of three times. COBALL. (See?) ...phsiii
z10 BC
As some of you may have noticed, the z10 BC introduces Instant Messaging on the HMC. This facility lets anyone logged onto the HMC send messages to other users logged onto the HMC. A source at POK sent me the log file from the first such conversation: ZOSPROD1: A/S/L? ZOSPROD2: 50/M/sitting next to you ...phsiii (It's actually a useful feature, but I couldn't resist...)
Re: z10 BC
Note that it isn't limited to the z10 BC only, but any HMC running version 2.10.1. I presume that the z10 EC is also shipping with this level. On Thu, Nov 13, 2008 at 12:29 PM, Phil Smith III [EMAIL PROTECTED] wrote: As some of you may have noticed, the z10 BC introduces Instant Messaging on the HMC. This facility lets anyone logged onto the HMC send messages to other users logged onto the HMC. A source at POK sent me the log file from the first such conversation: ZOSPROD1: A/S/L? ZOSPROD2: 50/M/sitting next to you ...phsiii (It's actually a useful feature, but I couldn't resist...) -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Page Space
Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
Sorry - I missed the in addition to normal load part. That must have been taking up a good chunk of it. 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:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Risk of Adding a Paging Volume
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly**
Re: Risk of Adding a Paging Volume
If you have spare volumes, format some as quickly as possible, add them t o the system and DRAIN the problem volume, take it out of the configuration files and after the next IPL, test that volume, reformat that volume, tes t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly**
Re: Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the list would consider the *RISK*? Low, Medium, or High? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Thursday, November 13, 2008 1:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly**
Re: Risk of Adding a Paging Volume
Low. We add paging volumes all the time to running systems. Lower than a paging volume with errors for sure. 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:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume I have the process and have done this before. What I am asking is what the list would consider the *RISK*? Low, Medium, or High? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Thursday, November 13, 2008 1:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly**
Re: Page Space
Or you schedule your test at a time when you can take a sufficient number of your normal guests down. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Risk of Adding a Paging Volume
Adding additional volume(s) and waiting for the next IPL I would rate as low risk. Continuing to run as you are, with the volume experiencing errors active, I would rate high risk. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: November 13, 2008 14:20 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume I have the process and have done this before. What I am asking is what the list would consider the *RISK*? Low, Medium, or High? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Thursday, November 13, 2008 1:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this
Re: Risk of Adding a Paging Volume
Thank you Marcy. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 1:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Low. We add paging volumes all the time to running systems. Lower than a paging volume with errors for sure. 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:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume I have the process and have done this before. What I am asking is what the list would consider the *RISK*? Low, Medium, or High? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Thursday, November 13, 2008 1:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha,
Re: Risk of Adding a Paging Volume
Adding a page volume is low risk. Just make sure you format the new volume with CPFMTXA first. Whether you add a new volume or not, you should drain the volume with errors, and make sure it's drained in SYSTEM CONFIG, too. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
The only risk is that not draining the problem volume. Any existing page in the problem error could cause a virtual machine or CP abend. The risk of not draining it is increasingly larger as the disk continues to be used. Draining and adding do work. I just added 10 disks to my paging farm. That was all the free slots that I had, or I would have added more. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
Thanks Peter Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 13, 2008 1:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Adding additional volume(s) and waiting for the next IPL I would rate as low risk. Continuing to run as you are, with the volume experiencing errors active, I would rate high risk. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: November 13, 2008 14:20 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume I have the process and have done this before. What I am asking is what the list would consider the *RISK*? Low, Medium, or High? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wheeler Sent: Thursday, November 13, 2008 1:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Scott, First thing I would do is drain the volume, then run ICKDSF against it with CPVOL EXAM command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go. Rachel Joy Scott Wandschneider, Scott Scott.Wandschnei To [EMAIL PROTECTED] IBMVM@LISTSERV.UARK.EDU com cc Sent by: The IBM z/VM OperatingSubject SystemRisk of Adding a Paging Volume [EMAIL PROTECTED] ARK.EDU 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in
Re: Risk of Adding a Paging Volume
Thank you Richard. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume The only risk is that not draining the problem volume. Any existing page in the problem error could cause a virtual machine or CP abend. The risk of not draining it is increasingly larger as the disk continues to be used. Draining and adding do work. I just added 10 disks to my paging farm. That was all the free slots that I had, or I would have added more. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Risk of Adding a Paging Volume
Thanks Dennis. Maybe with all the response I will get approval or not :) Thanks everybody! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 13, 2008 1:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Adding a page volume is low risk. Just make sure you format the new volume with CPFMTXA first. Whether you add a new volume or not, you should drain the volume with errors, and make sure it's drained in SYSTEM CONFIG, too. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott [EMAIL PROTECTED] wrote: I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. What does the list think? Scott R Wandschneider
Re: Page Space
Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
We run 24 hours/day, there is no convenient time. And the test is just a precursor to daily demand. By the end of January, every TPF guest will be of the 3-8GB variety, probably a few as big as 32G. The latter will be scheduled for weekends when demand is lower. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 13, 2008 11:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Or you schedule your test at a time when you can take a sufficient number of your normal guests down. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hello Ed, I tried NSX32705 and still the same. The D4B3290 logmode seems to work fine for everything but PC file to CMS. More testing... Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 2:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Page Space
Sounds like you'll be needing a boatload of paging DASD. Don't forget you only get 256 cp owned slots. So maybe you want to use mod 9. 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:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 11:38 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space We run 24 hours/day, there is no convenient time. And the test is just a precursor to daily demand. By the end of January, every TPF guest will be of the 3-8GB variety, probably a few as big as 32G. The latter will be scheduled for weekends when demand is lower. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 13, 2008 11:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Or you schedule your test at a time when you can take a sufficient number of your normal guests down. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
The 256 slot limit will force me to get larger disks. We have been using mod3s. I guess I will ask for enough mod9s to replace the existing and add additional space. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 11:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Sounds like you'll be needing a boatload of paging DASD. Don't forget you only get 256 cp owned slots. So maybe you want to use mod 9. 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:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 11:38 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space We run 24 hours/day, there is no convenient time. And the test is just a precursor to daily demand. By the end of January, every TPF guest will be of the 3-8GB variety, probably a few as big as 32G. The latter will be scheduled for weekends when demand is lower. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 13, 2008 11:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Or you schedule your test at a time when you can take a sufficient number of your normal guests down. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
This was not in an LPAR that runs Linux. It if TPF that is growing out of control. We didn't hit any server, just the everyday users of our non-Linux VM system. Lucky? Yes and no. We had already increased page space to account for what we were told would be the average size of a z/TPF machine. We were used to running at less than 10% allocated. And we had also increased spool to allow for z/TPF dumps. Together, they kept us out of the really deep stuff. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hello again, My client has come back with the following: We are using Onweb Client that is using HTTP protocol. I found something about this and i think we should use Buffered instead of WSF. I'll do the necessary change to make the Transfer mode = Buffered by default for the users and test it. http://msdn.microsoft.com/en-us/library/ms731913.aspx It appears that specifying a buffered transfer works but a write structured field does not. Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: November 13, 2008 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Ed, I tried NSX32705 and still the same. The D4B3290 logmode seems to work fine for everything but PC file to CMS. More testing... Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 2:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hello Mike, There is an old PTF but it was for TN3270E to TCP/IP V3 MVS. PQ17039 After connecting with TN3270E, a customer uses IND$FILE to send a PC file to TSO. The file transfer fails prematurely with a PCOM message TRANS13. The problem occurs when a data buffer contains the following string at the end of the buffer: x'FF' and the next buffer begins with an x'FF'. The only other problem that I have seen is that the CLEAR Session Before Transfer was turned off. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Ed, I tried NSX32705 and still the same. The D4B3290 logmode seems to work fine for everything but PC file to CMS. More testing... Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 2:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Page Space
What will be the effect, other than having additional space available, of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would there be a noticeable change in the performance of the paging subsystem? (I suspect that any change will be less noticeable than the effects of filling both page and spool. :-) ) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
I have to find the stuff, but at the z Expo we were told that mixing DASD types in a page farm is BD! I don't remember right off hand why. Maybe someone else can chime in while I research. On Thu, Nov 13, 2008 at 3:28 PM, Schuh, Richard [EMAIL PROTECTED] wrote: What will be the effect, other than having additional space available, of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would there be a noticeable change in the performance of the paging subsystem? (I suspect that any change will be less noticeable than the effects of filling both page and spool. :-) ) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: Page Space
Richard, Nothing unusual will happen at first. As the mod 3s start filling up, the system will attempt to page preferentially to the mod 9s because their performance will be better. (The paging subsystem will be able to write longer blocks of pages to the less full volumes.) In the extreme, you'll end up paging exclusively to those five volumes. One hopes you'd resolve the configuration (replace mod 3s with more mod 9s) before reaching that point Marty -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 3:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space What will be the effect, other than having additional space available, of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would there be a noticeable change in the performance of the paging subsystem? (I suspect that any change will be less noticeable than the effects of filling both page and spool. :-) ) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hi Ed, Can you explain what you mean by: the CLEAR Session Before Transfer was turned off. Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 3:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, There is an old PTF but it was for TN3270E to TCP/IP V3 MVS. PQ17039 After connecting with TN3270E, a customer uses IND$FILE to send a PC file to TSO. The file transfer fails prematurely with a PCOM message TRANS13. The problem occurs when a data buffer contains the following string at the end of the buffer: x'FF' and the next buffer begins with an x'FF'. The only other problem that I have seen is that the CLEAR Session Before Transfer was turned off. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Ed, I tried NSX32705 and still the same. The D4B3290 logmode seems to work fine for everything but PC file to CMS. More testing... Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 2:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Page Space
We have a holiday freeze to contend with, so I have no choice except to use what is already at hand or can be obtained in the next 3 days without spending any money. The only paging we see is when we have a bunch of these miscreants on the system, so it might be better for me to take the chance and mix the sizes. I think I would rather do that than run out of real estate. I will not be able to replace the dasd until some time after mid January. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marty Zimelis Sent: Thursday, November 13, 2008 12:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Richard, Nothing unusual will happen at first. As the mod 3s start filling up, the system will attempt to page preferentially to the mod 9s because their performance will be better. (The paging subsystem will be able to write longer blocks of pages to the less full volumes.) In the extreme, you'll end up paging exclusively to those five volumes. One hopes you'd resolve the configuration (replace mod 3s with more mod 9s) before reaching that point Marty -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 3:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space What will be the effect, other than having additional space available, of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would there be a noticeable change in the performance of the paging subsystem? (I suspect that any change will be less noticeable than the effects of filling both page and spool. :-) ) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Dougherty, Margaret is out of the office.
I will be out of the office starting 11/13/2008 and will not return until 11/18/2008. I will respond to your message when I return. *** IMPORTANT NOTE* The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
Re: IND$FILE fails through CA-TPX and TCP/IP for VM
Hello Mike, On z/VM if you just type IND$FILE without anything, the screen will clear. On the PCOM, there is a parameter that will indicate to the VM side that use the default (clear the screen), Always clear the screen, or never clear the screen. It has been awhile since I messed around with IND$FILE CMS command. But you can have IND$FILE do command for you. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 3:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hi Ed, Can you explain what you mean by: the CLEAR Session Before Transfer was turned off. Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 3:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, There is an old PTF but it was for TN3270E to TCP/IP V3 MVS. PQ17039 After connecting with TN3270E, a customer uses IND$FILE to send a PC file to TSO. The file transfer fails prematurely with a PCOM message TRANS13. The problem occurs when a data buffer contains the following string at the end of the buffer: x'FF' and the next buffer begins with an x'FF'. The only other problem that I have seen is that the CLEAR Session Before Transfer was turned off. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Ed, I tried NSX32705 and still the same. The D4B3290 logmode seems to work fine for everything but PC file to CMS. More testing... Mike From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M Martin Sent: November 13, 2008 2:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM Hello Mike, IND$FILE needs the extended data stream to be set in the DLOGMOD. SNX32705 is an SNA 3270 with extended data stream. Typically TCP/IP is uses a non-SNA logmode. Try NSX32705 or NSX32702 in ISTINLCM. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dodds, Jim Sent: Thursday, November 13, 2008 11:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IND$FILE fails through CA-TPX and TCP/IP for VM I remember I had a similar problem about 15 years ago when first started using this a new job. The problem was that there is a bit set in the logmode for file transfer to be able to use or not use. Check the logmode you are currently using and see if that could be the problem. Jim Dodds Systems Programmer Kentucky State University 400 East Main Street Frankfort, Ky 40601 502 597 6114 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Horlick, Michael Sent: Thursday, November 13, 2008 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IND$FILE fails through CA-TPX and TCP/IP for VM Greetings, My client is moving away from SNA to TCP/IP. We use CA-TPX as our session manager and the client uses a terminal emulator called 'Proclient OnWeb Web to Host'. They use IND$FILE and are getting error - TRANS13 when uploading a file from their PC to their CMS A-disk. It doesn't happen to them when native VM and it doesn't happen doing a download from the mainframe to the PC. I use myExtra! and under TPX I have no problems. They have no problems if using SNA. I specified the following in VM/VTAM. My SCEXIT does a DIAL to VTAM for any IP terminals connected to port 23 TC070LOCAL CUADDR=070,TERM=3277,USSTAB=USSTCPIP,FEATUR2=EDATS, * LOGAPPL=TPX,MODETAB=ISTINCLM,DLOGMOD=D4B3290 I think when they connect via SNA they get a DLOGMOD of SNX32705. Has this happened to anyone else? Any suggestions? Thanks, Mike
Re: Risk of Adding a Paging Volume
On Thu, Nov 13, 2008 at 8:36 PM, Wandschneider, Scott [EMAIL PROTECTED] wrote: Thanks Dennis. Maybe with all the response I will get approval or not :) One more from the peanut gallery... we don't get I/O problems on DASD these days. That used to be in the old days where we still had platters with rust that rotate... ;-) If you really have I/O problems then it would probably affect the entire DASD subsystem, so you have also other things to worry about (maybe someone on MVS using your volumes for something else?) It may also be that the page volume was not correctly formatted and CP complains and makes you *think* there are I/O problems on the device. In that case it may be an incorrect operating procedure and your new volume may be also bad. The page pack needs to be formatted completely with ICKDSF - not just the first cylinder, as some (MVS) storage admin folks are used to. Depending on what was there in the past, it may work for part of the volume. If Q ALLOC shows you only a small number of pages in-use on that volume (about the same as the number of errors you had) then that would be my guess. Rob
Re: Risk of Adding a Paging Volume
The only I/O Errors that we are seeing are on one of the paging volumes, BDCPG2: q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- BDCRES 1D60257390 24120 18848 24120 78% BDCPG1 1D64 1170 2169 18 125162 18 69% BDCPG2 1D65 1 3338 600840 121703 198393 20% == I/O Errors -- -- SUMMARY 804960 265713 33% USABLE804960 265713 33% maint Ready; T=0.01/0.01 13:58:34 I have already done the following in preparation: 1) ATTach 1D67 to MAINT 2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. 3) ALLOCATE 0-0 PAGE and 1-END PAGE. Next Steps are: 4) CP Define cpowned slot 07 BDCPG3 == Next available slot 5) DETach 1D67 from MAINT 6) ATTach 1D67 to system 7) CP Start DASD 1D67 page 8) CP Drain volid bdcpg2 all Modify the SYTEM CONFIG file as: CP_Owned Slot 6 BDCPG2 == Existing Drain VOLID BDCPG2 ALL == New CP_OWNED SLOT 7 BDCPG3 == New Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, November 13, 2008 3:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume On Thu, Nov 13, 2008 at 8:36 PM, Wandschneider, Scott [EMAIL PROTECTED] wrote: Thanks Dennis. Maybe with all the response I will get approval or not :) One more from the peanut gallery... we don't get I/O problems on DASD these days. That used to be in the old days where we still had platters with rust that rotate... ;-) If you really have I/O problems then it would probably affect the entire DASD subsystem, so you have also other things to worry about (maybe someone on MVS using your volumes for something else?) It may also be that the page volume was not correctly formatted and CP complains and makes you *think* there are I/O problems on the device. In that case it may be an incorrect operating procedure and your new volume may be also bad. The page pack needs to be formatted completely with ICKDSF - not just the first cylinder, as some (MVS) storage admin folks are used to. Depending on what was there in the past, it may work for part of the volume. If Q ALLOC shows you only a small number of pages in-use on that volume (about the same as the number of errors you had) then that would be my guess. Rob
Re: Page Space
Nah, mixing device types won't hurt much. as they fill, they start performing worse, and vm balances the load to ensure optiomal performance. read about mload. Mark Pace wrote: I have to find the stuff, but at the z Expo we were told that mixing DASD types in a page farm is BD! I don't remember right off hand why. Maybe someone else can chime in while I research. On Thu, Nov 13, 2008 at 3:28 PM, Schuh, Richard [EMAIL PROTECTED] wrote: What will be the effect, other than having additional space available, of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would there be a noticeable change in the performance of the paging subsystem? (I suspect that any change will be less noticeable than the effects of filling both page and spool. :-) ) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, November 13, 2008 11:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Do the math Number one reason for ONE outage at each new z/linux installation is to fill up page space - guess you were lucky and had some extra spool space (no block paging so slow), so you luckily didn't take the outage - which makes your servers even slower Schuh, Richard wrote: Don't presume. 92G real, 10 xstore. All MDC activity is in real, limited to 384MB. And I do not know the color of the machine :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, November 13, 2008 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space You didn't say how much real memory you have. Presumably less than 60G :) You either add enough real memory or you add enough page space to hold them all (at less that 50% occupied. I don't think there are miracles available in this scenario. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Page Space Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Regards, Richard Schuh
Re: Page Space
Marty did an excellent job of summarizing the effects of mixing sizes. Unpleasant in extreme cases yet infintely better than zero performance. That's what Brian Wade described in the case studies at the zExpo.
Re: Page Space
On Thursday, 11/13/2008 at 01:20 EST, Schuh, Richard [EMAIL PROTECTED] wrote: Yesterday, we were running a test using 17 z/TPF virtual machines, 3GB each. This was in addition to the normal load on the system. During the test, which was not moving along very quickly, nothing was, I noticed that our page packs were 100% allocated, up from the usual 10%. This stood out as a smoking gun, verified by watching the performance improve as each of the ids in the test logged off. I presume that this should have been expected; however, other matters have kept us so busy that we did not do the math. I imagine that the one way to avoid this type of problem, we expect a peak of approximately 150 concurrent z/TPF systems in the coming year, is a massive injection of paging DASD. Is this the only answer or are there any other steps that we can take to help? Make sure your dasd subsystem is up to the task, using your fave perf monitor to keep an eye on I/O response times. Alan Altmark z/VM Development IBM Endicott
Re: Risk of Adding a Paging Volume
On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott [EMAIL PROTECTED] wrote: The only I/O Errors that we are seeing are on one of the paging volumes, BDCPG2: I have already done the following in preparation: 1) ATTach 1D67 to MAINT 2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. 3) ALLOCATE 0-0 PAGE and 1-END PAGE. I suppose you meant to allocate cylinder 0 as PERM rather PAGE (only problem there is that people may assume it is bad). But it looks good in that you format the entire volume, so makes me wonder about the PG2 volume. Like what are you going to do with that once it is not being used anymore by VM ? What can you do to the volume to make I/O errors go away? What I tried to point out is that real I/O errors are handled by the DASD subsystem. It could be that some major hardware problems do result in the device passing errors to the host, but that would probably impact all logical volumes on that particular rank. I would strongly recommend you take the EREP data to a hardware CE to look at the sense codes. Since you only had two paging volumes, the bad volume was hit a lot as well. I recall from earlier discussion that even when CP failed to write the block, it still marks it as in-use (in the old days to avoid writing again in that same spot). So it may be that once you have shutdown all guests that have pages out on disk, there still remains pages allocated. Rob
Ted Kotlowski is out of the office.
I will be out of the office starting 11/14/2008 and will not return until 11/18/2008. I will respond to your message when I return. If your request requires immediate attention, Please contact the MVS Technical Support Hotline at 1-866-866-4488 x12000 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. **
