Re: LU name?
Hello Bobby Bauer, As indicated by others the ICC connections on the z890 and other systems allows the use of the LU parameter directly to the Z box itself. Then you will get a specific LU. I believe you need to have specified TN3270E on the Client. On the z/VSE CSI version, you can have a listener started that will allow the specification of LU on the Client too. Again, the Client must be using the TN3270E to specific the LU parameter. Example of Reflections configuration. If you leave the device name out it will not connect. Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bauer, Bobby (NIH/CIT) [E] Sent: Wednesday, December 15, 2010 3:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LU name? Not really sure what they are trying to do. I just got a request from our operation folks for this. I'm going to get back to CA myself. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Wednesday, December 15, 2010 2:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LU name? LU names are a SNA thing. They don't apply with TCPIP sessions. What are they trying to do - identify the session somehow? We are trying to make Automation point from CA work with a TN3270 session with a VM guest, The last step is to assign an LU name to the session. Don't see a way to do that in the VM world. Easy enough with MVS.
Re: LU name?
Ah. Digging a bit: the product allows the CA automation tool to drive a session and pick up console output. As somebody else noted, the only place in this scenario you would supply a LUname is if the CA product were talking to a ICC non-SNA console assigned to the guest - the LUname is used in the ICC tn3270E support to select the correct ICC session. If this is connecting to a guest VM system running under VM (ie, you have to DIAL to it), then there's no LUname involved - probably would need to set up a separate TCP stack that had a Telnet connection exit active to force any incoming telnet connection to DIAL to the appropriate guest. Or set up PVMG on MVS and run PVM on VM.
Re: LU name?
Hi, Bobby. z/VM TCPIP doesn't use (or need) LUs. I would suggest talking with CA Technical Support of this problem. DJ On 12/15/2010 01:33 PM, Bauer, Bobby (NIH/CIT) [E] wrote: > We are trying to make Automation point from CA work with a TN3270 > session with a VM guest, The last step is to assign an LU name to the > session. Don't see a way to do that in the VM world. Easy enough with > MVS. > > Any ideas? > > Thanks Bobby Bauer Center for Information Technology National > Institutes of Health Bethesda, MD 20892-5628 301-594-7474 > > -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
Re: LU name?
Not really sure what they are trying to do. I just got a request from our operation folks for this. I'm going to get back to CA myself. Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 From: David Boyes [mailto:dbo...@sinenomine.net] Sent: Wednesday, December 15, 2010 2:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LU name? LU names are a SNA thing. They don't apply with TCPIP sessions. What are they trying to do - identify the session somehow? We are trying to make Automation point from CA work with a TN3270 session with a VM guest, The last step is to assign an LU name to the session. Don't see a way to do that in the VM world. Easy enough with MVS.
Re: LU name?
If you are connecting through an OSA-ICC (or IDG9074) type connection you can assign an LU name in the OSA-ICC (or IDG9074) definition and then put that in the TN3270 software session setup on the PC. Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bauer, Bobby (NIH/CIT) [E] Sent: Wednesday, December 15, 2010 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: LU name? We are trying to make Automation point from CA work with a TN3270 session with a VM guest, The last step is to assign an LU name to the session. Don't see a way to do that in the VM world. Easy enough with MVS. Any ideas? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: LU name?
On Wednesday, 12/15/2010 at 02:37 EST, "Bauer, Bobby (NIH/CIT) [E]" wrote: > We are trying to make Automation point from CA work with a TN3270 session with > a VM guest, The last step is to assign an LU name to the session. Don?t see a > way to do that in the VM world. Easy enough with MVS. z/VM doesn't support LU names for TN3270E display sessions. They are used only with TN3270E printer sessions, and then only to allow you to figure out what RSCS link to assign it to. Unlike z/OS, TN3270 sesions on z/VM use CP's native non-SNA 3270 support, not VTAM. 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: LU name?
LU names are a SNA thing. They don't apply with TCPIP sessions. What are they trying to do - identify the session somehow? We are trying to make Automation point from CA work with a TN3270 session with a VM guest, The last step is to assign an LU name to the session. Don't see a way to do that in the VM world. Easy enough with MVS.
LU name?
We are trying to make Automation point from CA work with a TN3270 session with a VM guest, The last step is to assign an LU name to the session. Don't see a way to do that in the VM world. Easy enough with MVS. Any ideas? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: Pipes SORT within XEDIT - two example macros
Finally closing the loop with this thread:
With offline help from Rob, the following are two slightly different means
to accomplish the same thing - answering my original question about how to
sort a file within XEDIT without performing disk I/O, and without
needlessly buffering the whole file twice in XEDIT, and not even
mentioning avoidance of the XEDIT command "INSERT" (which truncates very
long records based on the maximum command line input).
Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.
/* PIPXESRT XEDIT - CMS Pipelines sort in XEDIT w/o disk I/O*/
/* No Pipelines Runtime Library (RTL) reliance */
parse source xos xct xfn xft xfm xcmd xenvir .
parse upper arg parms 1 operands '(' options ')' parmrest
parse var operands sortargs
'COMMAND EXTRACT /MSGMODE/AUTOSAVE/ALT/' /* Current settings */
$alt.1=alt.1
$alt.2=alt.2
'COMMAND SET MSGMODE OFF'/* Many line deletes */
'COMMAND SET AUTOSAVE OFF' /* Many line deletes */
'COMMAND TOP'
address command,
'PIPE (END ?)' ,
'| XEDIT', /* Read recs from XEDIT ring file */
'| SORT' sortargs , /* Sort and pass XEDIT input recs */
'| o: FANOUT' , /* Copy sorted recs to XEDIT ring file */
'| TAKE FIRST 1' , /* Do not buffer full file */
'| SPECS /:0 DELETE */' ,
'| SUBCOM XEDIT' , /* Execute ":0 DELETE *" command */
'? o:' , /* Accept sorted records from FANOUT */
'| XEDIT' /* Write sorted recs to XEDIT ring file*/
src=rc
'COMMAND SET ALT' $alt.1 $alt.2 /* Prevent AUTOSAVE */
'COMMAND SET AUTOSAVE' autosave.1 /* Restore setting*/
'COMMAND TOP' /* Back to first line */
'COMMAND SET MSGMODE' msgmode.1 /* Restore setting*/
Exit src
The following is a nearly-identical version, but which requires the
Pipelines RunTime Library "CONDITIONAL" keyword on the STRLITERAL stage
(see: PIPELINE NEWS), and also provides an example of the "IF" stage.
The "IF" stage _is_ present in the distributed CMS Pipelines, just not
documented there - perhaps because it was never fully tested?
/* RTLXESRT XEDIT - CMS Pipelines sort in XEDIT w/o disk I/O*/
/* Prereq: Pipelines Runtime Library (RTL) "COND" */
parse source xos xct xfn xft xfm xcmd xenvir .
parse upper arg parms 1 operands '(' options ')' parmrest
parse var operands sortargs
'COMMAND EXTRACT /MSGMODE/AUTOSAVE/ALT/LRECL/' /* Curr settings */
$alt.1=alt.1
$alt.2=alt.2
'COMMAND SET MSGMODE OFF'/* Many line deletes */
'COMMAND SET AUTOSAVE OFF' /* Many line deletes */
'COMMAND TOP'
address command,
'PIPE (END ?)' ,
'| XEDIT', /* Read recs from XEDIT ring file */
'| SORT' sortargs , /* Sort and pass XEDIT input recs */
'| STRLITERAL PREFACE CONDITIONAL /:0 DELETE */' , /*Preface*/
'| PAD' lrecl.1 ,/* Force cmd to match file lrecl */
'| x: IF TAKE' , /* "IF" recs (yes: ":0 DELETE *" + recs*/
'| SUBCOM XEDIT' , /* "THEN" execute ":0 DELETE *" cmd*/
'| x:' , /* "ELSE" */
'| XEDIT' , /* Write sorted recs to XEDIT ring file*/
'| x:' /* "ENDIF" */
src=rc
'COMMAND SET ALT' $alt.1 $alt.2 /* Prevent AUTOSAVE */
'COMMAND SET AUTOSAVE' autosave.1 /* Restore setting*/
'COMMAND TOP' /* Back to first line */
'COMMAND SET MSGMODE' msgmode.1 /* Restore setting*/
Exit src
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: Risk from change the SYSPROF exec
Hi Sergio, Take the warning to heart, but don't let it scare you. SYSPROF EXEC is indeed the right place to make that modification. FWIW, I normally modify SYSPROF with one single call to an external exec (VMCONFIG EXEC on my systems), that way I only have to manage a 1 line (+ comments) mod to SYSPROF EXEC, and can make changes that would otherwise go in SYSPROF EXEC much more easily. Locate the record in SYSPROF EXEC that has: 'SET COMDIR RELOAD' Immediately after that statement is a good place to put your mod. If you don't follow CMS Maintenance steps "strictly", I'll remind you that you need to make these changes on BOTH the MAINT 190 AND 490 disks, or the next time you do CMS maintenance the SYSPROF on MAINT 490 will overlay your 190, and of course you'll need to resave SYSPROF in the INSTSEG NSS. -Mike From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Sergio Lima Sent: Wednesday, December 15, 2010 10:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Risk from change the SYSPROF exec Hello List, I will try put the DIRMAINT product into Production running under Z/VM 5.4., tomorrow . So, We need put the command PW? for all users, and think put in the SYSPROF, because if put in the PROFILE EXEC, the user can remove this line from there. Looking at CMS PLANNING AND ADMINISTRATION, found this information : Modifying the SYSPROF EXEC : You can also modify the SYSPROF EXEC to tailor your system to the requirements of your installation. Attention The System Profile completes initialization of the CMS environment so any modifications that you make must be carefully fitted into the existing code to ensure that you don't refer to any and do not make use of the communications directory until after the SET COMDIR commands. Violating this rule may have unintended consequences. For additional information on tailoring your system, see the z/VM: CMS User's Guide. The question is that We don't want have any risk to do this, and want know, if someone have another idea how do this, without do a change in the SYSPROF. Thanks very much, Sergio Lima Costa Sao Paulo - Brazil
Re: New messages from TCP/IP after going from z/VM 5.2 to 5.4
Mike, The code is running through the same path in 5.4 that it was in 5.2...the only difference is there's now a message when we hit this case. There is no parameter to turn the message on or off. You need to figure out what interface is sending the offending packet. The message output gives you their MAC address: 04:09:23 DTCARP012IArpSenderHardwareAddr: 000629DC21BE Now, if that MAC address happens to belong to an interface on the stack that is issuing the message, then you should probably open a PMR so we can investigate why that's happening. If the MAC address doesn't belong to an interface on the stack issuing the message, then somebody else on your network is using that IP address...no matter what your telecom guy says :-) Regards, Miguel Delapaz z/VM Development The IBM z/VM Operating System wrote on 12/15/2010 10:40:53 AM: > Hello Alan, > > I contacted my telecom guy and he thinks maybe there is a new or > changed parameter in a TCP/IP configuration file since 5.2 thats > causing this. Do you think that could be the case? > > Also , I found the DTCARP049I message in the Messages and Codes book > but not the others. > > Thanks, > > Mike Horlick > > > > From: The IBM z/VM Operating System on behalf of Alan Altmark > Sent: Tue 14/12/2010 5:03 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: New messages from TCP/IP after going from z/VM 5.2 to 5.4 > > > > On Tuesday, 12/14/2010 at 04:19 EST, "Horlick, Michael" > wrote: > > > We went from z/VM 5.2 to 5.4 (and TCP/IP for VM 520 to 540) at the end > of > > November. I didn't notice it at first but I see that I am getting the > following > > type extra messages on the spooled console for each of my TCP/IP stacks > that I > > have: > > > > 04:09:23 DTCARP049I An ARP packet was received on link PCN3 with our IP > address > > 142.101.99.196 as the source address. Possible configuration error. > > > I had made no changes to any of my TCP/IP configuration files. On one my > stacks > > these type messages are occurring every so every few minutes. > > You made quite a leap going from 5.2 to 5.4 and you picked up a lot of new > functionality. The z/VM 5.4 TCP/IP Messages and Codes book includes > change bars for those DTCARP messages. > > It's telling you that you've got another host on your LAN that is > configured with the same IP address as VM TCP/IP. It didn't used to warn > you; now it does. > > 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: New messages from TCP/IP after going from z/VM 5.2 to 5.4
Hello Alan, I contacted my telecom guy and he thinks maybe there is a new or changed parameter in a TCP/IP configuration file since 5.2 thats causing this. Do you think that could be the case? Also , I found the DTCARP049I message in the Messages and Codes book but not the others. Thanks, Mike Horlick From: The IBM z/VM Operating System on behalf of Alan Altmark Sent: Tue 14/12/2010 5:03 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: New messages from TCP/IP after going from z/VM 5.2 to 5.4 On Tuesday, 12/14/2010 at 04:19 EST, "Horlick, Michael" wrote: > We went from z/VM 5.2 to 5.4 (and TCP/IP for VM 520 to 540) at the end of > November. I didn't notice it at first but I see that I am getting the following > type extra messages on the spooled console for each of my TCP/IP stacks that I > have: > > 04:09:23 DTCARP049I An ARP packet was received on link PCN3 with our IP address > 142.101.99.196 as the source address. Possible configuration error. > I had made no changes to any of my TCP/IP configuration files. On one my stacks > these type messages are occurring every so every few minutes. You made quite a leap going from 5.2 to 5.4 and you picked up a lot of new functionality. The z/VM 5.4 TCP/IP Messages and Codes book includes change bars for those DTCARP messages. It's telling you that you've got another host on your LAN that is configured with the same IP address as VM TCP/IP. It didn't used to warn you; now it does. 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
Did early Santa bring anyone a zEnterprise...
...and maybe a zBX? If so, and you can share your early experience/success with them, there's likely opportunity to be profiled in mainframe magazines and for IBM, bragging to the world about your brilliance. It's not much work and past profile subjects have liked the results. Vendors, feel free to suggest suitable/willing customers! Let me know... I get list digests so please reply directly or copy me off-list. Thanks. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042g...@gabegold.com LinkedIn: http://www.linkedin.com/in/gabegold
Re: Problems with MPROUTE going from z800 to z9BC computer
ok, thanks for your help. Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 10:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer I agree with Alan, use ping to see if it's getting out. You may find that the sourceip used does not have a route back to you. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 15, 2010 9:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer On Wednesday, 12/15/2010 at 08:21 EST, "Horlick, Michael" wrote: > Come migration time however, we could not get the VIPA/MPROUTE functionality > working. I could not ping from within the mainframe to anything beyond the OSA > card. Tried both QDIO and non-QDIO mode. > Our TCP/IP stack, no problems. > > We had to back out and now we have to try to set up a test VIPA/MROUTE setup > and try it on the new machine. Waiting on the telecom architect for this. > > No changes to the configuration files were done (except for QDIO in the > PROFILE TCPIP, but the same configuration files for non-QDIO). > > Any clues what could have gone wrong? Mike, network problems are all solved the same way: Divide and Conquer. If I understand you correctly: 1. The new system and the old one have the same IP configuration. That is, the same files on TCPIP and MPROUTE's A-disks. The same configuration files on TCPMAINT 198. The systems even have the same SYSTEM_IDENTIFIER. 2. The new system works fine *until* you bring up MPROUTE (it throws away any static routes not specifically marked as permanent). 3. The old and new systems are NOT up at the same time. When you PING something, a packet goes out and a packet comes back. To resolve why PING doesn't work, you need to figure out which of those two things didn't happen. Your network techs can help you, as they do this kind of stuff all the time with sniffers and queries on the switches/routers. Only then will you be able to take corrective action. Prior to that, you're just guessing, flailing at the problem in the hope you will accidentally fix it. 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Problems with MPROUTE going from z800 to z9BC computer
I agree with Alan, use ping to see if it's getting out. You may find that the sourceip used does not have a route back to you. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 15, 2010 9:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer On Wednesday, 12/15/2010 at 08:21 EST, "Horlick, Michael" wrote: > Come migration time however, we could not get the VIPA/MPROUTE functionality > working. I could not ping from within the mainframe to anything beyond the OSA > card. Tried both QDIO and non-QDIO mode. > Our TCP/IP stack, no problems. > > We had to back out and now we have to try to set up a test VIPA/MROUTE setup > and try it on the new machine. Waiting on the telecom architect for this. > > No changes to the configuration files were done (except for QDIO in the > PROFILE TCPIP, but the same configuration files for non-QDIO). > > Any clues what could have gone wrong? Mike, network problems are all solved the same way: Divide and Conquer. If I understand you correctly: 1. The new system and the old one have the same IP configuration. That is, the same files on TCPIP and MPROUTE's A-disks. The same configuration files on TCPMAINT 198. The systems even have the same SYSTEM_IDENTIFIER. 2. The new system works fine *until* you bring up MPROUTE (it throws away any static routes not specifically marked as permanent). 3. The old and new systems are NOT up at the same time. When you PING something, a packet goes out and a packet comes back. To resolve why PING doesn't work, you need to figure out which of those two things didn't happen. Your network techs can help you, as they do this kind of stuff all the time with sniffers and queries on the switches/routers. Only then will you be able to take corrective action. Prior to that, you're just guessing, flailing at the problem in the hope you will accidentally fix it. 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Problems with MPROUTE going from z800 to z9BC computer
Setup correctly it should work ok. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer I do have SourceVipa specified: ASSORTEDPARMS PROXYARP IGNOREREDIRECT SOURCEVIPA Are you saying that specifying this could cause the problem? Why would it work OK on the old machine but not on the new? Same config files, only difference new hardware. Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 9:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Sourcevipa is a TCP configuration parm. The book states: Note: For requests or connections originating at a z/VM TCP/IP stack, tolerance of device and adapter failures may be achieved by using the SOURCEVIPA feature. This capability causes virtual IP addresses to be used as the source IP addresses in all outbound datagrams except those associated with routing. This has burned me a couple of times because it chooses source ip address from the home list starting from the bottom up. It selects the first vipa address that it finds as the source ip for all communications. I.E. you may want to use address 172.26.1.1 as your source, but you end up using 172.25.1.1 and it may not be in the routing tables. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Have no idea what sourceVIPA is. Maybe you can explain. My configuration files were the same for TCPIP and MPROUTE. Would the type of OSA card matter? I believe I have an OSA-2 on the existing machine but an OSA-Express on the new. Thanks, Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 8:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Could you possibly be using sourceVipa where before you weren't? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 7:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the
Re: Problems with MPROUTE going from z800 to z9BC computer
Yes, you're right. Will wait till network people are involved. Thanks, Mike From: The IBM z/VM Operating System on behalf of Alan Altmark Sent: Wed 15/12/2010 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer On Wednesday, 12/15/2010 at 08:21 EST, "Horlick, Michael" wrote: > Come migration time however, we could not get the VIPA/MPROUTE functionality > working. I could not ping from within the mainframe to anything beyond the OSA > card. Tried both QDIO and non-QDIO mode. > Our TCP/IP stack, no problems. > > We had to back out and now we have to try to set up a test VIPA/MROUTE setup > and try it on the new machine. Waiting on the telecom architect for this. > > No changes to the configuration files were done (except for QDIO in the > PROFILE TCPIP, but the same configuration files for non-QDIO). > > Any clues what could have gone wrong? Mike, network problems are all solved the same way: Divide and Conquer. If I understand you correctly: 1. The new system and the old one have the same IP configuration. That is, the same files on TCPIP and MPROUTE's A-disks. The same configuration files on TCPMAINT 198. The systems even have the same SYSTEM_IDENTIFIER. 2. The new system works fine *until* you bring up MPROUTE (it throws away any static routes not specifically marked as permanent). 3. The old and new systems are NOT up at the same time. When you PING something, a packet goes out and a packet comes back. To resolve why PING doesn't work, you need to figure out which of those two things didn't happen. Your network techs can help you, as they do this kind of stuff all the time with sniffers and queries on the switches/routers. Only then will you be able to take corrective action. Prior to that, you're just guessing, flailing at the problem in the hope you will accidentally fix it. 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: Problems with MPROUTE going from z800 to z9BC computer
On Wednesday, 12/15/2010 at 08:21 EST, "Horlick, Michael" wrote: > Come migration time however, we could not get the VIPA/MPROUTE functionality > working. I could not ping from within the mainframe to anything beyond the OSA > card. Tried both QDIO and non-QDIO mode. > Our TCP/IP stack, no problems. > > We had to back out and now we have to try to set up a test VIPA/MROUTE setup > and try it on the new machine. Waiting on the telecom architect for this. > > No changes to the configuration files were done (except for QDIO in the > PROFILE TCPIP, but the same configuration files for non-QDIO). > > Any clues what could have gone wrong? Mike, network problems are all solved the same way: Divide and Conquer. If I understand you correctly: 1. The new system and the old one have the same IP configuration. That is, the same files on TCPIP and MPROUTE's A-disks. The same configuration files on TCPMAINT 198. The systems even have the same SYSTEM_IDENTIFIER. 2. The new system works fine *until* you bring up MPROUTE (it throws away any static routes not specifically marked as permanent). 3. The old and new systems are NOT up at the same time. When you PING something, a packet goes out and a packet comes back. To resolve why PING doesn't work, you need to figure out which of those two things didn't happen. Your network techs can help you, as they do this kind of stuff all the time with sniffers and queries on the switches/routers. Only then will you be able to take corrective action. Prior to that, you're just guessing, flailing at the problem in the hope you will accidentally fix it. 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
Risk from change the SYSPROF exec
Hello List, I will try put the DIRMAINT product into Production running under Z/VM 5.4., tomorrow . So, We need put the command PW? for all users, and think put in the SYSPROF, because if put in the PROFILE EXEC, the user can remove this line from there. Looking at CMS PLANNING AND ADMINISTRATION, found this information : Modifying the SYSPROF EXEC : You can also modify the SYSPROF EXEC to tailor your system to the requirements of your installation. Attention The System Profile completes initialization of the CMS environment so any modifications that you make must be carefully fitted into the existing code to ensure that you don’t refer to any and do not make use of the communications directory until after the SET COMDIR commands. Violating this rule may have unintended consequences. For additional information on tailoring your system, see the z/VM: CMS User’s Guide. The question is that We don't want have any risk to do this, and want know, if someone have another idea how do this, without do a change in the SYSPROF. Thanks very much, Sergio Lima Costa Sao Paulo - Brazil
Re: Problems with MPROUTE going from z800 to z9BC computer
I do have SourceVipa specified: ASSORTEDPARMS PROXYARP IGNOREREDIRECT SOURCEVIPA Are you saying that specifying this could cause the problem? Why would it work OK on the old machine but not on the new? Same config files, only difference new hardware. Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 9:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Sourcevipa is a TCP configuration parm. The book states: Note: For requests or connections originating at a z/VM TCP/IP stack, tolerance of device and adapter failures may be achieved by using the SOURCEVIPA feature. This capability causes virtual IP addresses to be used as the source IP addresses in all outbound datagrams except those associated with routing. This has burned me a couple of times because it chooses source ip address from the home list starting from the bottom up. It selects the first vipa address that it finds as the source ip for all communications. I.E. you may want to use address 172.26.1.1 as your source, but you end up using 172.25.1.1 and it may not be in the routing tables. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Have no idea what sourceVIPA is. Maybe you can explain. My configuration files were the same for TCPIP and MPROUTE. Would the type of OSA card matter? I believe I have an OSA-2 on the existing machine but an OSA-Express on the new. Thanks, Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 8:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Could you possibly be using sourceVipa where before you weren't? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 7:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclos
Re: Problems with MPROUTE going from z800 to z9BC computer
Sourcevipa is a TCP configuration parm. The book states: Note: For requests or connections originating at a z/VM TCP/IP stack, tolerance of device and adapter failures may be achieved by using the SOURCEVIPA feature. This capability causes virtual IP addresses to be used as the source IP addresses in all outbound datagrams except those associated with routing. This has burned me a couple of times because it chooses source ip address from the home list starting from the bottom up. It selects the first vipa address that it finds as the source ip for all communications. I.E. you may want to use address 172.26.1.1 as your source, but you end up using 172.25.1.1 and it may not be in the routing tables. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Have no idea what sourceVIPA is. Maybe you can explain. My configuration files were the same for TCPIP and MPROUTE. Would the type of OSA card matter? I believe I have an OSA-2 on the existing machine but an OSA-Express on the new. Thanks, Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 8:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Could you possibly be using sourceVipa where before you weren't? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 7:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Problems with MPROUTE going from z800 to z9BC computer
Have no idea what sourceVIPA is. Maybe you can explain. My configuration files were the same for TCPIP and MPROUTE. Would the type of OSA card matter? I believe I have an OSA-2 on the existing machine but an OSA-Express on the new. Thanks, Mike From: The IBM z/VM Operating System on behalf of Ward, Mike S Sent: Wed 15/12/2010 8:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Could you possibly be using sourceVipa where before you weren't? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 7:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Problems with MPROUTE going from z800 to z9BC computer
Hello Eric, Yes, I believe the two mainframes were connected to the same VLAN subnets. The client had no problem accessing the new CPU without VIPA/MPROUTE. Beyond that I don't know the answers to your questions. Something to ask the network people. Thanks, Mike From: The IBM z/VM Operating System on behalf of Eric Schadow Sent: Wed 15/12/2010 8:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Mike Were the two mainframes on the same or different VLAN/subnets? It could have been a ARP/MAC timeout issue? Are the MAC's locally administered on the mainframe? You may have private VLAN or some other mechanism setup to limit the host interactions on the switch. Eric -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Oops , I may accidently sent an earlier incomplete reply. Sorry. =20 Anyways, we had new cables attached from the OSA card on the new CPU = attached one to our switch, the other to the switch for the client. No = new cabling was done at migration time. We tested before the migration = and all well, non-VIPA.=20 =20 Thanks, =20 Mike=20 From: The IBM z/VM Operating System on behalf of Davis, Larry (National = VM/VSE Capability) Sent: Wed 15/12/2010 8:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Are you using the same or New Network connections to the network. Make = sure the two OSA ports are not cross connected at the switch. If they = are TRUNC'd together then you will have routing issues. Just get a new set of IP's to test with on the new box, and get your = network and firewall people involved. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On = Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - = Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of = our z/VM 5.4 system on it (XXXRES =3D 540RES, XXXPAG =3D 540PAGetc...). = I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given = that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, = one for our use, the other for the clients. For the client, on our = production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing = worked fine. We tried the OSA card in QDIO and non-QDIO mode and no = problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE = functionality working. I could not ping from within the mainframe to = anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE = setup and try it on the new machine. Waiting on the telecom architect = for this. No changes to the configuration files were done (except for QDIO in the = PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal =20 The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: Problems with MPROUTE going from z800 to z9BC computer
Could you possibly be using sourceVipa where before you weren't? -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 7:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Problems with MPROUTE going from z800 to z9BC computer
Mike Were the two mainframes on the same or different VLAN/subnets? It could have been a ARP/MAC timeout issue? Are the MAC's locally administered on the mainframe? You may have private VLAN or some other mechanism setup to limit the host interactions on the switch. Eric -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:46 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Oops , I may accidently sent an earlier incomplete reply. Sorry. =20 Anyways, we had new cables attached from the OSA card on the new CPU = attached one to our switch, the other to the switch for the client. No = new cabling was done at migration time. We tested before the migration = and all well, non-VIPA.=20 =20 Thanks, =20 Mike=20 From: The IBM z/VM Operating System on behalf of Davis, Larry (National = VM/VSE Capability) Sent: Wed 15/12/2010 8:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Are you using the same or New Network connections to the network. Make = sure the two OSA ports are not cross connected at the switch. If they = are TRUNC'd together then you will have routing issues. Just get a new set of IP's to test with on the new box, and get your = network and firewall people involved. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On = Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - = Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of = our z/VM 5.4 system on it (XXXRES =3D 540RES, XXXPAG =3D 540PAGetc...). = I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given = that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, = one for our use, the other for the clients. For the client, on our = production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing = worked fine. We tried the OSA card in QDIO and non-QDIO mode and no = problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE = functionality working. I could not ping from within the mainframe to = anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE = setup and try it on the new machine. Waiting on the telecom architect = for this. No changes to the configuration files were done (except for QDIO in the = PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal =20 The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: Problems with MPROUTE going from z800 to z9BC computer
Oops , I may accidently sent an earlier incomplete reply. Sorry. Anyways, we had new cables attached from the OSA card on the new CPU attached one to our switch, the other to the switch for the client. No new cabling was done at migration time. We tested before the migration and all well, non-VIPA. Thanks, Mike From: The IBM z/VM Operating System on behalf of Davis, Larry (National VM/VSE Capability) Sent: Wed 15/12/2010 8:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Are you using the same or New Network connections to the network. Make sure the two OSA ports are not cross connected at the switch. If they are TRUNC'd together then you will have routing issues. Just get a new set of IP's to test with on the new box, and get your network and firewall people involved. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal
Re: Problems with MPROUTE going from z800 to z9BC computer
Hello Larry, We had new cables from the OSA card on the new CPU c From: The IBM z/VM Operating System on behalf of Davis, Larry (National VM/VSE Capability) Sent: Wed 15/12/2010 8:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problems with MPROUTE going from z800 to z9BC computer Are you using the same or New Network connections to the network. Make sure the two OSA ports are not cross connected at the switch. If they are TRUNC'd together then you will have routing issues. Just get a new set of IP's to test with on the new box, and get your network and firewall people involved. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal
Re: Problems with MPROUTE going from z800 to z9BC computer
Are you using the same or New Network connections to the network. Make sure the two OSA ports are not cross connected at the switch. If they are TRUNC'd together then you will have routing issues. Just get a new set of IP's to test with on the new box, and get your network and firewall people involved. Larry Davis -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Horlick, Michael Sent: Wednesday, December 15, 2010 8:21 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Problems with MPROUTE going from z800 to z9BC computer Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal
Problems with MPROUTE going from z800 to z9BC computer
Greetings, A couple of days ago we tried to migrate from our current CPU (Z800 - Model 2066) to a z9BC Mode R07 (2096). We had this new machine for a couple of weeks and we created a copy of our z/VM 5.4 system on it (XXXRES = 540RES, XXXPAG = 540PAGetc...). I was able to test z/VM 5.4 and TCP/IP on it and it worked fine given that we were assigned new IP addresses for it. We have 2 TCP/IP stacks, one for our use, the other for the clients. For the client, on our production machine we use VIPA/MPROUTE. We could not test VIPA/MPROUTE on the new machine but static routing worked fine. We tried the OSA card in QDIO and non-QDIO mode and no problems. Connectivity for both us and the client. Come migration time however, we could not get the VIPA/MPROUTE functionality working. I could not ping from within the mainframe to anything beyond the OSA card. Tried both QDIO and non-QDIO mode. Our TCP/IP stack, no problems. We had to back out and now we have to try to set up a test VIPA/MROUTE setup and try it on the new machine. Waiting on the telecom architect for this. No changes to the configuration files were done (except for QDIO in the PROFILE TCPIP, but the same configuration files for non-QDIO). Any clues what could have gone wrong? Thanks, Mike Horlick CGI Montreal
