Cannot switch to CTC CF After FICON Director Migration for MIM
Article ID: 224819
Updated On:
Products
Issue/Introduction
Migration to devices on a new FICON director failed. Could not migrate from DASD Control file to VCF.
We did the following:
- migrated 1 of 2 sets of CTC devices to newer FICON Director
- prior to migration, switch to DASD communication
- After migration completed, failure to switch back to CTC communication, getting messages:
MIM0067I Command MIGRATE
MIM0232I VCF migration SCHEDULED - MASTER=A
MIM0342I system A VCF activation COMPLETE - MASTER=A
MIM0200W VCF ACCESS DELAYED - MASTER=A
MIM0328W VCF Reserve held by: B Q U V Y
MIM0200W VCF ACCESS DELAYED - MASTER=A
MIM0328W VCF Reserve held by: B Q U V Y
No changes were made to devices, only the ports on the switches got changed, with a corresponding GEN change to reflect this change.
Right now, we are using the remaining CTC links from the current switch. We are down to a single point of failure.
We followed the procedure to deallocate the devices and allocate them again, even did a MIM CTC reset of all the devices, but still did not resolve the issue.
PROCCTC functioned for all device pairs on the new switch.
Environment
Release : 12.5
Component : MIM
Cause
Hardware error
Resolution
When attempting to go to the new switch, The MIGRATE process on SYSA caused an interface control check on first new device on the FICON channel.
This occured during migration from DASD to CTC, when MIM does a Global Copy and sends a larger amount of data over the channel.
When that happened, IBM put out a message indicating an Interface Contol Check, causing MIM set the device permanently in error with the MIM0210 message.
SYSA 21262 20:55:18.26 STC23152 00000090 IOS000I E912,54,ICC,**,**02,,,,MIMGRA
SYSA 21262 20:55:18.26 STC23152 00000090 IOS050I CHANNEL DETECTED ERROR ON E912,54,**,**02,PCHID=01E4
SYSA 21262 20:55:18.27 STC23152 00000090 MIM0210 PERMANENT I/O ERROR ON DEVICE E912 CC=7F STATUS=0002 SENSE=0000
CMD=02
The VFC delay occurred as a result.
VCF recovery kicked in and retried the migration process.
The customer did a MIGRATE back to the DASD Control File, which is the exact right thing to do in that situation.
Further attempts to migrate were done, each one failed with I/O errors on varying systems.
Short term workaround was to fall back to the one set of devices remaining on the old switch.
Research on the MIM side showed all processes for migration had been done correctly.
Research on IBM side showed a hardware error on the new switch. A card was replaced, and subsequent migration activities ran successfully.
Additional Information
This is one possible cause of failure.
If this does not match your situation, please contact Broadcom support for assistance.
Feedback
