Re: Mod 54's on Linux
Marcy, we are using them. No problems at all with RHEL 4 or 5 linux. We are not using the pavs yet though. Mary Anne On Thu, Apr 24, 2008 at 12:36 AM, Marcy Cortes [EMAIL PROTECTED] wrote: OK, I really mean mod 9 of around size 65,000 cylinders or so (54G), if you want to get technical. Anyone using them for Linux use? Any concerns around the PAV need or un-need? We have had no problems and are happy with the ones of size 32,759 cyls. (primary goal being a) save ucb's and b) less things to put together with LVM for the crazy apps wanting 2TB on their servers). Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: New z/VM 5.3 VSWITCH Port Isolation function
Hi, problem is solved because it occured on z/VM 4.4 and due to out of service I moved to a more recent version and everything works fine :) Thanks! -- With kind regards/Mit freundlichen Gruessen, your/Ihr SuSE Team Wolfgang Engel ([EMAIL PROTECTED]) - SUSE LINUX Products GmbH Tel: +49-911-74053-668 Maxfeldstr. 5 Fax: +49-911-7417755 90409 Nuernberg, Email: [EMAIL PROTECTED] Germany WWW: http://www.suse.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -
Re: SCP/SFTP functionality
On Apr 24, 2008, at 12:25 AM, Thomas Kern wrote: I thought SFTP was an ftp like command set inside the SSH protocol and that FTPS was the FTP protected by SSL. Our Network gurus keep referring too out SSL protected TN3270 as TELNETS and even insisted on us using port 992 for it since that was set in some RFC. You're correct. It also confuses people, I have found, unless you spell them out. I can't imagine why. Add to this the question of flavors of FTPS--that is, with stunnel/ pre-VM-5.3 SSLSERV, you *can* encrypt the control channel, which might be good enough. But if you need to encrypt the data too, you need explicit SSL, and you need to negotiate an encrypted channel. It's enough to make a grown man cry. Adam
Re: (LCOS: 10.6908) Re: (LCOS: 10.6908) Re: Using SET SHARE, performance problem
Hi Tom, These systems have been a long time in creating and we rolled them out over time. It was really only after we converted the last (and most heavily used) one that we hit the 100% point at peak times and are now suffering. Also, we went only from CICS/TS 1.1.0 to CICS/TS 1.1.1 so there isn't anything major there. I checked the frequency of dumps, nothing unusual there. It seems only when relatively heavy batch jobs are run during the peak times that we are pushed to our limits and beyond. I'm curious how you are able to run in one VSE machine with CICS/TS running with a relatively heavy batch job and not have it affect other VSEs if pushed to 100% CPU utilization? Thanks, Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: April 23, 2008 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: (LCOS: 10.6908) Re: (LCOS: 10.6908) Re: Using SET SHARE, performance problem Well, yes and no... I tend to put all partitions in a balance group and then set shares. The reason is that I don't want any batch partitions being starved of CPU. Why? We use DB2. When a batch job issues a query to DB2, which may be over an IP connection, when the results come back, the batch job MUST be able to respond within the timeout option. The same thing happens with batch FTP. But your setup looks fine. That is, CICS is given the CPU when it needs it, over any batch job. All the jobs you have running ahead of CICS, are server class, and really shouldn't be using that much CPU. So, it looks like CICS is using all the CPU it can get and needs more. By any chance have you looked at the console log for CICS (from FAQS d,act,f5)) and see if you are getting a lot of dumps? Also do a CEMT INQ TRDUMPCODE and CEMT INQ SYDUMPCODE. I wonder if you are getting a lot of dumps that may be using up CICS resources. Also, when you went from VSE/ESA 2.6 to z/VSE 4.1, did you pull out the new JCL from ICCF Library(59) and recustomize it? I'm wondering if you either recustomized it wrong, or didn't recustomize it and didn't notice the vast amount of changes between CICS/TS (even though they are the same releases)? I've been bit by just taking the old JCL and using it after FSU upgrades. It works, at least it tests well, butit can be a land mine, just waiting. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Horlick, Michael [EMAIL PROTECTED] 4/23/2008 2:08 PM Hi Tom, This is what we have for our busiest VSE system: PRTYXCM MIKE AR 0015 PRTY G=T=P=BG=FA=F9=F7,Z,F4,F5,F6,E,F8,FB,F3,F2,F1 AR 0015 SHARE G= 100, T= 100, P= 100, BG= 100, FA= 100, F9= 100, F7= 100 F1 = Power, F2 = CA-Faqs F3 = VTAM, FB = BSM, F8 = Tmon/LSS, E = TCP/IP Telnet, F6 = CICS/TS Alternate, F5 = CICS/TS Primary, Z = Zeke, G = TCP/IP batch, all rest are batch partitions. Are you saying that instead of placing CICS/TS above all the batch I should put them in a balanced group and give them a large share value? Thanks, Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: April 23, 2008 2:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: (LCOS: 10.6908) Re: Using SET SHARE, performance problem It's not 10% times 5 machines = 50%NO It is an increase in 10% utilization for the amount of CPU that image was using. Say, you were at 75% cpu utilization prior to z/VSE 4.1. 10% is 7.5% added to 75% is 82.5% expected afterwards. That is for the sum of all the VSE machines. It is not 7.5% times 5 = 37.5% added to 75% = 112.5% If your CPU utilization, when batch isn't running, that is only CICS, database and communication, is under 85%, you don't have a cpu problem. Any problems is either I/O, paging, or scheduling. If you online load (again, no batch), was 85% or more, then, yes, the VSE upgrade did swamp you. If a CPU upgrade isn't in the near future, then you need to tune better (rob Peter to pay Paul). As you said, (I think), that it was the CICS/TS production partition was being impacted with batch was running in the same image, think again, it is the PRTY SHARE you are currently using. It was reset to IBM defaults and you need to update it to what you had it set to prior to the upgrade. Here, our base CPU utilization is about 25% without batch. We have 14 VSE systems running. When we run a lot of batch, with some extensive DB2, we run at 100% for hours. CICS response time, isn't affected. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Horlick, Michael [EMAIL PROTECTED] 4/23/2008 1:29 PM Unfortunately the guy with the EXPLORE/VM stats is off today. I have added them all up and the total VSEs add up to 90%. That's the minimum. There not
Re: z/VM 5,3 installation
Frank says hi back--he was my boss till he got a promotion a few months ago! As for the TCP2PROD messages, they actually seem to indicate that something was installed on the cloned lpar, but nothing was needed on the original lpar. Which is a little weird since this was our first attempt at maintenance on either lpar since the cloning occurred. Here are the messages about LDAPSRV in the original lpar's TCP2PROD $MSGLOG: ST:DTCPRD3021I TCP2PROD processing started ST:DTCPRD3018I No options in effect ST:DTCPRD3040I Issuing command: ST:VMFSIM QUERY SERVP2P PPF TDATA :COMPNAME TCPIPP2P :PRODID (STEM !VMFDATA. ST:DTCPRD3006I Product ID in effect: 5VMTCP30%TCPIP ST:DTCPRD3012I Obtaining PPF :DCL. information... ST:DTCPRD3019I Processing file(s) for: BFS ST: LDAPSRV LOADBFS I -- BFS ST:DTCPRD3058I No source files have been identified that require production ST:status ST:DTCPRD3059I Operations for current entry have been bypassed ST:DTCPRD3021I TCP2PROD processing completed with RC = 0 And here are the messages from the clone (once I'd started up the VMSERV* servers so it wouldn't get an error): ST:DTCPRD3021I TCP2PROD processing started ST:DTCPRD3018I No options in effect ST:DTCPRD3040I Issuing command: ST:VMFSIM QUERY SERVP2P PPF TDATA :COMPNAME TCPIPP2P :PRODID (STEM !VMFDATA. ST:DTCPRD3006I Product ID in effect: 5VMTCP30%TCPIP ST:DTCPRD3012I Obtaining PPF :DCL. information... ST:DTCPRD3019I Processing file(s) for: BFS ST: LDAPSRV LOADBFS I -- BFS ST:DTCPRD3038I LOADBFS command completed with RC = 0 ST:DTCPRD3021I TCP2PROD processing completed with RC = 0 Is there somewhere I can look to figure out what file(s) the cloned lpa r was processing at that time? Thanks! Shannon
Re: OSA rdev and vdev requirements for Linux guests.
Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Steve G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, April 24, 2008 12:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. 7000, 7001, 7002 used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, 7004, 7005, 7006 used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: (LCOS: 10.6908) Re: (LCOS: 10.6908) Re: Using SET SHARE, perf ormance problem
We used a different approach to this. Our CPU is a quad. We do not run VSE's turbo dispatcher in multi-engine mode as little of our workload is able to benefit. This limits each VSE guest to dispatch on a single CP and minimizes one VSE's ability to dominate the entire box. Note that each guest's workload fits MIP-wise onto a single CP, the guests do not sit at 100%. We have multiple production guests and balance the work across them as evenly as possible. We also use prty share within the balanced partitions, with the lowest value being 100 and the highest being 3000 or more. Weird? Probably. But quite effective in our environment with our workload. Mike Horlick wrote: I'm curious how you are able to run in one VSE machine with CICS/TS running with a relatively heavy batch job and not have it affect other VSEs if pushed to 100% CPU utilization? Thanks, Mike
Re: OSA rdev and vdev requirements for Linux guests.
VSWITCHes are very nice for isolating the Linux guests from external VLAN requirements. The Linux guests can be VLAN unaware and the VSWITCH handles tagging and untagging all the frames. They are also very nice for failover to an alternate OSA. No need to burden the Linux guests with that. Additionally, using VSWITCHes removes the need to hunt through the directory (or other documentation) for an unused real address. Can it be done with real OSA's, yeah, but VSWITCHes make life much, much easier. I wish a VSWITCH could connect to a Hypersocket as it's RDEV. *THAT* would make life really good. Brian Nielsen On Thu, 24 Apr 2008 07:51:34 -0400, Gentry, Stephen [EMAIL PROTECTED] wrote: Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Steve G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, April 24, 2008 12:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. 7000, 7001, 7002 used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, 7004, 7005, 7006 used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail. = ===
Dumpscan CP Abend z/VM 5.3
We took two CP abends Code (Hard) FRE016 which appears to be a header block clobber caused by the an application CA's VMSECURE. Level is z/VM 5.3 service level 0702. I loaded both Dumps down to OPERATNS 191 disk using DUMPLOAD and than tried to run a DUMPSCAN and receive a HCSPRC740I - Prefix Page could not be found. I can't find the error message in any of the IBM z/VM5.3 documentation I have. Does anyone know what this error indicates? I wanted to have a formatted dump before opening a call with IBM. Thank, Bill
Re: Dumpscan CP Abend z/VM 5.3
HELP HCSPRC740I returns: ,MSG HCSPRC740I All Help Information line 1 of 11 (c) Copyright IBM Corporation 1990, 2007 HCS740I THE PREFIX PAGE COULD NOT BE FOUND Explanation: The pointer to the prefix page was either zero, not on a 4KB boundary, or pointed to an address that is not in the dump. System Action: Processing continues, if possible. User Response: Enter a new subcommand. DUMPSCAN does not format a dump it just interprets it. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Capo Sent: Thursday, April 24, 2008 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Dumpscan CP Abend z/VM 5.3 We took two CP abends Code (Hard) FRE016 which appears to be a header block clobber caused by the an application CA's VMSECURE. Level is z/VM 5.3 service level 0702. I loaded both Dumps down to OPERATNS 191 disk using DUMPLOAD and than tried to run a DUMPSCAN and receive a HCSPRC740I - Prefix Page could not be found. I can't find the error message in any of the IBM z/VM5.3 documentation I have. Does anyone know what this error indicates? I wanted to have a formatted dump before opening a call with IBM. Thank, Bill This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: OSA rdev and vdev requirements for Linux guests.
Right, for redundancy, you'd want to have 2 different OSAs cards - each on a different physical switch. We have lost OSA cards here physical switches go down too (planned and unplanned). The vswitch will provide failover for all of the Linux servers. Dedicating OSA addresses and having failover would require 6 addresses per guest and some sort of dynamic routing protocol on them to redirect traffic should an interface be down. There is overhead in that too. Attaching real addresses also makes provisioning new guests a bigger challenge. And there is the UCB shortage issue here... So yeah, IMHO, if you have more the one Linux guest, vswitch is the way to go. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brian Nielsen Sent: Thursday, April 24, 2008 9:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] OSA rdev and vdev requirements for Linux guests. VSWITCHes are very nice for isolating the Linux guests from external VLAN= requirements. The Linux guests can be VLAN unaware and the VSWITCH handles tagging and untagging all the frames. They are also very nice for failover to an alternate OSA. No need to burden the Linux guests with that. Additionally, using VSWITCHes removes the need to hunt through the directory (or other documentation) for an unused real address. Can it be done with real OSA's, yeah, but VSWITCHes make life much, much = easier. I wish a VSWITCH could connect to a Hypersocket as it's RDEV. = *THAT* would make life really good. Brian Nielsen On Thu, 24 Apr 2008 07:51:34 -0400, Gentry, Stephen [EMAIL PROTECTED] wrote: Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Steve G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes Sent: Thursday, April 24, 2008 12:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA rdev and vdev requirements for Linux guests. Wait, what are you doing attaching osa's to Linux? VSWITCH! Seriously, I think you use a lot more storage on the Linux guest and make him less likely to be idle. Marcy Cortes This message may contain confidential and/or privileged information. If= you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on= this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Wednesday, April 23, 2008 9:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA rdev and vdev requirements for Linux guests. Way back when, in the olden days, I seem to remember that the first OSA address of a triplet used by Linux guests had to be an even address. But then there are also vague memories of more recent information that as long as the first OSA vdev of a triplet seen by a guest is even, it does not matter if its rdev is odd. Is that true, or have I been sneaking sips of Adam's cough medicine? If the first vdev of the triplet being even is all that matters, do all the rdevs have to be in ascending sequential order? Or could we harvest all those lone, odd-numbered OSA rdevs? E.g. 7000,= 7001, 7002 used, reclaim the abandoned 7003 rdev to be assigned as an even-numbered vdev, 7004, 7005, 7006 used, reclaim the abandoned 7007 rdev to be assigned as an even-numbered vdev, etc.)? And... where is this documented that I obviously overlooked? Of course if a restriction were removed, where would one find it documented except= in old manuals and folklore? :-) Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from= disclosure. If you are not the intended recipient of this message, or if= this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including= any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail
Re: Dumpscan CP Abend z/VM 5.3
CP dumps need to be displayed with the VMDUMPTL command; DUMPCSAN is for ancient CP dumps or VMDUMPS. One still uses DUMPLOAD to read the dump from the spool onto SFS or Minidisk. 2008/4/24, Stracka, James (GTS) [EMAIL PROTECTED]: HELP HCSPRC740I returns: ,MSG HCSPRC740I All Help Information line 1 of 11 (c) Copyright IBM Corporation 1990, 2007 HCS740I THE PREFIX PAGE COULD NOT BE FOUND Explanation: The pointer to the prefix page was either zero, not on a 4KB boundary, or pointed to an address that is not in the dump. System Action: Processing continues, if possible. User Response: Enter a new subcommand. DUMPSCAN does not format a dump it just interprets it. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Capo Sent: Thursday, April 24, 2008 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Dumpscan CP Abend z/VM 5.3 We took two CP abends Code (Hard) FRE016 which appears to be a header block clobber caused by the an application CA's VMSECURE. Level is z/VM 5.3 service level 0702. I loaded both Dumps down to OPERATNS 191 disk using DUMPLOAD and than tried to run a DUMPSCAN and receive a HCSPRC740I - Prefix Page could not be found. I can't find the error message in any of the IBM z/VM5.3 documentation I have. Does anyone know what this error indicates? I wanted to have a formatted dump before opening a call with IBM. Thank, Bill This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- Kris Buelens, IBM Belgium, VM customer support
Re: OSA rdev and vdev requirements for Linux guests.
Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Ties a guest to a particular piece of hardware (failure point), and forces the guest to handle all the recovery, ARP management, etc. Having CP do it for multiple guests is a much more resource efficient approach. It also ultimately uses up a lot more OSA port triplets, which aren't free. A couple 10G cards aren't cheap, but they're cheaper than multiple 1G cards, and you'll get better utilization out of the 10G cards. You also get a better chance to move any network processing outside the Z box -- 10G cards in switches tend to have LOTS of horsepower, and they're way, WAY cheaper than an IFL. Seriously, why shouldn't this be done? Consumes lots of memory in each guest (16M per OSA is the default, I think). Also forces the guest to be dispatched more often to handle all the I/O (particularly noticeable when using layer 2 where the guest has to handle ARP and other stuff). It's also a lot more management-intensive to have to figure out all that port mapping in the first place, and then figure it out again in a DR situation where the hardware is different. With VSWITCH, you change it in one place and it's done for all the guests on that VSWITCH whether you have 1 or 100.
Re: SCP/SFTP functionality
I know. I have been in too many conversations where I say that z/VM can support FTPS and the other instantly say 'Good, we can use SFTP from our SSH sessions.' So I have to re-educate them and 2 months later the scene repeats with the same cast of characters. At times, I regret having worked out how to do FTPS on z/VM. My time and efforts would have been better utilized in creating a secure drop-zone server using linux. /Tom Kern Adam Thornton wrote: On Apr 24, 2008, at 12:25 AM, Thomas Kern wrote: I thought SFTP was an ftp like command set inside the SSH protocol and that FTPS was the FTP protected by SSL. Our Network gurus keep referring too out SSL protected TN3270 as TELNETS and even insisted on us using port 992 for it since that was set in some RFC. You're correct. It also confuses people, I have found, unless you spell them out. I can't imagine why. Add to this the question of flavors of FTPS--that is, with stunnel/pre-VM-5.3 SSLSERV, you *can* encrypt the control channel, which might be good enough. But if you need to encrypt the data too, you need explicit SSL, and you need to negotiate an encrypted channel. It's enough to make a grown man cry. Adam
Re: Dumpscan CP Abend z/VM 5.3
DUMPSCAN doesn't support CP dumps, you need to use VMDUMPTL. Rick Bourgeois Virtual Software Systems, Inc. 7715 Browns Bridge Rd Gainesville, GA 30506 [EMAIL PROTECTED] 770-781-3200 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Capo Sent: Thursday, April 24, 2008 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Dumpscan CP Abend z/VM 5.3 We took two CP abends Code (Hard) FRE016 which appears to be a header block clobber caused by the an application CA's VMSECURE. Level is z/VM 5.3 service level 0702. I loaded both Dumps down to OPERATNS 191 disk using DUMPLOAD and than tried to run a DUMPSCAN and receive a HCSPRC740I - Prefix Page could not be found. I can't find the error message in any of the IBM z/VM5.3 documentation I have. Does anyone know what this error indicates? I wanted to have a formatted dump before opening a call with IBM. Thank, Bill
Re: VTAM R.I.P. -- SNATAM anyone?
I can't help but toss in two cents here... Back many years ago when I worked up at IBM Boulder we had an edict to install VTAM access to our VM system so all the sales people around the country could get PROFS. There was no GCS at the time, and the whole VS/1, VTAM, VSCS thing was a mess, unstable, and devoured our machine... We stumbled into a project from the Rochester MN lab called SNATAM. A true VM-based implementation of SNA. As I recall... It ran in a couple CMS userids and all the config files were just CMS files. It talked to MVS by CTCs and also supported attached 3745s. It was small, neat and efficient. Then management found our that we were running it instead of VTAM on such a high visibility project and forced us to switch to the VS/1 VTAM VSCS mess. Then eventually GCS etc. Then, when the Notes edict killed PROFS, it killed the need for VTAM there... The silly part was that the sales people across the country never even knew they were using VM -- just PROFS... If they knew they used VM all the time maybe they wouldn't have talked down about it so much... Sigh... Lee (no VTAM on my lab systems!) Jim Bohnsack wrote: We still have it here, but I suspect that it is not long lived. Some of my worst memories involve VTAM on VM. I was the VM team leader for the IBM Education support center in Dallas in 1985 and told my manager and my 2nd level that we should get VM/SP R4 for the remote locations we suppported and HPO R4 for the central site 3081's. R4 was the release with native VTAM support. VTAM had been supported for a while with VS/1 or DOS/VS hosting VTAM but someone decided that GCS was the way to go. They took a gutted MVS/XA and quickly fitted it into VM. I don't remember that GCS abended all the time, but CP certainly did. VM/SP R4, with and without HPO was an absolute disaster. If we went thru a day without a CP abend, we celebrated. R4 was probably the shortest lived VM release ever. I think it went GA in December of 1985 and was replaced with VM/SP 4.3 in about March. It was a great improvement. During the fall of '85, Barton Robinson practically lived with us being the expert from the East sent to help us. I remember the arguments inside IBM regarding VTAM vs. TCPIP. IBM was going to be pure VTAM. It's too bad that internal IBM was so stuck on SNA and VTAM that there could not have been an earlier combination of the two disciplines. Jim Schuh, Richard wrote: Lee Stewart, Senior SE Sirius Computer Solutions Phone: (303) 798-2954 Fax: (720) 228-2321 Email: [EMAIL PROTECTED] Web: www.siriuscom.com
Re: VTAM R.I.P. -- SNATAM anyone?
I remember the SNATAM name now. There was an Englishman, Graham Pursey, who used to attend the VNET Project Team meetings that were held once or twice a year. It seems to me that he was involved in some kind of VM based VTAM project. Was that it or was there something else? It seems to me that there was something besides SNATAM. Getting old and memory is the second thing to go. Don't remember what the first was. Jim Lee Stewart wrote: I can't help but toss in two cents here... Back many years ago when I worked up at IBM Boulder we had an edict to install VTAM access to our VM system so all the sales people around the country could get PROFS. There was no GCS at the time, and the whole VS/1, VTAM, VSCS thing was a mess, unstable, and devoured our machine... We stumbled into a project from the Rochester MN lab called SNATAM. A true VM-based implementation of SNA. As I recall... It ran in a couple CMS userids and all the config files were just CMS files. It talked to MVS by CTCs and also supported attached 3745s. It was small, neat and efficient. Then management found our that we were running it instead of VTAM on such a high visibility project and forced us to switch to the VS/1 VTAM VSCS mess. Then eventually GCS etc. Then, when the Notes edict killed PROFS, it killed the need for VTAM there... The silly part was that the sales people across the country never even knew they were using VM -- just PROFS... If they knew they used VM all the time maybe they wouldn't have talked down about it so much... Sigh... Lee (no VTAM on my lab systems!) -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: OSA rdev and vdev requirements for Linux guests.
On Thursday, 04/24/2008 at 10:27 EDT, Gentry, Stephen [EMAIL PROTECTED] wrote: Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Off the top of my head: (a) Security. You now limit what can be done with the OSA since you give it to a guest to use. You wouldn't want to share it with other guests (IMO). Do you know what low-level functions are available in the OSA? Me neither, but a virtual NIC is designed to prevent a guest from doing things you don't want it to do or limiting the scope of what it does. And I certainly wouldn't even THINK about letting a guest have arbitrary access to all your VLANs unless it is supposed to have that access. (b) High availability. If a guest is handling the OSA, then the guest must handle any OSA, cable, or switch errors or device outages. The VSWITCH handles that transparently for all guests using the VSWITCH. What if you have 5 guests that need OSAs? Each would need a backup as well. (c) Utilization. Who is using the OSA when this guest isn't? Does it sit idle? A VSWITCH operates an OSA on behalf of multiple guests. Alan Altmark z/VM Development IBM Endicott
Re: OSA rdev and vdev requirements for Linux guests.
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 04/24/2008 10:23:39 PM: On Thursday, 04/24/2008 at 10:27 EDT, Gentry, Stephen [EMAIL PROTECTED] wrote: Ok, I'll ask. Why wouldn't one attach an OSA card directly to a Linux guest? Seriously, why shouldn't this be done? Alan Altmark wrote: Off the top of my head: snip (b) High availability. If a guest is handling the OSA, then the guest must handle any OSA, cable, or switch errors or device outages. The VSWITCH handles that transparently for all guests using the VSWITCH. What if you have 5 guests that need OSAs? Each would need a backup as well. Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH with two OSAs (connected to different real switches), and the only thing attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the TCPIP machine attached to both OSAs and VIPA provided for high availability. I don't need MPROUTE any more, just simple static routing. Much easier to support. 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
Re: OSA rdev and vdev requirements for Linux guests.
On Thursday, 04/24/2008 at 11:44 EDT, Mark Wheeler [EMAIL PROTECTED] wrote: Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH with two OSAs (connected to different real switches), and the only thing attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the TCPIP machine attached to both OSAs and VIPA provided for high availability. I don't need MPROUTE any more, just simple static routing. Much easier to support. Amen to that. VM TCP/IP doesn't get any more of a free pass than any other guest and gets all the benefits VSWITCH can provide. The only question you need to be able to answer is: What is your alternate logon path if VM TCP/IP OR the VSWITCH is down? You need to have emergency automation, OSA-ICC or HMC 3270. WARNING: THE OSAs ARE NOW IN THE POSESSION OF VM TCP/IP ONLY TELNET IS AVAILABLE. ACCESS IS RESTRICTED TO MAINT, OPERATOR, AND SUPER-SECRET USERID CHUCKIE. YOU HAVE -- 15 -- MINUTES UNTIL SYSTEM SHUTDOWN. STOP SHUTDOWN MY SUCCESSFULLY LOGGING ON AND ISSUING SMSG MOTHER CANCEL. Alan Altmark z/VM Development IBM Endicott
Re: OSA rdev and vdev requirements for Linux guests.
My friend Mark worte: Even on my legacy VM systems (no Linux guests at all) I define a VSWITCH with two OSAs (connected to different real switches), and the only thing attached to the VSWITCH is the TCPIP virtual machine. Prior to VSWITCH the TCPIP machine attached to both OSAs and VIPA provided for high availability. I don't need MPROUTE any more, just simple static routing. Much easier to support. And someday we'll have layer 2 VM stack and all the OSA's in LACP mode happily sharing the workload over that whole farm of OSAs we have laying around. Then we can say we're done and Chuckie can retire. Wait, he's way too young. We'll find something else interesting for him to do. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: OSA rdev and vdev requirements for Linux guests.
Alan Altmark wrote:
Amen to that. VM TCP/IP doesn't get any more of a free pass than any
other guest and gets all the benefits VSWITCH can provide.
The only question you need to be able to answer is: What is your
alternate
logon path if VM TCP/IP OR the VSWITCH is down? You need to have
emergency automation, OSA-ICC or HMC 3270.
WARNING: THE OSAs ARE NOW IN THE POSESSION OF VM TCP/IP
ONLY TELNET IS AVAILABLE. ACCESS IS RESTRICTED TO
MAINT, OPERATOR, AND SUPER-SECRET USERID CHUCKIE.
YOU HAVE -- 15 -- MINUTES UNTIL SYSTEM SHUTDOWN.
STOP SHUTDOWN MY SUCCESSFULLY LOGGING ON AND
ISSUING SMSG MOTHER CANCEL.
Well, my legacy systems still run VTAM (with redundant OSAs and FICON CTC
paths to the z/OS CMC's), and I also interconnect them all with PVM. If
either VTAM or TCPIP is alive on any system, I can probably get to any
other.
On my Linux-hosting systems, I have both a TCPIP and a TCPIP2 stack. TCPIP
has a VSWITCH connection, and redundant FICON CTCs (through different
directors) connected to the IFL and z/OS LPARs on a CEC in our other
datacenter, as well as hipersocket connections to z/OS systems on the same
CEC (BTW, the OSAs on the z/OS systems need to be defined as PRIROUTERs if
they're going to provide a path to your IFLs if everything else is down).
Need to run MPROUTE here, of course, and setting appropriate COST0 factors
can get tricky.
TCPIP2 is my trusty back door, and can be set up with a hipersocket, CTC,
VSWITCH, or OSA connection (whichever suits your configuration the best).
Nothing fancy. You just want it to work WHEN YOU REALLY NEED IT, like when
you need to work on the primary stack machine, or in spite of all your
fancy configuration efforts the darn thing goes down anyway. :-( I run
limitted services on it - just telnet and FTP. And OSASF, again just in
case.
True story: Our z/OS systems TCPIP's are configured with two OSAs
(different than the OSAs used by the IFL's) and use VIPA for high
availability. They were upgraded to z/OS 1.7 a while back and there was a
bug (a combination of software and microcode problems, IIRC) that caused
BOTH OSA connections to drop (and could not be restarted). For two days no
one noticed! Why? Because OSPF had dutifully rerouted traffic to the z/OS
system through the IFL's VSWITCH and across the hipersocket link. And if
that VM system had been down, the z/OS traffic would have been routed to
the VSWITCH of the IFL in the other datacenter and across the FICON CTC
link. Cool, no? We continued to run that way until the following weekend,
when the z/OS folks could schedule a planned outage to fix their problem.
sarcasm
And that's another reason why we're killing our IFLs. (:{
/sarcasm
Mark Wheeler, 3M Company
