I've been working with IBM concerning a problem we have been seeing with
ksh running on z/OS. We're using the latest ksh binary available for
z/OS (mvs.390) downloaded from:
http://www2.research.att.com/~gsf/cgi-bin/download.cgi?action=list&name=ksh
This version corresponds to KSH 93q+ from 2005. Presumably, newer
versions of ksh do not build, or at least, are not built and made
available on z/OS.
IBM has been reluctant to look into this issue because they do not
provide support for ksh and have no other reports of this problem
(described below) happening with other programs. I have been unable to
find the KSH 93q+ source code available for download, so am writing to
see if someone might be able to make it available to me for further
debugging this issue.
The problem is that ksh is failing to open a file descriptor when the
same file descriptor was previously used in a parent sh (not ksh)
process. The problem reproduces readily using the test case below on
z/OS 1.8. For anyone interested, here are the files from the test case:
Readme.txt:
This test case demonstrates a defect in the z/OS /bin/sh
or AT&T ksh implementations, or possibly a defect in the
z/OS kernel. To reproduce the problem, run './test.sh'.
If the problem is reproduced, the following error message
should be displayed:
$ ./test.sh
./test2.sh[17]: 5: cannot open [EDC5113I Bad file descriptor.]
The test case consists of two shell scripts. 'test.sh'
attempts to delete a non-existent file using the /bin/sh
builtin implementation of 'rm', and then calls 'test2.sh'.
'test2.sh' re-execs itself using ksh and then attempts to
open file descriptor 5 for append to an output file. The
problem appears when trying to write through that file
descriptor.
Use of the builtin implementation of 'rm' on a non-existent
file triggers /bin/sh to open the z/OS message catalog
(even though no error is displayed in this case). The message
catalog will be opened as file descriptor 5 assuming no
unusual inherited open file descriptors. A case was opened
with IBM regarding the message catalog file descriptor not
being closed when ksh is exec'd. IBM confirmed that the
message catalog file descriptor is properly set to
close-on-exec. It seems that the file descriptor is somehow
tainted such that ksh is later unable to write through
that file descriptor.
The version of ksh being used is the most recent available
from AT&T at http://www2.research.att.com/sw/download/ The
specific URL for downloading the z/OS version of ksh is
http://www2.research.att.com/~gsf/download/tgz/ksh.2005-02-02.mvs.390.gz
Ksh reports its version as:
$ ./ksh --version
version sh (AT&T Labs Research) 1993-12-28 q+
test.sh:
#!/bin/sh
# Attempt to delete a non-existent file using the shell
# builtin implementation of 'rm'. This seems to be the
# trigger for the defect. Commenting out this line, or
# changing it to use /bin/rm avoids the problem.
rm -f non-existent-file
# Ensure CONFIG_SHELL is not set
unset CONFIG_SHELL
# Run the next script
./test2.sh
test2.sh:
#! /bin/sh
# On first invocation, CONFIG_SHELL will not be set
if test "x$CONFIG_SHELL" = "x"; then
# Re-exec this script using ksh
CONFIG_SHELL=./ksh
export CONFIG_SHELL
exec "$CONFIG_SHELL" "$0"
fi
# Open file descriptor 5 for append to the output file
exec 5>>test.out
# Attempt to write to file descriptor 5. If the defect
# is triggered, this will result in an error:
# <script>[line]: 5: cannot open [EDC5113I Bad file descriptor.]
echo "test" >&5
# Cleanup
rm -f test.out
Tom.
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
