Re: Jenkins vs. EBCDIC
Hi,
I think I found a workaround to this issue, which also relates to
JENKINS-3629 https://issues.jenkins-ci.org/browse/JENKINS-3629. The
workaround is based on z/OS UNIX function called Enhanced ASCII support.
First, you need to have the slave successfully connected and online on z/OS
UNIX using the above mentioned java options -Dfile.enconding=ISO8859-1 and
-text.
Then, I noticed that when you use the Execute Shell build step, Jenkins
creates a shell script in my /tmp and tries to execute it using /bin/sh
-xe... but this shell script is in ASCII so the text is garbled and the
script doesn't execute properly.
What I did was to reroute Jenkins' /tmp directory to my own specified
location using java option -Djava.io.tmpdir=/var/jenkins/tmp in the slave
configuration.
Then I allocated and mounted a new ZFS data set at /var/jenkins/tmp but
defined it to automatically tag all files in the file system as ASCII. An
example of a mount command with automatic tagging is:
MOUNT FILESYSTEM('JENKINS.TMP.ZFS')
MOUNTPOINT('/var/jenkins/tmp')
TYPE(ZFS) MODE(RDWR) TAG(TEXT,819)
Finally, prior to the Execute Shell build step, I use the Inject
environment variables build step to inject _BPXK_AUTOCVT=ON before the
shell script is executed. This environment variable tells z/OS to
automatically convert the ASCII-tagged files from /var/jenkins/tmp to
EBCDIC.
The shell script then executes successfully and output is displayed in the
console log.
Gil.
On Friday, May 2, 2014 10:06:34 PM UTC+3, wwwild...@gmail.com wrote:
Follow-up:
I've gotten Jenkins working fine on z/OS, pushing builds from Windows,
running the tests on z/OS, and publishing the results to tomcat running on
z/OS.
There were three key things for me to get working/understand that may be
helpful to others. Some or all of these may have already been mentioned by
others here or elsewhere:
1. ssh on z/OS - the key here for me was these changes to the sshd_config
config file in /etc/sshd:
StrictModes no
But, also, I had to do a number of things around setting folder and file
ownership and permissions (see the z/OS redbook on ssh, very helpful) and
work to synch up ssh on my cygwin/Windows with ssh on z/OS (I assume all of
this is standard ssh) - this was all to get password-less login to work.
2. When I setup z/OS slave(s) in Jenkins, using ssh to invoke the slave
jar, the script I have it invoke to run the jar has this command in it:
java -Dfile.encoding=ISO8859_1 -jar /usr/local/jenkins/slave.jar -text
This seemed to resolve any ASCII/EBCDIC issues I was seeing.
3. To run the Jenkins jobs I had to explicitly set the jobs to run on
Windows, using:
Restrict where this project can be run
setting the Label Expression to master.
Then to execute the job on z/OS I used build Execute Windows batch
command with an ssh command to invoke the desired script on z/OS; e.g.:
ssh USER@HOST su -s RACF_SURROGATE_USER -c SCRIPT_ON_ZOS_TO_RUN
And voila, that's it!
There are a lot of details underneath this and I had certain machinations
I had to go through for local requirements (e.g. RACF surrogate to allow me
to rebuild a Websphere profile file system).
www
On Monday, December 30, 2013 8:41:40 AM UTC-8, wwwild...@gmail.com wrote:
I see a similar issue; I can't get as far as getting the commands from
Jenkins to run on z/OS. That is I see errors like this:
[zOS unit tests] $ /bin/sh -xe /tmp/hudson4437459291454251752.sh
+ Ž ÍËÊ %?Ä/% ÂÑ
+ 1 ¢Á 1 ,Ñ 1 Ë^Í 1 ÑÈÈÁËÈË ËÇ
Ž ÍËÊ %?Ä/% ÂÑ: /tmp/hudson4437459291454251752.sh 1: FSUM7351 not found
The slave looks to be running fine on z/OS: java
-Dfile.encoding=ISO8859_1 -jar /usr/local/jenkins/slave.jar -text
and I can get System Information fine for the node.
I've gone through this thread, but I don't see any correspondence to the
classes in remoting-2.25-SNAPSHOT.jar and my 1.535 version of Jenkins.
So, obviously I have some kind of EBCDIC/ASCII mismatch between my
Windows Master and z/OS.
As far as I know z/OS UNIX shell requires script files to be in EBCDIC,
otherwise it's reasonably easy to deal with ASCII and EBCDIC from their
(e.g. via Java), but EBCDIC has to be a starting point.
So, if anyone knows what I'm missing please let me know.
www
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/83b5579c-f874-47c9-8264-a43133e571a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Jenkins vs. EBCDIC
Follow-up: I've gotten Jenkins working fine on z/OS, pushing builds from Windows, running the tests on z/OS, and publishing the results to tomcat running on z/OS. There were three key things for me to get working/understand that may be helpful to others. Some or all of these may have already been mentioned by others here or elsewhere: 1. ssh on z/OS - the key here for me was these changes to the sshd_config config file in /etc/sshd: StrictModes no But, also, I had to do a number of things around setting folder and file ownership and permissions (see the z/OS redbook on ssh, very helpful) and work to synch up ssh on my cygwin/Windows with ssh on z/OS (I assume all of this is standard ssh) - this was all to get password-less login to work. 2. When I setup z/OS slave(s) in Jenkins, using ssh to invoke the slave jar, the script I have it invoke to run the jar has this command in it: java -Dfile.encoding=ISO8859_1 -jar /usr/local/jenkins/slave.jar -text This seemed to resolve any ASCII/EBCDIC issues I was seeing. 3. To run the Jenkins jobs I had to explicitly set the jobs to run on Windows, using: Restrict where this project can be run setting the Label Expression to master. Then to execute the job on z/OS I used build Execute Windows batch command with an ssh command to invoke the desired script on z/OS; e.g.: ssh USER@HOST su -s RACF_SURROGATE_USER -c SCRIPT_ON_ZOS_TO_RUN And voila, that's it! There are a lot of details underneath this and I had certain machinations I had to go through for local requirements (e.g. RACF surrogate to allow me to rebuild a Websphere profile file system). www On Monday, December 30, 2013 8:41:40 AM UTC-8, wwwild...@gmail.com wrote: I see a similar issue; I can't get as far as getting the commands from Jenkins to run on z/OS. That is I see errors like this: [zOS unit tests] $ /bin/sh -xe /tmp/hudson4437459291454251752.sh + Ž ÍËÊ %?Ä/% ÂÑ + 1 ¢Á 1 ,Ñ 1 Ë^Í 1 ÑÈÈÁËÈË ËÇ Ž ÍËÊ %?Ä/% ÂÑ: /tmp/hudson4437459291454251752.sh 1: FSUM7351 not found The slave looks to be running fine on z/OS: java -Dfile.encoding=ISO8859_1 -jar /usr/local/jenkins/slave.jar -text and I can get System Information fine for the node. I've gone through this thread, but I don't see any correspondence to the classes in remoting-2.25-SNAPSHOT.jar and my 1.535 version of Jenkins. So, obviously I have some kind of EBCDIC/ASCII mismatch between my Windows Master and z/OS. As far as I know z/OS UNIX shell requires script files to be in EBCDIC, otherwise it's reasonably easy to deal with ASCII and EBCDIC from their (e.g. via Java), but EBCDIC has to be a starting point. So, if anyone knows what I'm missing please let me know. www -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins vs. EBCDIC
I see a similar issue; I can't get as far as getting the commands from Jenkins to run on z/OS. That is I see errors like this: [zOS unit tests] $ /bin/sh -xe /tmp/hudson4437459291454251752.sh + Ž ÍËÊ %?Ä/% ÂÑ + 1 ¢Á 1 ,Ñ 1 Ë^Í 1 ÑÈÈÁËÈË ËÇ Ž ÍËÊ %?Ä/% ÂÑ: /tmp/hudson4437459291454251752.sh 1: FSUM7351 not found The slave looks to be running fine on z/OS: java -Dfile.encoding=ISO8859_1 -jar /usr/local/jenkins/slave.jar -text and I can get System Information fine for the node. I've gone through this thread, but I don't see any correspondence to the classes in remoting-2.25-SNAPSHOT.jar and my 1.535 version of Jenkins. So, obviously I have some kind of EBCDIC/ASCII mismatch between my Windows Master and z/OS. As far as I know z/OS UNIX shell requires script files to be in EBCDIC, otherwise it's reasonably easy to deal with ASCII and EBCDIC from their (e.g. via Java), but EBCDIC has to be a starting point. So, if anyone knows what I'm missing please let me know. www -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
Any updates on this? I'm in the same boat. The slave.jar connects just fine with no special encoding, but any artifacts created on z/OS USS side come back to the Jenkins server as EBCDIC and so does the log file found on the server (even though it won't display on the web page). Thanks! Dave (dorcus) -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
It doesn't seem practical for build artifacts to have their encodings changed automatically; doing so would require that the Jenkins slave code somehow be told which files are safe to convert and which are not. The log is a different situation, of course; that would be safe to convert (and to do so on the fly). - Original Message - From: jenkinsci-users@googlegroups.com To: jenkinsci-users@googlegroups.com At: Nov 22 2013 16:50:04 Any updates on this? I'm in the same boat. The slave.jar connects just fine with no special encoding, but any artifacts created on z/OS USS side come back to the Jenkins server as EBCDIC and so does the log file found on the server (even though it won't display on the web page). Thanks! Dave (dorcus) -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
I agree. I just found the iconv utility. I run this as the last steps in my shell script on any artifacts I want brought back to Jenkins. This worked beautifully! Using Jenkins with z/OS opens up a lot of possibilities! -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
Kohsuke, just checking: I sent you the build.xml and a logfile last week. Did you have a chance to look into it yet? Anything else I could do? Open a bug report, maybe? Thanks. On Mon, Jun 17, 2013 at 9:47 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: It should be able to, actually. Any chance you can send me that log file and build.xml? Also, give us the whole stack trace for that error, not just the error message, please. 2013/6/17 Dirk Haun 68k...@gmail.com Thanks for making me check the logfile :) Indeed, it's not empty but contains the output in EBCDIC. I guess Jenkins simply couldn't display that in the browser? From the looks of it, we can now run commands (without having to translate them to EBCDIC manually), but we seem to have a problem with SVN authentication: Checking out svn://our-svn-server/cpmffmeta/trunk ERROR: Subversion checkout has been canceled hudson.util.IOException2: remote file operation failed: /.../jenkins/workspace/zpdtCommandTest at hudson.remoting.Channel@5d0a3a93 :sva-zpdt-emul ... Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try. Authentication failed We'll investigate some more ... On Sun, Jun 16, 2013 at 2:06 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: Thanks for helping us troubleshoot this. If you look at the log file inside $JENKINS_HOME, is it really empty? It should contain console log in EBCDIC, then you should see charsetCP037/charset (or something like that) in build.xml. 2013/6/13 Dirk Haun 68k...@gmail.com Thanks. The good news: We can now connect the slave without having to set the file.encoding. The bad news: Our jobs don't produce any console output any more. Neither a simple set command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp-auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured
Re: Jenkins vs. EBCDIC
Thanks for making me check the logfile :) Indeed, it's not empty but contains the output in EBCDIC. I guess Jenkins simply couldn't display that in the browser? From the looks of it, we can now run commands (without having to translate them to EBCDIC manually), but we seem to have a problem with SVN authentication: Checking out svn://our-svn-server/cpmffmeta/trunk ERROR: Subversion checkout has been canceled hudson.util.IOException2: remote file operation failed: /.../jenkins/workspace/zpdtCommandTest at hudson.remoting.Channel@5d0a3a93 :sva-zpdt-emul ... Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try. Authentication failed We'll investigate some more ... On Sun, Jun 16, 2013 at 2:06 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: Thanks for helping us troubleshoot this. If you look at the log file inside $JENKINS_HOME, is it really empty? It should contain console log in EBCDIC, then you should see charsetCP037/charset (or something like that) in build.xml. 2013/6/13 Dirk Haun 68k...@gmail.com Thanks. The good news: We can now connect the slave without having to set the file.encoding. The bad news: Our jobs don't produce any console output any more. Neither a simple set command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ...*** * The problem is that commands that we type into the text field of the Execute shell build
Re: Jenkins vs. EBCDIC
It should be able to, actually. Any chance you can send me that log file and build.xml? Also, give us the whole stack trace for that error, not just the error message, please. 2013/6/17 Dirk Haun 68k...@gmail.com Thanks for making me check the logfile :) Indeed, it's not empty but contains the output in EBCDIC. I guess Jenkins simply couldn't display that in the browser? From the looks of it, we can now run commands (without having to translate them to EBCDIC manually), but we seem to have a problem with SVN authentication: Checking out svn://our-svn-server/cpmffmeta/trunk ERROR: Subversion checkout has been canceled hudson.util.IOException2: remote file operation failed: /.../jenkins/workspace/zpdtCommandTest at hudson.remoting.Channel@5d0a3a93 :sva-zpdt-emul ... Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try. Authentication failed We'll investigate some more ... On Sun, Jun 16, 2013 at 2:06 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: Thanks for helping us troubleshoot this. If you look at the log file inside $JENKINS_HOME, is it really empty? It should contain console log in EBCDIC, then you should see charsetCP037/charset (or something like that) in build.xml. 2013/6/13 Dirk Haun 68k...@gmail.com Thanks. The good news: We can now connect the slave without having to set the file.encoding. The bad news: Our jobs don't produce any console output any more. Neither a simple set command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master.*** * The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp-auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check
Re: Jenkins vs. EBCDIC
Thanks for helping us troubleshoot this. If you look at the log file inside $JENKINS_HOME, is it really empty? It should contain console log in EBCDIC, then you should see charsetCP037/charset (or something like that) in build.xml. 2013/6/13 Dirk Haun 68k...@gmail.com Thanks. The good news: We can now connect the slave without having to set the file.encoding. The bad news: Our jobs don't produce any console output any more. Neither a simple set command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins
Re: Jenkins vs. EBCDIC
Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- You
Re: Jenkins vs. EBCDIC
No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users
Re: Jenkins vs. EBCDIC
Thanks. The good news: We can now connect the slave without having to set the file.encoding. The bad news: Our jobs don't produce any console output any more. Neither a simple set command nor attempting to check out from SVN (which worked before) leave anything in the console - it's simply empty. Any ideas? On Thu, Jun 13, 2013 at 2:20 PM, Kohsuke Kawaguchi k...@kohsuke.org wrote: No, it's not. I created https://ci.jenkins-ci.org/job/remoting/lastBuild/ 2013/6/13 Dirk Haun 68k...@gmail.com Kohsuke, thanks for trying to fix it. But I'm afraid there's no difference - it still can only connect when we set the file.encoding to ISO8859. I took the remoting-1.42-SNAPSHOT.jar from here: https://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/2599/ Was that even the correct file? But I didn't see any other version anywhere. On Wed, Jun 12, 2013 at 5:14 PM, Kohsuke Kawaguchi k...@kohsuke.orgwrote: I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from
Re: Jenkins vs. EBCDIC
This should work out of the box, because we take the encoding of the slave into account for obvious reasons. the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. Does your slave JVM have a proper default encoding configured? 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. Does your slave JVM have a proper default encoding configured? 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
RE: Jenkins vs. EBCDIC
Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)... If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding - does that work? /James From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Dirk Haun Sent: 12 June 2013 15:03 To: jenkinsci-users Subject: Re: Jenkins vs. EBCDIC Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlphttp://%3cip-of-master%3e/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.orgmailto:k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. Does your slave JVM have a proper default encoding configured? 2013/6/12 Dirk Haun 68k...@gmail.commailto:68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.commailto:jenkinsci-users%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.commailto:jenkinsci-users%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.commailto:jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins vs. EBCDIC
XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci
Re: Jenkins vs. EBCDIC
I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding? There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi k...@kohsuke.org XML without prolog is parsed as UTF-8, so I think that part is OK. I'm spotting a few places in JNLP handshaking that relies on ASCII-compatible encoding, so I wonder if that's causing it. In any case, I think we need more detailed error messages. Another thing I spotted is the BASIC auth header. How is the username and password supposed to be encoded? 2013/6/12 James Nord (jnord) jn...@cisco.com Looks like jenkins serves up its JNLP pages without an XML prolog (the ?xml version=1.0 encoding=UTF-8? bit)… ** ** If you save the file and add an XML prolog for UTF-8 and run from that without setting the encoding – does that work? ** ** /James ** ** *From:* jenkinsci-users@googlegroups.com [mailto: jenkinsci-users@googlegroups.com] *On Behalf Of *Dirk Haun *Sent:* 12 June 2013 15:03 *To:* jenkinsci-users *Subject:* Re: Jenkins vs. EBCDIC ** ** Ah, the default encoding. It seems we *have* to set it to something other than EBCDIC so we can even get a connection to our master. The slave is connected via Java Web Start and started like so: java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl http://ip-of-master/computer/sva-zpdt-emul/slave-agent.jnlp -auth username:password Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not get a connection to the master. ** ** Connecting via ssh is not an option, as it's not available on the emulator. Any suggestions? ** ** On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi k...@kohsuke.org wrote: This should work out of the box, because we take the encoding of the slave into account for obvious reasons. ** ** the Execute Shell feature uses the CommandInterpreter class, which uses the FilePath.createTextTempFile method to create a shell script. This file takes contents as String, then uses the encoding of the slave when it does new FileWriter(f). So it should write the shell script in EBCDIC. ** ** Does your slave JVM have a proper default encoding configured? ** ** ** ** 2013/6/12 Dirk Haun 68k...@gmail.com We're trying to use Jenkins to build our software on OS/390 (using the Hercules emulator, not real hardware, but still). This OS uses EBCDIC as its native character set, not ASCII. We've successfully managed to check out from our SVN repository (yay!), but now we would need to run commands to build the software. And this is where we run into problems ... The problem is that commands that we type into the text field of the Execute shell build step need to be translated from ASCII to EBCDIC when run on the OS/390 side. We confirmed that this is the problem by manually translating a simple command to EBCDIC and typing those characters into the text input field - the command was then executed. However, a lot of EBCDIC characters have non-printable ASCII equivalents, so this is not an option in practice (besides it being a pain in the back to maintain). Is there any any plugin that can handle this situation? Alternatively, is there a plugin that would simply let us run a script that's already on the OS/390 side? Please note that again, there's the problem of character set translation - this time with the file name; but since the SVN plugin does work as expected, maybe some part of Jenkins is already doing the right thing. We're stuck at this point, so any help is appreciated. Thank you. bye, Dirk -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ** ** -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group
