Juergen,
If you can compile JSVC on your system and make sure we have a start
script with the proper settings then I can make the installer plugin
build installers for z/OS.
Just svn check this out and build it:
http://svn.apache.org/repos/asf/jakarta/commons/proper/daemon/trunk/src/native/unix/
Then attach the executable to a JIRA issue as an attachment along with
any init script customizations you need. I can rigg this into the
installers plugin for you.
Also if you don't want a graphical installer what format does z/OS use?
Perhaps we can generate installers in that format.
Thanks,
Alex
Juergen Weber wrote:
On 2/12/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
At this point, a question would be : what can we do to guarantee that ADS
can be distributed as a package running on z/OS. The problem is that we
don't have IBM computers nor z/OS system available to do some tests.
I would suggest that you propose a patch for the scripts and
server.xml to
make them z/OS friendly, so that we can test it on Linux/Unix platforms.
Well, from a (pure) Java point of view z/OS is just a usual unix, the
only exception being that default IO encoding is EBCDIC. But if you
set the system properties I gave the VM runs in ascii and everything
is the same (almost as the XML problem shows).
But generally, if a Java program runs fine in an IBM JDK in Linux or
Windows, it should run on z/OS with Ascii IO, too.
IBM JDKs are at
http://www-128.ibm.com/developerworks/java/jdk/linux/download.html
for Windows you can download DB2 Express-C, it contains a 1.5 level JDK
As for the native starter, we shall see. Usually C code will port, too.
I am not a great friend of the graphical installer, I very much prefer
Tomcat's tar -xf installer.
A server should install without a gui. z/OS Java does support X, but
contrary to IBM's lore the CPU's are much slower than Pentiums an CPU
time is shared between lots fo users. E.g. an openldap configure and
build takes at least an hour...
So a resource-inintensive install would be very much preferable.
This patch should not break our current packages, so it will have to
check
the local system to set some properties. It might be necessary to
handle the
I am not sure if I understand this, could you give a pointer, where
this check happens?
server.xml encoding through a little bit of sed (we still have to
check the
reason why z/OS does not support UTF-8 on top of the server.xml).
Do you think this is something you can do? Otherwise, I guess you will
have
to handle your own post-installation modifications...
I can try.
Cheers,
Jürgen
