Michael Based on my experience with IBM OSA features, the issue is *not* how to set up the definition of your VIPAs but how you set up the definition of your OSA features.
Here is an extract from some documentation I have which - I think - covers the topic which is giving you trouble: <quote> IP Routing Control when MPCIPA Devices are Shared When CS/390 IP first activates an MPCIPA device, the IP addresses corresponding to active entries in the CS/390 IP HOME list are communicated to the OSA. The IP addresses are is stored with other specifications relating to the LPAR on which that CS/390 IP instance is running. If there are any changes to the active entries in the HOME list, for example, the changes to IP address status associated with dynamic VIPA mechanisms in a sysplex configuration, the change is also communicated to the OSA. Note: An entry in the HOME list is active when the corresponding IP address is eligible to be advertised by a dynamic routing protocol. An entry in the HOME list is inactive when the corresponding IP address is ineligible to be advertised by a dynamic routing protocol. When an IP packet arrives from the external media at the OSA, the OSA compares the destination IP address in the IP header against the HOME list associated with each LPAR. If there is a match in the comparison process, the OSA routes the IP packet to the CS/390 instance running on the LPAR identified by the comparison process. In addition to maintaining the associated HOME list in the OSA, CS/390 IP also communicates the "device router status" parameter to the OSA. The "device router status" parameter (following the description in the IBMTCPIPMVS MIB) is also stored with other specifications relating to the LPAR on which that CS/390 IP instance is running. The PRIROUTER, SECROUTER and NONROUTER parameters are used to specify the "device router status" parameter. Note: There is no official name for what is here described as the "device routing parameter". The name is taken from the description of the parameter in the IBMTCPIPMVS MIB. If there is no match in the comparison process, the OSA checks whether any of the stored "device router status" parameters specifies PRIROUTER. If any do, the OSA routes the IP packet to the CS/390 IP instance running on the LPAR where the related specifications include the PRIROUTER "device router status" parameter. If there is no match in the comparison process and none of the stored "device router status" parameters specifies PRIROUTER, the OSA checks whether any of the stored "device router status" parameters specifies SECROUTER. If any do, the OSA routes the IP packet to the CS/390 IP instance running on the LPAR where the related specifications include the SECROUTER "device router status" parameter. If there is no match in the comparison process and none of the stored "device router status" parameters specifies either PRIROUTER or SECROUTER, the OSA discards the arriving IP packet. Note that this implies that all of the stored "device router status" parameters specify NONROUTER. During activation of an MPCIPA device, the OSA checks the "device router status" parameter. If PRIROUTER is specified on the DEVICE statement and any of the existing specifications relating to an LPAR already specify PRIROUTER, the specification of PRIROUTER on the DEVICE statement is ignored and NONROUTER is assumed. During activation of an MPCIPA device, the OSA checks the "device router status" parameter. If SECROUTER is specified on the DEVICE statement and any of the existing specifications relating to an LPAR already specify SECROUTER, the specification of SECROUTER on the DEVICE statement is ignored and NONROUTER is assumed. </quote> I've included the description of the "device router status" parameter in case that's where your problem lies. You'll see that this behaviour where the OSA feature responds to the IP addresses in the HOME list, including any VIPAs, is tied in with the definition of the OSA feature as an MPCIPA device, more precisely when the DEVICE and LINK statements use the following pattern: DEVICE OSA0 MPCIPA PRIROUTER AUTORESTART LINK OSA0L IPAQENET OSA0 IFHSPEED 1000 Note that my experience and the above text is 3 years old so there may have been some changes in the interim. Are your Amdahl OSA features defined this way? If not, how are they defined? Is there an online document which covers technical aspects of the Amdahl OSA features similar to "Open Systems Adapter-Express Customer's Guide and Reference", SA22-7935-05 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IOA2Z120 ? If you have installed OSA/SF, the QUERY CHPID command will enable you to interrogate the OSA feature so that you can see what is in the "OSA Address Table". Chris Mason ----- Original Message ----- From: "Michael Buckley" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Wednesday, 20 September, 2006 6:28 AM Subject: Amdahl OSA cards and VIPA > Hopefully someone can remember how VIPA can be set up when using Amdahl OSA > cards. It does not appear that multiple IP Addresses can be associated with > single device. Is there an alernate way to set this up then, or is it that > VIPA is not possible ove rthe Amdahl channel ? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
