BCPii Recovery enhancements

[Brian.R.Young]

We are in the process of upgrading to z16 and noticed some weird BCPii behavior.  2 basic issues:

1) The SE is in a weird state and has to be recycled for discovery to completely work.  OPS BCPii does not see comm. go away and come back.

2) MCLs get installed and OPS BCPii does not know when communication comes back.

We have determined after working with support that the events are not received on the published interface when comm. actually goes away or comes back.   I did notice this IBM BCPii msg. when we tried to use the interface after MCLs were applied to our test box this past weekend.  The MCLs were applied on Sat. however we did not try to use it until Monday.

HWI007I BCPII IS ATTEMPTING COMMUNICATION WITH THE LOCAL CENTRAL
PROCESSOR COMPLEX (CPC).

We know we can't control what IBM supports however we were hoping that OPS could periodically poll and test the connection and rediscover if necessary once communications is reestablished.  See case 33715612 for reference.

[Marcel van Ek]

Hi Brian, we've also experienced some issues with MCL upgrades. (ever since starting using BCPii , but since r14 and BCPiiv2 in OPS its been better, but not faultless)

Also running z16 and during MCL we see these events

HWSHWCOMER HARDWARE COMMUNICATION ERROR - PERMANENT  CPC IBM390PS.xxxxxx

For multiple CPC's, depending on MCL actions from IBM

What we see is that we need to cycle (or refresh topo) the OPSbcpii task at which point we then get these:

HWSHWCOMER HARDWARE COMMUNICATION EVENT - AVAILABLE  CPC IBM390PS.xxxxxx

So it's not discovering that automatically...

In case it were TEMPORARY errors it usually recovers okay.....but as we're relying on BCPii for several automated actions, we always cycle the OPSbcpii task after IBM completes their stuff....

Marcel van Ek

------------------------------
Automated Operations
Atos
Netherlands
------------------------------