Re: New switch question.

I noted in an earlier exchange that you have a Twinaxial console? If so,
that means the system is somewhat older (being polite, better word is
ancient) so the ethernet communications might need a jumpstart.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Tue, Jan 31, 2023 at 10:48 AM K Crawford <kscx3ksc@xxxxxxxxx> wrote:

Thank you Jim.
Your last paragraph is what I needed. I assumed this but you know what
they say about assume.
Currently we do NOT have an HMC. But in the next month we are supposed to
get one.

On Tue, Jan 31, 2023 at 10:39 AM Jim Oberholtzer <
midrangel@xxxxxxxxxxxxxxxxx> wrote:

First the POWER system. It's likely there are a total of two maybe three
Ethernet cables. One for normal communications, most likely in a 4 port
PCI card. You did not indicate if you have an HMC or not, but I'll

presume

you have one since the system is on a SAN. There should be a cable from
the HMC port that "might" go to the switch, although ordinarily it goes
directly to the HMC. Leave that one alone. If you do not have an HMC

then

the second cable is very likely a LAN console, that would go into your
network switch. It is highly likely that if the normal communications

line

is unplugged, then plugged into the new switch within a few seconds that
IBMi will just recover the communications loss and all will be well.

More

than about 15 seconds then you might need to go in with the console and

do

a retry on the inevitable error that will show up in QSYSOPR. It is
possible with more advanced settings that the Ethernet will either stop
cold, and not restart on it's own, or never go down at all. We can't

tell

with what you told us. We would need to see the line definition to know.

SAN: there are two different switches. The one with the Fibre Cable

(much

thinner than most ethernet cables) should not be affected by the Ethernet
switch change since it's a different device altogether. The Ethernet

cable

again should be moved very quickly (15 seconds or less) to avoid needing

to

reset the SAN to get Ethernet communications going again (or signing on
with a direct connect). Moving the Ethernet should not affect IBMi at

all,

but if the SAN is used for iSCSI communications to other systems, then it
will cause an outage on those systems when the cable is moved.

So the short answer is: IBMi will recover almost by itself, assuming the
outage is very short. The SAN should not cause any trouble for IBM i
either. I've done that very same thing several times, but just plan to
have all the cables laid out so the interruption is very short.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Tue, Jan 31, 2023 at 10:20 AM K Crawford <kscx3ksc@xxxxxxxxx> wrote:

My network people are moving to a new switch. Nothing special about it

vs

the old one just newer, my understanding it is configured the same.

They

have everything switched to the new switch except for the IBMi. The

switch

is not giving out IPs (DHCP) that is done by the active directory. The
IBMi has static IPs.


Note I am not a hardware person so if I got terms wrong work with me.


Currently we have the IBMi CPU with a SANS. Coming out of the back of

the

CPU are two cables going to the switch. I assume one is the primary

and

the other is the backup. Also coming out of the CPU is a thin cable

going

to the SANS. Coming out of the SANS are also two cables going to the
switch. Once again I assume one is the primary and the other is the
backup.



What I am trying to figure out is do I need to end any services like

TCP/IP

before moving the cables from the old switch to the new switch. Or

just

unplug from the old switch and plug into the new switch? Also what

testing

would I need to do before/after to ensure everything is working.



A bit confused why the SANS directly connects to the switch but that is
another conversation.


--
KCrawford
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
KCrawford
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.