Not much to disagree with, is there? (My "really appreciate" was sarcastic; did I fail to make that clear?) My sarcasm referred to their lack of flexibility with regard to enclaves and POSIX; not to their flexibility or lack thereof with regard to specifying the option.
I have not run a test; I don't KNOW that nO is NOT acceptable. Perhaps the manual writer simply thought it too silly to mention. He says what IS acceptable; he does not say that nO is not acceptable. You're right: it would arguably be harder to write code that accepted NO, No, and no but not nO. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, October 18, 2012 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) I disagree. If 'NO', 'No', and 'no' are acceptable, 'nO' should be too. The obvious ways to make the first three interchangeable---using one of the HLASM macro-language LOWER or UPPER BIFs or the like---would indeed make 'nO' admissible too. A line or two of ad hoc code would be re On 10/18/12, Sam Siegel <s...@pscsi.net> wrote: > On Thu, Oct 18, 2012 at 10:34 AM, Charles Mills <charl...@mcn.org> wrote: > >> I really appreciate the flexibility IBM demonstrates in the last >> sentence: >> >> Be running with POSIX(ON) and have set the environment variables to >> signal that you want to establish a nested enclave. You can use the >> __POSIX_SYSTEM environment variable to cause a system() to establish >> a nested enclave instead of performing a fork()/exec(). >> __POSIX_SYSTEM can be set to NO, No, or no. >> > > I'm wondering what would happen if 'nO' was specified? ;-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
