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. 
<[[email protected]](mailto:On Mon, Aug 12, 2024 
at 7:40 AM, John S. Giltner, Jr. <<a href=)> wrote:

> You should only need 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 +0000, roscoe5 <[email protected]> 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 <[[email protected]](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 
>>> <[[email protected]](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 <[email protected]>
>>>>> Date: On Fri, Aug 2, 2024 at 6:39 PM
>>>>> Subject: Fw: Multiple VIPAs
>>>>> To: [email protected] <[email protected]>
>>>>> 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 [email protected] with the message: INFO IBM-MAIN
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to