Rocket® Open-Source Languages and Tools for z/OS®

We are running z/OS V2 R1 and in preparation for going to V2 R2, I am installing the Perl distribution from Rocket’s Open Source Tools site. My first foray into testing resulted in: CEE3559S External variable PL_op_mutex was not found in DLL libperl.so. The traceback information could not be determined. [1] + Done(137) ./genConfigFile.pl rkmadm asdfasdf 50397899 Killed ./genConfigFile.pl I’ve not had any luck searching on the LE message CEE3559S.

I’ve just installed the OpenSSL tool and am running a BPXBATCH job to display the version information using the following command: openssl version It works, in that it displays this message: OpenSSL 1.0.2h 3 May 2016 however on the next line it also produces this message: WARNING: can’t open config file: /rsusr/rocket/ssl/openssl.cnf In my case the tool is installed into a directory called /usr/local/Rocket/ported/openssl I can’t work out why the version command is trying to open /rsusr/rocket/ssl (which doesn’t exist on my system) Any ideas what I have done wrong or haven’t done?

We’re currently running PHP version 5.4.4 build 0003 on z/OS V2R2. When running a simple php -v or php -help command we receive S0CC abend (HFP-Exponent-Overflow Exception). This problem occurs in one of our Test LPARs but we’re not seeing the issue on another one of our test LPARs. Could this problem be related to a specific LE Option? What can we do to further troubleshoot this issue?

Implemented perl 5.16.2 as part of z/OS 2.2 migration. A critical perl user was not able to run existing code with 5.16.2 but it works with 5.8.7. Here’s our test case: 5.8.7: #!/usr/lpp/perl #####!/usr/bin/perl open( RESPONSE_BASE, “<:encoding(ISO8859-1)”, “/u/snomre/weekly_tdi/kmbtstorig.txt” ); open( RESPONSE_MOD, “>:encoding(ISO8859-1)”, “/tmp/kmbtst.txt” ); while (<RESPONSE_BASE>) { chomp; print( “before substitution $_\\n” ); s/( ¬# \\s*)HELLO=.*/$1HELLO=Melissa/; print( RESPONSE_MOD “$_\\n” ); } close(RESPONSE_BASE); close(RESPONSE_MOD); 5.16.2 #!/usr/bin/perl open( RESPONSE_BASE, “<:encoding(ISO8859-1)”, “/u/snomre/weekly_tdi/kmbtstorig.txt” ); open( RESPONSE_MOD, “>:encoding(ISO8859-1)”, “/tmp/kmbtst.txt” ); while (<RESPONSE_BASE>) { chomp; print( “before substitution $_\\n” ); s/( ¬# \\s*)HELLO=.*/$1HELLO=Melissa/; print( RESPONSE_M

I’m testing php 5.4.4 to replace the ibm ported php 5.1.2 under IBM HTTP server 8.5.5.9. with the IBM ported php, i have a cgi called php, which is a shell script that then executes the php cgi program, with the php script name from the url. With php 5.1.2, I can run a php script that does the print phpinfo() and I get the proper html page back. When i change my php shell script to use the 5.4.4 php_cgi, I don’t get any output back. Instead I get a 404 error page in my browser, but neither the web or php error logs show any problem. Have you run into this issue? What do I need to do in order to get this working with the 5.4.4? Thanks, Peter

I just installed Python and the thread module is missing. Is this expected? Other modules import successfully. $ echo $PYTHONHOME /usr/lpp/ported/bin $ echo $PYTHONPATH /usr/lpp/ported/lib/python2.7 $ python -vvv # installing zipimport hook import zipimport # builtin # installed zipimport hook # trying /usr/lpp/ported/lib/python2.7/site.so # trying /usr/lpp/ported/lib/python2.7/sitemodule.so # trying /usr/lpp/ported/lib/python2.7/site.py # /usr/lpp/ported/lib/python2.7/site.pyc matches /usr/lpp/ported/lib/python2.7/site.py import site # precompiled from /usr/lpp/ported/lib/python2.7/site.pyc # trying /usr/lpp/ported/lib/python2.7/os.so # trying /usr/lpp/ported/lib/python2.7/osmodule.so # trying /usr/lpp/ported/lib/python2.7/os.py # /usr/lpp/ported/lib/python2.7/os.pyc matches /usr/lpp/ported/lib/python2.7/os.py import os # precompiled from /usr/lpp/ported/lib/python2.7/os.pyc import errno # builtin import posix # builtin # trying /usr/lpp/ported/lib/python2.7/posixpat

All z/OpenSource languages and tools have in common the existence of a file named README.ZOS containing instructions and example commands for installation of the tool. This file is located in : share/doc/<toolName>/<version>/ There are also instructions for unpacking.

Hi, I’ve been working with the z/OS Open Source version of PHP and found a behavior that is different then the previous version we’ve used. We commonly use PHP scripts to parse through the results of system commands at our shop for system checking and monitoring. One such example is a script that checks the available space in file systems. We’ll do something like this: $dfcmd = “df -kP" exec(”$dfcmd",$dfout,$dfrc); foreach ($dfout as $df) { #Check each filesystem } In the previous version of PHP the results from the command would result in $dfout being populated as an array with each output line as a separate array element. This allowed the following foreach loop to parse through the results. In the new version, $dfout is instead populated with a long string with the EOL characters included. Is this the desired behavior? Thanks!

The version of a distribution is often not enough for uniquely identifying it for purposes of knowing whether or not you have the most up-to-date code. Sometimes, for the same tool version, Rocket will make available for download multiple iterations each with a different build number. When requesting support for a language or tool from Rocket be sure to include the name, version, and build number. The build number is part of the original distribution file you downloaded from Rocket. Also, in the unpacked distribution you will find a VERSION.ZOS file that contains this information within this sub-folder: share/doc/<toolName>/<version> (e.g. share/doc/bash/4.3) It is best to keep this file so you can uniquely identify your tool version.

Can PHP track sessions and timeout user after x amount of idle time in an Apache and WebSphere Application Server on a Z system environment.

Welcome to the Rocket z/OS Open Source Languages and Tools forum. This is a place where you can ask questions about our open source languages and tools and get answers from other mainframe professionals like yourself, as well as members of the Rocket team.