The message means that OMPROUTE can't find the interface VIPALINK2, so I would display your home address list to make sure that it shows up in the list as address 7.7.7.8 and named VIPALINK2.
I would also need to see the OSPF definition for VIPALINK2. On Mon, 12 Aug 2024 13:51:18 +0000, roscoe5 <rosc...@protonmail.com> wrote: >Thanks again. >I understand it’s a routing issue and I added a matching OSPF_Interface where >the original one was defined, using the new IP and Destination Address. >But when I issue the OBEYFILE command I get “EZZ7871I NO MATCHING INTERFACE >STATEMENTS FOR 7.7.7.8 (VIPALINK2)”. >My gut instinct keeps coming back to the PROFILE member where the >original/working VIPA has the pair of physical IPAQENET interfaces with >SOURCEVIPAINTs pointing at the VIPA. > >This new VIPA doesn’t have any matching physical interfaces pointing at it. > >I’m thinking I need a similar association, but multiple sources say that I >don’t. > >No doubt I’m missing something simple. > >Just to be clear, the dynamic Obey of the PROFILE member does allow me to Ping >the new IP from TSO, just not from the outside, confirming the OMP/OSPF issue. > >Sent from [Proton Mail](https://proton.me/mail/home) for iOS > >On Mon, Aug 12, 2024 tt 8:19 AM, John S. Giltner, Jr. ><[000005a978a73af8-dmarc-requ...@listserv.ua.edu](mailto:On Mon, Aug 12, 2024 >at 8:19 AM, John S. Giltner, Jr. <<a href=)> wrote: > >> O.K., that is a routing issue. You need to look at your OSPF parameters and >> verify that you are setup to advertise 7.7.7.8 to your neighbors. If your >> not, then you need to update you OSPF parameters to advertise it and go from >> there. No matter what you may want to check with whomever handles your OSPF >> neighbors and see if they are setup to accept that route. >> >> On Mon, 12 Aug 2024 11:49:22 +0000, roscoe5 <rosc...@protonmail.com> wrote: >> >>>John, >>>Thanks for your time and the thorough response. I’m not too concerned about >>>the applications, but your comments confirmed what I thought in that area. >>>One quick test failed to work in the OSPF space (did not recognize the new >>>IP address). However, I think I’ll have another test opportunity soon, so >>>I’ll continue down this path. >>>Thanks again! >>> >>>Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>> >>>On Mon, Aug 12, 2024 at 7:40 AM, John S. Giltner, Jr. >>><[000005a978a73af8-dmarc-requ...@listserv.ua.edu](mailto:On Mon, Aug 12, >>>2024 at 7:40 AM, John S. Giltner, Jr. <<a href=)> wrote: >>> >>>> You should only ned to add a new VIPA: >>>> >>>> For all traffic that is initiated to your system, they just specify the >>>> destination IP address 7.7.7.8, or create a DNS entry that resolves to >>>> that address and have them use that host name. >>>> >>>> For most of traffic the that you initiate outbound I would look at using >>>> SRCIP entries with job names something like >>>> >>>> SRCIP >>>> >>>> JOBNAME MYTSTJOB 7.7.7.8 >>>> >>>> ENDSRCIP >>>> >>>> Then any job you submit with the name MYTSTJOB will use the address >>>> 7.7.7.8 as its source IP address. You can add multiple job names as needed >>>> or even code a pattern like MYTSTJ* and then any job that starts with >>>> MYTSTJ willuse 7.7.7.8 >>>> >>>> You can either update you existing TCPIP parameter and issue the OBEY >>>> command, or if you use PDS for your TCPIP parameters just create a new >>>> member with all of your SRCIP parameters and obey that member. >>>> >>>> To keep the SRCIP parameters across IPL's in your normal TCPIP parameters >>>> just INCLUDE the DSN of where you have coded the SRCIP statements. >>>> >>>> Once a TCP connection is setup between two IP addresses, all traffic will >>>> flow between those to addresses. So there is nothing that would cause a >>>> connection that was established with 7.7.7.8 to start flowing with 7.7.7.7. >>>> >>>> If you are still running standard FTP then you could have problems because >>>> it uses 2 TCP connections and it could be tough to have both connections >>>> use the new IP address. >>>> >>>> On Sun, 11 Aug 2024 20:50:24 +000 , roscoe5 <rosc...@protonmail.com> wrote: >>>> >>>>>I thought I had an answer, but no. >>>>>(Hard to test; can’t IPL) >>>>> >>>>>Trying to make this clearer. >>>>> >>>>>We currently have a single VIPA and two physical INTERFACE statements, >>>>>let's say ... >>>>> >>>>>INTERFACE VIPALINK1 DEFINE VIRTUAL IPADDR 7.7.7.7 >>>>> >>>>>INTERFACE LINK0010 >>>>> >>>>>DEFINE IPAQENET >>>>> >>>>>PORTNAME T0010 >>>>> >>>>>IPADDR 10.1.1.1/29 >>>>> >>>>>SOURCEVIPAINT VIPALINK1 >>>>> >>>>>... >>>>> >>>>>add >>>>> >>>>>NTTERFACE LINK0020 >>>>> >>>>>DEFINE IPAQENET >>>>> >>>>>PORTNAME T0020 >>>>> >>>>>IPADR 10.1.1.2/29 >>>>> >>>>>SOURCEVIPAINT VIPALINK1 >>>>> >>>>>... >>>>> >>>>>We woul like to add a second VIPA, VIPALINK2, very much like the first, >>>>>except with IPADDR 7.7.7.8. >>>>> >>>>>Do I need to create more IPAQENET INTERFACES (with or without new ports) >>>>>and give them a SOURCEVIPAINT VIPALINK2? >>>>> >>>>>Or is there any way to simply use the current existing IPAQENET INTERFACEs >>>>>and associate them with VIPALINK2? >>>>> >>>>>The obvious challengewwould be, how would the app/system know which VIPA >>>>>to use? Fair question. >>>>> >>>>>One of my peers suggested that as we expect the traffic would be inbound, >>>>>it would come in on 7.7.7.8. >>>>> >>>>>Further, any session created from inbound 7.7.7.8 shulld go back out on >>>>>7.7.7.8. >>>>> >>>>>Beyond the above technical question, some may want to ask why? What is >>>>>tobe gained. >>>>> >>>>>The answeris,multiple applications are using 7.7.7.7 with most unsecured. >>>>> >>>>>We intend to require ALL traffic on 7.7.7.8 be AT-TLS encrypted. >>>>> >>>>>Then test and migrate apps, independently, on to 7.7.7.8. >>>>> >>>>>Thanking in advance, >>>>> >>>>>Bob >>>>> >>>>>ennt from [Proton Mail](https://proton.me/mail/home) for iOS >>>>> >>>>>On Mon, Aug 5, 2024 at 5:22 PM, roscoe5 >>>>><[rosc...@prtoonmail.com](mailto:On Mon, Aug 5, 2024 at 5:22 PM, roscoe5 >>>>><<a href=)> wrote: >>>>> >>>>>> Never mind, I figured it out. >>>>>> As is too often, I was making it more complicated than necessary. >>>>>> >>>>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>>>> >>>>>> On Fri, Aug 2, 2024 at 6:43 PM, roscoe5 >>>>>> <[0000056b62686b81-dmarc-requ...@listserv.ua.edu](mailto:On Fri, Aug 2, >>>>>> 2024 at 6:43 PM, roscoe5 <<a href=)> wrote: >>>>>> >>>>>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: roscoe5 <rosc...@protonmail.com> >>>>>>>> Date: On Fri, Aug 2, 2024 at 6:39 PM >>>>>>>> Subject: Fw: Multiple VIPAs >>>>>>>> To: ibm-m...@listserv.ua.edux <ibm-m...@listserv.ua.edux> >>>>>>>> Cc: >>>>>>>> >>>>>>>> Hello, >>>>>>>> In our TCP/IP (z/OS 3.1) we define OSA interfaces with IP addresses, >>>>>>>> and use the SourceVipaInt to refer to a Virtual IP address/interface. >>>>>>>> That much is working fine. >>>>>>>> I want to add another VIPA IP Address, where users can continue to use >>>>>>>> applications on (for example) 7.7.7.7 or get to the same services on >>>>>>>> the new 7.7.7.8 address. >>>>>>>> The plan is to use PAgent on the new address and enforce >>>>>>>> security/encryption. >>>>>>>> >>>>>>>> My question is, in the TCPIP Profile configuration, can I assign a >>>>>>>> native (not virtual) interface to two virtual interfaces (7.7.7.7 and >>>>>>>> 7.7.7.8)? Or do I need to duplicate the native interfaces with >>>>>>>> IPAQENET, PORTNAME, IPADDR, etc., and refer these new interfaces to >>>>>>>> the 7.7.7.8 virtual address? >>>>>>>> Thanks in advance, >>>>>>>> Bob >>>>>>>> >>>>>>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>>> >>>>>---------------------------------------------------------------------- >>>>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>>---------------------------------------------------------------------- >>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
