Re: Nested enclaves and POSIX(ON)
In cae1xxdeniobbjjea8bfkn_xpwazivrucqzpgxwronmim_js...@mail.gmail.com, on 10/21/2012 at 04:21 PM, John Gilmore jwgli...@gmail.com said: bad manners PKB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Sun, 21 Oct 2012 16:21:52 -0400, John Gilmore wrote: ... I don't mind ad hominem criticisms of me, even when they take the puerile forms his take; but the technical content of his posts, once redemptive of his bad manners, I'm certainly no expert on the subject of ad hominem, but isn't a reference to his manners an ad hominem criticism? Also, this latest post of yours has no technical content. I no longer judge that there is any reason to read them, and I have taken local steps to avoid seeing them in any circumstances. Ok. But I don't need to know that. Since I shall not comment further on his posts, I wish to avoid any misunderstanding of this personal action. IMO there is no need to explain. Feel free to comment or not. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
...and what SHOULD be the IBM-MAIN logo becomes relevant once again: http://i.qkme.me/3r3ku1.jpg On Mon, Oct 22, 2012 at 8:52 AM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: On Sun, 21 Oct 2012 16:21:52 -0400, John Gilmore wrote: ... I don't mind ad hominem criticisms of me, even when they take the puerile forms his take; but the technical content of his posts, once redemptive of his bad manners, I'm certainly no expert on the subject of ad hominem, but isn't a reference to his manners an ad hominem criticism? Also, this latest post of yours has no technical content. I no longer judge that there is any reason to read them, and I have taken local steps to avoid seeing them in any circumstances. Ok. But I don't need to know that. Since I shall not comment further on his posts, I wish to avoid any misunderstanding of this personal action. IMO there is no need to explain. Feel free to comment or not. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
In cae1xxdesvwomzzgscbtwrat9grkif67fq1i_4v4m8u5yxrd...@mail.gmail.com, on 10/18/2012 at 10:27 PM, John Gilmore jwgli...@gmail.com said: It is difficult for me to avoid the conclusion that Paul Gilmartin's latest post in this thread was disingenuous. That says more about you than it does about him. I see nothing in Message-ID: 5318340582333965.wa.paulgboulderaim@listserv.ua.edu to suggest that he doesn't believe what he wrote. There is much anecdotal evidence that secondary-school debating-society posts all but empty of substantive content are becoming more and more common here. Yours among them. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
In 8836369831477103.wa.paulgboulderaim@listserv.ua.edu, on 10/19/2012 at 06:18 PM, Paul Gilmartin paulgboul...@aim.com said: I know very little COBOL. But I understand that the levels are for record/control block definitions. Except when they aren't. 77 and 88 are magic numbers in COBOL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
In CAE1XxDEoPLRZNdi_yt1E32k8s29YBH8oucHPhu2Vw9P0YV=2...@mail.gmail.com, on 10/20/2012 at 09:19 AM, John Gilmore jwgli...@gmail.com said: COBOL's 88-level machinery is an artefact of lacunæ elsewhere. In particular, boolean variables, A variable definition in COBOL can be followed by more than two level 88 declarations; they are closer to status variables in JOVIAL than they are to boolean variables. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
I see Shmuel's posts only when they are part of a thread I have posted to, but even that is now too much. I don't mind ad hominem criticisms of me, even when they take the puerile forms his take; but the technical content of his posts, once redemptive of his bad manners, has now deteriorated. It is often exiguous or worse. I no longer judge that there is any reason to read them, and I have taken local steps to avoid seeing them in any circumstances. Since I shall not comment further on his posts, I wish to avoid any misunderstanding of this personal action. Shmuel is and should be free to post here. Freedom of speech must certainly include the freedom to express notions that seem to me to be devoid of merit. John Gilmore, Ashland, MA 01721 - USA Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Most levels are for breaking an area of memory into various fields. Not an 88 level. DATA DIVISION. ... 10 FIELD-NAME PIC X(5). 88 FIELD-NAME-TRUE VALUE 'TRUE ;. 88 FIELD-NAME-FALSE VALUE 'FALSE'. ... PROCEDURE DIVISION ... IF FIELD-NAME-TRUE THEN is equivalent to IF FIELD-NAME = 'TRUE ' THEN On Fri, Oct 19, 2012 at 6:18 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 19 Oct 2012 16:33:20 -0400, Kirk Talman wrote: Cobol has EVALUATE and 88 levels that can accomplish this. I know very little COBOL. But I understand that the levels are for record/control block definitions. How does this (help to) provide the function of strcasecmp()? (Perhaps a schematic example?) IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 10/18/2012 04:21:07 PM: From: Paul Gilmartin C has the standard library function strcasecmp(). Does COBOL or PL/I provide similar. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
COBOL's 88-level machinery is an artefact of lacunæ elsewhere. In particular, boolean variables, while they have made their way into the COBOL standard, have not yet made it into IBM COBOL implementations. An eminent jesuit cardinal, confronted with the knuckle of one saint and a portion of the thigh bone of another, observed that it was long past time to give these things a decent burial. John Gilmore, Ashland, MA 01721 - USA Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Sat, 20 Oct 2012 09:19:24 -0400, John Gilmore wrote: COBOL's 88-level machinery is an artefact of lacunæ elsewhere. In particular, boolean variables, while they have made their way into the COBOL standard, have not yet made it into IBM COBOL implementations. IBM's adherence to standards is frequently moderated by an NIH attitude. IBM fails to understand that nowadays it is a tail (in a couple senses) that can no longer wag the dog. On Sat, 20 Oct 2012 07:32:24 -0500, Mike Schwab wrote: Most levels are for breaking an area of memory into various fields. Not an 88 level. Ah! I quite misunderstood, taking '88' to be a cardinal number (not Jesuit). DATA DIVISION. ... 10 FIELD-NAME PIC X(5). 88 FIELD-NAME-TRUE VALUE 'TRUE ';. 88 FIELD-NAME-FALSE VALUE 'FALSE'. ... PROCEDURE DIVISION ... IF FIELD-NAME-TRUE THEN is equivalent to IF FIELD-NAME = 'TRUE ' THEN So it's almost but not quite entirely unlike the use of enum in other languages. But still: On Fri, Oct 19, 2012 at 6:18 PM, Paul Gilmartin wrote: ... How does this (help to) provide the function of strcasecmp()? (Perhaps a schematic example?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Cobol has EVALUATE and 88 levels that can accomplish this. IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 10/18/2012 04:21:07 PM: From: Paul Gilmartin paulgboul...@aim.com C has the standard library function strcasecmp(). Does COBOL or PL/I provide similar. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Fri, 19 Oct 2012 16:33:20 -0400, Kirk Talman wrote: Cobol has EVALUATE and 88 levels that can accomplish this. I know very little COBOL. But I understand that the levels are for record/control block definitions. How does this (help to) provide the function of strcasecmp()? (Perhaps a schematic example?) IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 10/18/2012 04:21:07 PM: From: Paul Gilmartin C has the standard library function strcasecmp(). Does COBOL or PL/I provide similar. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Oct 18, 2012, at 10:50 AM, Sam Siegel s...@pscsi.net wrote: On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. I gather it's also not possible to turn POSIX on programmatically, is that correct? It has to be set either with a #pragma or one of the CEEOPTS type methods, is that right? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
the C/C++ needed to be callable from non-POSIX COBOL. It's worse than that. POSIX anything is not even callable from POSIX COBOL. That's how the message reads, and I just verified by running the COBOL program //CEEOPTS DD * POSIX(ON) What a PITA! LE. G. Am I reading what you say to imply that this should work if the C were on its own TCB (task)? That if I wrote a little COBOL-callable stub to ATTACH the C++ program and wait for it that it should work? Can anyone confirm or deny my conjecture that there is no straightforward programmatic way to turn POSIX(ON) from within a program (short of using CEEPIPI to build a new enclave, etc.). I can't have a basic C++ program that starts up and after a while says this next function is going to require POSIX(ON) and so calls setposix(true); Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 7:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Thu, Oct 18, 2012 at 9:28 AM, Charles Mills charl...@mcn.org wrote: the C/C++ needed to be callable from non-POSIX COBOL. It's worse than that. POSIX anything is not even callable from POSIX COBOL. That's how the message reads, and I just verified by running the COBOL program //CEEOPTS DD * POSIX(ON) What a PITA! LE. G. Am I reading what you say to imply that this should work if the C were on its own TCB (task)? That if I wrote a little COBOL-callable stub to ATTACH the C++ program and wait for it that it should work? Charles - You are correct. That is exactly what my process does. COBOL calls ASM. ASM attaches task. Attached task uses CEEPIPI to call POSIX(ON) C/C++ code. Sam Can anyone confirm or deny my conjecture that there is no straightforward programmatic way to turn POSIX(ON) from within a program (short of using CEEPIPI to build a new enclave, etc.). I can't have a basic C++ program that starts up and after a while says this next function is going to require POSIX(ON) and so calls setposix(true); Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 7:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Thu, Oct 18, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Yes - From my reading of the DOC, each TCB can have a separate and independent LE ENCLAVE. This has proven to be true and works well. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Oct 18, 2012, at 10:50 AM, Sam Siegel s...@pscsi.net wrote: On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. I gather it's also not possible to turn POSIX on programmatically, is that correct? It has to be set either with a #pragma or one of the CEEOPTS type methods, is that right? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Don't have C/C++ compiler, so cannot test this, but could a new pthread be used instead of an intermediate ASM program in order to get a new LE enclave on the new thread (TCB)? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 9:28 AM, Charles Mills charl...@mcn.org wrote: the C/C++ needed to be callable from non-POSIX COBOL. It's worse than that. POSIX anything is not even callable from POSIX COBOL. That's how the message reads, and I just verified by running the COBOL program //CEEOPTS DD * POSIX(ON) What a PITA! LE. G. Am I reading what you say to imply that this should work if the C were on its own TCB (task)? That if I wrote a little COBOL-callable stub to ATTACH the C++ program and wait for it that it should work? Charles - You are correct. That is exactly what my process does. COBOL calls ASM. ASM attaches task. Attached task uses CEEPIPI to call POSIX(ON) C/C++ code. Sam Can anyone confirm or deny my conjecture that there is no straightforward programmatic way to turn POSIX(ON) from within a program (short of using CEEPIPI to build a new enclave, etc.). I can't have a basic C++ program that starts up and after a while says this next function is going to require POSIX(ON) and so calls setposix(true); Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 7:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Do anyone know that ? : http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.bpxb100/sdd.htm This change the behaviour of your current address space, making each ATTACH to create a new Unix process (Dubbing), each one having its own enclave and then maybe their own POSIX option For SDSF users, you should be able to see changes with ps option Quoc-Hoa TRAN On Thu, Oct 18, 2012 at 6:57 PM, McKown, John john.mck...@healthmarkets.com wrote: Don't have C/C++ compiler, so cannot test this, but could a new pthread be used instead of an intermediate ASM program in order to get a new LE enclave on the new thread (TCB)? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 9:28 AM, Charles Mills charl...@mcn.org wrote: the C/C++ needed to be callable from non-POSIX COBOL. It's worse than that. POSIX anything is not even callable from POSIX COBOL. That's how the message reads, and I just verified by running the COBOL program //CEEOPTS DD * POSIX(ON) What a PITA! LE. G. Am I reading what you say to imply that this should work if the C were on its own TCB (task)? That if I wrote a little COBOL-callable stub to ATTACH the C++ program and wait for it that it should work? Charles - You are correct. That is exactly what my process does. COBOL calls ASM. ASM attaches task. Attached task uses CEEPIPI to call POSIX(ON) C/C++ code. Sam Can anyone confirm or deny my conjecture that there is no straightforward programmatic way to turn POSIX(ON) from within a program (short of using CEEPIPI to build a new enclave, etc.). I can't have a basic C++ program that starts up and after a while says this next function is going to require POSIX(ON) and so calls setposix(true); Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 7:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:06 AM, Charles Mills charl...@mcn.org wrote: I have a program written in LE C++ that is among other usages designed to be callable from a COBOL (or potentially other LE) program. I recently changed the program to run POSIX(ON) because it is now sometimes calling the GSK crypto routines. Now, when I call it from a COBOL program I get the following error: CEE3648S POSIX(ON) run-time option in a nested enclave enclave-name is not supported. Explanation: In Language Environment, a process can have only one enclave that is running with POSIX(ON), and that enclave must be the first enclave. All nested enclaves must be running with POSIX(OFF). Programmer response: Specify the POSIX(ON) run-time option for only the first enclave. Make sure all nested enclaves specify POSIX(OFF). System action: The application will be terminated. Is it truly the case that a POSIX(ON) main program can't be invoked from another LE program? That seems kind of restrictive given that a number of C library functions require POSIX(ON). I ran into that problem with a bunch of C/C++ code that needed to be POSIX(ON). Same requirement, the C/C++ needed to be callable from non-POSIX COBOL. My solution was to put the C/C++ in a seperate TCB and use CEEPIPI in that TCB to start a new LE ENCLAVE. - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN
Re: Nested enclaves and POSIX(ON)
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. :-( Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Yes - From my reading of the DOC, each TCB can have a separate and independent LE ENCLAVE. This has proven to be true and works well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
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? ;-) :-( Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Yes - From my reading of the DOC, each TCB can have a separate and independent LE ENCLAVE. This has proven to be true and works well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? ;-) :-( Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Yes - From my reading of the DOC, each TCB can have a separate and independent LE ENCLAVE. This has proven to be true and works well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
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
Re: Nested enclaves and POSIX(ON)
The manual writer was being silly. The point he or she should have made was that the value was not case-sensitive. For 'no', there are only 2^2 = 4 possible case variants; but for 'yes' there are 2^3 = 8; and for 'maybe' there are 2^5 = 32. Enumeration breaks down very quickly. I doubt that your sarcastic intent was missed by any reader you would care about, and it is understandable. That said, case independence is a highly desirable attribute in contexts like this one. It should be (but is not yet) the norm, everyone's expectation. John Gilmore, Ashland, MA 01721 - USA Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Thu, 18 Oct 2012 11:14:30 -0700, Charles Mills wrote: You're right: it would arguably be harder to write code that accepted NO, No, and no but not nO. Not necessarily; the programmer could easily have coded 3 switch/case/SELECT labels for the branches considered plausible. Easier to code than to document. C has the standard library function strcasecmp(). Does COBOL or PL/I provide similar. HLASM? For all I know it might be one of the new z/EC12 instructions. -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 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. ... Are those not merely macro-language BIFs, but can they generate code to perform the translation at runtime? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
For all I know it might be one of the new z/EC12 instructions. Might be hard to do in hardware. You need locale information. What is the upper-case of 汉字/漢字? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, October 18, 2012 1:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, 18 Oct 2012 11:14:30 -0700, Charles Mills wrote: You're right: it would arguably be harder to write code that accepted NO, No, and no but not nO. Not necessarily; the programmer could easily have coded 3 switch/case/SELECT labels for the branches considered plausible. Easier to code than to document. C has the standard library function strcasecmp(). Does COBOL or PL/I provide similar. HLASM? For all I know it might be one of the new z/EC12 instructions. -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 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. ... Are those not merely macro-language BIFs, but can they generate code to perform the translation at runtime? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
Dragging this thread kicking and screaming back to the OP, yup, it works. I had generic C-callable ATTACH, WAIT, and DETACH functions in assembler. I wrapped some minimal C around them and voila! Only about 3 or 4 hours wasted on this stupid, stupid bit of design idiocy. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Thursday, October 18, 2012 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nested enclaves and POSIX(ON) On Thu, Oct 18, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote: Sam, I am curious was your CEEPIPI and assembler driver to call and establish separate tasks? Yes - From my reading of the DOC, each TCB can have a separate and independent LE ENCLAVE. This has proven to be true and works well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
My point was of course that case independence makes all of 'no', 'nO',
'No', 'NO' interchangeable in use. In PL/I one writes, say,
arg = lower(argument) ;
match = (arg = 'no') ;
or, indifferently,
arg = upper(argument) ;
match = (arg = 'NO') ;
The same thing can be done in C, using all but identical assignment
statements (although the variable declarations for them must be
different). Moreover, since Paul Gilmartin raised the issue, I will
add that this is a fortiori possible in assembly language too.
It is of course true that
match = (arg = 'no') | (arg = 'nO') | (arg = 'No')
| arg = ('NO') ;
is longer than it would be if the term (arg = 'nO') were omitted, but
I would dispense with the services of a programmer who wrote such
things.
I am delighted that Charles found a solution to his problem.
John Gilmore, Ashland, MA 01721 - USA
Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
On Thu, 18 Oct 2012 18:03:46 -0400, John Gilmore wrote:
arg = upper(argument) ;
match = (arg = 'NO') ;
The same thing can be done in C, using all but identical assignment
statements (although the variable declarations for them must be
But why bother when you can use the standard library function,
strcasecmp()?
different). Moreover, since Paul Gilmartin raised the issue, I will
add that this is a fortiori possible in assembly language too.
It is of course true that
match = (arg = 'no') | (arg = 'nO') | (arg = 'No')
| arg = ('NO') ;
is longer than it would be if the term (arg = 'nO') were omitted, but
I would dispense with the services of a programmer who wrote such
things.
My assertion was (and is) that the HLASM macro-language UPPER and
LOWER BIFs avail little to this end.
I am delighted that Charles found a solution to his problem.
Not only a problem but also a perplexity over elliptical documentation.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nested enclaves and POSIX(ON)
It is difficult for me to avoid the conclusion that Paul Gilmartin's latest post in this thread was disingenuous. He is not, moreover, the only or, certainly, the most egregious offender. There is much anecdotal evidence that secondary-school debating-society posts all but empty of substantive content are becoming more and more common here. LOWER and UPPER are certainly HLASM macro-language, i.e., assembly-time, BIFs. Equally, they are C and PL/I, i.e., execution-time, BIFs. They are all, no matter what their binding times, specializations of the System/360 TRanslate instruction [when they are implemented in even minimally intelligent fashion]. In the case of PL/I, which makes a much more general TRANSLATE BIF available, they are also gratuitous, provided for the convenience of quondam C programmers accustomed to thinking and coding at much lower levels of generality.) Binding-time decisions can be important, even crucial; but what can be done early can usually, almost always be done late too. Mr. Gilmartin thus has thing ass backwards. Premature bindings are almost always the culprits. John Gilmore, Ashland, MA 01721 - USA Avant d'imprimer cet e-mail, réfléchissons à l'impact sur l'environnement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
