Foswiki on Mainframe

-- MarkNaughton - 28 Jan 2013

Hi all,

I am trying to install Foswiki on the MVS platform, running z/OS 1.12, and using Unix System Services. I have managed to get the configuration panels

up and running but due to the EBCDIC encoding, the configuration data is not saved correctly. Is there anything I can do apart from manually updating

the LocalSite.cfg? In fact, does Foswiki support this platform?

Thanks,

Mark.

You might be the first to try Foswiki on z/OS, I don't recall the questions coming up before. We don't have test facilities available, so as with some of our other platforms, "support" comes down more to experience from users.

Do you know if the Unix System Services supports any way to run in ASCII mode, or is EBCDIC required?

Can you provide some more details about what goes wrong when the configuration is saved?

Lastly, what version of Perl do you have available. Looking through some Google results, IBM shows it supplies Perl 5.8.7, which is quite old (May 2005). I don't believe there is any testing done on releases older than 5.8.8, and Foswiki 1.2 will require minimum 5.8.8.

We'll be glad to try to work through issues with you.

-- GeorgeClark - 28 Jan 2013

Looking at http://perldoc.perl.org/perlebcdic.html ... this appears to be a rather challenging task.

-- GeorgeClark - 28 Jan 2013

If you search for TWiki on Mainframe you'll find that it has been done before and this should give you some insights.

I've both Foswiki and Mainframe experience, but alas not Foswiki on a Mainframe. Hopefully, I can help. George's comments above about Perl 5.8.7 could be the most important thing to address.

-- JulianLevens - 28 Jan 2013

George/Julian, First off - thanks for replying to this post - I know it is an obscure one. I am running Perl 5.8.7. Path configurations are the current issue - /usr/lpp/java/J6.0_64/bin is translated to /usr/lpp/java/J6.0m64/bin. In the SafeEnvPath, the following from my USS profile is changed to LJAVAmHOMEn.

I am assuming that Foswiki will only run on later versions of Perl?

Thanks fellas for your help.

-- MarkNaughton - 29 Jan 2013

When I try to save the new configuration, it also fails with the following:

Unable to obtain value from $this->{values}->{Languages}{bg}{Enabled}. eval failed with HPE20504 Can't use string ("0") as a HASH ref while "strict refs" in use at (eval 671) line 1.

Thanks

-- MarkNaughton - 29 Jan 2013

I'm not quite sure where the SafeEnvPath would be translated with underscore converted to m.

• The initial value is set by lib/Foswiki/Configure/Checkers/SafeEnvPath.pm and unfortunately it uses hard-coded path separator to parse apart the directories.
• You should be able to undo the results of the check by modifying the SafeEnvPath field, down at the bottom of the GeneralPathSettings, or are you saying that the valid value is saved to LocalSite.cfg with the underscore changed to the m.
• If the field is being modified when written to the LSC, then the issue might be in Foswiki::Configure::FoswikiCfg or Foswiki::Configure::Valuer Unfortunately this is a pretty complex area of the code.

I'm not following what the USS profile and LJAVAmHOMEn is all about. The "n" looks suspiciously that the \n escaped newline is not being escaped.

