Re: PERFSVM
I don't think CP saves this information in its Warmstart or Checkpoint area, so will need to repeat this MONITOR command after IPLs. Anyhow, you should also prepare for a COLD start. So the easiest is to include it in some PROFILE EXEC, For example that of PERFSVM. -- Kris Buelens, IBM Belgium, VM customer support 2007/4/9, Austin, Alyce (CIV) [EMAIL PROTECTED]: Hello Roger, Thank you for all the great information! I changed the monitor sample configuration size to 600 as you suggested and the problem was corrected. Will this change stay in affect after an IPL or do I have to re-issue the command? Thank again for your support, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Roger Lunsford Sent: Monday, April 09, 2007 5:51 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: PERFSVM If you are MISSING SAMPLE CONFIGURATION RECORDS (which are generated when the Perfkit connects up to MONDCSS), you will need to do the following (note: SAMPLE CONFIG size needs vary by system configurations. We ship with an ample size that is good for 'most' shops. However, if you monitor a lot of users or devices, this size may need to be increased): 1-MONITOR STOP 2-MONITOR SAMPLE CONFIG SIZE 600 3-RESTART THE PERFKIT If this increase does not correct the problem, restart with step 1, and increase the config size by another 300 (aka: 900 the 2nd time). If this corrects and no more error messages then you are good to go. Be aware: -Increasing the SAMPLE CONFIG SIZE could cause a need to increase the MONDCSS size as well (becuase the Sample Config size comes out of the MONDCSS SAMPLE area). But not to worry, the Perfkit will tell you via messages if this is needed. If you do need to increase the MONDCSS size, you will need to: A-MONITOR STOP B-Ensure there is NO OVERLAP with other DCSS/NSS in address range of MONDCSS (EX: Q NSS ALL MAP to find where all NSS are located) C-CP DEFSEG MONDCSS 9000-9AFF SC RSTD (example locations) D-CP SAVESEG MONDCSS E-RESTART the PERFKIT watching for any Error message at startup. You can also trim down the amount of users/devices being monitored via the MONITOR SAMPLE ENABLE/DISABLE USER userid or MONITOR SAMPLE ENABLE/DISABLE I/O CLASS/DEV (ref CP MONTOR SAMPLE command). I hope this helps. Roger Lunsford IBM z/VM CP/Perfkit/Monitor Level2/Level3
z/VM Security residency
Hello all, there will be a redbook residency in Poughkeepsie, NY, July 9th - Aug 3rd regarding Security on z/VM More info can be found at http://www.redbooks.ibm.com/residents.nsf/50da6a28780ffa688525701b004a4f21/ead9f593e671170b85257296007b4c33?OpenDocumentHighlight=0,z%2Fvm there is still one slot free. Feel free to contact me (marian dot gasparovic at sk dot ibm dot com) or Paola (see contact on page mentioned above) === Marian Gasparovic === The mere thought hadn't even begun to speculate about the merest possibility of crossing my mind. TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/
Re: Z/VM TCPIP Question
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, April 09, 2007 4:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Z/VM TCPIP Question On Monday, 04/09/2007 at 01:05 EST, McKown, John [EMAIL PROTECTED] wrote: The far end shut down the connection. You'd need to look at the logs on the far end. We've had this before when the server ran out of disk space. I doubt that is your problem because you said that it works a bit later. Perhaps the server is overloaded? Or something in between. I have seen overloaded firewalls send RSTs in both directions. The client thinks the server did it and the server thinks the client did it. Alan Altmark Ah. I'm not really an in-depth LAN person. I keep forgetting about intermediate nodes. Even though we had one that would randomly start dropping packets, causing all sorts of problems with the open system server people saying it was the mainframe and us saying it was their server. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Z/VM 5.3 and VMSECURE
Will VMSECURE require maintenance when I move from Z/VM 5.2 to Z/VM 5.3? Will the existing Z/VM 5.2 installation instructions work for Z/VM 5.3? Jim Hughes 603-271-5586 There's no sense in being precise when you don't even know what you're talking about. John von Neumann
Re: Z/VM 5.3 and VMSECURE
The CA policy is to announce support requirements for new levels of an operating system at GA of the new operating system release. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hughes, Jim - OIT Sent: Tuesday, April 10, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Z/VM 5.3 and VMSECURE Will VMSECURE require maintenance when I move from Z/VM 5.2 to Z/VM 5.3? Will the existing Z/VM 5.2 installation instructions work for Z/VM 5.3? Jim Hughes 603-271-5586 There's no sense in being precise when you don't even know what you're talking about. John von Neumann
Tracing VSWITCH - SAG broker problem
Hi all. Sorry for the lengthy post. I have a problem trying to get SAG broker in VSE to talk to SAG broker on a windows platform. For legacy reasons we wish to keep the environment the same so there is NO VSE TCPIP stack involved. This does make it more complicated but that is how it has/is been running in production for 4 years. Overview: VSE Broker talks to VSE net-work which uses IUCV to talk to a CMS NET-WORK userid which then talks to TCPIPC (142.214.154.47) port(7879). TCPIPC is on a VSWITCH connected to the OSA card and then out to the network to the windows server (142.214.62.87) running NET-WORK and broker. The production system uses a different TCP stack and CMS userid but the same VSWITCH and OSA card. VSE NET-WORK can see the windows NET-WORK but when we start the broker services the services fail to start. LOGON Function Started (ETB001) Rsp= 0215 0148 Msg= NET: Connection error LOGON Function Failed The network guys are tracing data to/from the 142.214.154.47 and 142.214.62.87 using their laptop and see no traffic between these IP addresses when we try to start the services. They see traffic when both NET-WORK connect at the beginning. I have set up a NETSTAT OBEY MORETRACE QDIO to see what traffic is being dropped on/picked up from the VSWITCH. (I hope that is what Im tracing). I do see data being captured but the network guys see nothing. As unlikely as it is the data appears to get lost in the VSWITCH or OSA card. 1) Is there some documentation/tools on reading QDIO traces to I can analyze this captured trace? 2) Is there a trace I can setup to trace traffic leaving the VSWITCH to the OSA card or trace certain channels (ports) on the OSA card? Currently one LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by DTCVSW1 userid. Any suggestions would help. Hans Rempel. Sent via the WebMail system at hmrconsultants.com
Re: Z/VM 5.3 and VMSECURE
How could VM:Secure not need an overhaul, or at least a tune up, if it is to support the new pass phrases? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Bolch Sent: Tuesday, April 10, 2007 9:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Z/VM 5.3 and VMSECURE The CA policy is to announce support requirements for new levels of an operating system at GA of the new operating system release. Bob Bolch -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Hughes, Jim - OIT Sent: Tuesday, April 10, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Z/VM 5.3 and VMSECURE Will VMSECURE require maintenance when I move from Z/VM 5.2 to Z/VM 5.3? Will the existing Z/VM 5.2 installation instructions work for Z/VM 5.3? Jim Hughes 603-271-5586 There's no sense in being precise when you don't even know what you're talking about. John von Neumann
Multiprise 2000 Ficon
Hi, I think the answer is no, but I would like to know if you can get a Ficon channel card for a Multiprise 2000. We want to connect the Multiprise to external DASD. We were planning on having Escon and Ficon connections to the external DASD at the same time, but it looks like we can only have one or the other, not both, and if we switch connectors, the data space must be wiped and redefined. So there goes our migration plan. The only Escon to Ficon converters I can find connect Ficon channels to Escon devices, not the other way around. Any ideas? Peter I've seen their type before -- the problem is real, their solution is nonsense, but they feel like everyone should line up behind them because the problem is real. - Anonymous 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 of 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 by 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 basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: Tracing VSWITCH - SAG broker problem
On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel [EMAIL PROTECTED] wrote: Hi all. Sorry for the lengthy post. I have a problem trying to get SAG broker in VSE to talk to SAG broker on a windows platform. For legacy reasons we wish to keep the environment the same so there is NO VSE TCPIP stack involved. This does make it more complicated but that is how it has/is been running in production for 4 years. If it has been working, what changed? 1)Is there some documentation/tools on reading QDIO traces to I can analyze this captured trace? No. To get that level of help you need to open a PMR. 2)Is there a trace I can setup to trace traffic leaving the VSWITCH to the OSA card or trace certain channels (ports) on the OSA card? Currently one LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by DTCVSW1 userid. You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself is done exactly as your network guys are doing - with sniffers. Beware that OSA port sharing enables the OSA to short cut the packets if it recognizes the destination MAC or IP address as belonging to the OSA. And you know how I am about providing pictures, IP addys, and subnet masks. I can't tell if the various hosts are [supposed to be] in the same subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone configuration descriptions, particularly where shared OSAs come into play. :-D Alan Altmark z/VM Development IBM Endicott
Re: Multiprise 2000 Ficon
I think the answer is no, but I would like to know if you can get a Ficon channel card for a Multiprise 2000. We want to connect the Multiprise to external DASD. We were planning on having Escon and Ficon connections to the external DASD at the same time, but it looks like we can only have one or the other, not both, and if we switch connectors, the data space must be wiped and redefined. So there goes our migration plan. The only Escon to Ficon converters I can find connect Ficon channels to Escon devices, not the other way around. Peter: You can NOT put FICON features into a MP2000 (G3 technology). FICON came with G5 technology in 1998. Jim
Time to move
Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I don't expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure I'll just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Multiprise 2000 Ficon
Thanks Jim, That's what I thought, but I was hoping that I had missed something. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Elliott [EMAIL PROTECTED] Sent: April 10, 2007 14:11 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Multiprise 2000 Ficon I think the answer is no, but I would like to know if you can get a Ficon channel card for a Multiprise 2000. We want to connect the Multiprise to external DASD. We were planning on having Escon and Ficon connections to the external DASD at the same time, but it looks like we can only have one or the other, not both, and if we switch connectors, the data space must be wiped and redefined. So there goes our migration plan. The only Escon to Ficon converters I can find connect Ficon channels to Escon devices, not the other way around. Peter: You can NOT put FICON features into a MP2000 (G3 technology). FICON came with G5 technology in 1998. Jim 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 of 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 by 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 basis of the information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is the property of the TTC and must not be altered or circumvented in any manner.
Re: Time to move
Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
In fact, your directory doesn't have to be on the sysres at all. Just make sure the volume it's on is in the CP_Owned list. Dennis O'Brien I wonder if other dogs think poodles are members of a weird religious cult. -- Rita Rudner -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Munson Sent: Tuesday, April 10, 2007 11:32 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Tracing VSWITCH - SAG broker problem
For more information on using the 'SNIFFER' support added in z/VM 5.2.0, please see the Troubleshooting a Virtual Switch or Guest LAN section of the z/VM Connectivity Guide. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking Alan Altmark/Endicott/[EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/10/2007 02:04 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tracing VSWITCH - SAG broker problem On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel [EMAIL PROTECTED] wrote: Hi all. Sorry for the lengthy post. I have a problem trying to get SAG broker in VSE to talk to SAG broker on a windows platform. For legacy reasons we wish to keep the environment the same so there is NO VSE TCPIP stack involved. This does make it more complicated but that is how it has/is been running in production for 4 years. If it has been working, what changed? 1)Is there some documentation/tools on reading QDIO traces to I can analyze this captured trace? No. To get that level of help you need to open a PMR. 2)Is there a trace I can setup to trace traffic leaving the VSWITCH to the OSA card or trace certain channels (ports) on the OSA card? Currently one LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by DTCVSW1 userid. You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself is done exactly as your network guys are doing - with sniffers. Beware that OSA port sharing enables the OSA to short cut the packets if it recognizes the destination MAC or IP address as belonging to the OSA. And you know how I am about providing pictures, IP addys, and subnet masks. I can't tell if the various hosts are [supposed to be] in the same subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone configuration descriptions, particularly where shared OSAs come into play. :-D Alan Altmark z/VM Development IBM Endicott
Re: Time to move
That sound like more trouble than necessary. You can put the DRCT anywhere on the volume. In fact it does not have to be on the IPL volume, just a CPOWNED volume. This does take care and consideration. You might want to do it on a 2nd level test system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Richard Feldman (WFF) Sent: Tuesday, April 10, 2007 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Time to move Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I don't expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure I'll just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Time to move
Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
On Tuesday, 04/10/2007 at 01:51 EST, RPN01 [EMAIL PROTECTED] wrote: Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. WHAT?!? You have something else on your paging volumes? As you say, not ideal. Alan Altmark z/VM Development IBM Endicott
Re: Time to move
On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David From: The IBM z/VM Operating System on behalf of RPN01 Sent: Tue 4/10/2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
Hello Everyone, I have seen, read, and been told about having a separate page volume. It just seems like a true waste of space. Yes, I understand that disk is getting cheaper all the time, but budgets are kept here. I do have room, so the question is with all the VSE systems V=V but with enough real to cover them, and z/VM paging at 0 to 1 per sec, how much of an impact would it be to have paging on other volumes? q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- 430RES 0752257390 24120533563 2% 430W04 0715 1 2000 36 0 0 0% -- -- SUMMARY 384120533 1% USABLE384120533 1% And could you explain (again) the seldom ending channel program for paging? Thanks, Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David
Re: Time to move
It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David From: The IBM z/VM Operating System on behalf of Edward M. Martin Sent: Tue 4/10/2007 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Hello Everyone, I have seen, read, and been told about having a separate page volume. It just seems like a true waste of space. Yes, I understand that disk is getting cheaper all the time, but budgets are kept here. I do have room, so the question is with all the VSE systems V=V but with enough real to cover them, and z/VM paging at 0 to 1 per sec, how much of an impact would it be to have paging on other volumes? q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- 430RES 0752257390 24120533563 2% 430W04 0715 1 2000 36 0 0 0% -- -- SUMMARY 384120533 1% USABLE384120533 1% And could you explain (again) the seldom ending channel program for paging? Thanks, Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David
Re: Time to move
Necessity is the Mother of all... I wanted to share the RES pack between two systems, and I wanted to share the Spool volumes between the two systems. I needed a pack that would be unique to each system, and I didn't want a full mod 27 devoted to just the CP Directory. We don't have any CMS users to speak of, other than two administrators, and the Linux guests are *supposed* to stay up constantly, so the number of logins and links going on are at a bare minimum, so stashing the directory at the front of the paging volume seemed the least painful place to put it. At least, that's the logic I came up with for my choice. I suppose that, if it becomes a huge conflict at some point in the future, I can get my DASD people to carve me out two mod 3's for the directories (and listen to the abuse I'd have to take) and move the directory to these, separating them from the paging. There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 2:19 PM, David Kreuter [EMAIL PROTECTED] wrote: On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David From: The IBM z/VM Operating System on behalf of RPN01 Sent: Tue 4/10/2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
On 4/10/07, RPN01 [EMAIL PROTECTED] wrote: Necessity is the Mother of all... He said, while cleaning his ears with the barrel of a gun :-) There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) Indeed. Have you considered to share you object directory as well? That might amuse many. You would run DIRECTXA on one system, and when that completed you make the other systems issue a Diag3C (iirc) to have them drop any cached portions of the object directory. If you want, you could make the slave system run another DIRECTXA to write an up-to-date on your spare RES volume. If you also want the update-in-place directory it may take a bit more tweaking... Rob
Re: Time to move
But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Tuesday, April 10, 2007 3:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh Why? You dare ask WHY?!? We, the great unwashed, have no need to know why. Yes, I get testy about IBM being so closed mouth. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 4:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
Bottom line is 'Do your users complain about poor performance?'. If not then just make a mental note and move on to more productive things. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 4:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Time to move
And, by the way, the directory can sit on multiple, not contiguous DRCT areas, spread over one or multiple packs. We often ran like this when in urgent need for extra DRCT space. -- Kris Buelens, IBM Belgium, VM customer support
Re: Time to move
On 4/10/07, David Kreuter [EMAIL PROTECTED] wrote: What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. Right. Most installations with Linux these days find that the amount of page packs is given by the need to keep utilization under 50% rather than by having enough heads to achieve high paging rates. Back then some IBM internal systems used part of the volume for paging and the other part for backups (instead of using tape). This made sense because backups were done at night where the system was probably not paging a lot and certainly few users there to suffer from poor paging. Until you allow end-users to also restore data during office hours... -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Time to move
Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I don't expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure I'll just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold.=20 After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa.=20 Sound reasonable?,=20 Some easier solutions have already been suggested, but if you decide to go ahead with this one (or for future reference), do a CLEAN start instead of COLD. The difference between COLD and CLEAN starts is that system data files (NSS, DCSS, IMG, NLS, TRF) files are preserved and restored on a COLD start, but not on a CLEAN start. If you move and re-format your warmstart area, no matter what kind of start you do, the pointers to the system data files will be erased along with the pointers to all of the other spool files. Of course, when you SPXTAPE everything, be sure that you really back up everything, including the system data files. Then do a CLEAN start and restore everything back from tape. You won't save any time doing a COLD start in this situation, especially since the files you may think you are saving will be lost. John Franciscovich z/VM Development
DPROP V7.4 and DB2/VSE 7.3?
We are currently DB2/VSE 7.3 with Capture/VSE (Data Propagator) 7.3. One of the problems with Capture/VSE, is it requires to be administered by DB2/UDB V7. However, with DB2/UDB 7.3 on my PC, I can't use its Control Center (or any code on my PC) to work on DB2/UDB V9.1 (which I have running on an IFL). Catch-22 However, the Program Directory for Data Propagator Q V7.4, says that it would run with DB2/VSE 7.4 and DB2/UDB V8 (and I assume V9 as the Program Directory was written prior to V9 availability). My DB2/VSE 7.3 has maintenance thru Oct/2006 applied. I'm wondering if anyone is running Data Propagator Q 7.4 with DB2/VSE 7.3? Sure would make life easier if it would work. Bad part is where I have test systems that I can test DPROP Q 7.4 on VSE, I don't have a test PC available that I can load DB2/UDB V8 or V9 for testing. I don't want to touch my PC as it is the production administrator for Data Propagator on VSE and I don't want to mistakenly loose my ability to work on our current DB2 software. Thanks Tom Duerbusch THD Consulting
Re: DPROP V7.4 and DB2/VSE 7.3?
Never mind Apparently Data Propagator Q required MQSeries. As in chargeable product. There went that option. Tom Duerbusch THD Consulting Tom Duerbusch [EMAIL PROTECTED] 4/10/2007 4:10 PM We are currently DB2/VSE 7.3 with Capture/VSE (Data Propagator) 7.3. One of the problems with Capture/VSE, is it requires to be administered by DB2/UDB V7. However, with DB2/UDB 7.3 on my PC, I can't use its Control Center (or any code on my PC) to work on DB2/UDB V9.1 (which I have running on an IFL). Catch-22 However, the Program Directory for Data Propagator Q V7.4, says that it would run with DB2/VSE 7.4 and DB2/UDB V8 (and I assume V9 as the Program Directory was written prior to V9 availability). My DB2/VSE 7.3 has maintenance thru Oct/2006 applied. I'm wondering if anyone is running Data Propagator Q 7.4 with DB2/VSE 7.3? Sure would make life easier if it would work. Bad part is where I have test systems that I can test DPROP Q 7.4 on VSE, I don't have a test PC available that I can load DB2/UDB V8 or V9 for testing. I don't want to touch my PC as it is the production administrator for Data Propagator on VSE and I don't want to mistakenly loose my ability to work on our current DB2 software. Thanks Tom Duerbusch THD Consulting
Re: Time to move
Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. --
Re: Tracing VSWITCH - SAG broker problem
Thanks Tracy. I did find a webpage from Paul Giordano talking about tracing VSWITCH but ran into problem/time with IPFORMAT exec. I used sample ETC and Config files from IBM. ipformat debug file a 228 +++ 40 +++ DMSRTL2103E Error in compiled CMS system Rexx file; additional information: 4100 41 IPFORMAT EXEC 228 Ready(20041); T=0.27/0.27 17:50:09 Allan. Thanks for your comments. Nothing has changed or broke in production. We are trying to setup a test environment with new TCPIP stack and network server with new software. I would like to prove that the VSWITCH and OSA are not the problem because I use the same VSWITCH and OSA in the production TCPIP stack. The traces seem to show that data is heading onto the VSWITCH. Why the network folks don't see it is a mystery to me. I have a few tests planned for Thursday morning which I hope will shed more light on the situation. Hans _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tracy J Adams Sent: April 10, 2007 2:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Tracing VSWITCH - SAG broker problem For more information on using the 'SNIFFER' support added in z/VM 5.2.0, please see the Troubleshooting a Virtual Switch or Guest LAN section of the z/VM Connectivity Guide. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking Alan Altmark/Endicott/[EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/10/2007 02:04 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tracing VSWITCH - SAG broker problem On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel [EMAIL PROTECTED] wrote: Hi all. Sorry for the lengthy post. I have a problem trying to get SAG broker in VSE to talk to SAG broker on a windows platform. For legacy reasons we wish to keep the environment the same so there is NO VSE TCPIP stack involved. This does make it more complicated but that is how it has/is been running in production for 4 years. If it has been working, what changed? 1)Is there some documentation/tools on reading QDIO traces to I can analyze this captured trace? No. To get that level of help you need to open a PMR. 2)Is there a trace I can setup to trace traffic leaving the VSWITCH to the OSA card or trace certain channels (ports) on the OSA card? Currently one LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by DTCVSW1 userid. You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself is done exactly as your network guys are doing - with sniffers. Beware that OSA port sharing enables the OSA to short cut the packets if it recognizes the destination MAC or IP address as belonging to the OSA. And you know how I am about providing pictures, IP addys, and subnet masks. I can't tell if the various hosts are [supposed to be] in the same subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone configuration descriptions, particularly where shared OSAs come into play. :-D Alan Altmark z/VM Development IBM Endicott
Re: Time to move
I have systems with paging to 3390-3's. A lot of them. It wasn't hard just tedious. And a one time/seldom effort. -Original Message- From: The IBM z/VM Operating System on behalf of Rob van der Heij Sent: Tue 4/10/2007 5:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move On 4/10/07, David Kreuter [EMAIL PROTECTED] wrote: What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. Right. Most installations with Linux these days find that the amount of page packs is given by the need to keep utilization under 50% rather than by having enough heads to achieve high paging rates. Back then some IBM internal systems used part of the volume for paging and the other part for backups (instead of using tape). This made sense because backups were done at night where the system was probably not paging a lot and certainly few users there to suffer from poor paging. Until you allow end-users to also restore data during office hours... -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Time to move
I understood that. I don't understand why existing code paths that have been around for *A WHILE* would be considered effort by developers, unless it was horribly broken. Shudder. Or no longer in the architecture, unlikely as that may be. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 6:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. --
Re: DPROP V7.4 and DB2/VSE 7.3?
Hi, Tom I think Adam has hit on a good solution for your problemif you have enough PC resources available, try using one of the virtualization tools that are now out there. If you are running a flavor of Windows 9XP, Vista, etc.) as your base system, you might try looking at InnoTeks' VirtualBox solution. it's free and can be downloaded from here: http://www.virtualbox.org/ I've personally used it to run OS/2 Warp and Linux in a v.m. on my Windows based Thinkpad...but I'm kinda weird that way.:-) DJ - Original Message Follows - From: Adam Thornton [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DPROP V7.4 and DB2/VSE 7.3? Date: Tue, 10 Apr 2007 17:18:20 -0500 On Apr 10, 2007, at 4:10 PM, Tom Duerbusch wrote: Bad part is where I have test systems that I can test DPROP Q 7.4 on VSE, I don't have a test PC available that I can load DB2/UDB V8 or V9 for testing. I don't want to touch my PC as it is the production administrator for Data Propagator on VSE and I don't want to mistakenly loose my ability to work on our current DB2 software This sounds like a job for virtualization! Got enough room to put a small virtual machine on your PC, in which you could install the client you want, without messing with your production setup? Adam
