How to know the IP address of the mainframes?

[Binamra]

Hi,

How to know the IP address of the mainframe I am working on?

I searched and got to know that we can use TSO HOMETEST, but it gives so many IPs which one is mine, how to confirm that?

And we have Prod and Test regions, which region's IP are those, Test or Prod?

[Robert Sample]

The BEST -- and easiest -- way is to ask your site support group.

You could, if you have access, check the TCPPARMS data set member being used for your LPAR as it will have the IP address. I don't recall which member

If you know the DNS name of the mainframe, you could ping it from your PC.

And every LPAR on the system has unique IP addresses. If you connected to the TEST LPAR, you will find the TEST LPAR IP addresses. If you connected to the PROD LPAR, you will find the PROD LPAR IP addresses.

And, assuming you find the IP address, what good does that data do you? There are very few instances when you need to know the IP address of the LPAR.

[Robert Sample]

Looking at the HOMETEST output, this line

Code: Select all

 EZA0611I The following IP addresses correspond to TCP Host Name:

is followed by the IP addresses that the LPAR is using. Note that it is not at all unusual for an LPAR to have multiple IP addresses assigned. And the data following this line of the HOMETEST output:

Code: Select all

EZA0614I The following IP addresses are the HOME IP addresses defined in PROFILE 
.TCPIP: 

give you a way to cross-check the first list.

If you get multiple IP addresses returned from HOMETEST, that often means the IP addresses are serviced in a round-robin method so each will be used in turn.

[Binamra]

Thanks Robert.

I got it like this:

Code: Select all

EZA0611I The following IP addresses correspond to TCP Host Name: xxxx
EZA0612I 111.11.111.11 	                                              

You said that multiple IPs can be assigned to the LPAR, what is the use of addressing the same LPAR with multiple IPs?

[Robert Sample]

In what you posted, the 111.11.111.11 would be the IP address for the LPAR.

The purpose of providing multiple IP addresses to the LPAR is redundancy. For high availability, you want to eliminate single points of failure. If you assign two IP addresses to the LPAR, and those IP addresses are associated with different OSA cards using different cables to connect to different switches / routers, one connection could go down but still allow the mainframe to communicate with the network. It is not unusual for mainframes to be up and running 99.999% of the time -- which translates to just over 5 minutes PER YEAR of unscheduled down time. To achieve that kind of availability, you have to look at every possible single point of failure and either eliminate it or create a redundancy for it.

[Binamra]

In what you posted, the 111.11.111.11 would be the IP address for the LPAR.

The purpose of providing multiple IP addresses to the LPAR is redundancy. For high availability, you want to eliminate single points of failure. If you assign two IP addresses to the LPAR, and those IP addresses are associated with different OSA cards using different cables to connect to different switches / routers, one connection could go down but still allow the mainframe to communicate with the network. It is not unusual for mainframes to be up and running 99.999% of the time -- which translates to just over 5 minutes PER YEAR of unscheduled down time. To achieve that kind of availability, you have to look at every possible single point of failure and either eliminate it or create a redundancy for it.

Thank you!

Why it is called 'redundancy'? Is not that we usually avoid "redundancy"?

[nicc]

You want to avoid redundant, i.e. no longer wanted, items. But in this case redundancy means' reserve' - if the prime fails then the backup/reserve takes over.

[Robert Sample]

I should have explained ... "single point of failure" (SPOF) is a technical term that means a component whose failure will keep the system from running. You have to analyze a system to find any SPOF that exist, and then figure out a way to provide an alternate way to keep the system running in the event that the SPOF fails. Having redundancy is one way of doing this; for example using multiple CPU in the box allows one of them to be down and the other(s) continue to process. Having two paths to every I/O device allows one path to fail and still allow the system to connect to the I/O device. And so forth -- high availability requires looking at every component of the system to identify any SPOF that exists.

[Binamra]

Thanks Robert.

Just a different question, if this is how redundancy works, then all open systems to which the most of the companies plan to move can implement 'redundancy' to give the high availability like mainframes? But most of the times such migration does not work as good as mainframes, why?

[nicc]

New question, new topic. Locked.