Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Jerry, I’m a colleague of Richard.

$php --version
PHP 7.0.5 (cli) (built: Jun 13 2017 21:46:49) ( NTS )
Copyright © 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright © 1998-2016 Zend Technologies

VERSION.ZOS shows
Tool: php
Version: 7.0.5
Build Number: 012

Did I miss a newer version to download?

– Manfred

Jerry, I’m a colleague of Richard.

$php --version
PHP 7.0.5 (cli) (built: Jun 13 2017 21:46:49) ( NTS )
Copyright © 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright © 1998-2016 Zend Technologies

VERSION.ZOS shows
Tool: php
Version: 7.0.5
Build Number: 012

Did I miss a newer version to download?

– Manfred

Jerry, I’m a colleague of Richard.

$php --version
PHP 7.0.5 (cli) (built: Jun 13 2017 21:46:49) ( NTS )
Copyright © 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright © 1998-2016 Zend Technologies

VERSION.ZOS shows
Tool: php
Version: 7.0.5
Build Number: 012

Did I miss a newer version to download?

– Manfred

Just suggestion,
exec1 has ASCII encoding, exec2 - EBCDIC ?

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

When I execute exec1 from an OMVS command line I get similar output to what I see in the browser so this is consistent. Note that the CGI_ environment variables are configured the same in both environments so I would expect this (both are set to EBCDIC). Both file exec1 and file exec2 contain EBCDIC and neither file is tagged. I tried changing the tagging but this didn’t affect the output.

This is the OMVS command line output I see when invoking exec1 without arguments:

X-Powered-By: PHP/7.0.5                                                                                     
Content-type: text/html; charset=UTF-8                                                                      
                                                                                                            
RC=4<br />output[0]=-                                                                                       
                     ---@¦--------¤£@--                                                                     
                                       ---¢£@---                                                            
                                                -<br />output[1]=<br />output[2]=<br />output[0]=hello world
input one                                                                                                   
last line                                                                                                   
<br />output[1]=<br />output[2]=

If I invoke as “exec1 conv=yes” then the following is displayed:

X-Powered-By: PHP/7.0.5                                                                                                             
Content-type: text/html; charset=UTF-8                                                                                              
                                                                                                                                    
RC=0<br />output[0]=hello world<br />output[1]=input one<br />output[2]=last line<br />output[0]=ÇÁ%%?-Ï?Ê%À<br />output[1]=Ñ>øÍÈ-?>
Á<br />output[2]=%/ËÈ-%Ñ>Á

This result seems to indicate that the PHP script can not handle the EBCDIC output generated by the externally called REXX. This scenario worked correctly in PHP 5.

The second example displays a simple form in the browser and POSTs the query string back to itself. It’s very basic and yet it seems that PHP is unable to translate the returned data correctly. Most likely this is due to translation performed by Apache. Once again this scenario worked correctly in PHP 5.

The output for php --version is the same as documented by Manfred.

Thanks for raising the internal ticket Tatyana. I can’t log in to see it’s content so is there some way I can track it?

Richard.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Tatyana, the SetEnv _BPXK_AUTOCVT ON statement is already present in the httpd.conf file for the IHS. This was required to enable PHP to read the php.ini file as it is tagged as EBCDIC. Richard.

Hi Tatyana, additionally to what Richard said.

If the php.ini (whose content is IBM-1047) were not tagged as IBM-1047 then php would assume that the php.ini is ASCII. So it seems that the tagging of php.ini (in case it is IBM-1047) is required, and thus:

SetEnv _BPXK_AUTOCVT ON

is required as well.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Could you provide your httpd.conf?

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi Tatyana,
Here is the stuff.

envvars: https://paste.fedoraproject.org/paste/7tLMMoxQ54m9AjFeHcURLw

httpd.conf: https://paste.fedoraproject.org/paste/AxSyPaV0hhde7q5OjrdO7A

You have to adjust some things. At least server name and presumably the directory names.

When I run exec1 I get:

RC=4
output[0]=�����@����������@�������@����
output[1]=
output[2]=
output[0]=hello world input one last line
output[1]=
output[2]=

Hope this helps to track things down.

Thanks a lot for your support.

– Manfred

Hi,

Yes, we reproduced this issue. And setup _BPXK_AUTOCVT solved this problem.
I looked at your config and found several differences. From README.ZOS:

Recommended settings for IBM HTTP Server are:

CharsetSourceEnc ISO8859-1
CharsetDefault ISO8859-1

These environment variables can be set in Apache configuration file, e.g.

SetEnv CGI_HEADER_ENCODING EBCDIC
SetEnv CGI_BODY_ENCODING NONE

Could you try to check using exactly these settings (of course, including SetEnv _BPXK_AUTOCVT ON), please?

Hm, I did as suggested, i.e. httpd.conf contains now:

SetEnv _BPXK_AUTOCVT ON 
SetEnv CGI_HEADER_ENCODING EBCDIC 
SetEnv CGI_BODY_ENCODING NONE 
                                                  
CharsetSourceEnc ISO8859-1 
CharsetDefault ISO8859-1 

When running exec1 I get:

����ʀa�?�����$�)hello world input one last line �ʀa�?�����$�)�ʀa�?�����$)�ʀa�?�����$�)��%%?��?�%���>��Ȁ?>��%/�Ȁ%�>���ʀa�?�����$�)�ʀa�?�����$)

which looks bad.

Anything, I missed or mixed up?

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi

I managed to run PHP 7 in “CGI” mode, but I have an error in “FastCGI” mode that I can not solve:

