You are installing a firmware update on a Brocade DCX with CUP enabled. z/OS reported a Brocade 143-120 Exam timeout on the CUP device. Which action should you take to avoid losing CUP commands?

The correct answer is C. Vary the CUP device offline before starting the firmware update. See the full explanation below for the reasoning.

Question

Options

ABlock the CUP port before starting the firmware update.
BProhibit the CUP port before starting the firmware update.
CVary the CUP device offline before starting the firmware update.
DUse the portdisable command to disable the CUP port before starting the firmware update.

How the community answered

(30 responses)

A
10% (3)
B
3% (1)
C
83% (25)
D
3% (1)

Community Discussion

Orla P.Dec 5, 2025

The correct answer is C, vary the CUP device offline before starting the firmware update. Taking the CUP device offline at the z/OS level is the proper way to stop z/OS from sending CUP commands during the update window, which prevents those timeout errors without touching the fabric-side port state.

Toby R.Jun 24, 2026

The correct answer is C. You need to vary the CUP device offline in z/OS before starting the firmware update, because that tells z/OS to stop sending commands to the CUP device gracefully, which prevents those timeout errors you saw, since the OS is no longer trying to reach a device that goes temporarily unavailable during the update process.

Carlos M.Jun 24, 2026

Toby's right that varying the CUP offline first is the key step, but worth noting that on newer z/OS levels you also want to confirm the device shows "offline" in the HMC before you kick off the firmware load, because the vary command and the hardware actually reflecting offline can have a small lag that catches people off guard.

Lena V.Nov 7, 2025

Saw this exact trap - went with C, varied CUP offline first, saved my score.

Carlos M.Jun 17, 2026

C is right, varying the CUP device offline lets z/OS stop queuing commands before the update hits.

Wesley A.Nov 19, 2025

Burned by this exact scenario my first attempt. The trap is thinking you need to do something on the Brocade side first, so you go for A, B, or D because those all sound like "I am touching the switch before the update." But the timeout z/OS is reporting tells you the real problem: z/OS is actively trying to talk to that CUP device, and if you just yank the firmware out from under it, you lose in-flight commands. The fix has to happen on the z/OS side first, which means telling z/OS to stop sending commands to that device before you ever touch the switch. Genuine question for anyone who got tripped up here: do you understand why varying the device offline is different from just blocking or prohibiting the port on the Brocade side? Think about which system is initiating the CUP conversation and which one needs to gracefully stop first, and you will see why C is the only option that actually protects those commands rather than just cutting the wire mid-sentence.

Viktor S.Nov 26, 2025

Portdisable is the right call here because you are working at the fabric level, telling the switch to stop processing traffic on that port before you touch the firmware, which is exactly the kind of clean handoff that prevents CUP from choking on commands mid-update. Varying the device offline or blocking the port are z/OS-side actions that do not actually stop the switch from trying to service requests, so you are still leaving the door open for that timeout scenario to repeat.

Wesley A.Nov 28, 2025

Viktor, I get the logic but C is actually the one here because varying the device offline through z/OS is what formally quiesces all I/O and removes it from the active channel path, which is the step the firmware update process actually checks for before proceeding, whereas portdisable at the fabric level does not satisfy that prerequisite from the OS perspective and can still leave pending I/O in flight.

Dervla O.Jun 8, 2026

C is the right call here, and the reasoning is straightforward: varying the CUP device offline through z/OS suspends command traffic gracefully before the firmware disruption hits, which prevents the timeout condition from dropping in-flight commands mid-process. The other options touch the Brocade side of the connection rather than the host side, so they do not give z/OS a clean exit before the update begins.

-1

Full 143-120 Practice