IBM provides several hosted development server programs, but I'm not
familiar with the details of these programs.
IBM System z™ Remote Development Program
http://www-304.ibm.com/isv/spc/rdp.html
Validation Program for z/OS
http://www-304.ibm.com/partnerworld/wps/pub/systems/technical/hardware/iiczosprogram
I wouldn't want you to spend time getting the latest ksh to build just
for little old me. I have access to a z/OS system and can try building
it myself (unfortunately, I can't provide access to our system outside
our organization). My motivation right now is to try and get a simpler
test case to IBM for this issue since, to me, it appears there is likely
a defect in the z/OS sh or kernel leading to the issue I described (I
just can't see why else a file descriptor opened in a parent process and
closed upon exec in a child process would change behavior of the child
process with respect to later use of the same file descriptor). I was
hoping that, if I could look at the source code for this old version of
ksh, that I might be able to isolate a test case that uses just a few
lines of code. If that source code isn't available, then my best bet may
just be to try and build the latest ksh and see if I can still reproduce
the problem.
Tom.
On 2/14/2011 9:27 PM, Glenn Fowler wrote:
as I recall we used some form of guest login on a z/os virtual machine
if I can secure such a login again for a few days I can get
the lastest to build
does ibm still have that setup?
On Mon, 14 Feb 2011 15:21:24 -0800 tom honermann wrote:
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
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