[error] [client 126.32.101.80] FastCGI: incomplete headers (115 bytes) received from server “/local/basepro/m4stats/php/php.fcgi”, referer: http://tmvs:8080/

In Apache conf file I have :

CharsetSourceEnc IBM-1047
CharsetDefault ISO8859-1
AddType application/x-httpd-php .php

In the shell that runs the PHP script I have (both for CGI mode and FastCGI mode) :

export _BPXK_AUTOCVT=ON
export CGI_HEADER_ENCODING=EBCDIC
export CGI_BODY_ENCODING=EBCDIC

PHP scripts and php.ini are IBM-1047 encoded.

Thanks,

Denis

I’m not sure if it’s related to this particular issue but I’ve also found that file uploads don’t appear to work in PHP 7. This can be observed by adding enctype=“multipart/form-data” to my POST example above along with an input field of type=“file”. Adding a vardump($_FILES) returns an empty array as does vardump($_POST) so not even ASCII characters are getting back to the PHP script. This same scenario works correctly with Rocket PHP 5.4.4 so it seems something in PHP 7 is flushing the multipart payload.

None of these specific issues were encountered in Rocket PHP 5.4.4.

Hi. I’ve encountered a couple of issues with the handling of ASCII and EBCDIC in PHP 7 (these examples work correctly in PHP 5). I have PHP 7 CGIs working successfully using the requires environment variables and IHS definitions but these specific situations don’t seem to correctly handle the conversion of character sets.

The first is the exec() function. This can return an array of output generated by the externally called program. I have a PHP script calling a REXX script with the REXX returning multiple lines of output via the SAY statement. When the output arrives back to PHP it appears to be ASCII encoded EBCDIC and the array is not correctly populated.

Here is the PHP script called exec1:

#!/ported/php/bin/php-cgi
<?php
if($_GET["conv"]=="yes")
 $p=" | iconv -f IBM-1047 -t ISO8859-1";
else
 $p="";
$output=array();
exec("./exec2 input one".$p,$output,$rc);
echo "RC=$rc";
echo "<br />output[0]=".$output[0];
echo "<br />output[1]=".$output[1];
echo "<br />output[2]=".$output[2];
echo "<br />output[0]=".iconv("IBM-1047","ISO8859-1",$output[0]);
echo "<br />output[1]=".iconv("IBM-1047","ISO8859-1",$output[1]);
echo "<br />output[2]=".iconv("IBM-1047","ISO8859-1",$output[2]);
?>

Here is the external REXX called exec2:

/*rexx*/
parse arg in
say "hello world"
say in
say "last line"
exit 4

Navigating to exec1 in the browser shows that all of the exec2 output lines are placed as a single string in the first element of array $output and the string is EBCDIC so doesn’t display very well. Adding query string exec1?conv=yes passes exec2 output through iconv and $output is then populated correctly (this is not a very good solution). It seems as though the exec() function isn’t handling character conversion correctly as the output generated by REXX exec2 is EBCDIC.

The second situation involves POSTing form data back to the PHP script. It is also coming back as EBCDIC (probably due to IHS processing) and consequently the PHP $_POST superglobal is not populated correctly. Here is an example PHP script called testpost:

#!/ported/php/bin/php-cgi
<?php
$cginame=$_SERVER["PHP_SELF"];
echo "<form action=\\"$cginame\\" method=\\"post\\" name=\\"form1\\">\\n";
echo "<br /><strong>Edit1:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit1"]."\\" ".
     "name=\\"edit1\\" size=\\"20\\">\\n";
echo "<br /><strong>Edit2:</strong>";
echo "<input type=\\"text\\" value=\\"".$_POST["edit2"]."\\" ".
     "name=\\"edit2\\" size=\\"20\\">\\n";
echo "<br /><input type=\\"submit\\" value=\\"Refresh\\" name=\\"refresh\\">\\n";
echo "</form>\\n";
echo "<br />Edit1: ".$_POST["edit1"];
echo "<br />Edit2: ".$_POST["edit2"];
echo "<br />";
print_r($_POST);
foreach($_POST as $n=>$v)
 echo "<br />".iconv("IBM-1047","ISO8859-1",$n).",$v";
?>

It’s not beautiful to look at but when run in the browser it shows that $_POST contains all of the variable information as a single string in a single array element. The script also passes $_POST through iconv to show that the data is actually EBCDIC by converting it to ASCII.

It’s most likely that something is misconfigured somewhere but it’s not clear what that might be so any guidance is appreciated.

Richard.

Hi,

We think there is a problem in your environment, because now we are not able to reproduce this issue. I added short config, which we use in our work. Could you try to use it?

config.tar (10 KB)

Hi Tatyana,
I tried out the httpd.conf (which is http 8.5 based) you provided. I created an http 8.5 based test server for this.

As we use a directory cgi-bin I added

ScriptAlias /cgi-bin/ "/u/testhttp/server/cgi-bin/"

For PHP I added
SetEnv PHPRC /u/testhttp/server/conf

To be able to start and stop the server using MVS commands, I added:

LoadModule zos_cmds_module modules/mod_zos_cmds.so

Then I tried a shell script, a REXX script and a simple PHP script. In all cases I get EBCDIC output in Firefox.

When trying out Richard’s exec1 I get

RC=4
output[0]=�����@����������@�������@����
output[1]=
output[2]=
output[0]=hello world input one last line
output[1]=
output[2]=

Trying Richard’s testpost I also get EBCDIC garbage in Firefox.

Hm, being confused now as you said your httpd.conf did work.

– Manfred