Month: July 2008

More blog issues
I found that though the normal user access to blogs was not really impacted by the transfer for MySQL 5.1 (except that it seems to be significantly faster), some admin panels didn’t work properly at all. To be honest: couldn’t be accessed at all, because things seemed to be broken somehwhere in the MySQL database access. So I had to configure these blogs to use the new 5.1 database. This applied to the SYSMGR blog, the Bootcamp2008 blog and my Trips, Tracks and Travels. Remarkably, the testblogs that are still available for older WordPress versions) did work nicely, even in the Admin panels.
So I am moving all blogs to MySQL 5.1, and put versiom 4.1 to rest. It may cause some blogs inaccessable for some time.
There was, for some reason, a problem with the Bootcamp 2008 blog: it failed to load, the admin panel didn’t show up or it was the WP25 admin page (the BC2008 logical refers to the BC2008 environment first, and to the WP25 environment after that). The logicals were fully correct, the same structure and definition is used for both the Bootcamp 2007 and Trips,Tracks and Travels blog, and these were all fine, both the blog as the admin panels.
Restarting the webserver solved the problem – but I had to define the logicals /EXEC first 😉
Anyway, this problem is solved now. There must have been a glitch within the server cache, perhaps?
WordPress 2.6
is out for a week now, I got it already and will test it this week. It may cause some themes to be changed because the current skin is not compatible with this version.
I installed it, and it didn’t work out-of-the-box as did the previous versions: a number of files have a dot in the name and this is replaced by underscore when unzipping the package:

class.wp-dependencies.php
class.wp-scripts.php
class.wp-styles.php
functions.wp-scripts.php
functions.wp-styles.php

The PHP code however checks for the name containing the dot;
Luckily, it’s just one file (script-loader.php) where these five are loaded. I renmaned the files and it worked. Well, almost. The database has to be created, after that tables were created but accessing the testblog (after I added it into the WASD configuration, of course) failed. That is: the main page is shown but the stylesheets are missing. Login and admin however cannot be accessed. Cause: When the tables are created, the default protocol for the blog is http, where I expect it to be https since the testblog is on the operator web – which is, for obvious reasons, secured.
Changing these two entries (site URL and home) usiing direct access to the database to state https solved this. It works fine. So now it’s a matter testing it all.
LogScan problem
I updated the logscan last weekend: the list of “allowed locations” needed an update because there are some new directories, and some old ones. But due to a mistake: the last entry of one of the lists ended in “|”, there was hardly any invalid location, just the commands that I think inappropiate on the site. This error has been corrected now and the list rerun.

VAMP (the Vms/Apache/Mysql/PHP site) is found to be offline for quiet a while now, so I disabled access in the OpenVMS blogroll for the moment.

One little problem
As turned out, the Bootcamp 2008 blog fails using the new MySQL extension. Wondering why, I found the blog stored in antother place than I would expect: I thought the blog to be in the WordPress database but it’s not: It is found to be in one of the test databases: the WP23 one. It was set that way in the configuration file, wrong, but well, keep it there, it doesn’t matter really, even when the logical refers to WP25. Well, I may have made a mistake there. Anyway, accessing the WP23 database – which is a 4.1.14 one as well, now fails drastically: the database is sensed to be “gone” on fairly every SQL statement….

Accessing the 5.1.22 database however is fine, no problem.

I think on moving all databases to the new MySQL version: a new database, but using port 3306. Irt means re-importing the data. Just wait to see wether backup succeeeds tonight. Only: how would I move just that blog from the WP23 database to the WordPress one? Well, let’s read the MySQL documentation 🙂

MySQL 5.1.23
I installed this today, and set things up to run this new database. It looks good, for all, but things may go wrong, as I encountered logging in. Refreshing the page went Ok, so it must be a minor thing. Perhaps while still running the 4.1.14 PHP_MYSQL I just did.
Rebuilding a 5.1 engine is now easy. Just have the logical be changed from MYSQL_ROOT to MYSQL051_ROOT, and the job is done. It’s, again. an improvement. And what’s more: the 4.1.14 database is acecssable with the same engine. As I would expect; no real incomptabilities found, yet, so I keep the SYSMGR running on teh 5.1-23 database for now, unless something really gets stuck. It’s the one with major updates (like this entry); I just have to be sure that this database is added in the backup cycle and startup-sequence.

HP freeware available – by package
HP used to allow HTTP and possibly FTP access available on the contents of the Freeware CD’s but during the bootcamp last May, it was noticed this access has been removed, and the only way to get what you want is to download the full package. I got the impression that this is not what most users like, so I downloaded the files, unpcaked and restored them on my system to allow anyone to access the CD content – by package and, in that respect, by file. It’s a plain copy of the CD’s and the only thing I added is a file telling about the packages on the CD – by scanning FREEEWARE_README.TXT on each of the packages. Some don’t have one, and some have no description so for these, you’ll have to access the package to find out.

Just follow the link “Search Freeware” in the OpenVMS links.

MySQL engine now working
I cannot stand it doesn’t built like it should with HP’s kit, so I simply retried with the porting lib included. It compiles but still fails to run – same message, same location. Obviously since this has been changed in PHP sources and so need to be restored, and I forgot about that….Done that, and now I reget the error on realpath that I had before. I found it to be in the STDLIB include and it certainly relates to the CRTL version:

