Hi Wendell,
Thanks for pointing out the typo in the example. I'll request an update
to the pubs to fix that.
The CREDSNAM DD names a file that contains the credentials you want to
add. It looks like your credential file is mostly there. The accessKey value
should be the Azure storage account name. However, the contents of the
credentials file has an extra comma after the "secretAccessKey" value. That is
what it is complaining about in the GDKU0034E ERROR PARSING CREDENTIALS FILE
message.
The intent of the CREDSNAM DD file is that it holds the actual cloud
credentials you are adding for that user, i.e. the same ones you enter with the
ISPF application. So, it would be different for each user. The idea is that the
security admin gets the credentials into a file, uploads it to z/OS to a
personal directory, runs the GDKUTIL to add those credentials, and then deletes
the file because you don't want those credentials potentially exposed. I've
seen some customers use automation like Jenkins or Ansible to create the file
on z/OS with the credentials, before submitting the GDKUTIL job, and then
deleting the temp credentials file before completing.
Sincerely,
Andrew Wilt
DFSMSdfp CDA (Cloud Data Access) Product Owner
IBM Z Content Solutions | IBM z/OS Cloud Data Access
z/OS DFSMS Community
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Wendell Lovewell
Sent: Tuesday, May 19, 2026 8:13 AM
To: [email protected]
Subject: [EXTERNAL] Re: ADRDSSU Restore CLOUD without ~/gdk files?
Thank you for your help Ernesto.
I'm trying to run the job in Example 9 (from
https://www.ibm.com/docs/en/zos/3.2.0?topic=examples-example-9-new-default-credentials-cloud1-provider
)
But I don't think I understand what it's supposed to do.
I ran:
//ADDKEYS EXEC PGM=GDKUTIL,REGION=0M
//SYSPRINT DD SYSOUT=L
//SYSOUT DD SYSOUT=L
//SYSIN DD *
CREDENTIALS(ADD) PROVIDER(AZURE)
/*
//CREDSNAM DD *
/usr/lpp/dfsms/gdk/azurekeys.json
/*
/usr/lpp/dfsms/gdk/azurekeys.json contains:
{
"accessKey": "9xxxxxxxxxxxxx42",
"secretAccessKey": "38Exxxx2348C3",
}
(btw, the EXEC stmt in the example didn't have a step name, and it also says
//CREDSNAME, not //CREDSNAM.)
But I got these error messages:
5695-DF124 DFSMSdfp CDA 3.2 CLOUD OBJECT UTILITY 2026139 14:26:16
CREDENTIALS(ADD) PROVIDER(AZURE)
GDKU0013I CREDSNAM: /usr/lpp/dfsms/gdk/azurekeys.json
GDKU0030I BUCKET NAME NOT SPECIFIED FOR CREDS(ADD) COMMAND. CREDENTIALS WILL
BE SAVED AS DEFAULT CREDENTIALS
GDKU0034E ERROR PARSING CREDENTIALS FILE. RC: 265 RSN: 104 DIAG: Expected
pair name in object at offset 364.
-should the file pointed to by CREDSNAM be a valid gdkkeyf.json file, or just
the key/secretKey pair? (Or should it be accessKey/secretAccessKey?)
-should those 2 values be the storage account name and Access key we also enter
from SYS1.SAXREXEC(GDKAUTHP), or from a different user's gdkkeyf.json file?
(The keys stored for different users are different, so I doubt that's correct.
Does Azure have both an accesskey and secretAccessKey?)
Thanks again,
Wendell
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
