PHP ECO2 problem solved
One of the suggestions on the ITRC was to use the undocumented SET WATCH FILE facility to find out what exactly was loaded. As it turned out, there was definitively something wrong in loading the PHP extensions. Whatever I tried, it always stopped at some point – after loading the first or second. It didn’t matter what I left in, or out, I always got the ACCVIO error.
This is the log I kept of these tests.
To keep all information into one file, I created a small test procedure to be run in batch, producing lots of output but having all data at hand in one logfile. One action taken was examining the link date of every executable:
$loop1:
$ f = f$search("PHP_ROOT:[extensions]*.EXE;1")
$ if f .eqs. "" then goto loop1end
$ write sys$output 'f'PHP_ROOT:[extensions]*.EXE;1
$ pipe analyze/image 'file' | search sys$pipe link
$ goto loop1
$loop1end:
PHP_ROOT:[extensions]*.EXE;1 would be the old PHP version, and PHP_ROOT:[extensions]*.EXE;2 the new one.
Drytesting the analysis in a simple test on the CLI-prompt – on both the old and new versions – revealed the dates were 100% equal. Comparing the files reveled NO DIFFERENCES….Something has gone wrong in setting up the environment!
Next, I checked the newly installed version in the Apache environment – and found there were new versions of every extension available, dated on the same date as the PHP and PHPSHR they belonged to: 3-Apr-2008, where the working environment only contained the ECO1 routines, dated 26-Sep-2006. Excepot for the module I built myself, of course.
So I copied all new files, reset the test environment to run the ECO-2 PHP executables, and behold: IT WORKED. So the problem was solved – so far. Next was of course renaming the new versions to become the valid ones, and just test the blog to run. It did – and so I entered this entry using ECO2.
The only problem that might occur is that the MySQL module used is built against the old PHPSHR. Reading the database was found not to cause a problem, and because saving the draft doesn’t moan either. write access is no problem either.
So it might well work. Publishing now….
Update
It does. Good news!
Next: admit the error on ITRC…
What I’ll do in the next update: Keep the PHP environment in the Apache location and run it from there. It would have prevented these problems. Or: In case of a new version, set PHP_ROOT to the Apache installation directory, in case of error change it back to the WASD environment. It means I still need to copy the files form [BIN] and [EXTENSIONS] to the WASD environment BEFORE updating PHP. But that is a way I have walked before.