Question

I installed Twiki on z/OS 1.6. This is an ebcdic platform that uses codepage IBM-1047. I converted all textfiles to this codepage. When changing values on the configure page and pressing 'Next' I get the following error:

"Software error: HPE20221 Unmatched ( in regex; marked by <-- HERE in m/^(\.htaccessO.\\.(?i)( <-- HERE ?:php­0-9s]?(\..\)?O­sp]htm­l]?(\..\)?OplOpyOcgi))$/ at /opt/data/twiki/lib/TWiki/Configure/Types/REGEX.pm line 37, line 1. "

I am new to TWiki and Perl, so any help/suggestion is welcome.

Environment

-- TWikiGuest - 23 Oct 2007

Answer

Sorry, closing this after more than 30 days of inactivity. Please feel free to re-open if needed.

-- PeterThoeny - 03 Dec 2007

I have reproduced this error on a fresh TWiki 4.2.0 installation. The error_log in Apache says: Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE ^\s\*?~^\$@%`/ at /var/www/html/twiki420/lib/TWiki/Configure/Types/REGEX.pm line 38, line 1.

Perl version 5.8.0, Apache version 1.3.27, OS is Red Hat Linux 9 heavily patched.

-- CarlPatten - 13 Feb 2008

Same Problem here on z/OS 1.8.

-- KevinKeller - 27 Feb 2008

What Permissions are set on configure? 755?

-- JosephTrexler - 29 Feb 2008

555 on configure

One other note: it allows me to save one change fine. The error occurs if I make a second change and try to save it. For instance, I open the Miscellaneous category, change {Stats}{TopViews} from 10 to 12, click "Next," enter my password, click "Save". That works. Then I click the "Return to Configuration" link, go back and change TopViews? to 9. I click "Next" and get the error in my web log. I have to completely exit my browser to be able to save configuration changes again. Reproduced under both Firefox 2.0.0.12 and Internet Explorer 6 web browsers.

-- CarlPatten - 17 Mar 2008

From emails that I have read (in passing) on the perl 5 porters mailing list, it seems that no-one has reported to them the staus of ebcdic support. They don't have any information to suggest that it works (or to suggest that it does not).

While this problem sounds (from Carl's report) to not be ebcdic specific - it sounds like they (the perl project) could do with your help.

unfortuanaly, I havn't managed to reproduce the problem :/

-- SvenDowideit - 18 Mar 2008

There are two entirely different OSs and character sets being used here (potentially):

• Carl - Since you are running TWikiOnLinux on your mainframe, this is not an EBCDIC issue at all - Linux on IBM mainframes runs in ASCII.
• Kevin and original poster (TWikiGuest) - your issue may well be due to Perl EBCDIC support - have a look in the TWiki code for the 'is it EBCDIC' test and run this from the command line to check if EBCDIC is working at all.

All - please state whether you are using Linux on top of z/OS when you get this error - and preferably create a new Support request for each case, as it's somewhat confusing - Kevin in particular hasn't given any details.

To check which character code you are using, run this one-liner from the Unix/Linux shell:

      perl -e 'print (("A" eq chr(193) ? "ebcdic" : "ascii")."\n") '

Although it's odd that two sets of people are getting similar issues, there are different character sets, OSs and Perl versions in at least two of the cases, and the detailed error messages are different even though they have similarities - so it would be best to split Carl's Linux issue into a separate Support request.

All (but particularly z/OS users):

• Which browser character set is your web server configured for? Typically you would convert IBM-1047 on the web server (i.e. used by TWiki) to and from ISO-8859-1 or some other ASCII-based character set (i.e. used to and from the web browser). However, that's probably not the issue here as this is a server side error.
• Try installing an older version of TWiki that was known to work on mainframes, which would help determine if the issue is in Perl/OS, character set, or TWiki. The comments on RewritingUrlsWithEscapedCharsUnderOs390 may help - the patches I made there for I18N with EBCDIC were included in TWikiRelease04Sep2004, which is quite an old version but should help narrow this down.

-- RichardDonkin - 19 Mar 2008

Having just looked at the code for 4.2.0, lib/TWiki/Configure/Types/REGEX.pm has some suspicious code that would probably break EBCDIC usage - this code is basically validating a regular expression that is entered into configure. See line 30 in particular, which hard-codes ASCII values:

 $value =~ s/([[\x01-\x09\x0b\x0c\x0e-\x1f"%&'*<=>@[_\|])/'&#'.ord($1).';'/ge;

To fix or work around this:

• Directly edit the LocalSite.cfg file generated by configure - something of a hack as you'll need to do this again every time you save from configure
• Modify REGEX.pm to use EBCDIC values instead of the hard coded ASCII ones - you should be able to find a suitable conversion table somewhere.
• (Harder) Modify this code to not use 0x... constants at all - if it's possible to avoid these the code should automatically work on EBCDIC

Of course, it might be to do with how your web server translates (or not) the input of forms - so some TWikiDebugging will be required here with 4.2.0.

Since there was a lot of code changed in TWiki 4.0 and later, there may be other ASCII-isms, so you might find these issues in other places too. However, a quick grep -R '\b0x[0-9a-f][0-9a-f]' . doesn't reveal anything important (the Attach.pm hits are where it looks at image file headers which will remain in ASCII I think).

-- RichardDonkin - 19 Mar 2008

Closing question, seems to be answered.

Best to open a bug report if there is one. Link provided in sidebar.

-- PeterThoeny - 01 May 2008

Change status to: AskedQuestions AssignedQuestions AnsweredQuestions ClosedUnanswered