Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
Sam, Thanks for the confirmation, that's what I just figured out from re-reading the FM. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sam Siegel Sent: Friday, March 17, 2017 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs There are two tables which contain the programs: 1) The PreInit table coded with CEEXPIT, CEEXPITY and CEEXPITS macros; 2) The table maintained by LE. During the LE initialization process, a table is constructed in storage controlled by LE. The information in the PreInit table is copied over. The add_entry function updates the LE constructed table, not the user constructed table. Notice that the add_entry, delete_entry, identify_entry, identify_environment and identify_attribute use the environment token, not the table address as function arguments. Please read the add_entry doc again. You will see that it specifically says that the "LE maintained table" On Fri, Mar 17, 2017 at 8:16 AM, Farley, Peter x23353 <peter.far...@broadridge.com> wrote: > Gord, > > That's what I have coded so far, but here is what happens: > > 1. The (init_sub) returns RC=8, but based on the ASMPIPI example I let > that go as not a fatal error since the pre-init table has only empty entries > 2. The first (add_entry) succeeds RC=0 in R15, but the pre-init table is > not updated at all (see debugging display below). The program being added > was compiled with Enterprise COBOL V4.2 so it is certainly a valid LE HLL > subroutine. > > So why does the (add_entry) not update the pre-init table? What am I doing > wrong here? > > Peter > > The pre-init table is defined with four empty entries like this: > > PPTBLCEEXPIT , > CEEXPITY , > CEEXPITY , > CEEXPITY , > CEEXPITY , > CEEXPITS , > > Debugging display (thank you Cole Software!) right after (add_entry) > succeeds, sanitized (names are not what I actually use here): > > XDC ===> d testpipi+4b8 2;d testpipi+4b8? 4;d testpipi+4308 2;d > testpipi+4308+c? > _ _EF48 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI+4B8, @R14+3A, > @R1+50, @R12+4B8, > _ TESTPIPI+4B8, PRIVATE+CF48 > _ +4B8 8fB70992D0 *..k}* > <=== EP address of TESTSUBR and pre-init > table index returned by (add_entry) > _ _370992D0 8f (A.S.TSOUSERE) --- TESTSUBR+0, XPRIVATE+8992D0 > _+0 8f 47F0F028 00C3C5C5 0288 0014 *.00..CEE...h* > <=== TESTSUBR module in storage > _ +10 8f 47F0F001 98CEAC00 37099386 *.00.q.lf* > _ +20 8f 0DFF 90ECD00C 4110F038 *..}. .0.* > _ +30 8f 98EFF04C 07FF 370992D0 *q.0<..k}* > _ _00012D98 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI +4308, > TESTPIPI+4308, PRIVATE+10D98 > _ +4308 8f80042508 0003 ** > <=== Address of CEEPIPI, two other > constants, address of pre-init table > _ +4310 8f 0009 00012EE4 3711BDB8 *...U..].* > _ _00012EE4 8f (A.S.TDPEFARE) --- TESTPIPI.TESTPIPI +4454, > TESTPIPI+4454, PRIVATE+10EE4 > _ +4454 8f C3C5C5E7 D7E3C2D3 0004 *CEEXPTBL* > <=== Pre-init table after (add_entry) succeeds (RC = > 0) > _ +4460 8f 0010 0002 40404040 ** > _ +4470 8f 40404040 40404040 ** > _ +4480 8f 40404040 40404040 ** > _ +4490 8f 40404040 40404040 ** > _ +44A0 8f 40404040 00278000 ** > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gord Tomlin > Sent: Thursday, March 16, 2017 5:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler > main programs > > On 2017-03-16 16:11, Farley, Peter x23353 wrote: >> Doesn't use of (add_entry) presume that you add to the table BEFORE you call >> (init_subr) or (init_subr_dp)? What if initialization is set up to be done >> first, before any entries at all appear in the table? > > We do INIT_SUB, followed by ADD_ENTRY calls for all the routines to be > called via CEEPIPI. Then we do CALL_SUB for any routine using the index > returned by ADD_ENTRY. -- This message and any attach
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
There are two tables which contain the programs: 1) The PreInit table coded with CEEXPIT, CEEXPITY and CEEXPITS macros; 2) The table maintained by LE. During the LE initialization process, a table is constructed in storage controlled by LE. The information in the PreInit table is copied over. The add_entry function updates the LE constructed table, not the user constructed table. Notice that the add_entry, delete_entry, identify_entry, identify_environment and identify_attribute use the environment token, not the table address as function arguments. Please read the add_entry doc again. You will see that it specifically says that the "LE maintained table" On Fri, Mar 17, 2017 at 8:16 AM, Farley, Peter x23353 <peter.far...@broadridge.com> wrote: > Gord, > > That's what I have coded so far, but here is what happens: > > 1. The (init_sub) returns RC=8, but based on the ASMPIPI example I let > that go as not a fatal error since the pre-init table has only empty entries > 2. The first (add_entry) succeeds RC=0 in R15, but the pre-init table is > not updated at all (see debugging display below). The program being added > was compiled with Enterprise COBOL V4.2 so it is certainly a valid LE HLL > subroutine. > > So why does the (add_entry) not update the pre-init table? What am I doing > wrong here? > > Peter > > The pre-init table is defined with four empty entries like this: > > PPTBLCEEXPIT , > CEEXPITY , > CEEXPITY , > CEEXPITY , > CEEXPITY , > CEEXPITS , > > Debugging display (thank you Cole Software!) right after (add_entry) > succeeds, sanitized (names are not what I actually use here): > > XDC ===> d testpipi+4b8 2;d testpipi+4b8? 4;d testpipi+4308 2;d > testpipi+4308+c? > _ _EF48 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI+4B8, @R14+3A, > @R1+50, @R12+4B8, > _ TESTPIPI+4B8, PRIVATE+CF48 > _ +4B8 8fB70992D0 *..k}* > <=== EP address of TESTSUBR and pre-init > table index returned by (add_entry) > _ _370992D0 8f (A.S.TSOUSERE) --- TESTSUBR+0, XPRIVATE+8992D0 > _+0 8f 47F0F028 00C3C5C5 0288 0014 *.00..CEE...h* > <=== TESTSUBR module in storage > _ +10 8f 47F0F001 98CEAC00 37099386 *.00.q.lf* > _ +20 8f 0DFF 90ECD00C 4110F038 *..}. .0.* > _ +30 8f 98EFF04C 07FF 370992D0 *q.0<..k}* > _ _00012D98 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI +4308, > TESTPIPI+4308, PRIVATE+10D98 > _ +4308 8f80042508 0003 ** > <=== Address of CEEPIPI, two other > constants, address of pre-init table > _ +4310 8f 0009 00012EE4 3711BDB8 *...U..].* > _ _00012EE4 8f (A.S.TDPEFARE) --- TESTPIPI.TESTPIPI +4454, > TESTPIPI+4454, PRIVATE+10EE4 > _ +4454 8f C3C5C5E7 D7E3C2D3 0004 *CEEXPTBL* > <=== Pre-init table after (add_entry) succeeds (RC = > 0) > _ +4460 8f 0010 0002 40404040 ** > _ +4470 8f 40404040 40404040 ** > _ +4480 8f 40404040 40404040 ** > _ +4490 8f 40404040 40404040 ** > _ +44A0 8f 40404040 00278000 ** > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gord Tomlin > Sent: Thursday, March 16, 2017 5:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler > main programs > > On 2017-03-16 16:11, Farley, Peter x23353 wrote: >> Doesn't use of (add_entry) presume that you add to the table BEFORE you call >> (init_subr) or (init_subr_dp)? What if initialization is set up to be done >> first, before any entries at all appear in the table? > > We do INIT_SUB, followed by ADD_ENTRY calls for all the routines to be > called via CEEPIPI. Then we do CALL_SUB for any routine using the index > returned by ADD_ENTRY. > > -- > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
Never mind. Re-reading the Fine Manual I think I just found the answer to my question: (init_sub) takes as an argument a user-supplied pre-init table, but does not modify the user copy of the table. Instead, it copies the user entries into a "Language Environment-maintained table". Similarly, when (add_entry) succeeds it adds the new entry into the "Language Environment-maintained table" (although it does not actually say so in so many words). So the "user supplied" pre-init table is used to size and initialize the "Language Environment-maintained table" but is never actually updated by (init_sub) or (add_entry), nor is the user-supplied table ever used by (call_sub). Have I got it right now? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Friday, March 17, 2017 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs Gord, That's what I have coded so far, but here is what happens: 1. The (init_sub) returns RC=8, but based on the ASMPIPI example I let that go as not a fatal error since the pre-init table has only empty entries 2. The first (add_entry) succeeds RC=0 in R15, but the pre-init table is not updated at all (see debugging display below). The program being added was compiled with Enterprise COBOL V4.2 so it is certainly a valid LE HLL subroutine. So why does the (add_entry) not update the pre-init table? What am I doing wrong here? Peter The pre-init table is defined with four empty entries like this: PPTBLCEEXPIT , CEEXPITY , CEEXPITY , CEEXPITY , CEEXPITY , CEEXPITS , Debugging display (thank you Cole Software!) right after (add_entry) succeeds, sanitized (names are not what I actually use here): XDC ===> d testpipi+4b8 2;d testpipi+4b8? 4;d testpipi+4308 2;d testpipi+4308+c? _ _EF48 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI+4B8, @R14+3A, @R1+50, @R12+4B8, _ TESTPIPI+4B8, PRIVATE+CF48 _ +4B8 8fB70992D0 *..k}* <=== EP address of TESTSUBR and pre-init table index returned by (add_entry) _ _370992D0 8f (A.S.TSOUSERE) --- TESTSUBR+0, XPRIVATE+8992D0 _+0 8f 47F0F028 00C3C5C5 0288 0014 *.00..CEE...h* <=== TESTSUBR module in storage _ +10 8f 47F0F001 98CEAC00 37099386 *.00.q.lf* _ +20 8f 0DFF 90ECD00C 4110F038 *..}. .0.* _ +30 8f 98EFF04C 07FF 370992D0 *q.0<..k}* _ _00012D98 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI +4308, TESTPIPI+4308, PRIVATE+10D98 _ +4308 8f80042508 0003 ** <=== Address of CEEPIPI, two other constants, address of pre-init table _ +4310 8f 0009 00012EE4 3711BDB8 *...U..].* _ _00012EE4 8f (A.S.TDPEFARE) --- TESTPIPI.TESTPIPI +4454, TESTPIPI+4454, PRIVATE+10EE4 _ +4454 8f C3C5C5E7 D7E3C2D3 0004 *CEEXPTBL* <=== Pre-init table after (add_entry) succeeds (RC = 0) _ +4460 8f 0010 0002 40404040 ** _ +4470 8f 40404040 40404040 ** _ +4480 8f 40404040 40404040 ** _ +4490 8f 40404040 40404040 ** _ +44A0 8f 40404040 00278000 ** -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, March 16, 2017 5:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs On 2017-03-16 16:11, Farley, Peter x23353 wrote: > Doesn't use of (add_entry) presume that you add to the table BEFORE you call > (init_subr) or (init_subr_dp)? What if initialization is set up to be done > first, before any entries at all appear in the table? We do INIT_SUB, followed by ADD_ENTRY calls for all the routines to be called via CEEPIPI. Then we do CALL_SUB for any routine using the index returned by ADD_ENTRY. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
Gord, That's what I have coded so far, but here is what happens: 1. The (init_sub) returns RC=8, but based on the ASMPIPI example I let that go as not a fatal error since the pre-init table has only empty entries 2. The first (add_entry) succeeds RC=0 in R15, but the pre-init table is not updated at all (see debugging display below). The program being added was compiled with Enterprise COBOL V4.2 so it is certainly a valid LE HLL subroutine. So why does the (add_entry) not update the pre-init table? What am I doing wrong here? Peter The pre-init table is defined with four empty entries like this: PPTBLCEEXPIT , CEEXPITY , CEEXPITY , CEEXPITY , CEEXPITY , CEEXPITS , Debugging display (thank you Cole Software!) right after (add_entry) succeeds, sanitized (names are not what I actually use here): XDC ===> d testpipi+4b8 2;d testpipi+4b8? 4;d testpipi+4308 2;d testpipi+4308+c? _ _EF48 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI+4B8, @R14+3A, @R1+50, @R12+4B8, _ TESTPIPI+4B8, PRIVATE+CF48 _ +4B8 8fB70992D0 *..k}* <=== EP address of TESTSUBR and pre-init table index returned by (add_entry) _ _370992D0 8f (A.S.TSOUSERE) --- TESTSUBR+0, XPRIVATE+8992D0 _+0 8f 47F0F028 00C3C5C5 0288 0014 *.00..CEE...h* <=== TESTSUBR module in storage _ +10 8f 47F0F001 98CEAC00 37099386 *.00.q.lf* _ +20 8f 0DFF 90ECD00C 4110F038 *..}. .0.* _ +30 8f 98EFF04C 07FF 370992D0 *q.0<..k}* _ _00012D98 8f (A.S.TSOUSERE) --- TESTPIPI.TESTPIPI +4308, TESTPIPI+4308, PRIVATE+10D98 _ +4308 8f80042508 0003 ** <=== Address of CEEPIPI, two other constants, address of pre-init table _ +4310 8f 0009 00012EE4 3711BDB8 *...U..].* _ _00012EE4 8f (A.S.TDPEFARE) --- TESTPIPI.TESTPIPI +4454, TESTPIPI+4454, PRIVATE+10EE4 _ +4454 8f C3C5C5E7 D7E3C2D3 0004 *CEEXPTBL* <=== Pre-init table after (add_entry) succeeds (RC = 0) _ +4460 8f 0010 0002 40404040 ** _ +4470 8f 40404040 40404040 ** _ +4480 8f 40404040 40404040 ** _ +4490 8f 40404040 40404040 ** _ +44A0 8f 40404040 00278000 ** -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, March 16, 2017 5:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs On 2017-03-16 16:11, Farley, Peter x23353 wrote: > Doesn't use of (add_entry) presume that you add to the table BEFORE you call > (init_subr) or (init_subr_dp)? What if initialization is set up to be done > first, before any entries at all appear in the table? We do INIT_SUB, followed by ADD_ENTRY calls for all the routines to be called via CEEPIPI. Then we do CALL_SUB for any routine using the index returned by ADD_ENTRY. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
On 2017-03-16 16:11, Farley, Peter x23353 wrote: Doesn't use of (add_entry) presume that you add to the table BEFORE you call (init_subr) or (init_subr_dp)? What if initialization is set up to be done first, before any entries at all appear in the table? We do INIT_SUB, followed by ADD_ENTRY calls for all the routines to be called via CEEPIPI. Then we do CALL_SUB for any routine using the index returned by ADD_ENTRY. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
Hi, if the COBOL subroutines are compiled using NORENT, there could be another possibility; we used this at my former customer's site. The ASSEMBLER main program could call a dummy COBOL main, which does nothing (but builds the LE environment) and calls again the ASSEMBLER main at a secondary entry point. Now the enclave is present, and from now on the ASSEMBLER main can do its work and call the COBOL subroutines. The COBOL subroutines, IMO, only need the correct value in register 12 (the pointer to the Common Anchor Area of LE) and some values in the save areas must be set up correctly (next available byte pointer); you will have to copy these values from the save area that the COBOL main did build. You will see what you have to do if you look at the prologue code of the COBOL functions. Things are different, if the COBOL routines are compiled using RENT; that is, if they have writable static areas; then you need something like CEEFETCH - a normal call using V address constant (or LINK or LOAD macro) will not be sufficient. At the end, the ASSEMBLER main line (secondary entry) returns to the COBOL dummy main; this dummy main terminates the enclave and then it returns to the ASSEMBLER "real" main line. This worked for us; every ASSEMBLER main program was built this way and had a dummy HLL main program linked to it (it was PL/1, in fact), and this was how the main programs built LE enclaves, so that PL/1 and C subroutines could be called later (if necessary). The call to the HLL subroutines was done by a special CALL macro which did the necessary preparations, so that the subroutines found the LE enclave. Kind regards Bernd Am 16.03.2017 um 18:57 schrieb Farley, Peter x23353: Hi All, We are preparing for the transition from COBOL V4.2 to COBOL V5.2. Existing non-LE-enabled assembler main programs need to change from using IGZERRE initialization to using CEEPIPI enclave initialization to allow calling multiple COBOL subroutines, sometimes calling a subroutine more than once per batch step execution. We do know that the assembler main programs really ought to be converted to LE-enabled to make things better, but that is beyond available programmer resources and time at the moment. It may be scheduled later, but in the meantime we need a quicker solution. We already use a set of assembler macros to hide the initialization and loading and calling of COBOL programs from non-LE-enabled main programs, so I am modifying the macros to use CEEPIPI rules instead so that programs can just be re-translated to accomplish the change. Now to my questions: The (call_sub) function of CEEPIPI to call a subroutine states that "The next call to (call_sub) initializes a new enclave", which is obviously CPU expensive. The (call_sub_addr) function of CEEPIPI to call a subroutine does not have this statement. Does this mean I can use the following sequence of calls and only have one enclave created and reused for each called subroutine? CEEPIPI ( (init_sub), . . . ) LOAD EP=SUBPGM1 Save address for CEEPIPI LOAD EP=SUBPGM2 Save address for CEEPIPI CEEPIPI ( (call_sub_addr), (addr-for-SUBPGM1), . . . ) CEEPIPI ( (call_sub_addr), (addr-for-SUBPGM2), . . . ) Etc. CEEPIPI ( (term), . . . ) Or do I need to use the CEEPIPI initialization function (init_sub_dp) instead of (init_sub) to accomplish multiple (call_sub_addr)'s with only one enclave initialization? TIA for your help in understanding the rules here. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Need help understanding use of CEEPIPI from non-LE assembler main programs
On Thu, Mar 16, 2017 at 3:11 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Doesn't use of (add_entry) presume that you add to the table BEFORE you > call (init_subr) or (init_subr_dp)? What if initialization is set up to be > done first, before any entries at all appear in the table? > I'm not 100% sure, but since you're supplying a "token", which you get from the init_sub or init_subp call, I don't think you can do it BEFORE one of the "init_" calls. Also, remember that COBOL is an LE language. And it can do dynamic calls without knowing the name before hand. Looking at one portion, it appears that the "add_entry" can do the z/OS LOAD for you: "routine_entry (input/output) The routine entry address that is added to the PreInit table. If routine_entry is zero on input, routine_name is used as the load name. On output, routine_entry is set to the load address of routine_name. The high-order bit of the entry_point address must be set to indicate the addressing mode for the routine. If the high-order bit is OFF, the routine is called in 24 bit addressing mode and the address must be a valid 24 bit address. If the high-order bit is ON, the routine is called in 31 bit addressing mode and the address must be a valid 31 bit address. " > > Can initialization happen with a "dummy" LE-enabled subroutine in the > table and then calls be made using (call_subr_addr) without any > corresponding table entry for the module(s) to be called? > You talking to me? [grin]. I have no idea, but from what I can read, I get the impression that whatever CEEPIPI function you use to call a routine, the name of that routine must be in the LE pre-init table. > > Peter > > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
Doesn't use of (add_entry) presume that you add to the table BEFORE you call (init_subr) or (init_subr_dp)? What if initialization is set up to be done first, before any entries at all appear in the table? Can initialization happen with a "dummy" LE-enabled subroutine in the table and then calls be made using (call_subr_addr) without any corresponding table entry for the module(s) to be called? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, March 16, 2017 4:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs On Thu, Mar 16, 2017 at 2:52 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I thought I might need to use stert_seq and end_seq too. Thanks for the > advice. > > However, I am running into a little roadblock at the moment. I set things > up copying some of the sample program ASMPIPI listed in the LE Pgmrs Guide, > but without any fixed program name in the ceexptbl entry since the > initialization macro cannot know what program(s) will be called: > > PPTBLCEEXPIT , PREINIT TABLE WITH INDEX > CEEXPITY 0,0 DYNAMICALLY LOADED RTNE, CALL-BY-ADDR > * > CEEXPITS , END OF PREINIT TABLE > > Neither (init_sub) nor (init_sub_dp) will succeed with this ceexptbl, both > of them fail with RC=8. > > Is there any way to set up a totally dynamic ceexptbl, with no actual > entries for any LE-enabled HLL program, and still be able to initialize > successfully? If not, does it matter if the only entry in the ceexptbl is > a dummy HLL program that will NOT be invoked via that table, but only other > programs called via (call_subr_addr) with the address returned by a LOAD > macro? > add_entry: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceea200/cladde.htm > > Peter > -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
On Thu, Mar 16, 2017 at 2:52 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I thought I might need to use stert_seq and end_seq too. Thanks for the > advice. > > However, I am running into a little roadblock at the moment. I set things > up copying some of the sample program ASMPIPI listed in the LE Pgmrs Guide, > but without any fixed program name in the ceexptbl entry since the > initialization macro cannot know what program(s) will be called: > > PPTBLCEEXPIT , PREINIT TABLE WITH INDEX > CEEXPITY 0,0 DYNAMICALLY LOADED RTNE, CALL-BY-ADDR > * > CEEXPITS , END OF PREINIT TABLE > > Neither (init_sub) nor (init_sub_dp) will succeed with this ceexptbl, both > of them fail with RC=8. > > Is there any way to set up a totally dynamic ceexptbl, with no actual > entries for any LE-enabled HLL program, and still be able to initialize > successfully? If not, does it matter if the only entry in the ceexptbl is > a dummy HLL program that will NOT be invoked via that table, but only other > programs called via (call_subr_addr) with the address returned by a LOAD > macro? > add_entry: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceea200/cladde.htm > > Peter > -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
I thought I might need to use stert_seq and end_seq too. Thanks for the advice. However, I am running into a little roadblock at the moment. I set things up copying some of the sample program ASMPIPI listed in the LE Pgmrs Guide, but without any fixed program name in the ceexptbl entry since the initialization macro cannot know what program(s) will be called: PPTBLCEEXPIT , PREINIT TABLE WITH INDEX CEEXPITY 0,0 DYNAMICALLY LOADED RTNE, CALL-BY-ADDR * CEEXPITS , END OF PREINIT TABLE Neither (init_sub) nor (init_sub_dp) will succeed with this ceexptbl, both of them fail with RC=8. Is there any way to set up a totally dynamic ceexptbl, with no actual entries for any LE-enabled HLL program, and still be able to initialize successfully? If not, does it matter if the only entry in the ceexptbl is a dummy HLL program that will NOT be invoked via that table, but only other programs called via (call_subr_addr) with the address returned by a LOAD macro? Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Thursday, March 16, 2017 3:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need help understanding use of CEEPIPI from non-LE assembler main programs You have an Assembler program, and once it has called and returned from one COBOL program, it goes on to call and return from other COBOL programs (or other invocations of the same program)? You'll want to look at start_seq and end_seq. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help understanding use of CEEPIPI from non-LE assembler main programs
You have an Assembler program, and once it has called and returned from one COBOL program, it goes on to call and return from other COBOL programs (or other invocations of the same program)? You'll want to look at start_seq and end_seq. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Need help understanding use of CEEPIPI from non-LE assembler main programs
Hi All, We are preparing for the transition from COBOL V4.2 to COBOL V5.2. Existing non-LE-enabled assembler main programs need to change from using IGZERRE initialization to using CEEPIPI enclave initialization to allow calling multiple COBOL subroutines, sometimes calling a subroutine more than once per batch step execution. We do know that the assembler main programs really ought to be converted to LE-enabled to make things better, but that is beyond available programmer resources and time at the moment. It may be scheduled later, but in the meantime we need a quicker solution. We already use a set of assembler macros to hide the initialization and loading and calling of COBOL programs from non-LE-enabled main programs, so I am modifying the macros to use CEEPIPI rules instead so that programs can just be re-translated to accomplish the change. Now to my questions: The (call_sub) function of CEEPIPI to call a subroutine states that "The next call to (call_sub) initializes a new enclave", which is obviously CPU expensive. The (call_sub_addr) function of CEEPIPI to call a subroutine does not have this statement. Does this mean I can use the following sequence of calls and only have one enclave created and reused for each called subroutine? CEEPIPI ( (init_sub), . . . ) LOAD EP=SUBPGM1 Save address for CEEPIPI LOAD EP=SUBPGM2 Save address for CEEPIPI CEEPIPI ( (call_sub_addr), (addr-for-SUBPGM1), . . . ) CEEPIPI ( (call_sub_addr), (addr-for-SUBPGM2), . . . ) Etc. CEEPIPI ( (term), . . . ) Or do I need to use the CEEPIPI initialization function (init_sub_dp) instead of (init_sub) to accomplish multiple (call_sub_addr)'s with only one enclave initialization? TIA for your help in understanding the rules here. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
