Hi Robert, IMS uses the CEEPIPI approach to make the JVM persistent, but thats actually only needed if multiple modules are serially executed and (speaking with COBOL) end with a GOBACK. The GOBACK of the first module called would terminate the LE enclave (and as such the JVM) so CEEPIPI is used to allow the next program to work the same way without tiering down the JVM. The COBOL (and C JNI) work like this, you start a program e.g. with JCL PGM=PROG1. Enterprise COBOL initializes the JVM (CreateJavaVM and AttachCurrentThread JNI calls under the covers if I remember correctly, in C and e.g. PL/I you do that by yourself and the environment for the JVM is pointed to by _CEE_ENVFILE) and with that JVM pointer you can do any number of JNI calls (e.g. call Java methods) and after each call the calling program is returned control. The JNIEnvPtr will be valid as long as the JVM or the LE enclave stay up.You can do the same thing in assembler, but you need an LE enclave with POSIX(ON) and XPLINK(ON) since the JVM on z/OS is written in C and requires those settings (in addition that up to Java 8 the 31bit version of Java needs to be used). But if the inital assembler uses CEEENTRY and CEETERM it will be quite easy to achieve, because it would create the LE enclave and remain until the initial assembler ends. From that first module you can call any non LE assembler as you like.The JVM can be ended by using JNI call DestroyJavaVM to make sure any unfinished work on the Java side is ended (as opposed to just end the first module and terminate the JVM together with the LE enclave and the address space). One question is, why would you need to make the JVM persistent with CEEPIPI in batch?You can do PROG1 call anything then return, PROG1 call Java then return as long and as many times as you want without the need of CEEPIPI and reusing the JVM - since its not terminated after return from Java. But to make it more complicated, since Java 11 for z/OS there is no 31bit JVM anymore and the JVM will be in a secondary 64bit LE enclave. There is a libjvm31.so shared library which can be used to make the JNI calls work, with the difference that most references require 64bit parameters. (Under the covers CEL4RO64 service is used)https://www.ibm.com/support/pages/enhancement-coboljni-interface
For now, I think the easiest way to do it, is in COBOL. Hope that helps,Denis. On Wednesday, July 12, 2023 at 02:40:08 PM GMT+2, Crawford Robert C (Contractor) <000004e08f385650-dmarc-requ...@listserv.ua.edu> wrote: Thanks, Allan. Back in the 90's I used CEEPIPI to create a persistent C enclave I could call from Assembler because building the environment is expensive. Unfortunately, CEEPIPI documentation is kind of scarce. What we do find doesn't give us very many clues for how to get to Java. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of allan winston Sent: Tuesday, July 11, 2023 5:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Invoke Java from Assembler Robert, This reminds me of a situation I ran into 25 years ago involving assembler and COBOL. Granted, COBOL and Java are different environments, but there may be enough similarity in the issues to be relevant. We had an assembler main program that called a COBOL subroutine repeatedly. It was chugging along just fine until LE maintenance showed a large spike in CPU time within LE library routines, as shown by Strobe. It seemed as though the LE environment was constantly being created and torn down. I did look into solutions, such as using CEEPIPI, but this program was a major CPU consumer in this shop and we needed a quick solution. The solution I proposed and was implemented was to create a new main program, written in COBOL, that called the former assembler main program. That way the new main program established the LE environment that persisted until the program terminated. So, ALC calling COBOL changed to COBOL calling ALC calling COBOL. In your case: Java calling COBOL changed to COBOL calling Java calling COBOL. I have never used Java, so this is somewhat a shot in the dark. I should have created an ETR on IBMLINK about the increased CPU overhead, but did not bother since we had a circumvention. Allan On Tue, Jul 11, 2023 at 5:58 PM Crawford Robert C (Contractor) < 000004e08f385650-dmarc-requ...@listserv.ua.edu> wrote: > We're interested in invoking Java from assembler in batch. > Specifically, we'd like to create a persistent Java environment we can > call repeatedly and terminate when we're through. > > Has anyone done this? Is the LE pre-initialization module CEEPIPI > worth exploring? > > Thanks. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > > ---------------------------------------------------------------------- > 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
