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
