Sorry, I misunderstood the original question. I thought you were asking about calling existing MVS load modules from Java. It looks like you want to be able to package a Java application as an MVS load module (?).
A batch Java "application" is most commonly a *set* of jar files containing Java classes (Java byte code). These files are not directly executable z instruction load modules - they have to be interpreted or dynamically compiled (or compiled ahead-of-time and cached in a class cache) by the JVM. A Jar is really just a zip file that has a couple of optional metadata files that add additional information. It is certainly technically possible to store JAR files in a PDS by writing your own Java ClassLoader. One approach might be to have a member for each JAR. You might even use the "executable" JAR concept to store the MainClass name in the Jar manifest, so that you could "execute" that member with your own launcher or main class. I just don't see much benefit to do this however, other than avoiding the zFS filesystem. Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Aug 3, 2009 at 3:31 PM, Ron Wells <[email protected]> wrote: > Kirk > What I recv'd back from Pgm'r.. > >>> > > yep, the 8 char limit would be a huge limitation to building a class > structure, but then again, we've been working with 4 char program names on > SCORE for who knows how long... i'm sure we would come up with a nice > convention for naming. > > my desire is to execute everything solely within the TSO environment. > > so rather than writing my code and putting it in a jar file on HFS, and > then in my batch job doing something like this: > //XA344JVA JOB (6000),'AARON DUNLAP',CLASS=B,MSGCLASS=S, > // MSGLEVEL=(1,1),NOTIFY=&SYSUID > //********************************************************************* > //SA20 EXEC PROC=JZOS, > // JAVACLS='jabs.replication.upload.TASUploadMF', > // ARGS='file:/u/eeepc/apps/config/mf/upload.properties' > //STDENV DD * > ... > > I want to do something like this: > > //XA344JVA JOB (6000),'AARON DUNLAP',CLASS=B,MSGCLASS=S, > // MSGLEVEL=(1,1),NOTIFY=&SYSUID > //********************************************************************* > //SA20 EXEC PROC=JZOS, > // JAVACLS='XA344.PDS.JAVA(TESTCODE)', > // ARGS='A.P1.CM.ZZ.BRCH.PARMLIB(MYPARM)' > //STDENV DD * > ... > > within the context of the class structure of java, this might not make > much sense though... > > > > > > > > > From: > Kirk Wolf <[email protected]> > To: > [email protected] > Date: > 08/03/2009 02:54 PM > Subject: > Re: Java question > Sent by: > IBM Mainframe Discussion List <[email protected]> > > > > FWIW, Java already has a mechanism for launching a Unix executable > (binary, > shell script, REXX script) as a child process, where stdin/stdout/stderr > can > be piped into the child process. It is not difficult to create a REXX > shell script in the HFS filesystem that loads and executes MVS load > modules. > > Calling MVS load modules directly from Java (in the same process) is > another > matter, and that is what I thought you were asking about earlier. > > Kirk Wolf > Dovetailed Technologies > > On Mon, Aug 3, 2009 at 2:46 PM, Ron Wells <[email protected]> wrote: > > > reason asking is Java pgm'r was curious as why Java did not have > something > > on the z/OS platform without the HFS/ZFS restriction(need).. > > > > > > > > From: > > "McKown, John" <[email protected]> > > To: > > [email protected] > > Date: > > 08/03/2009 02:42 PM > > Subject: > > Re: Java question > > Sent by: > > IBM Mainframe Discussion List <[email protected]> > > > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:[email protected]] On Behalf Of Ron Wells > > > Sent: Monday, August 03, 2009 2:26 PM > > > To: [email protected] > > > Subject: Java question > > > > > > Is there anything on horizon for Java pgm's written and exec'd MVS > > > Loadlib's? ... > > > > Out of curiousity, why? I do understand that many don't seem to like > UNIX > > stuff on z/OS. And, it might actually be possible if there were a way to > > "integrate" the JZOS run-time into the load module, along with a > > specialized class loader. The heart of loading a Java program is the > class > > loader. I can imagine a class loader which could load classes from a > PDS. > > One of the main problems would be the 8 character limit on member names > in > > a PDS. > > > > -- > > John McKown > > Systems Engineer IV > > IT > > > > Administrative Services Group > > > > HealthMarkets(r) > > > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > > (817) 255-3225 phone * (817)-961-6183 cell > > [email protected] * www.HealthMarkets.com > > > > Confidentiality Notice: This e-mail message may contain confidential or > > proprietary information. If you are not the intended recipient, please > > contact the sender by reply e-mail and destroy all copies of the > original > > message. HealthMarkets(r) is the brand name for products underwritten > and > > issued by the insurance subsidiaries of HealthMarkets, Inc. -The > > Chesapeake Life Insurance Company(r), Mid-West National Life Insurance > > Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > > Email Disclaimer > > This E-mail contains confidential information belonging to the > sender, > > which may be legally privileged information. This information is > intended > > only for the use of the individual or entity addressed above. If you > are > > not the intended recipient, or an employee or agent responsible > for > > delivering it to the intended recipient, you are hereby notified that > any > > disclosure, copying, distribution, or the taking of any action in > reliance > > on the contents of the E-mail or attached files is strictly prohibited. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > Email Disclaimer > This E-mail contains confidential information belonging to the sender, > which may be legally privileged information. This information is intended > only for the use of the individual or entity addressed above. If you are > not the intended recipient, or an employee or agent responsible for > delivering it to the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or the taking of any action in reliance > on the contents of the E-mail or attached files is strictly prohibited. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
