compiling Java question - z/OS jar(s) on non-z/OS?
McKown, John
Any ideas about where I can find out what is permitted? Hum, will this even work?
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
john....@healthmarkets.com * 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 list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Paul Gilmartin
>I don't know if this is allowed. I tried to find something on the Web about it in the IBM site, but failed. I have a number of JVMs on z/OS (1.4.0, 1.4.2, 1.5.0_31, 1.5.0_64, 1.6.0_31, and 1.6.0_64). What I'd like to do is write and compile my Java on Linux/Intel. But to do so using things such as JRIO, JZOS, and so on, I need the z/OS jar files readable on my Linux system. I would really like to have them actually reside on my PC. But I guess that I could NFS mount the z/OS subdirectories on the PC instead.
>
>Any ideas about where I can find out what is permitted? Hum, will this even work?
>
IIRC, I did this once, long ago, with HelloWorld. But going the other way;
compiling on z/OS and running on Solaris, because of relative levels of
JVM, etc. And I may have needed to downgrate the target in a compiler
option. And I needed to mount the directory twice, once with xlat(Y) for
the .java, and once with xlat(N) for the .class. Like Steve, I lost
interest and never did much with it. And I no longer remember how I
set up the various paths.
-- gil
Kirk Wolf
You just need to copy the {SDK_HOME}/lib/ext/ibmjzos.jar to your
workstation and put it in the CLASSPATH.
If you download the alphaWorks version of JZOS, it includes this jar
(which contains the field mapping classes) and also contains a jar for
generating record classes from ADATA files. The generator will run on
z/OS or on your workstation if you download the ADATA files.
Have you looked at the JZOS Cookbook? It has a sample Eclipse
project and a guide to help you get started.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Jan MOEYERSONS
>What I'd like to do is write and compile my Java on Linux/Intel. But to do so
> using things such as JRIO, JZOS, and so on, I need the z/OS jar files readable
> on my Linux system. I would really like to have them actually reside on my
PC.
We routinely compile Java on Windows and run it on zOS, AIX and Solaris. We
also routinely compile Java on zOS and run it on zOS, and Solaris.
All you need is to make sure you have the required jars on your classpath.
And you want to be consistent in your JDK levels. If you compile on 1.4.2,
you want to run on 1.4.2 (or higher, of course).
Cheers,
Jantje.
Paul Gilmartin
>
>Well... This is certainly a can of worms.
>
>If indeed the method of copying doesn't matter, then there is surely a
>problem with the many licence agreements that have nothing to say
>about how to get software from distribution medium to licensed
>execution platform. For example, much z/OS software comes on CD, but
>few z/OS platforms have a CD reader that is usable for this purpose,
>so in almost every case the software is copied from CD to a desktop
>machine (Windows, Linux), and then to z/OS. If the licence is silent
>
Gasp! Sigh. Ummm. You might mount the CD on the desktop
machine, then copy directly to the licensed target system.
Why bother making an intermediate copy on the desktop?
To be very picky, if I browse a member of SYS1.MACLIB with
a terminal emulator on my desktop, a copy of (part of) that
file exists in the screen buffer on the desktop, and perhaps
in swap files, etc.
IANAL. But I wish I had the income of one.
Sigh,
gil
Timothy Sipples
>Well... This is certainly a can of worms.
No, I don't think so.
>I think you are conflating running software on a machine it isn't
>licensed for, with using things like macros or include files that are
>incidental to executable software to compile on a machine not licensed
>to run the executable software for ultimate execution on the licensed
>machine.
If you mean that I'm conflating "software" with "software," yes, I guess I
am. :-) Compilers, macros, include files, libraries, programmers' tools,
etc., etc. are often licensed software, too -- and have been for decades.
You can compile (more correctly in this example: generate bytecode for)
Java directly on z/OS. That's a standard feature of the (licensed) Java SDK
for z/OS. There's no barrier whatsoever to compiling Java on and for z/OS.
(Including at sub-peak intervals, in low-ish service classes, on your
licensed machine.)
There's absolutely no universal right to compile anywhere/everywhere, which
is what you seem to be suggesting.
John is asking specifically about compiling Java elsewhere to then run on
z/OS. You can do that. But the IBM Java SDK for z/OS is licensed code. You
can't use *that* SDK (in whole or in part) on your unlicensed machine, but
you can use *another* licensed JDK to do the compile if you wish. Among
many examples, you can download Sun's JDK for Microsoft Windows or for
Linux and use it to perform the compile according to its license. Java
bytecode is portable (upward or equal JVM level, but not necessarily
downward).
The JZOS and JRIO classes and methods are unique to the Java SDK for z/OS.
They are an intrinsic part of that particular licensed software product.
Again, you can compile your JZOS/JRIO applications on your licensed z/OS
machine at whatever time and in whatever service class you wish. Or you can
obtain the relevant jar file(s) from IBM through a separate, authorized,
licensed avenue, as Kirk (quite rightly) suggested. But you cannot NFS
mount, BitTorrent, FTP, card punch/read, print/optical scan, or otherwise
copy software licensed to machine A onto unlicensed machine B.
It really isn't complicated: don't copy licensed software to run on
unlicensed machines.
As it happens, this is *exactly* how one of my customers ran into trouble:
they copied a library from a licensed software product onto a machine that
was not licensed for that software product, and they used the library.
(Sigh. :-( ) Many libraries/class collections, including Java jar files,
can be (often are) licensed!
>I really don't know that the status of the latter is
>well defined in the absence of a reference in the licence.
If the license for licensed software doesn't say you can do it, you almost
certainly can't do it. At the very least, you shouldn't assume you can. If
there's any ambiguity, ask the vendor first.
>If indeed the method of copying doesn't matter, then there is
>surely a problem with the many licence agreements that have nothing
>to say about how to get software from distribution medium to licensed
>execution platform. For example, much z/OS software comes on CD, but
>few z/OS platforms have a CD reader that is usable for this purpose,
>so in almost every case the software is copied from CD to a desktop
>machine (Windows, Linux), and then to z/OS. If the licence is silent
>on this point, and since it is well established that even such
>transient action is copying under the copyright statues, then there
>should be a problem. But there isn't, because everyone understands
>that this is the way you install such a package, and that it isn't
>going to be executed on the intermediate platform. Neither IBM nor CA
>nor anyone else sues their customers because they stored a z/OS
>software image on Windows while getting it to the licensed machine.
There's no ambiguity on this point in the license agreements that I've
read. You're now talking about a very different situation. Yes, most
license agreements talk about execution (and/or making productive use of,
etc.), and most license agreements tolerate the minimum amount of temporary
copying strictly to facilitate execution on the licensed machine(s).
Copyright law also understands that, e.g. loading programs from disk
storage into electronic memory for execution.
>One could well argue that similar reasoning would apply to the case of
>using include files and the like on one platform as input to a
>compiler/assembler targeting a platform licensed for execution.
You could argue that, and it wouldn't be a correct argument. :-)
Now, it may or may not be in the interest of particular vendor(s) to have
somewhat different license terms for include files, libraries, headers,
etc., etc. -- but that's up to the vendor, not up to you or me. So ask the
vendor, first.
I've just read the Java SDK for z/OS license agreement, which also
incorporates the IBM International Program License Agreement (IPLA). It
doesn't say anything about copying jar files from z/OS to PCs for compiling
as being an authorized use. There's a lot of language to the contrary.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy...@us.ibm.com
Timothy Sipples
apparently for some duration, as your queue fills) not ready? It sounds
like that could be the core problem worth correcting.
McKown, John
If I could, I would totally abandon z/OS for Linux. Be it on a z or other processor, such as Intel. But I'm too old for anybody to think that I might understand "new technologies". And, anyway, a younger, healther person is more cost effective. Hard to argue with that.
--
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
john....@healthmarkets.com * 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
----------------------------------------------------------------------
Timothy Sipples
run on z/OS -- including Java which uses z/OS-only methods. The jar files
are available, as Kirk noted, at no additional charge. You can compile on
or off your mainframe -- and, at least on your mainframe, almost certainly
at zero real cost.
If someone wants to pretend it's hard, I suppose that's their right. :-)
Whether it's z/OS, or Microsoft Office, or Oracle Database, or Software
AG's Adabas, or any other piece of licensed software, just follow the
rules, that's all. If you don't know what the rules are, ask. Just don't
assume.
That is all. Simple.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
E-Mail: timothy...@us.ibm.com
Roger Bowler
<timothy...@US.IBM.COM> wrote:
>IBM is making it *very* easy to create Java to run on z/OS -- including
>Java which uses z/OS-only methods. The jar files are available, as Kirk
>noted, at no additional charge. You can compile on or off your mainframe
Hold on, that's not what you said before. You said (and I quote):
>But the IBM Java SDK for z/OS is licensed code. You can't use *that* SDK
>(in whole or in part) on your unlicensed machine, but you can use *another*
>licensed JDK to do the compile if you wish. Among many examples, you can
>download Sun's JDK for Microsoft Windows or for Linux and use it to perform
>the compile according to its license. Java bytecode is portable (upward or
>equal JVM level, but not necessarily downward).
>The JZOS and JRIO classes and methods are unique to the Java SDK for
>z/OS.
So how do you compile off the mainframe if you can't use the SDK that
contains the classes you need?
>That is all. Simple.
I'm so glad you told me.
Roger Bowler
Hercules "the people's mainframe"