We have a customer attempting to run our webapp on USS - z/OS V1R10. The appserver is tomcat 6.0.18.

I am noticing that on this particular OS only, a rewritten URL is not parsed for the jsessionid. This is obviously a problem when cookies are not sent from the client for whatever reason.

Since we use this same exact code (both our webapp and tomcat) on other OSes without having this problem I was wondering if anyone has any thoughts about why z/os would have a problem? It makes no sense to me, frankly.

I'm going to write a test webapp to further verify my findings and maybe learn some new info.

Thanks.

It seems to me extremely unlikely that the z/OS OS has anything to do with the problem.

Perhaps there is a firewall or HTTP proxy or Web/edge server between your browser and the z/OS Tomcat server that is causing problems by removing the jsessionid from the URL. To find out, you should turn on tomcat logging and see if the url is arriving in tact.

BTW: using jsessionid in a URL is considered by many as a security exposure:
https://issues.apache.org/bugzilla/show ... i?id=45255

I found the problem. It is a Tomcat bug. I filed bug 47320 on ASF Bugzilla.

https://issues.apache.org/bugzilla/show ... i?id=47320

In summary, when Tomcat parsed the URL for the jsessionid and made a String out of it, the encoding wasn't specified. Therefore the default of EBCDIC was used.

We don't recommend running z/OS Tomcat with a default file encoding of EBCDIC. If you do, this won't be the last bug you find

Running with -Dfile.encoding=IBM-1047 works fine, you just have to make sure that you specify EBCDIC encoding for any files or datasets that your webapps read/write, if necessary. This is usually not a big issue.

BTW: Have you tried our new T:Z Quickstart for Tomcat package?

I tried the default encoding switch as you suggested and it didn't have any effect on the jsessionid received from an URL.

(I added the switch to the JAVA_OPTS env var.)

Are you sure this is the encoding to use? It seems that if I am receiving input encoded in what is essentially ASCII then this is not the default encoding I should be specifying for Tomcat/Java.

Some background if you are curious:
I am not actually a z/os user/customer. What is happening is we have a potential customer who wants to run our webapp on this OS. Usually our customers run on other OSes which you can probably name.

We are leasing a z/os system so we can troubleshoot this issue for our potential customer.

I really appreciate the help you have given and will point out your services and products to the rest of our group and our customers. Thanks!

I'm sorry, I mistakenly said "IBM-1047" (EBCDIC) when I meant ISO8859-1 (Latin-1 ASCII). We recommend running z/OS Tomcat with -Dfile.encoding=ISO8859-1.

Yes, forcing ISO8859-1 does solve the original problem.

Thanks!

I had to edit catalina.sh and encode the "start" command to bootstrap.jar to be "ascii".

i.e. org.apache.catalina.startup.Bootstrap "$@" \x73\x74\x61\x72\x74

Even then, I was getting some messages from Bootstrap that indicates it was still receiving something in EBCDIC but I haven't bothered to track that down.

I'm sure you have better ways of dealing with this so if the customer is really interested in pursuing this, I may just send them to you.

Thanks again!

You may want to consider using the JZOS launcher to start Tomcat, and even better yet the pre-packaged T:Z Quickstart for Tomcat version.

Thanks, I have pointed out your Tomcat T:Z offering to people who know much more about IBM OSes than me.

Thanks again for all the help!