/*
** realpath()
** Not in ANSI standard.
** Optional parameters not in X/Open or Posix specifications.
*/
#if __CRTL_VER >=80300000
# if defined _POSIX_C_SOURCE || !defined _ANSI_C_SOURCE

# if defined _POSIX_C_SOURCE
char * realpath (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name);
# else
char * realpath (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);
# endif

# if __INITIAL_POINTER_SIZE

# pragma __pointer_size 32
char * _realpath32 (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);

# pragma __pointer_size 64
char * _realpath64 (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);

# endif /* /POINTER_SIZE */

# endif /* realpath() */
#endif /* __CRTL_VER >=80300000 */

I’m on 8.3 and so I’ll have a problem.

The code containing the problem definition shows it is the non-posix version:

#ifndef __REALPATH_H
#define __REALPATH_H 1

/*
** Define the realpath function prototypes
*/
char *realpath (const char *, ...);
#endif /* -_REALPATH_H */
#endif

First one, that’s no problem. The DECC include clearly shows two, at least. The error on type however is weird, because both are defined char *. Or it should be an int64 pointer, if __INITIAL_POINTER_SIZE is false…?. The listing looks promising:

I5 5853
I5 5854 /*
I5 5855 ** realpath()
I5 5856 ** Not in ANSI standard.
I5 5857 ** Optional parameters not in X/Open or Posix specifications.
I5 5858 */
I5 5859 #if __CRTL_VER >=80300000
I5 5860 # if defined _POSIX_C_SOURCE || !defined _ANSI_C_SOURCE
I5 5861
I5 X 5862 # if defined _POSIX_C_SOURCE
I5 X 5863 char * realpath (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name);
I5 X 5864 # else

Source Listing 14-JUL-2008 13:45:53 HP C V7.3-009-48GBT Page 104
21-NOV-2007 09:42:33 SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1(STDLIB)

I5 5865 char * realpath (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);
E
E
I5 5866 # endif
I5 5867
I5 5868
I5 X 5869 # if __INITIAL_POINTER_SIZE
I5 X 5870
I5 X 5871 # pragma __pointer_size 32
I5 X 5872 char * _realpath32 (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);
I5 X 5873
I5 X 5874 # pragma __pointer_size 64
I5 X 5875 char * _realpath64 (const char * __XOPEN_RESTRICT __file_name, char * __XOPEN_RESTRICT __resolved_name, ...);
I5 X 5876
I5 X 5877 # endif /* /POINTER_SIZE */
I5 5878
I5 5879 # endif /* realpath() */
I5 5880 #endif /* __CRTL_VER >=80300000 */
I5 5881

but what is fundamentally wrong with the PHP code?

I3 25358 #ifndef __REALPATH_H
I3 25359 #define __REALPATH_H 1
I3 25360
I3 25361 /*
I3 25362 ** Define the realpath function prototypes
I3 25363 */
I3 25364 char *realpath (const char *, ...);
......1
%CC-W-MISMATPARAM, (1) In this declaration, parameter 2 has a different type than specified in an earlier declaration of this functi
on.

%CC-E-NOTCOMPAT, (1) In this declaration, the type of "realpath" is not compatible with the type of a previous declaration of "realp
ath" at line number 450 in file SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1 (text module STDLIB).

I3 25365
I3 25366 #endif /* -_REALPATH_H */
I2 25367 #endif

Wait: I’m using CXX and that may make a difefrence. The number of arguments doesn’t match, the second MAY now be referred to as an int – and therefore I get an ACCVIO when storing a string “0000” is attempted.
I decided to change the realpath.h code, to match the definition in the C include:

char *realpath (const char *, char *, ...);

Since now equal, it compiles without a problem. But does it work?

After saving this post, stopping what was running PHP_WASD, and re-accessing the editor, it looks it works. No crash, no non-compliant answer, no error messages in the generarted pages. Checked it with PHP-Info, and indeed, it shows 4.1.14 – the one I’m running. And phpMyAdmin, that previously mentioned 3.1.28, now also mentions 4.1.14.

This simple change to realpath.h did the trick.

I mentioned it on JFP.s MySQL forum as well, so anyone will be able to get on. Moreover, since 4.1.4 is now working, could I try 5.1.22?

PHP_MySQL
Now I got the new sourcekit, I installed it on a separate location – the kit contains all code in separate backup savesets, and I decided to install the whole lot – or better, what think be needed for rebuilding the MYSQL engine – on one particular location. It seems to me that this is the case at HP as well, but there it would have been on a separate disk, something I didn’t choose to.

It meant I needed to reconsider the commandprocedure to build the extention, but it made no difference.. It failed on the same location: the realpath function being off the declaration, for the second parameter, and of type. The latter stopped the compilation.
After consulting Jean Francois Pieronne on his MySQL forum on July 8th), his suggestion was I could do without files located on a location “portlib”, and it meant two files to be changed. Now the code compiled properly and linked without errors (after I did some minor update to the option file, since a shared image was renamed). No real problem either, but using the module causes a severe problem: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000030303030, PC=FFFFFFFF80A98508, PS=0000001B

So I had to revert to the older version….

Could it be that the C-compiler matters, or the DECC-library? Examining the kit as delivered by HP, it’s built with C 6.5 on OpenVMS 7.3-1, where I used C 7.3 on openVMS 8.3. It may explain why I have these troubles in compilation: the big issue that the realpath function is differently specified than in the DECC library.