John McKown writes: >As an offshoot from this, if it were my choice, then I'd likely keep my >Java development stuff on a UNIX file server. This UNIX file server >would NFS export the appropriate subdirectories. The z/OS system would >NFS import them. All Java development would occur on PC desktops running >Linux or Windows <shudder>, which can access those NFS exported >directories. I'd use either Netbeans or Eclipse on the desktop for Java >development (I use Netbeans, myself). This would allow the programmers >easy access to edit, compile, and test Java. Promotion would be from the >NFS mounted subdirectories onto "production" UNIX files residing on the >z/OS system. Again, this would be my first take on how to do it. >Unfortunately, the interest in Java on z/OS here is approaching zero >from beneath.
I'm afraid I would disagree with John here, which is rare. The "official" way, if you want an Eclipse-based Java programming environment, is WebSphere Developer for System z. That's quite an elegant way to do it, and you certainly don't need a separate UNIX box. I should also point out that it is possible you might have one or more WDz licenses and don't know it yet. At least some license rights to WDz come with CICS 3.1 or WebSphere Host Integration Solution (HATS), so check your announcement letters for those products if you have them. You might be pleasantly surprised. But failing all that, I don't see why you couldn't operate in UNIX System Services unless and until you wanted to invoke Java programs with JCL. It has UNIX shell, UNIX file structures (zFS or the older HFS), access to the JDK, etc. and you can get a terminal connection to it, transfer files, etc. It is the UNIX(TM) box, and you already have it, so why not use it if you think you need one? Both of the above methods are much more likely to preserve regulatory compliance around code development and promotion to production. It's worth noting that there are a couple limitations to OS/390 for Java, if you're looking for yet more reasons to move to z/OS. One is that newer Java releases are not likely to run on OS/390, so if a Java programmer is looking for the newer APIs then that might be an impediment. Another is that none of the 64-bit Java releases will run on OS/390, and I see how 64-bit addressing could be useful in certain Java batch programming for getting a very large chunk of memory that never garbage collects during the entire batch run. (Garbage collection requires CPU.) Yet another is that OS/390 doesn't support zAAP engines, and the zAAP technology has a radical, beneficial impact on the economics of running Java on your mainframe. If you have any non-trivial Java workload then run, don't walk, and get one or more zAAPs. Sounds like an interesting effort, so I hope it goes well. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- 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
