Re: Static CEEPCALL to COBOL 5/6
Will do. Thanks for you help! Frank On Tue, 17 Aug 2021 18:57:14 +, Mitch Mccluhan wrote: > Frank, >...being with IBM, I have some contacts that sometimes help me out. I passed >your question along to our COBOL compiler lab and they think you may have >encountered a shortcoming in COBOL 6.3. They recommended that you should call >IBM support and open a case. >I hope this helps. >Regards, >Mitch McCluhan > > >-Original Message- >From: Frank Swarbrick >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Mon, Aug 16, 2021 2:46 pm >Subject: Static CEEPCALL to COBOL 5/6 > >I have a very simple LE-enabled assembler program: > SYSSTATE ARCHLVL=2 >CALLER CEEENTRY MAIN=YES,RMODE=ANY > CEEPCALL COBTEST,MF=(E,) > CEETERM >PPA CEEPPA , > CEEDSA , > CEECAA , > END CALLER > >This works under the following conditions: >- COBTEST is a COBOL V6.3 DLL and is "DLL linked" with CALLER. >- COBTEST is a COBOL V4.2 non-DLL and is static linked with CALLER. > >However, if COBTEST is a COBOL V6.3 non-DLL and is static linked with CALLER, >it abends with an S0C1. >It appears that when a COBOL V6.3 program is static linked with an >LE-assembler main program it's wiping our or not properly setting CEECAACRENT, >the address of the writable static area. > >Specifically, the CEEPCALL macro expansion has the following statement: >L 15,500(,12) LOAD 15 WITH CEECAACRENT >When working properly, this loads R15 with a valid address. But in the not >working scenario it's loading address 0. > >Should this be working? Is this a bug? Am I doing something wrong? > >Thanks, >Frank > >-- >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: Static CEEPCALL to COBOL 5/6
Frank, ...being with IBM, I have some contacts that sometimes help me out. I passed your question along to our COBOL compiler lab and they think you may have encountered a shortcoming in COBOL 6.3. They recommended that you should call IBM support and open a case. I hope this helps. Regards, Mitch McCluhan -Original Message- From: Frank Swarbrick To: IBM-MAIN@LISTSERV.UA.EDU Sent: Mon, Aug 16, 2021 2:46 pm Subject: Static CEEPCALL to COBOL 5/6 I have a very simple LE-enabled assembler program: SYSSTATE ARCHLVL=2 CALLER CEEENTRY MAIN=YES,RMODE=ANY CEEPCALL COBTEST,MF=(E,) CEETERM PPA CEEPPA , CEEDSA , CEECAA , END CALLER This works under the following conditions: - COBTEST is a COBOL V6.3 DLL and is "DLL linked" with CALLER. - COBTEST is a COBOL V4.2 non-DLL and is static linked with CALLER. However, if COBTEST is a COBOL V6.3 non-DLL and is static linked with CALLER, it abends with an S0C1. It appears that when a COBOL V6.3 program is static linked with an LE-assembler main program it's wiping our or not properly setting CEECAACRENT, the address of the writable static area. Specifically, the CEEPCALL macro expansion has the following statement: L 15,500(,12) LOAD 15 WITH CEECAACRENT When working properly, this loads R15 with a valid address. But in the not working scenario it's loading address 0. Should this be working? Is this a bug? Am I doing something wrong? Thanks, Frank -- 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: Static CEEPCALL to COBOL 5/6
CEEPCALL COBTEST,MF=(E,) expands to: DS0H 01-CEEPCALL CEE0007F ALIAS C'COBTEST' 01-CEEPCALL EXTRN CEE0007F 01-CEEPCALL CEE0007F XATTR SCOPE(IMPORT),REFERENCE(INDIRECT),REFERENCE(CODE) 01-CEEPCALL CNOP 0,4 01-CEEPCALL J CEE0007J BRANCH AROUND QCON 01-CEEPCALL CEE0007Q DCQ(CEE0007F) OFFSET TO DESCRIPTOR 01-CEEPCALL CEE0007J DS0H 01-CEEPCALL L 15,500(,12)LOAD 15 WITH CEECAACRENT 01-CEEPCALL A 15,CEE0007Q ADD OFFSET TO FUNC DESC @P0C 01-CEEPCALL BASR 14,15 BRANCH TO ENTRY POINT 01-CEEPCALL For the invocations that work, the CEE0007Q variable (in this example) resolves (correctly) to 0, which is the offset of the "descriptor". If there were two CEEPCALL invocations (of two different programs) the CEE00xxQ variable resolves to 20, which is the offset of the descriptor for this routine. I specifically refer to the following from the binder step: --- CLASS C_WSA LENGTH = 40 ATTRIBUTES = MRG, DEFER , RMODE=ANY OFFSET =0 IN SEGMENT 002 ALIGN = DBLWORD --- CLASS OFFSET NAMETYPELENGTH SECTION 0 COBTEST DESCRIPTOR 20 20 DLLTEST DESCRIPTOR 20 It's interesting to note that when COBTEST is compiled with COBOL V6.3, there's an additional item in the C_WSA class: CLASS OFFSET NAMETYPELENGTH SECTION 0 COBTEST DESCRIPTOR 20 20 DLLTEST DESCRIPTOR 20 40 COBTEST#SPART84 COBTEST Not sure what that represents, but I imagine it might have something to do with the issue. As for how any of this works to actually invoke the desired module, I don't really know. The macro code generated for both static and DLL calls is identical and indeed the assembler has no idea which linkage will be used. So my guess is that the BASR 14,15 doesn't branch directly to the routine, but rather to some special code that does the DLL load, if required, and then branches to the routine from there. No DLL load for static linkage, of course. I can change the CEEPCALL to invoke a CSECT that simply does an abend (see below). ABENDER CSECT, ABENDER RMODEANY ABEND2001,DUMP END ABENDER Then I see the following. From the LE dump: Information for enclave CALLER Information for thread 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP HLE77B0 Call 2 CEEPGTFN+0855FCCC CEEPLPKA Exception 3 CALLER +008C CALLER CALLER Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 00014170 076C0EC8 076C0EC8 +4A4C 20170307 CEL 2 000140B0 077A1080 077A11F0 +0855FB5C 20170307 LIBRARY 3 00014030 0FD0 0FD0 +008C 20210816 ASM IBM Fault Analyzer shows this: Event
Re: Static CEEPCALL to COBOL 5/6
I cannot comment on the specific situations, but - register 12 normally contains the address of the CEECAA control block, when running under LE control - at position 500 of the CEECAA, the address of the current active WSA (writeable static area) is stored; the WSA is related to the module to be called (or just having been called), and it contains all its static (but modifyable) variables. The WSA is built if the module is compiled with the RENT option; if not, there is no WSA. It would be interesting to look at the expansion of the complete CEEPCALL macro, because: the CEEPCALL must do some action first to load COBTEST, to setup and initialize the WSA (which is specific to COBTEST), and to store its address into 500(R12) ... which seems not to work in some of the scenarios. (This is why we did CEEFETCH in the situation mentioned some mails before, when we had to call a PL/1 module which was compiled using the RENT compiler option). HTH, kind regards Bernd Am 16.08.2021 um 20:46 schrieb Frank Swarbrick: I have a very simple LE-enabled assembler program: SYSSTATE ARCHLVL=2 CALLER CEEENTRY MAIN=YES,RMODE=ANY CEEPCALL COBTEST,MF=(E,) CEETERM PPA CEEPPA , CEEDSA , CEECAA , END CALLER This works under the following conditions: - COBTEST is a COBOL V6.3 DLL and is "DLL linked" with CALLER. - COBTEST is a COBOL V4.2 non-DLL and is static linked with CALLER. However, if COBTEST is a COBOL V6.3 non-DLL and is static linked with CALLER, it abends with an S0C1. It appears that when a COBOL V6.3 program is static linked with an LE-assembler main program it's wiping our or not properly setting CEECAACRENT, the address of the writable static area. Specifically, the CEEPCALL macro expansion has the following statement: L 15,500(,12)LOAD 15 WITH CEECAACRENT When working properly, this loads R15 with a valid address. But in the not working scenario it's loading address 0. Should this be working? Is this a bug? Am I doing something wrong? Thanks, Frank -- 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
Static CEEPCALL to COBOL 5/6
I have a very simple LE-enabled assembler program: SYSSTATE ARCHLVL=2 CALLER CEEENTRY MAIN=YES,RMODE=ANY CEEPCALL COBTEST,MF=(E,) CEETERM PPA CEEPPA , CEEDSA , CEECAA , END CALLER This works under the following conditions: - COBTEST is a COBOL V6.3 DLL and is "DLL linked" with CALLER. - COBTEST is a COBOL V4.2 non-DLL and is static linked with CALLER. However, if COBTEST is a COBOL V6.3 non-DLL and is static linked with CALLER, it abends with an S0C1. It appears that when a COBOL V6.3 program is static linked with an LE-assembler main program it's wiping our or not properly setting CEECAACRENT, the address of the writable static area. Specifically, the CEEPCALL macro expansion has the following statement: L 15,500(,12)LOAD 15 WITH CEECAACRENT When working properly, this loads R15 with a valid address. But in the not working scenario it's loading address 0. Should this be working? Is this a bug? Am I doing something wrong? Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
