z/OS

Hi Andrew- this question has been forwarded to our CDA SME. (Due to the holiday week, it might not be until next week when we can get an answer, but just wanted to let you know we're working on it!)  

Hi Andrew.  I think the first possible error is that the gdkconfig.json file should be copied into your ~/gdk/config.json . (It looks like you maybe copied it into your home directory, but it should be in the gdk/ directory within your home directory. 

As to the CSNBKGN RC 12, I think that usually indicates that ICSF isn't running on your system. https://www.ibm.com/docs/en/zos/3.1.0?topic=codes-reason-return-code-c-12 . Once you get ICSF started, you may find that you don't have a crypto card domain assigned to your system. While that is more secure, you can add the "allow-no-CEX": "true" value to the config.json file in your ~/gdk/ directory. This tells CDA that you are okay that the encryption key generated and saved in the ICSF Crypto Key Data Set (CKDS) isn't wrapped (encrypted) by the crypto card master key. 

I'm hoping this gets you going. If not, please post more. I'm watching the thread now.

Andrew Wilt

Thanks for the attention.

@Andrew Wilt the config.jobs is in my ~/gdk folder along with the gdkkeyf.json and the providers files. Sorry if I didn't make that clear initially. I haven't modified it, it's a straight copy from the samples folder.

I'll bring the information about ICSF up to my systems programmers. This is all new to us, so we're learning.

Thanks and I'll keep updating!

Update: We're still working through enabling this. Turns out my gdkauthp errors were because the encryption cards weren't configured into ICKSF. Our RACF team is working through that now. 

Ok, my RACF team and systems programmers have ironed out the encryption facilities. I'm still getting the "Failed to initialize and parse..." errors in GDPAUTHP. 

I've checked a bunch of stuff on my end:

permissions on the gdk folder, contents, and every directory above it to the root are 755
The character set on the config files themselves is untagged
with _BPX_AUTOCVT="ON" I can cat the contents of the files from the OMVS shell (TN3270) and get contents and open the files in OEDIT.
If I tag the files to UTF-8, I can cat the contents in the shell, but OEDIT interprets them as garbage
If I tag the files to IBM-1047 I can cat the contents in the shell, and OEDIT can read them
If I tag the files untagged, I can cat the contents in the shell, and OEDIT can read them.

none of the character set states seems to affect GDKAUTHP being able to access them. 
if I delete the contents of $HOME/gdk, leaving an empty directory structure, the errors go away. But I'm left with no cloud providers.

if I copy the provider files back into $HOME/gdk, I get the cloud providers in the panel list.
BUT! when I try to save a new credential set, I get a new error!

ERROR: No write access to keyFile: /shared_automount/autousers/ads5176/gdk/gdkk
eyf.json                                                                        
***                                                                            

So, we have a permissions issue between GDKAUTHP and being able to write to the gdk path in my USS home directory. So, the new question is: What user/Group does GDKAUTHP run as to access these files, or how do I determine what that is? I don't think setting the key files to 777 is appropriate.

Thanks!

Ok, we got it!
After the RACF and ICKSF was done, I re-copied the sample files from /usr/lpp/dsfms/gdk/samples to my home directory, reset the perms to 600 and it's working. Thanks!

Welp! In the middle of replying, I saw your note that you got it working. I'll post the answers to your question so others can have some insight. 

The contents of the gdkkeyf.json and all other JSON files that CDA accesses is expected to be IBM-1047.  I don't see a clear reason that GDKAUTHP wasn't able to access them previously, though. When you run the ISPF application, it runs under the TSO ID (and authority) of the current user. That RACF user would need to have write permission to the gdkkeyf.json file. The first ISPF panel displayed will display the current user id (or last used userid) in the UserID field. There is no special group expected in order to be able to save into the gdkkeyf.json file when saving credentials. Additionally, the current TSO ID would need read access to the provider file that the keys are being saved for.

If you are a security administrator and are saving the credentials for another user, your RACF ID would need to have write permission to that user's gdkkeyf.json file. (That could be accomplished by being part of a group that has write access to the file and directories.)

We definitely don't recommend setting the key file permissions to 777. At least you would need 600 if you are saving your own keys, and 460 if a security admin is saving keys for you and they are in the group for the file.

Was there something different in the permissions when you copied the gdkkeyf.json file the last time?