MOD_PHP ECO2 problem

[Willem Grooters]

I downloaded and installed this patch, and ran into a nasty protblem: NOT ANY PHP code could be executed with the new executables. Not even the most basic of all available scripts delivered with MOD_PHP: PHP_RULES.PHP...

Being a WASD user, my first thought was it would be the PHP engine (PHPWASD that links PHPSHR). But even having followed the author's advise to update the server software (PHPWASD) the problem persisted. Using the old PHPSHR, there is no problem at all (even when linked to the new PHPWASD code).

To rule out the webserver software, I ran the very same tests with old and new versions of PHP.EXE and PHPSHR.EXE, with the same results as using the web. With the very same results.

As I understood, the WASD author has tested the update on several machines and found his software needed an update. He has found no issues at all.
Quite likely, there must be something wrong in my running environment, but what?

A summary of these tests has been attached.
The system (VMS 8.2, AXP) is patched up to ( and including) Update-6. Tests have been executed under SYSTEM.

[Thierry Uso]

OpenVMS/Itanium 8.3-1H1 + last patches CSWS and CSWS_PHP

My PHP applications (Textpattern, Pmwiki, Mantis) seem to work...

[Willem Grooters]

Thierry,

No wonder. But as stated, it works on other systems under WASD, so it should work on my box as well.
Moving to Itanium would be nice, moving (back) to CSWS will not be considered.

The problem was signalled using the webserver, but this cause can be ruled out: It has been observed using PHP interactively - that's why I pushed it onto ITRC. The attachement is the result of these tests with PHP.EXE.

Another thought: would such behaviour occur if the PHP.EXE/PHPSHR.EXE build has been optimized for EV6 (AXP 21264) and would run on EV56 (21164A)? There is no indication on this limitation!

BTW: typo in my original post: Running 8.3)

[Wim Van den Wyngaert]

"it works on other systems under WASD"

Same VMS versions ? Same ys$libarry:decc$shr ? Also no problem when running stand alone ?

Wim

[Wim Van den Wyngaert]

php_rules is simply an echo of a few simple lines. Why the different output in the new version ? Did you install another php_rules outside the enclosed output ?

Wim

[Craig A Berry · Accepted solution]

How does PHP load shareable images? I would guess it uses LIB$FIND_IMAGE_SYMBOL rather than resolving everything at link time. When you point PHPSHR at an image with an extension of .EXE_NEW (rather than .EXE), does it find and load it properly? SET WATCH FILE with your example would probably tell you a lot about whether it's getting the right versions of everything, including shareable images, configuration files, etc.

[Willem Grooters]

Wim:
several - and knowing the author, it probably is patched up to the same level as my system (UPDATE-06 includes the latest CRTL patch).
If DECC$SHR would make a difference here: Why does the old version work properly, and fails the new one? So I don't think it has to do with that (unless, PHP and PHPSHR are linked against an even newer version).

At mentions: This is found when running standalone - outside the webserver, to rule that one out, and without ANY other module referenced (Ok, PHP_OpenVMS may be used, but that is used in both old and new version)

For what I can tell without any further reference: The difference must be related to some error that has been signalled by PHP/PHPSHR. That forces routine php-error - to signal ACCVIO as stated.
The error does not occur using the old version of PHP/PHPSHR, or is simply ignored.
This knowlegde comes from WASD WATCH output, that has the very same footprint.

Craig:
I thought about that. But as I found out, mixing old and new versions would fail definitely (see the logfile).
Building WASD with the new PHPSHR version is done by renaming PHPSHR.EXE_NEW to PHPSHR.EXE and link it. That's how I got PHPWASD.EXE_NEW (after renaming the result).

But as said more often: this has nothing to do with the webserver. PHP.EXE itself fails.

I'll try your SET WATCH suggestion, and publish the results.

[Wim Van den Wyngaert]

Willem,

I remember 20 years ago we often had problems with installing applications due to cobrtl being different. So, why not C.

If you copy the file and define the logical you can directly check if that is the case.

Wim

[Willem Grooters]

Craig's suggestion revelead that any load wold stop at some point - mostly after loading 2 or 3 modules - and then run into an error - ACCVIO, or leading to ACCVIO.
Examining the output, I checked the module's link data and found the problem: Although I expected to use the new (ECO-2) modules, I was still using the ECO-1 ones. Something has gone wrong in updating my working environment...
After copying these new files, and running PHP as of ECO-2. the problem was gone. Activating all ECO-2 executables - including PHPWASD built against it's PHPSHR - the problem was solved.