thanks for the hosting info we like to keep the builds current for all targets so from-source-only users are thrown into a build-debug cycle
here are the 2005 ast-ksh source snapshots ast-ksh.2005-01-31.tgz ast-ksh.2005-02-02.tgz ast-ksh.2005-03-19.tgz ast-ksh.2005-07-01.tgz ast-ksh.2005-07-29.tgz ast-ksh.2005-09-16.tgz and the only binary snapshot for 2005 ast-ksh.2005-02-02.mvs.390.tgz I'll send you ast-ksh.2005-02-02.tgz in a separate msg On Mon, 14 Feb 2011 22:13:02 -0800 tom honermann wrote: > 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
