Yes, this would be a consequence of moving access from one ess port
to another.

Each ess port has a separate wwpn.  During the cfgmgr run the wwpn of
the ess port is stored in the ODM under the hdisk definition.  So,
when you change the ess port used by a lun, AIX still tries to access
the lun via the old ess port.  To change this requires the hdisk to
be deleted and recreated.

Here's an example of one of my systems that has a ess hdisk via fc:

  istbd1u:root:/==>lsattr -E -l hdisk9
  scsi_id       0x31e00            N/A                        True
  lun_id        0x560f000000000000 N/A                        True
  location                         N/A                        True
  ww_name       0x10000000c9233e36 N/A                        False
  pvid          none               Physical volume identifier False
  q_type        simple             Queuing TYPE               True
  queue_depth   64                 Queue DEPTH                True
  start_timeout 180                START unit time out value  True
  rw_timeout    60                 READ/WRITE time out value  True

  NOTE: the ww_name field is the wwpn of the ess port that this hdisk
  uses.

Interestingly, there is a similar problem with failed ess fc cards.
When a ESS FC card fails and is replaced, the new card put in has a
new wwpn!  Any access to a lun via that ess port won't work until the
AIX hdisk is deleted/recreated.  When this happened to us we were
just amazed!!!!!!!   Every other raid vendor I know of who supports
FC uses persistent wwpn names on the raid system fc adapters.  For
example, EMC uses a wwpn name that included the Symm serial number
and card slot number.  If you swap out the Symm fc card, the new card
put in will have the same wwpn of the pervious card.  We found out
that in testing the ESS, IBM tested by pulling out the fc card and
then putting the same card back in the same bay/slot!!!!!  There is a
microcode fix which provides persistent ess wwpn names, but it
requires you to delete/recreate your AIX hdisk's.  Dending on how
long you've had your ESS, you may already be using this microcode.

I strongly suggest that all ESS fiber channel customers talk to IBM
about this microcode upgrade.

On 11 Jun 2001, at 17:18, Van Ruler, Ruud R SSI-ISES-31 wrote:

> Guys
>
> t
his is not really a TSM matter but perhaps someone could help me out here:
>
> At the moment we have a concerning situation on a ESS. When we change
> ESS-ports for an AIX-server without touching the assigned LUN's of the
> server, only a Hba-swap on the ESS, our customers complain about the
> availability of the disks from the servers point of view. They say that
> after we performed this action and they have deleted the disks, rebooted the
> server and ran config-manager, they still have missing disks (some disks are
> visible, but not all of them), note that before the Hba-swap, the server
> could see all its disks.
> When they boot the server again a couple of days later, all the disks are
> visible again without us performing any actions on the ESS or the switches.
>
> any ideas ???
>
> thanks
>
>
> Ruud van Ruler,  Shell Services International BV - ISES/31
> Our Central Data Storage Management home page:
> http://sww2.shell.com/cdsm/
> > Room 1B/G01
> > Dokter van Zeelandstraat 1, 2285 BD Leidschendam NL
> Tel : +31 (0)70 - 3034644, Fax 4011, Mobile +31 (0)6-55127646
> Email Internet: ruud.r.vanruler AT is.shell DOT com
>                           rvanruler AT hotmail DOT com
>
>                                                             R.vanRuler
>