Thanks for chiming in Tom. Using a COBOL "stub" as a top-level main program would certainly be simpler from a structural standpoint, but because we are an old and quite large shop there are many dozens (in some cases hundreds) of JCL's that would have to be changed to invoke the stub routine if we took that approach. There are also assembler E15/E35 exits which invoke COBOL subroutines to be considered for the need to modify the SORT MODS control cards to use the new stub name. The change control and regression testing issues become the main problem, not the technical solution.
Changing the assembler main program or assembler E15/E35 exit sources to be a COBOL stub instead and having the stub call a new program name that is the original assembler main program or exit program would be another approach to that issue which would avoid having to change JCL's or MODS control cards for SORT. The main issue, as you correctly point out, is whether the VS COBOL II subprogram modules can be recompiled with eCOBOL of some version. In some cases (where the VS COBOL II module has limited usage across the shop) that is certainly the cleanest approach. However, when the VS COBOL II subroutine is also invoked widely by other COBOL applications as well as the targeted assembler main programs, it is very difficult to implement a compiler change to that subprogram with thorough regression testing by so many different applications throughout the shop. It becomes a programmer resource constraint and management priority issue rather than a technical issue. Projects to satisfy business, client and regulatory needs almost always trump technical issue changes like this one. There are other technical solutions, such as creating a new source module with the VS COBOL II source code and compiling that new subprogram with eCOBOL and changing the targeted assembler programs to use the new subprogram name rather than the VS COBOL II subprogram name. Then other COBOL applications still using the old VS COBOL II subprogram can be changed in an extended or phased timeline compatible with programmer resource constraints and management priority considerations. Tony H.'s suggestion to try using the (init_subr_dp) call to CEEPIPI instead of the (init_subr) call has turned out to work flawlessly in my limited testing so far. It remains to be seen if it causes any issues in a real-program conversion. I will post any gotcha's we find as we move forward. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ross Sent: Tuesday, June 06, 2017 7:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to call VS COBOL II RES program from COBOL V5.2-enabled assembler? >EXEC PGM=ASM1 (LOAD and CALL)--> VSCOB2RES >Also:;ASM1 (LOAD and CALL via CEEPIPI)--> eCOBOL52 >Two different CAL's in one top-level assembler program to COBOL programs >compiled with different COBOL compilers. Either or both COBOL programs may >be called multiple times in one execution of ASM1. >My question was prompted by the eCOBOL V5.2 migration statement that COBOL >V5.2 programs can call and be called by VS COBOL II RES programs. I cannot They can! Not all kinds of CALLs (example: DLL CALLs) but most CALLs. You are not talking about COBOL calling COBOL, hoever. >use CEEPIPI to CALL the VS COBOL II RES program because CEEPIPI returns RC=20 >when you try to add it to the CEEPIPI table. Yes, only LE-conforming programs can be used with CEEPIPI. VS COBOL II programs are LE-enabled (can run with LE) but are not LE-conformaing (must run with LE). >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). If you really cannot recompile wht VS COBOL II programs with newer compilers and save MSUs/MIPS/CPU, then you have a problem. The easiest solution, from what limited info I have here, is to use a different method toe keep LE active between CALLs to COBOL. Remove the use of IGZERRE and add a COBOL stub in front of your ASM program! Then use the COOBL stub in the JCL: EXEC PGM=COBSTUB (Which then CALLs ASM1, which then LOADs and CALLs any COBOL) Since COBSTUB is always active, LE is always up, no performance hit for repeatedly LOADing and BASR/BALRing to COBOL > If eCOBOL V5.2 can call and be called by VS COBOL II RES programs, how does > it do that, and how can I do the same thing? Use simple CALLs, not IGZERRE or CEEPIPI. Cheers, TomR >> COBOL is the Language of the Future! << -- 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
