DSCLI Password Field

With recent versions of the DSCLI utility, we can no longer programmatically populate the password field and must instead rely exclusively on the built‑in pwfile mechanism. Additionally, we are unable to use the -passwd flag directly on the command itself, as passing credentials inline is a security violation. This presents challenges, particularly because not all reporting functionality is exposed through the REST API. Until IBM achieves feature parity between the REST API and DSCLI, DSCLI remains our primary method of access.

Our environment changes frequently—subsystems, access users, and credentials are all highly dynamic. Earlier versions of DSCLI allowed us to manage this variability with significantly greater flexibility. Looking ahead, we anticipate a need to programmatically check out the ID used for backend reporting (which depends on DSCLI), where credentials would rotate automatically and potentially remain valid for as little as one hour.

As an initial stop‑gap, the ability to use a wildcard within the pwfile to support all HMCs would materially reduce operational friction, with a longer‑term enhancement to allow an inline password stream to follow later. Ultimately, enabling this capability, enhancing the REST API to match DSCLI functionality, or fully replacing DSCLI with an SSH‑based solution would eliminate these limitations and significantly simplify our workflow.