Re: Oops on ADDNWSSTGL -- MIDRANGE-L

Subject: Re: Oops on ADDNWSSTGL
From: Holger Scherer <hs@xxxxxxx>
Date: Tue, 2 Jul 2019 23:07:31 +0200
List-archive: <https://archive.midrange.com/midrange-l/>
List-help: <mailto:midrange-l-request@lists.midrange.com?subject=help>
List-id: Midrange Systems Technical Discussion <midrange-l.lists.midrange.com>
List-post: <mailto:midrange-l@lists.midrange.com>
List-subscribe: <https://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=subscribe>
List-unsubscribe: <https://lists.midrange.com/mailman/options/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=unsubscribe>

IBM i is very resilient on storage. Vary off the NWSD, remove the link, vary on again.
You even may IPL the host LPAR without big harm to the guests LPARs.
Ok, they will hang for some minutes with A6000266 and TCP connections may break,
but the guests will stay alive...

been there, done that multiple times.

-h

Am 02.07.2019 um 22:16 schrieb Rob Berendt <rob@xxxxxxxxx>:

The cure was to vary off the nwsd. IBM recommends that you power down the guest first.

At one time I accidentally varied off a nwsd on a live system. The guest just acted hung and immediately returned to life upon the nwsd being varied back on. When I told IBM that today their reply was "you got <extremely> lucky".
I decided it would be better to power off and did it that way then.

As an Amazon Associate we earn from qualifying purchases.

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.