PHP newbe (again)

[Wim Van den Wyngaert]

A year ago I tried to use PHP.
Now I upgraded to the new CSWS_PHP and relinked with Mark's install.com (VMS 7.3 WASD 9.0, yes PHP 1.3 is not supported on 7.3).

I reactivated the extentions I need in php.ini.
I set the extensions_dir to HT_ROOT:[PHP.AXP.EXTENSION].

But when I execute in the scripts directory :

1) php_calendar
Warning: dl(): Unable to load dynamic library 'HT_ROOT:[PHP.AXP.EXTENSIONS]/php_calendar' - no such file or directory in HT_ROOT:[PHP.AXP.SCRIPTS]PHP_CALENDAR.PHP on line 7

2) php_openvms

Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in HT_ROOT:[PHP.AXP.SCRIPTS]PHP_OPENVMS.PHP on line 145

Did I forget something ? is 2) a Bug ?

Wim

[Wim Van den Wyngaert]

I started php.exe and this programs displays the warning of 1) too (warning ? This should be an error). For all extentions that are enabled.

I did a set watch file/class=all and I don't see any accesses to the exe files. After php.ini I only see C.dir and messages.dir that are accessed.

wIM

[Mark Daniel_2]

1) The setup for enabling PHP scripts recommended by [SRC.PHP]READMORE.HTML does not seem to have been followed; hence the

HT_ROOT:[PHP.AXP.SCRIPTS]PHP_CALENDAR.PHP

rather than the

CGI-BIN:[000000]PHP_CALENDAR.PHP

I would have expected, with the unloadable extension specified as

'/php_root/extensions/php_calendar' - no such file or directory

I'm not sure of the mapping rule you are trying to use to activate this script. The

'HT_ROOT:[PHP.AXP.EXTENSIONS]/php_calendar' -
no such file or directory

also looks bizarre (combination of U**x and VMS file specification syntax).

Have you executed HT_ROOT:[SRC.PHP]PHP_STARTUP to define required WASD PHP logicals?

The extensions are located in PHP_ROOT:[EXTENSIONS] and PHP_CALENDAR.EXE should be there too.

Suggest you check and follow the setup recommendation in the READMORE.HTML. It can be a little complex as a result of differing capabilities of WASD version, PHPWASD version, CSWS PHP version, VMS version, and combinations thereof.

http://wasd.vsm.com.au/ht_root/src/php/readmore.html

It *may* have something to do with trying to run it under VMS V7.3, don't know and can't check easily.

It may also be some sort of unforeseen interaction with an installed and running CSWS on the same system, though I have done this and not had any such issue.

(As always with WASD-specific questions you *may* get prompter or more informed responses via the info-WASD mailing list.)

2) This one needs to be prefixed with "I'm no PHP expert but ..."

These days PHP.INI has this by default (I think)

allow_call_time_pass_reference = Off

This message goes away if it is made 'on' (apparently not recommended programming practice these days). It is now recommended PHP parctice to always pass by value and let the called function decide whether it needs to make a reference out of the argument.

http://php.planetmirror.com/manual/en/print/language.references.php

This (looks to me like it) would require a modification to the OPENVMS PHP extension code

[.ALPHA-CSWS_PHP-V0103.ext.openvms]OPENVMS.C

in the above source which reads

/*
** Return the Csid value just in case it's a context value
*/
if (SyiCsidPtr != NULL)
{
zval_dtor (SyiCsidPtr);
ZVAL_LONG (SyiCsidPtr, SyiCsidVal);
}

To me the C code is always treating the argument as a 'pointer'.

Just changing the script (to remove the offending '&' at the indicated lines) would (probably) not work the way that might be expected because the above code will try to move the SyiCsidVal to the 'location' represented by the value (not address) passed in SyiCsidPtr.

(I'm quite happy to be edjumacted by someone who knows what they're talking about here :-)

[Wim Van den Wyngaert]

Mark,

I tried it with specification of extensions_dir as HT_ROOT:[PHP.AXP.EXTENSION] as well as with the default value. Same reaction (slightly different messages).

Had to search for it but the php_startup is executed in startup_local. Seems ok to me, the logicals are there.

All php_xxx.exe are present on their correct place.

For those that didn't understand the end (as I did) : http://www.urbandictionary.com/define.php?term=Edjumacated

Wim

[Wim Van den Wyngaert]

Is this normal in php_info ?

SERVER["GATEWAY_API"] PHPWASD AXP-1.3.2, 70200000, 18-AUG-2005 06:08:27.56

_SERVER["GATEWAY_PHP"] PHPSHR V1.3, PHPSHR, 16-SEP-2005 10:05:38.84

PHPWASD was released before the version of PHPSHR was made ...

Wim

[Mark Daniel_2]

Here's my development systems relevant logical names

(LNM$SYSTEM_TABLE)

