On DS8870 R7.3, the following problem has occurred and we heard from PFE/Development that its cause is microcode specification.
Therefore, on 2015/05 we have opened FITS MR0513155244 to request the design change, but we do not know its result because FITS was already sunset...
But now, this symptom is occurring with R7.5.8, so we think our request has rejected.
...
We would like to know whether the same symptom will be occur on DS8880(R8 code).
And would like to request a design change if DS8880 has a same design.
As for problem(specification) details, please refer below "Problem details on DS8870" section.
<Problem details on DS8870>
Please refer to PMR#01079,67D,760(Below link).
https://w3-03.ibm.com/systems/techlink/psdb/global/viewRecord.do?category=PMH&uid=0107967D760-20150323&sessionTime=1539607456165&rsid=2&seqNo=3&displayId=01079%2C67D%2C760&searchStr=01079%2C67d&totalHits=3
The customer's Preserved Mirror operation is as follows.
11. Everyday 07:50, establish Preserved Mirror with below command.
COPY FULL INDD(PRI111) OUTDD(SEC111) ALLDATA(*) ALLEXCP
DUMPCOND -FCNOCOPY PURGE ADMIN FCTOPPRCP(PMP)
22. Everyday(Next day) 07:30 withdraw them with below command.
FCWITHDR SDEVN(X'A769') TDEV(X'A779')
((The customer is doing Step11 and 22 everyday.))
33. Preserved mirror volumes are about 500 vols.
44. At a timing of establish PMP, the following message are posted on the OS console.
07:50:31 IEA494I A94E,1LA527,PPRC PAIR DUPLEX PENDING FC,SSID=3109,CCA=DE
07:50:35 IEA494I C9CB,1ME105,PPRC PAIR DUPLEX PENDING FC,SSID=310D,CCA=DB
07:51:58 IEA494I A94E,1LA527,PPRC PAIR FULL DUPLEX,SSID=3109,CCA=DE
07:51:59 IEA494I C9CB,1ME105,PPRC PAIR FULL DUPLEX,SSID=310D,CCA=DB
The above messages are posted every day mostly, but it isn't the specific address.
The device address which are called with IEA494I are Local-B's address.
55. The same messages are posted with the same address at a timing of withdraw on next day 07:30.
Our understanding is, basically the above DUPLEX Pending(state change) does not occur under Preserve Mirror environment.
Also, back ground copy does not occur after issuing the withdraw command because its(DFSMSdss command) default option is FORCE.
Therefore we want to know why this State Change(IEA494I) was occurred.
(We think that DS8870 has a some illegal volume state, so DS8870 does not accepted a Preserved Mirror command...??)
The answer to above question is as follows from PMR(from PFE/Development).
The cause of IEA494I message is due to flashcopy capabilityheck returned as incapable for Preserve Mirror (FCTOPPRCP(PMP)).
Then established as non PMIR as desired Preferred parameter which pair goes duplex pending. (caused IEA494I message)
After further discussion, it is possible that number of pairs on primary and secondary are different.
Then withdraw force on primary side only in less pair number situation of primary than secondary can cause pair remain in secondary.
Then withdraw invocation is necessary on both primary and secondary.
This could prevent original issue (IEA494I message) as well.
For the above situation, we hear it is the specification of the DS8870 microcode.
As designed PMIR, we know FCWITHDR command for local side is also Withdrawing(performing) for remote relationship.
Our requirement is to Withdraw all relationship in the local and remote side by local side's FCWITHDR command even if number of pairs on primary and secondary are different.
