Re: Supporting Dot.1q trunk in z/Linux
Marcy :) Your using a trunk port requires the vswitch to "vlan tag" the stuff sent over it. So say you have default vlan of 100 on the vswitch going out over it and your vswitch has that defined as the default. Then if the IP x.x.x.x is on vlan 100 then you don't need a vlan on the grant. If the IP x.x.y.x is on vlan 200 then you will need a VLAN parm on the vswitch grant. Like set vswitch vswitch1 grant Linux8 vlan 200. I kind of feel it's safer to always put a vlan number on any grant on a vswitch using a trunk port. Symptoms of getting it wrong will be no packets going anywhere on a 'q vswitch details" Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Saturday, March 26, 2011 10:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Supporting Dot.1q trunk in z/Linux Mary, What would be the LAN name on the GRANT? And is the GRANT the place I would need to specify LAN parameter? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes Sent: Saturday, March 26, 2011 10:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux Right, your vswitch and nicdef statements don't change.You may have to put a vlan on your SET VSWITCH GRANT statements. Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, March 24, 2011 8:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Supporting Dot.1q trunk in z/Linux Thanks Alan, this is what I was looking for. So the Vswitch and the NIC def for the guest does not change correct? It appears that the only thing that changes is at the switch level where it becomes a Trunk connection correct? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Thursday, March 24, 2011 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux On Thursday, 03/24/2011 at 01:01 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" wrote: > So my question is from my z/Linux side what changes to I need to make and where > are these changes reflected In my setup on the z/Linux. Just so you know my > z/VM TCP/IP stack is not really being used for the z/Linux guests that is being > done within z/Linux in my case RHEL 5.2 You will make NO changes to your Linuxes. Those on existing subnet A will remain there and be on VLAN "A". New ones on Subnet B will be assigned to VLAN "B". When a Linux on A and one on B want to talk to each other, the traffic will flow into the VSWITCH, down the OSA, out of the box, into the router, and back. This may generate a requirement to reassign IP addrs so that those two servers are placed in the same subnet, with no need for traffic to flow out of the box. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Supporting Dot.1q trunk in z/Linux
Mary, What would be the LAN name on the GRANT? And is the GRANT the place I would need to specify LAN parameter? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes Sent: Saturday, March 26, 2011 10:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux Right, your vswitch and nicdef statements don't change.You may have to put a vlan on your SET VSWITCH GRANT statements. Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, March 24, 2011 8:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Supporting Dot.1q trunk in z/Linux Thanks Alan, this is what I was looking for. So the Vswitch and the NIC def for the guest does not change correct? It appears that the only thing that changes is at the switch level where it becomes a Trunk connection correct? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Thursday, March 24, 2011 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux On Thursday, 03/24/2011 at 01:01 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" wrote: > So my question is from my z/Linux side what changes to I need to make and where > are these changes reflected In my setup on the z/Linux. Just so you know my > z/VM TCP/IP stack is not really being used for the z/Linux guests that is being > done within z/Linux in my case RHEL 5.2 You will make NO changes to your Linuxes. Those on existing subnet A will remain there and be on VLAN "A". New ones on Subnet B will be assigned to VLAN "B". When a Linux on A and one on B want to talk to each other, the traffic will flow into the VSWITCH, down the OSA, out of the box, into the router, and back. This may generate a requirement to reassign IP addrs so that those two servers are placed in the same subnet, with no need for traffic to flow out of the box. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Supporting Dot.1q trunk in z/Linux
Thanks Mary! Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes Sent: Saturday, March 26, 2011 10:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux Right, your vswitch and nicdef statements don't change.You may have to put a vlan on your SET VSWITCH GRANT statements. Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, March 24, 2011 8:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Supporting Dot.1q trunk in z/Linux Thanks Alan, this is what I was looking for. So the Vswitch and the NIC def for the guest does not change correct? It appears that the only thing that changes is at the switch level where it becomes a Trunk connection correct? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Thursday, March 24, 2011 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux On Thursday, 03/24/2011 at 01:01 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" wrote: > So my question is from my z/Linux side what changes to I need to make and where > are these changes reflected In my setup on the z/Linux. Just so you know my > z/VM TCP/IP stack is not really being used for the z/Linux guests that is being > done within z/Linux in my case RHEL 5.2 You will make NO changes to your Linuxes. Those on existing subnet A will remain there and be on VLAN "A". New ones on Subnet B will be assigned to VLAN "B". When a Linux on A and one on B want to talk to each other, the traffic will flow into the VSWITCH, down the OSA, out of the box, into the router, and back. This may generate a requirement to reassign IP addrs so that those two servers are placed in the same subnet, with no need for traffic to flow out of the box. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Supporting Dot.1q trunk in z/Linux
Right, your vswitch and nicdef statements don't change.You may have to put a vlan on your SET VSWITCH GRANT statements. Marcy -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Thursday, March 24, 2011 8:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Supporting Dot.1q trunk in z/Linux Thanks Alan, this is what I was looking for. So the Vswitch and the NIC def for the guest does not change correct? It appears that the only thing that changes is at the switch level where it becomes a Trunk connection correct? Thank You, Terry Martin Lockheed Martin CMS - CITIC 3300 Lord Baltimore Drive, Suite 200, 21244 Engineering Computing Mainframe Support Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Thursday, March 24, 2011 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Supporting Dot.1q trunk in z/Linux On Thursday, 03/24/2011 at 01:01 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" wrote: > So my question is from my z/Linux side what changes to I need to make and where > are these changes reflected In my setup on the z/Linux. Just so you know my > z/VM TCP/IP stack is not really being used for the z/Linux guests that is being > done within z/Linux in my case RHEL 5.2 You will make NO changes to your Linuxes. Those on existing subnet A will remain there and be on VLAN "A". New ones on Subnet B will be assigned to VLAN "B". When a Linux on A and one on B want to talk to each other, the traffic will flow into the VSWITCH, down the OSA, out of the box, into the router, and back. This may generate a requirement to reassign IP addrs so that those two servers are placed in the same subnet, with no need for traffic to flow out of the box. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: RSCS Problem - return code=- 1 error number=54 (Connection reset by peer)
David, Thanks for the suggestions but I think there is a fundamental problem with our TCP/IP set up. I tried sending files via FTP and get exactly the same problem, small ones get through but larger transfers hang. Time to get my networking hat on :-) Regards, Paul Garment Global z/OS Virtual Host Environment Global z/OS Core Engineering Ground Floor - B3 Block 10 - Radbroke Hall Knutsford, Cheshire WA16 9EU Mail Van 49 Tel: 0044 (0)1565-614429 Clearway 7-2000-4429 Mobile 07824527131 From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: 24 March 2011 17:36 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Problem - return code=- 1 error number=54 (Connection reset by peer) Here's a known working one with TA0: LINKDEF WKSTN14 TYPE TCPNJE QUEUE SIZE RET SLOW 9000 8100 NODE WKSTN14 PARM WKSTN14 HOST=x.x.x.x KEEPALIV=YES STREAMS=1 TA=0 BUFF=3976 And one with TA=1: LINKDEF WKSTN15 TYPE TCPNJE QUEUE SIZE RET SLOW 9000 8100 NODE WKSTN15 PARM WKSTN15 HOST=y.y.y.y KEEPALIV=YES STREAMS=7 TA=1 BUFF=3976 From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: Thursday, March 24, 2011 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Problem - return code=- 1 error number=54 (Connection reset by peer) Explicitly code it. If you are using TA=0, then streams MUST be 1. If you are using TA=1, you have to spell out all 7 streams. This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority.
DB2 Connect and DB2 V7.5
Thanks to all who responded! The DB2 Connect V8.1 is the Enterprise Version, it works well with the VM DB2 V7.3 Database (without Stored Procedure Server). Meanwhile I did an unload of the modules from P1 (V7.3) and loaded them into T1 (V7.5): now all works well. But this is not my preferred method for migration :-) I have little knowledge of the Linux/DB2 Connect System. Rebinding should be done from Linux. But this is a production system and I don't know what a rebind causes changes on the Linux side itself. I don't want to disturb the production system connection. TIA Ewald Roller
Re: Support Element (SE) vs HMC and IP Addresses
The HMC "can do things" because it talks to the SE. As an example, the SE is where the IOCDS is stored, it's really what you talk to when you make lpar profile changes. There are some things you can't do from the HMC, that's why there is the "single object operation" option on the HMC to connect to the SE. What you should have is a firewall between your HMC/SE network and your company network. That is how we have it set up. This way we can limit what/who can "see" the HMC/SE equipment. When the HMC/SE equipment needs to connect cross the company network we assign "normal" company IP addresses to those connections. An example of this would be the HMCs talking to the company NTP servers to sync their time for STP support. Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of George Henke/NYLIC Sent: Friday, March 25, 2011 6:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Support Element (SE) vs HMC and IP Addresses Also, would someone kindly explain the functional differences between the Support Element (SE) and the Hardware Management Console (HMC) other than the HMC can: * do everything an SE can do * do it for more than one CEC * do it as a portal for the intra/internet * Alan Altmark Sent by: The IBM z/VM Operating System 01/19/2011 12:50 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Support Element (SE) vs HMC and IP Addresses On Wednesday, 01/19/2011 at 10:59 EST, George Henke/NYLIC wrote: > ty, Kris, I am trying to setup RSF (Remote Support Facility) fot our new z/196 > coming in soon and need to make one of the HMC adapters available to the IBM > Support System via the internet. Follow the instructions in the HMC Broadband RSF guide located in ResourceLink. The HMC will use NAT to proxy the SEs onto your networks. Whatever you do, don't connect the SEs directly to your network! The z196 installation guide also has a chapter on planning for your RSF connection. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: Support Element (SE) vs HMC and IP Addresses
Also, would someone kindly explain the functional differences between the Support Element (SE) and the Hardware Management Console (HMC) other than the HMC can: do everything an SE can do do it for more than one CEC do it as a portal for the intra/internet Alan Altmark Sent by: The IBM z/VM Operating System 01/19/2011 12:50 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Support Element (SE) vs HMC and IP Addresses On Wednesday, 01/19/2011 at 10:59 EST, George Henke/NYLIC wrote: > ty, Kris, I am trying to setup RSF (Remote Support Facility) fot our new z/196 > coming in soon and need to make one of the HMC adapters available to the IBM > Support System via the internet. Follow the instructions in the HMC Broadband RSF guide located in ResourceLink. The HMC will use NAT to proxy the SEs onto your networks. Whatever you do, don't connect the SEs directly to your network! The z196 installation guide also has a chapter on planning for your RSF connection. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: Support Element (SE) vs HMC and IP Addresses
Alan Altmark wrote: Our networking people say the SE's are reachable from our corporate intranet so that we can provide redundance for two mainframes, 1000 miles apart. But I suspect they are reachable only through the HMC. If the SE's are connected directly to the corporate intranet,, what problems might we expect to have? Alan Altmark Sent by: The IBM z/VM Operating System 01/19/2011 12:50 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Support Element (SE) vs HMC and IP Addresses On Wednesday, 01/19/2011 at 10:59 EST, George Henke/NYLIC wrote: > ty, Kris, I am trying to setup RSF (Remote Support Facility) fot our new z/196 > coming in soon and need to make one of the HMC adapters available to the IBM > Support System via the internet. Follow the instructions in the HMC Broadband RSF guide located in ResourceLink. The HMC will use NAT to proxy the SEs onto your networks. Whatever you do, don't connect the SEs directly to your network! The z196 installation guide also has a chapter on planning for your RSF connection. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: DB2 Connect and DB2 V7.5
Hello Ewald, I think the missing OBJECTs with CREATOR of NULLID are from running a BIND from UDB DB2/Connect against a DB2/VM server using DB2??LST. Please check your UDB DB2/Connect PD. However, you also have to run the following 'GRANT's before running the UDB DB2/Connect BIND: CONNECT SQLDBA IDENTIFIED BY SQLDBAPW; SET ERRORMODE CONTINUE; GRANT SELECT ON SYSTEM.SYSCATALOG TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSCOLUMNS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSINDEXES TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSTABAUTH TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSKEYCOLS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSINDEXES TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSTABAUTH TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSKEYCOLS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSSYNONYMS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSKEYS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSVIEWS TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSCOLAUTH TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSTEM.SYSPROGAUTH TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSCAT.ROUTINES TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSCAT.INDEXES TO NULLID WITH GRANT OPTION; GRANT SELECT ON SYSCAT.INDEXCOLUSE TO NULLID WITH GRANT OPTION; COMMIT WORK RELEASE; ...Roland --- On Fri, 3/25/11, E. Roller wrote: From: E. Roller Subject: DB2 Connect and DB2 V7.5 To: IBMVM@LISTSERV.UARK.EDU Date: Friday, March 25, 2011, 10:54 AM Hi, struggling on with implementing DB2 V7.5, on VM I got some DRDA Problems with DB2 Connect. Environment: Database P1 is on Level 7.3 Database T1 is on Level 7.5 DB2 Connect V7.2 connects to P1 and T1 with no problems DB2 Connect V8.1 connects to P1 with no problems DB2 Connect V8.1 connecting to T1 ends up with errors: Warning: SQL error: [IBM][CLI Driver][SQLDS/VM] SQL0805N Package ".NULLID.SYSSN200" was not found. SQLSTATE=51002 , SQL state 51002 in SQLExecDirect in /web/intern/htdocs/archivts/TA0010.php on line 292 Warning: SQL error: [IBM][CLI Driver][SQLDS/VM] SQL0805N Package ".NULLID.SYSSN200" was not found. SQLSTATE=51002 , SQL state 51002 in SQLExecDirect in /web/intern/htdocs/archivts/TA0010.php on line 325 The difference of the databases P1 and T1 are in SYSTEM.SYSACCESS table: the old V7.3 fatabase contains the following entries (and some more), I don't know, where they come from: TNAME CREATOR -- --- SYSLN100 NULLID SYSLN101 NULLID SYSLN102 NULLID SYSLN200 NULLID SYSLN201 NULLID SYSLN202 NULLID SYSLN300 NULLID SYSLN301 NULLID SYSLN302 NULLID SYSLN400 NULLID SYSLN401 NULLID SYSLN402 NULLID SYSSN100 NULLID SYSSN101 NULLID SYSSN102 NULLID SYSSN200 NULLID SYSSN201 NULLID SYSSN202 NULLID SYSSN300 NULLID SYSSN301 NULLID In the V7.5 database these entries are missing. Reading the Database Administration Guide, I found out, that I have to set up a Stored Procedure Server for DB2 UDB V8.x connections. This is new with DB2 V7.3, the old database on this level works well without a Stored Proc Server. What do I miss ?? TIA Ewald Roller