"PHPSHR" = "php_root:[bin]phpshr.exe"
"PHPWASDSHR" = "php_root:[bin]phpshr.exe"
"PHP_ROOT" = "$1$DKA0:[HT_ROOT.php.AXP.]"

My PHP_ROOT looks like

Directory PHP_ROOT:[000000]

BIN.DIR;1 0.50KB 21-NOV-2005 02:29:34.24
EXTENSIONS.DIR;1 1KB 21-NOV-2005 02:29:34.32
PHP.INI;15 21KB 30-NOV-2005 00:15:53.52
SCRIPTS.DIR;1 0.50KB 21-NOV-2005 02:29:34.39

Selected portions of the WATCH report when executing

/cgi-bin/php_calendar.php

from the READMORE.HTML scripts section.

050 /cgi-bin/php_calendar.php Y- MAP /cgi-bin/*.php* /php-bin/*.php*
051 /php-bin/php_calendar.php Y- EXEC /php-bin/* (@cgi-bin:[000000]phpwasd.com)/cgi-bin/*
|02:42:26.59 MAPURL 1095 0001 MAPPING RESULT|
Mapped:
Translated:
Script: /php-bin/php_calendar.php
Script-File: CGI-BIN:[000000]PHP_CALENDAR.PHP
Run-Time: @cgi-bin:[000000]phpwasd.com
|02:45:35.58 CACHE 0569 0001 RESPONSE CACHE search path 0A3A7CB2A62E1A6C2AE7C8A984B31B55|
|02:45:35.58 DCL 1310 0001 RESPONSE SCRIPT as HTTP$NOBODY RTE /php-bin/php_calendar.php CGI-BIN:[000000]PHP_CALENDAR.PHP (@cgi-bin:[000000]phpwasd.com)|
|02:45:35.58 DCL 1734 0001 DCL RTE idle pid:0000114B of HTTP$NOBODY (/php-bin/php_calendar.php)|

(I hate this ITRC interface with passion!)

You can see my mapping rules in the above report

map /cgi-bin/*.php* /php-bin/*.php*
exec /php-bin/* (@cgi-bin:[000000]phpwasd.com)/cgi-bin/*

On my 8.2 development system I could make them

map /cgi-bin/*.php* /php-bin/*.php*
exec /php-bin/* (cgi-bin:[000000]phpwasd.exe)/cgi-bin/*

just depends. Of course my development configuration systems tends to end up all over the place as I try all sorts of different things for occasions such as these.

[Mark Daniel_2]

>Is this normal in php_info ?
>
>SERVER["GATEWAY_API"] PHPWASD AXP-1.3.2, 70200000, 18-AUG-2005 06:08:27.56
>
>_SERVER["GATEWAY_PHP"] PHPSHR V1.3, PHPSHR, 16-SEP-2005 10:05:38.84
>
>PHPWASD was released before the version of >PHPSHR was made ...

In this case it is not significant. When CSWS PHP V1.3 was released I verified that the PHPWASD that had been built against CSWS PHP V1.2-1 linked and behaved correctly with V1.3. It did. I posted a message on info-WASD to that effect.

http://wasd.vsm.com.au/cgi-bin/yahmail/info-WASD-2005/WASD_2005/530?cmc=538&anc=3&pfr=&psu=&win=10
http://wasd.vsm.com.au/cgi-bin/yahmail/info-WASD-2005/WASD_2005/531?cmc=538&anc=3&pfr=&psu=&win=10

(the correction was needed because at this time of the day down here (0230) the brain begins to a bit gluggy - as indeed it is probably right now :-)

[Wim Van den Wyngaert]

Got it.

In php.ini it is written that the extension_dir must be commented out for WASD. I removed the comment (;) in the old version and it worked. Now you have leave it in comment, so using the default setting (which is not the value in comment).

Wim

[Wim Van den Wyngaert]

BTW : I even defined php_extension_dir: as a system wide logical. Didn't work.

Thx for the assistance Mark. Must be very late over there (or early).

Wim

[Mark Daniel_2]

Glad you got it working.

In my [SRC.PHP] that the PHPWASD kit is generated from the example PHP.INI has

; (WASD: for use with CSWS PHPSHR this needs to be commented out)
;extension_dir = php_extension_dir:

So the PHPWASD kit somes with this already commented out, which may explain why it works out-of-the-box.

What did you have against this configuration option?

My guess is that an early VMS Engineering release or in-house development version used a separate logical name, PHP_EXTENSION_DIR, to locate the extension images. My next guess is that now it uses PHP_ROOT:[EXTENSIONS] unless otherwise specified.

FWIW, the contents of PHP.INI seem to be a little neglected. For instance, although in the release notes as supported (and in fact only partly supported) is GD, but there was no

;extension=php_gd.exe

in the PHP.INI in the CSWS PHP V1.3 kit (and precious little else).

[Mark Daniel_2]

>BTW : I even defined php_extension_dir: as a >system wide logical. Didn't work.

No. As mentioned in the earlier post I think that is a hangover from some earlier CSWS PHP development.

It will allow you to configuration non-default location by specifying it in U*x style syntax, for example

extension_dir = /ht_root/php/axp/extensions

If you do it like this

extension_dir = ht_root:[php.axp.extensions]

then you get the sort of error you initially reported.

>Thx for the assistance Mark. Must be very late >over there (or early).

Getting close to my bed (again) time.

[Wim Van den Wyngaert]

Mark,

Nothing against the option but I think I must have read to fast and removed the comment in the previous version just as with some of the other options where it was needed.

My task is still not finished because PHPNUKE is the next one behaving strangely.
Keeps me busy.

Sleep well

Wim (sleeping within 3 hours too)

[Wim Van den Wyngaert]

Further remarks.

1. After upgrade of PHP a deassign of PHP_ROOT must be done because startup will not change it, only create.

2. the executable PHP.exe is still not able to find the extensions and displays the messages of 1).

3. For phpnuke (and others) make sure to have error_reporting on E_ALL (not E_ALL ^ E_NOTICE). Otherwise they don't digest the use of undeclared variables.

Wim

[Mark Daniel_2]

>1. After upgrade of PHP a deassign of PHP_ROOT
>must be done because startup will not change
>it, only create.

Thanks, missed that one.

The introduction of the IA64 CSWS PHP kit required that a decision taken back with WASD PHP v1.1 had to be revised. WASD endeavours to allow fully integrated installations for mixed architecure clusters. I had to move the CSWS PHP components to an architecture-specific location, from [PHP] TO [PHP.AXP] and [PHP.IA64].

(Normally PHP_STARTUP.COM which defines the PHP_ROOT logical does not touch an existing logical name to allow a local site to place that area independently of the WASD kit.)

>2. the executable PHP.exe is still not able to
>find the extensions and displays the messages
>of 1).

I thought that one had been solved.

PHP.INI extension_dir commented-out, or set to a U**x syntax equivalent of the location, e.g.

extension_dir = /ht_root/php/axp/extensions

If it's showing message similar to

Warning: dl(): Unable to load dynamic library 'HT_ROOT:[PHP.AXP.EXTENSIONS]/php_calendar' - no such file or directory in CGI-BIN:[000000]PHP_CALENDAR.PHP on line 7

then remove the configuration directive or modify as described above. If the message has changed then please post.

>3. For phpnuke (and others) make sure to have
>error_reporting on E_ALL (not E_ALL ^
>E_NOTICE). Otherwise they don't digest the use
>of undeclared variables.

This might vary on a per-PHP-application basis and so should be done at that level.

With PHPWASD v1.3 there are a number of ways to accomplish per-PHP-application configuration

http://wasd.vsm.com.au/ht_root/src/php/readmore.html#Configure_PHP

You can also 'wrap' the specific PHP application's PHP engine and define whatever environment you wish. See an example of doing this at

http://wasd.vsm.com.au/ht_root/other/infaq/hastymail.html

sections "WASD Scripting Wrapper" and "WASD Mapping Rules".

(This is a per-application usage of the same approach used by WASDPHP.COM http://wasd.vsm.com.au/ht_root/src/php/readmore.html#Configure_WASD)

** I really should increase my knowledge of this remarkably capable development environment.

*** Thanks for the feedback on WASD's PHP.

[Wim Van den Wyngaert]

Mark,

Sorry for the confusion but in 3 it must be NOT E_ALL
BUT E_ALL ^ ~E_NOTICE
read : show all but don't show notices.

The messages Unable to load dynamic library are now only given when running php.exe interactivly. So it works when using php via wasd.

** PHPNUKE and its sisters and brothers such as drupal are may be fine when everything works. But the slightest problem causes corrupt database contents and after that the application stop functioning. Bad (or no) error handling !!! Recreate db ... and restart.

Wim

[Mark Daniel_2]

Hmmm ...

KLAATU$ show sym php
PHP == "$HT_ROOT:[PHP.AXP.BIN]PHP"
KLAATU$ php -v
PHP 4.3.10 (cgi) (built: Sep 16 2005 10:06:54)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
KLAATU$ php -q PHP_CALENDAR.PHP

Testing the Calendar extension

Gregorian month (abbr.): Dec

Gregorian month: December

Julian month (abbr.): Nov

Julian month: November

Jewish month: Heshvan

French month: Frimaire


(Unprivileged account, so it can't be a protection issue.)

[Wim Van den Wyngaert]

Mark,

Had to do some further testing.

PHP.exe only gives the message when your default directory is sys$login (it seems). So, I found a small bug.

Wim