I'm new to Co:Z. I've completed the installation and the SSH from zos to my windows SSHD works. I'm trying to run the example coz batch job in the doc and am receiving the following errors.
fromdsn-clientÝI¨: version: 1.0.5 2008-03-01
Spawn error, file=sncrm &,y& &..CC9RSCNTS& - EDC5129I No such file or directory. (errno2=0x053B006C)
todsn-clientÝD¨: server exit_code=102
Spawn error, file=eqnlcrm &..CC9RSCHM& - EDC5129I No such file or directory. (errno2=0x053B006C)
Spawn error, file=sncrm &,y& &..CC9RSCDQQ& - EDC5129I No such file or directory. (errno2=0x053B006C)
todsn-clientÝE¨: error: CoZServer terminated before all input was read
fromdsn-clientÝD¨: server exit_code=102
todsn-clientÝD¨: server exit_code=102
I can see that I'm having trouble reaching STDIN/STDOUT/STDERR, but don't know what is causing the problem.
I'm not running SSHD on zos, I understand that to be optional for this kind of run.
Any idea where I've gone wrong?
Thanks,
Rob Wunderlich
Spawn error, EDC5129I No such file or directory. (errno2=0x0
-
RobWunderlich
- Posts: 7
- Joined: Wed Mar 26, 2008 3:58 pm
You are right about not needing SSHD on z/OS - it is not required to use Co:Z.
I assume that you are able to login to z/OS under a telnet (not TSO) shell and use the ssh command to get to your Windows box, correct? Note: ssh will not run under TSO OMVS.
Does the userid running the batch job have a OMVS segment in RACF ( or equivalent in your security product)? In other words, can you login to the telnet shell and use ssh from the userid that the batch job is executing under. ? It looks to us like perhaps your job cannot be "dubbed" for using Unix System Services. In order to logon to a telnet shell with this userid, it will also need to have a home directory set in the OMVS segment, which is probably why you are seeing "directory not found".
It also looks like you are having a codepage problem, but that might be resolved when you get your job capable for Unix System Services apis (also known as "dubbing").
Please let us know if you find your problem - I would like to add any known solutions to our FAQ.
I assume that you are able to login to z/OS under a telnet (not TSO) shell and use the ssh command to get to your Windows box, correct? Note: ssh will not run under TSO OMVS.
Does the userid running the batch job have a OMVS segment in RACF ( or equivalent in your security product)? In other words, can you login to the telnet shell and use ssh from the userid that the batch job is executing under. ? It looks to us like perhaps your job cannot be "dubbed" for using Unix System Services. In order to logon to a telnet shell with this userid, it will also need to have a home directory set in the OMVS segment, which is probably why you are seeing "directory not found".
It also looks like you are having a codepage problem, but that might be resolved when you get your job capable for Unix System Services apis (also known as "dubbing").
Please let us know if you find your problem - I would like to add any known solutions to our FAQ.
-
RobWunderlich
- Posts: 7
- Joined: Wed Mar 26, 2008 3:58 pm
I can rlogin to zos with this userid and ssh successfully to the Windows box.
The userid does have an OMVS segment and home directory and is frequently used for USS tasks.
The process is getting dubbed. I get the SYSPRINT message:
CoZAgent: rbwadmin@apptest target program '/bin/bash' PID: 5556
I can also see many debug messages from CoZAgent in SYSOUT, so it appears the SSH is working and the CoZAgent is launched.
I think you're on to something with the codepage error. I'll correct that and see if it fixes the problem.
-Rob
The userid does have an OMVS segment and home directory and is frequently used for USS tasks.
The process is getting dubbed. I get the SYSPRINT message:
CoZAgent: rbwadmin@apptest target program '/bin/bash' PID: 5556
I can also see many debug messages from CoZAgent in SYSOUT, so it appears the SSH is working and the CoZAgent is launched.
I think you're on to something with the codepage error. I'll correct that and see if it fixes the problem.
-Rob
-
RobWunderlich
- Posts: 7
- Joined: Wed Mar 26, 2008 3:58 pm
-
RobWunderlich
- Posts: 7
- Joined: Wed Mar 26, 2008 3:58 pm
Fixed my codepage problem. Just had to change the codepage in my emulator to 1047 
Still have the problem though with STDIN/STDOUT/STDERR, For example:
cozserver(1)[E]: Spawn error, file=È?ÀË> : àà ëèà|íè - EDC5129I No such file or directory. (errno2=0x053B006C)
[17:44:49.480] todsn-client[D]: server exit_code=102
[17:44:49.631] cozagent[E]: Stderr DD Writer(1064) ended with RC=103
I'll keep digging.
-Rob
Still have the problem though with STDIN/STDOUT/STDERR, For example:
cozserver(1)[E]: Spawn error, file=È?ÀË> : àà ëèà|íè - EDC5129I No such file or directory. (errno2=0x053B006C)
[17:44:49.480] todsn-client[D]: server exit_code=102
[17:44:49.631] cozagent[E]: Stderr DD Writer(1064) ended with RC=103
I'll keep digging.
-Rob
Rob,
Ok, so the batch job userid seems to be able to be dubbed OK. Thats good.
It does sound to me like you are invoking ssh and the remote (Windows) CoZAgent program, so that's good too (and is usually the only hard part
So it seems like your systems default Unix encoding is off for some reason. This is usually set by the LANG= or LC_* environment variables.
COZPROC doesn't run a shell, so setting these in /etc/profile is not sufficient.
Co:Z will try to read /etc/init.options, which is used to set primordial environment variables, but it will print a warning message if it is unable to read this file. Do you see this message?
/etc/init.options is where IBM's USS planning guide suggests that you set TZ, LANG, and NLSPATH. One guess is that you have something odd set for LANG=, which is different than what your shells are using (via /etc/profile). Its a little tricky, since setting certain LC_* environment variables can also alter your default codepage.
Here's a test that might help us figure out what you actually have set. There is a program called DTLSPAWN that ships with Co:Z, that is basically a flexible replacement for BPXBATCH. There is sample JCL for it shipped with Co:Z. By default, DTLSPAWN runs your default login shell, but you can run any command.
If you do this:
// EXEC PROC=DTLSPAWN,CMD='/bin/env'
You will display your default environment, without a shell, which is what Co:Z sees.
This should be equivalent, if you prefer, to running something like this with BPXBATCH:
// EXEC PGM=BPXBATCH,PARM='PGM /bin/env'
//STDOUT DD ...
//STDERR DD ...
This will let us know what environment you have set by default.
I don't know what national language you are using, but if you are in the US, you would normally use ISO8859-1 for your default system encoding. This can be specified as the default by setting LANG=C, so long as you don't override by setting one of the LC_* variables differently.
You can alter Co:Z environment variables dynamically by using the config property:
server-env-LANG=C
But in this case I'm not actually sure if this particular variable can be changed after the program starts. It certainly cannot hurt to try this if you determine that you have it set wrong.
COZ_TRSUB is an environment variable that allows us to create "alias names" for codepages that you name in the fromdsn and todsn commands.
Please let us know what you find so that we can figure out if there is a way to avoid this problem in the future.
Ok, so the batch job userid seems to be able to be dubbed OK. Thats good.
It does sound to me like you are invoking ssh and the remote (Windows) CoZAgent program, so that's good too (and is usually the only hard part
So it seems like your systems default Unix encoding is off for some reason. This is usually set by the LANG= or LC_* environment variables.
COZPROC doesn't run a shell, so setting these in /etc/profile is not sufficient.
Co:Z will try to read /etc/init.options, which is used to set primordial environment variables, but it will print a warning message if it is unable to read this file. Do you see this message?
/etc/init.options is where IBM's USS planning guide suggests that you set TZ, LANG, and NLSPATH. One guess is that you have something odd set for LANG=, which is different than what your shells are using (via /etc/profile). Its a little tricky, since setting certain LC_* environment variables can also alter your default codepage.
Here's a test that might help us figure out what you actually have set. There is a program called DTLSPAWN that ships with Co:Z, that is basically a flexible replacement for BPXBATCH. There is sample JCL for it shipped with Co:Z. By default, DTLSPAWN runs your default login shell, but you can run any command.
If you do this:
// EXEC PROC=DTLSPAWN,CMD='/bin/env'
You will display your default environment, without a shell, which is what Co:Z sees.
This should be equivalent, if you prefer, to running something like this with BPXBATCH:
// EXEC PGM=BPXBATCH,PARM='PGM /bin/env'
//STDOUT DD ...
//STDERR DD ...
This will let us know what environment you have set by default.
I don't know what national language you are using, but if you are in the US, you would normally use ISO8859-1 for your default system encoding. This can be specified as the default by setting LANG=C, so long as you don't override by setting one of the LC_* variables differently.
You can alter Co:Z environment variables dynamically by using the config property:
server-env-LANG=C
But in this case I'm not actually sure if this particular variable can be changed after the program starts. It certainly cannot hurt to try this if you determine that you have it set wrong.
COZ_TRSUB is an environment variable that allows us to create "alias names" for codepages that you name in the fromdsn and todsn commands.
Please let us know what you find so that we can figure out if there is a way to avoid this problem in the future.
Rob,
I think our posts crossed. I'm beginning to think that the problem is that your windows box doesn't have a proper codepage configured, or at least one that is recognized by z/OS. That is where COZ_TRSUB is used to map Windows goofy "US-ASCII".
On Windows, under a CYGWIN shell, try running the following non-functional fromdsn command with tracing on to see what your default Windows codepage is:
export COZ_LOG=D
fromdsn -ssh foo@bar //FOO.BAR
For me, this prints:
fromdsn-client version:1.0.5 2008-03-01
fromdsn-client[D] clientCodePage 'US-ASCII' (via setlocale)
ssh: bar: no address associate with name
...
See what you get for your default Windows codepage.
Kirk
I think our posts crossed. I'm beginning to think that the problem is that your windows box doesn't have a proper codepage configured, or at least one that is recognized by z/OS. That is where COZ_TRSUB is used to map Windows goofy "US-ASCII".
On Windows, under a CYGWIN shell, try running the following non-functional fromdsn command with tracing on to see what your default Windows codepage is:
export COZ_LOG=D
fromdsn -ssh foo@bar //FOO.BAR
For me, this prints:
fromdsn-client version:1.0.5 2008-03-01
fromdsn-client[D] clientCodePage 'US-ASCII' (via setlocale)
ssh: bar: no address associate with name
...
See what you get for your default Windows codepage.
Kirk
Rob,
It would help us to have a trace level log of the startup. Try this:
//STEP1 EXEC PROC=COZPROC,
// ARGS='-LT,t myuid@linux1.myco.com'
//STDIN DD *
# This is input to the remote shell
echo "We are running on: " `uname -sr`
//COZCFG DD *
agent-options=-LT,t
target-env-COZ_LOG=T,t
server-env-COZ_LOG=T,t
//
(Note the "T" rather than the "D" from the online documentation). You can email to info@dovetail.com and we'll take a look. This information will probably give us what we need to solve your problem.
It would help us to have a trace level log of the startup. Try this:
//STEP1 EXEC PROC=COZPROC,
// ARGS='-LT,t myuid@linux1.myco.com'
//STDIN DD *
# This is input to the remote shell
echo "We are running on: " `uname -sr`
//COZCFG DD *
agent-options=-LT,t
target-env-COZ_LOG=T,t
server-env-COZ_LOG=T,t
//
(Note the "T" rather than the "D" from the online documentation). You can email to info@dovetail.com and we'll take a look. This information will probably give us what we need to solve your problem.
-
RobWunderlich
- Posts: 7
- Joined: Wed Mar 26, 2008 3:58 pm
FWIW, here's the output from the previously requested /bin/env run:
I'll email the trace log. Thanks for sticking with this.
-Rob
- LIBPATH=/lib:/usr/lib:.
_EDC_ADD_ERRNO2=1
HOME=/u/wts03
_BPX_SHAREAS=MUST
_BPX_SPAWN_SCRIPT=YES
_BPXK_JOBLOG=STDERR
PATH=/bin:/usr/bin
- fromdsn-client[D]: clientCodePage 'US-ASCII' (via setlocale)
I'll email the trace log. Thanks for sticking with this.
-Rob
With some good information from Rob handled offline, his problem was identified to be a corrupted z/OS Unicode System Services translate table.
Co:Z includes a utility "showtrtab" that will dump out a translate table. This table will tell you what Co:Z is expecting to use for a given source and target codepage pair. From your z/OS system, do this (assuming you have the Co:Z bin directory in your PATH):
I've attached the output from our system below as a reference.
As a result of this, and several other problems with Unicode System Services, we've created a new release of Co:Z that allows users to force the use of iconv as an alternative.
See http://www.dovetail.com/forum/viewtopic.php?t=673 for more information.
Co:Z includes a utility "showtrtab" that will dump out a translate table. This table will tell you what Co:Z is expecting to use for a given source and target codepage pair. From your z/OS system, do this (assuming you have the Co:Z bin directory in your PATH):
Code: Select all
showtrtab -LTranslator=T -s ISO8859-1 -t IBM-1047 -q LM
Code: Select all
showtrtab[T]: Translator: -> Translator(ISO8859-1, IBM-1047, LM)
showtrtab[T]: Translator: -> getCodePage(ISO8859-1)
showtrtab[D]: Translator: Looking for codepage substitution environment variable: COZ_TRSUB_ISO8859-1
showtrtab[T]: Translator: <- getCodePage()
showtrtab[T]: Translator: -> getCodePage(IBM-1047)
showtrtab[D]: Translator: Looking for codepage substitution environment variable: COZ_TRSUB_IBM-1047
showtrtab[T]: Translator: <- getCodePage()
showtrtab[T]: Translator: -> initialize( ISO8859-1->IBM-1047, t=LM)
showtrtab[T]: Translator: -> getCcsid(ISO8859-1)
showtrtab[T]: Translator: <- getCcsid(819)
showtrtab[T]: Translator: -> getCcsid(IBM-1047)
showtrtab[T]: Translator: <- getCcsid(1047)
showtrtab[T]: Translator: -> initCunbcprm()
showtrtab[T]: Translator: <- initCunbcprm()
showtrtab[T]: Translator: <- initialize()
showtrtab[T]: Translator: <- Translator()
00: 00 01 02 03 37 2D 2E 2F 16 05 15 0B 0C 0D 0E 0F
10: 10 11 12 13 3C 3D 32 26 18 19 3F 27 1C 1D 1E 1F
20: 40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61
30: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F
40: 7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6
50: D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D
60: 79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96
70: 97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07
80: 20 21 22 23 24 25 06 17 28 29 2A 2B 2C 09 0A 1B
90: 30 31 1A 33 34 35 36 08 38 39 3A 3B 04 14 3E FF
A0: 41 AA 4A B1 9F B2 6A B5 BB B4 9A 8A B0 CA AF BC
B0: 90 8F EA FA BE A0 B6 B3 9D DA 9B 8B B7 B8 B9 AB
C0: 64 65 62 66 63 67 9E 68 74 71 72 73 78 75 76 77
D0: AC 69 ED EE EB EF EC BF 80 FD FE FB FC BA AE 59
E0: 44 45 42 46 43 47 9C 48 54 51 52 53 58 55 56 57
F0: 8C 49 CD CE CB CF CC E1 70 DD DE DB DC 8D 8E DF See http://www.dovetail.com/forum/viewtopic.php?t=673 for more information.