Tape Library

 View Only

 SETSYS CLOUD CDA - STORED PASSWORD NOT FOUND

Andrew Humphries's profile image
Andrew Humphries posted 02/23/26 01:01 PM

We are implementing TCT with CDA between our DS8K and TS7700 (all internal). 

CDA panel is setup, keyrings defined, provider file in place, however we are getting a STORED PASSWORD NOT FOUND when issuing the SETSYS command.

SETSYS CLOUD(NAME(spcloud) CDACREDENTIALS)

COMMAND REQUEST 00011343 SENT TO DFSMSHSM                
ARC1583I CLOUD PASSWORD ERROR - STORED PASSWORD NOT FOUND
ARC0100I SETSYS COMMAND COMPLETED - CLOUD(NAME(SPCLO... 

They Key and Secret Key have all been checked, re-entered, looks ok. Does anyone know which password, or where it is looking that it can't find the CDA password?

Thank you,

Andrew

Andrew Wilt's profile image
Andrew Wilt posted 02/24/26 11:15 AM

Hi Andrew,

    I am not an expert on the DFSMShsm side of the process, but I'll make sure they are aware of the question and can get a more complete answer posted here.

    With CDA, though, I often see similar things when credentials are saved on one system in the Sysplex, but they can't be accessed on a different LPAR. Often, the cause is that ICSF on the other system hasn't seen the updated entry in the ICSF Crypto Key Data Set (CKDS). To fix that, restarting the ICSF address space is needed. For a more permanent (and usable) solution, the ICSF parmlib member (CSFPRMxx) should have the SYSPLEXCKDS(YES) setting. That tells each ICSF address space that they are sharing the CKDS with other LPARs, and should be aware of changes done by other systems.
    In your environment, was the DFSMShsm address space that issued the error on an LPAR different from where the CDA credentials utility was run/credentials saved?

Andrew Wilt

DFSMSdfp CDA Product Owner

Robert Gensler's profile image
Robert Gensler posted 02/26/26 08:14 AM

Hi Andrew,

Something I would want to verify is the file ownership and permissions of the files and directories in the ~/gdk sub-directory.   For example,  if the hsm server runs under the dfhsm userID, then I would want to make sure that the dfhsm userID has an OMVS segment defined.  And the gdk directory exist under that users home directory.  Then I would want to look at file ownership and permissions.  the dfhsm userID would either have to be the owner or in a group with read access to the files and read and execute to the directories.  Sometimes what I have seen is that since we are setting this up for hsm under a different userID ownership of the files is pointing to the user that setup the config, not the dfhsm userID. 

It looks like you have the function installed and enabled in hsm because if you didn't hsm would have thrown a syntax error on the SETSYS with CDACREDS.  That points me to wanting to look closer at the permissions mentioned above. 

Hope this helps and if not please reach out we are happy to help you get this setup and configured!  

Related Content