We created a jobs which launches a linux script. Within the script we tsdsn strings to a z/OS file. When ran under a user id that exist on z/OS and linux, the job runs fine. Now we wanted to setup a run similiar to prod. The z/OS id will be an application id and the linux id would also be a application id but different. We are getting access problems. Could you explain how the credentials are working for fromdsn? We are going to create a matching z/OS and linux application id to see if that works.
stderr
IKJ56231I FILE SYS00003 NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+
IKJ56231I TEXT UNIT X'0002' CONTAINS INVALID LENGTH
fromdsn()[E]: DatasetHandler: BPXWDYN allocation failed S99ERROR=0x037C S99INFO=0x0002
fromdsn()[E]: DatasetHandler: BPXWDYN command was: "alloc fi(SYS00003) reuse msg(2) da('') shr"
IKJ56247I FILE SYS00003 NOT UNALLOCATED, IS NOT ALLOCATED
FOTS1346 Permission denied, please try again.
IKJ56231I FILE SYS00003 NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+
IKJ56231I TEXT UNIT X'0002' CONTAINS INVALID LENGTH
fromdsn()[E]: DatasetHandler: BPXWDYN allocation failed S99ERROR=0x037C S99INFO=0x0002
fromdsn()[E]: DatasetHandler: BPXWDYN command was: "alloc fi(SYS00003) reuse msg(2) da('') shr"
IKJ56247I FILE SYS00003 NOT UNALLOCATED, IS NOT ALLOCATED
FOTS1346 Permission denied, please try again.
IKJ56231I FILE SYS00003 NOT ALLOCATED, SYSTEM OR INSTALLATION ERROR+
IKJ56231I TEXT UNIT X'0002' CONTAINS INVALID LENGTH
fromdsn()[E]: DatasetHandler: BPXWDYN allocation failed S99ERROR=0x037C S99INFO=0x0002
fromdsn()[E]: DatasetHandler: BPXWDYN command was: "alloc fi(SYS00003) reuse msg(2) da('') shr"
IKJ56247I FILE SYS00003 NOT UNALLOCATED, IS NOT ALLOCATED
FOTS1373 Permission denied (publickey,password,keyboard-interactive).
[22:51:26.701058] CoZLauncher[E]: <29> appid01@testsrv3l target command '<default shell>' ended with RC=255
Problem running under application id
Its difficult to tell precisely what is happening without seeing more details from your job, but it looks to me like you are not even getting an ssh connection setup to the remote server.
It appears you are using "SSH_ASPASS" for ssh authentication, and that you have pointed this to read_passwd_dsn.sh. This is a shell script that will be called by Ported Tools ssh to authentication the connection. If you look at the shell script you will see that it does a "fromdsn" command, using the contents of the "PASSWD_DSN" environment variable as the argument. In your case it looks like an empty DSN is being set in this environment variable. This causes the fromdsn command to get an error and to not write the password to stdout (which is an unnamed pipe back to the Ported Tools ssh command). ssh doesn't get a password, so you get FOTS1346.
It appears you are using "SSH_ASPASS" for ssh authentication, and that you have pointed this to read_passwd_dsn.sh. This is a shell script that will be called by Ported Tools ssh to authentication the connection. If you look at the shell script you will see that it does a "fromdsn" command, using the contents of the "PASSWD_DSN" environment variable as the argument. In your case it looks like an empty DSN is being set in this environment variable. This causes the fromdsn command to get an error and to not write the password to stdout (which is an unnamed pipe back to the Ported Tools ssh command). ssh doesn't get a password, so you get FOTS1346.
I placed the variable (server-env-PASSWD_DSN=) under the //STDENV and the reset in the coz config file. I did this so I could variably supply the password member depending on which user i was using. I placed the variable in the config file and it is working. I assume what I thought was working with ASKPASS was really using the ssh key pair. Thanks for the insight in your response. It lead me to find my problem. I thought it would be ok to supply the one variable inline.
It should be possible to set PASSWD_DSN in STDENV, but you would just have:
PASSWD_DSN=whatever
This would set this environment variable for the top-level Co:Z Launcher batch job, but that would get inherited by the process that starts ssh.
But I see no reason to do this - you can use concatenated DD statements to supply COZCFG, so that one could contain the property:
server-env-PASSWD_DSN=whatever
PASSWD_DSN=whatever
This would set this environment variable for the top-level Co:Z Launcher batch job, but that would get inherited by the process that starts ssh.
But I see no reason to do this - you can use concatenated DD statements to supply COZCFG, so that one could contain the property:
server-env-PASSWD_DSN=whatever