5.8.7 will probably work for the current code. I think we still claim support < 5.8.8, but that will change in 1.2.0, where we definitely require 5.8.8. ( http://foswiki.org/Development/RequirePerl588) And work being done for better utf8 / unicode support will almost certainly require a much more modern perl, though the requirement has not yet been determined. In 1.1.x, Foswiki.pm itself requires perl 5.5 minimum. Some extensions might requirer newer.

The perlebcdic document I linked to seems to suggest that things are badly broken in newer versions of perl.

Perl used to work on EBCDIC machines, but there are now areas of the code where it doesn't. If you want to use Perl on an EBCDIC machine, please let us know by sending mail to perlbug@perl.org

I'd suggest fixing up the LocalSite.cfg errors with an editor if you can, and let's see if the basic stuff like viewing pages works. How far can you get.

-- GeorgeClark - 29 Jan 2013

Ah... USS - Unix System Services. Did you miss something? "The following (?) from my USS is changed to ...

The eval failed. That's probably down in Valuer.pm. Unfortunately line numbers reported in eval failures are rather unhelpful.

-- GeorgeClark - 29 Jan 2013

This is likely a long road - before we go down it, please consider whether it's worth the effort to you, and understand that it will take considerable effort from you.

The hard-coded path separator is unfortunate - but there are zillions of them in Foswiki. POSIX environments should accept them and translate to native. If this one doesn't it's hopeless - well, more work that anyone wants to do. For every one that's been turned into a File::Spec call, 3 more pop up.

The _ to m translation isn't anything explicit in configure. I believe CGI does the transformation. Look in your site perl library (something like /usr/share/perl5/) for CGI.pm; I believe the actual translation table is in CGI/Util.pm. Well, tables - EBCDIC is variable.

I'd start there - are the translation tables correct for the OS that you're using?

Although the line numbers are indeed unhelpful, the message from die is quite clear (remember my campaign to check every eval is still on-going...this one is an early, if small, victory.)

Assuming 1.1.6, uncomment the line #$SIG{__DIE__} = sub { Carp::confess( $_[0] || '' ) }; in bin/configure (roughly line 235). That should give a traceback.

One of $this, {values}, {Languages}, or {bg} is zero, and should not be. Or Perl thinks it is.

I expect that $this is OK, as it was used to find the method. So that would probably mean that the %cfg hash has been corrupted. ($this->{values} contains a reference to %Foswik::cfg at this point). "0" is probably the value of {Enabled}.

You could add ', Data::Dumper::dumper( \%Foswiki::cfg)' (without the quotes) to the end of the 'die' at line 49 of Valuer.pm. Be prepared for a LOT of output.

{bg} would be, IIRC, Bulgarian. Probably the first Language in the list, as that version of configure sorts by language code.. The languages are found by scanning the locale directory for .po files. You can try setting the {LocalesDir} to /dev/null - and get the next error. It might show a pattern...

In any case, this may be a long road.

If the necessary changes have reasonable scope, we can probably get them into v.next.

But I expect you'll have to do a lot of work to help. As George said, we don't have the environment to test with.

-- TimotheLitt - 29 Jan 2013

Hi Tim/George, Much appreciated for your thoughts and comments on this. I agree it will be a lot of so will report back today on what I have currently found out. Thanks again.

-- MarkNaughton - 30 Jan 2013

Ok, I'll try to answer everything you've asked so far.

1. Whenever I save the configuration (initially as it fails a second time), the values in the SafeEnvPath are converted incorrectly - ie is translated into LJAVAmHOMEn. 2. I have manually changed the LSC with the correct path. 3. I have considered whether the Mainframe is suitable for Foswiki and have fed this back. It is an experiment to show that the old Mainframes still have life in them 4. All path values have been checked. 5. The codepage I am using is IBM_1047. 6. An initial page reload reported version.pm not found. I found that Perl 5.8.7 did not have this installed so I installed it from CPAN. 6. After all this, I encountered the following:

Error in tempfile() using path: Parent directory (path) is not writable

I changed the /working/tmp permissions and this worked.

7. Next issue is exec of path -r%REVISION|N% %FILENAME|F% failed: EDC5129I No such file or directory. - resolved this by changing the LSC manually to RcsLite.

8. I now have Foswiki up and running albeit the display is slightly skewy which I'll look further into tomorrow.

Thanks for your help guys and I'll report back tomorrow. At least this may help 'future' users of Foswiki on the Mainframe!

-- MarkNaughton - 30 Jan 2013

Sorry guys, will be away for a week on a business trip so will report back further mid February. Found that Perl 5.8.7 is missing various HTML Perl modules so need to install them to clear the errors.

-- MarkNaughton - 01 Feb 2013

Bad news here from the Perl community. EBCDIC support on the chopping block.

http://www.nntp.perl.org/group/perl.mvs/2013/02/msg1619.html

-- GeorgeClark - 07 Feb 2013

Oh dear, thats not good. I heard that Rocket Software will be working with IBM to produce updated versions of perl, cURL, bzip2, sudo, and PHP. Will be interesting to see how that works.

-- MarkNaughton - 11 Feb 2013

Hi all, Thanks for your suggestions above but I have been unable to get it working on the MVS platform. Therefore I have to concede that the only choice I have is a Linux platform. Thanks again for your help.

-- MarkNaughton - 31 Mar 2013

Commenting is disabled while not logged in