IBM FRU identification built into the sync communications cable

FIELD REPLACEABLE UNITS ID AND THE COMM CABLE

My IML (boot) of the IBM 3174 ends with a status message of 5202 and secondary code 0200 which tells me that the proper cable is not attached to the back of the controller. Reading in the maintenance manual I found a paragraph that claims that "FRU Management" will verify the ID of the cable connected. 

IBM maintenance strategies by the 1980s were to swap major chunks of a machine - the Field Replaceable Unit (FRU) - rather than diagnose down to and repair individual components. The configuration combinations on the 3174 are extremely numerous, thus the hardware has a means of interrogating each attached replaceable module to determine its type. 

The connector on the back of the controller is a DB-25 connector which is used for either RS-232 (V.24/V.28) or V.35 serial connections. Clearly IBM is using some of the pins in a non-standard way to identify which of the two types of cables are hooked up. That will also be used to set the speed and protocol being used. 

The microcode of the 3174, during startup, determines what is configured and how it is to be managed. As part of that, it checks the cable and will stop further loading if the correct type of cable isn't attached. I imagine that if the cable were right, it would check some of the control signals so that it won't finish loading if the communications line does not appear active. 

WIRING UNKNOWN

I am faced with a non-standard use of the DB-25 pins that is unknown to me. I have to figure out what pins to connect and what signals to send so that the 3174 microcode is convinced I have a valid cable and communications link. 

Fortunately, I found a eBay listing for an RS232 cable for the 3174 and bought it. I don't know what speed or other configuration it might expect, but at least I will have a valid cable to move forward. It has DB-25 connectors on both ends, as well as two Test/Operate switches in the connector side that hooks to the 3174. 

This should resolve the FRU ID check issue, leaving me a relatively simple task of convincing the controller that there is a communications line talking IBM BSC protocol.