Farley, Peter x23353
2017-06-16 14:39:10 UTC
For the archive, reporting back on gotcha's as promised.
While testing the CEEPIPI interface I ran into this problem:
1. Initialize CEEPIPI environment (init_subr_dp)
2. Attempt to add non-LE COBOL subroutine to CEEPIPI table (add_subr)
3. CEEPIPI reports back RC=20, not an LE-enabled module; IBM says it is not added to the CEEPIPI table in this case
4. Issue LOAD for non-LE COBOL module, save address
5. Terminate CEEPIPI environment (term_env)
6. LOAD and call IGZERRE to initialize non-LE COBOL environment
7. BALR 14,15 to non-LE COBOL subroutine gets S0C1 because the load module has been deleted from storage
IBM has accepted APAR # PI81896 for this problem. It seems that the (term_env) call to CEEPIPI was deleting added modules even when they were not supposed to have been retained in the CEEPIPI table (not positive of the exact cause, but that was the result).
++APAR was made available to us and we tested it successfully on a sandbox system, but it has not yet been released as a regular PTF so we are going to wait for the GA PTF before applying it to any production system.
Workaround was to reverse steps 4 and 5 above so that the module remains loaded for subsequent calls.
I also did some limited testing with a small date-processing COBOL subroutine compiled with LE COBOL V5.2, LE COBOL V4.2, VS COBOL II linked with SCEELKED IGZEBST and VS COBOL II linked with VS COBOL II IGZEBST. I experimented with NOT terminating the CEEPIPI environment (initialized with (init_subr_dp) function) and also calling IGZERRE to initialize the non-LE COBOL environment, and multiple repeated calls to all four modules worked without any abends. COBOL Level 2 still says this is not a supported environment though, and that I probably did not exercise enough COBOL functionality to encounter any problems, so we won't be using that technique going forward.
We are still grappling with level 2 about whether VS COBOL II subroutines linked with SCEELKED IGZEBST should be accepted by CEEPIPI as LE-enabled subroutines. I will report back after we resolve that issue.
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Thursday, June 08, 2017 12:39 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
Using the (init _subr_dp) call to CEEPIPI instead of the (init_subr) call that I originally used seems to have done the trick. In my assembler main test program I can now call an eCOBOL V4.1 subprogram using CEEPIPI and a VS COBOL II subprogram using a simple CALL after a one-time call to IGZERRE. Multiple calls to both types of COBOL subprograms do not fail.
I still have to test with an eCOBOL V5.2 subprogram in the mix, but I am hopeful at this point.
Thanks again for that suggestion. I will report any gotcha's that we encounter as we move forward with this project for real-world programs.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Wednesday, June 07, 2017 9:12 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
Thanks for the idea of trying init_main_dp and IGZERRE together, I will try that and see if it flies.
These are non-LE-enabled assembler main programs (and some E15/E35 exits) calling VS COBOL II subroutines. Some of those COBOL subroutines can and will be recompiled to eCOBOL 4.2 first and later eCOBOL 5.2, but some cannot be recompiled so easily due to their widespread use elsewhere in the shop and the resource constraints on getting all using applications to test in one or even multiple QA cycles.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Tuesday, June 06, 2017 7:25 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
I'm speculating here - never tried it, but if you are desperate... If you use CEEPIPI init_main_dp for the new COBOL environment, will it complain that there is already an active LE environment? What if you call CEEPIPI init_main_dp first, and then IGZERRE? In other words how does LE know (and why does it care in the PIPI case) that you have another environment active?
Tony H.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
While testing the CEEPIPI interface I ran into this problem:
1. Initialize CEEPIPI environment (init_subr_dp)
2. Attempt to add non-LE COBOL subroutine to CEEPIPI table (add_subr)
3. CEEPIPI reports back RC=20, not an LE-enabled module; IBM says it is not added to the CEEPIPI table in this case
4. Issue LOAD for non-LE COBOL module, save address
5. Terminate CEEPIPI environment (term_env)
6. LOAD and call IGZERRE to initialize non-LE COBOL environment
7. BALR 14,15 to non-LE COBOL subroutine gets S0C1 because the load module has been deleted from storage
IBM has accepted APAR # PI81896 for this problem. It seems that the (term_env) call to CEEPIPI was deleting added modules even when they were not supposed to have been retained in the CEEPIPI table (not positive of the exact cause, but that was the result).
++APAR was made available to us and we tested it successfully on a sandbox system, but it has not yet been released as a regular PTF so we are going to wait for the GA PTF before applying it to any production system.
Workaround was to reverse steps 4 and 5 above so that the module remains loaded for subsequent calls.
I also did some limited testing with a small date-processing COBOL subroutine compiled with LE COBOL V5.2, LE COBOL V4.2, VS COBOL II linked with SCEELKED IGZEBST and VS COBOL II linked with VS COBOL II IGZEBST. I experimented with NOT terminating the CEEPIPI environment (initialized with (init_subr_dp) function) and also calling IGZERRE to initialize the non-LE COBOL environment, and multiple repeated calls to all four modules worked without any abends. COBOL Level 2 still says this is not a supported environment though, and that I probably did not exercise enough COBOL functionality to encounter any problems, so we won't be using that technique going forward.
We are still grappling with level 2 about whether VS COBOL II subroutines linked with SCEELKED IGZEBST should be accepted by CEEPIPI as LE-enabled subroutines. I will report back after we resolve that issue.
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Thursday, June 08, 2017 12:39 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
Using the (init _subr_dp) call to CEEPIPI instead of the (init_subr) call that I originally used seems to have done the trick. In my assembler main test program I can now call an eCOBOL V4.1 subprogram using CEEPIPI and a VS COBOL II subprogram using a simple CALL after a one-time call to IGZERRE. Multiple calls to both types of COBOL subprograms do not fail.
I still have to test with an eCOBOL V5.2 subprogram in the mix, but I am hopeful at this point.
Thanks again for that suggestion. I will report any gotcha's that we encounter as we move forward with this project for real-world programs.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Wednesday, June 07, 2017 9:12 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
Thanks for the idea of trying init_main_dp and IGZERRE together, I will try that and see if it flies.
These are non-LE-enabled assembler main programs (and some E15/E35 exits) calling VS COBOL II subroutines. Some of those COBOL subroutines can and will be recompiled to eCOBOL 4.2 first and later eCOBOL 5.2, but some cannot be recompiled so easily due to their widespread use elsewhere in the shop and the resource constraints on getting all using applications to test in one or even multiple QA cycles.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Tuesday, June 06, 2017 7:25 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler?
I can call the VS COBOL II RES program multiple times if I first LOAD
and call IGZERRE once (the LE version from CEE.SCEERUN), but using
IGZERRE and CEEPIPI together is not allowed either according to the migration guide (cannot establish 2 different COBOL environments at the same time in the same LE enclave, which makes sense to me).
I'm unclear - are these old and new programs COBOL *main* programs or subroutines? They sound like main programs, but...and call IGZERRE once (the LE version from CEE.SCEERUN), but using
IGZERRE and CEEPIPI together is not allowed either according to the migration guide (cannot establish 2 different COBOL environments at the same time in the same LE enclave, which makes sense to me).
I'm speculating here - never tried it, but if you are desperate... If you use CEEPIPI init_main_dp for the new COBOL environment, will it complain that there is already an active LE environment? What if you call CEEPIPI init_main_dp first, and then IGZERRE? In other words how does LE know (and why does it care in the PIPI case) that you have another environment active?
Tony H.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN