Re: qopensys etc.

It was Zend Core. Strangely, I can no longer find the page on Zend's site... but it's still in Google's cache.

Here's a quote from their knowledgebase article #267:

Zend Core for i5/OS requires that /usr/local is a directory, rather
than a symbolic link. A previously installed application has set up
/usr/local as a symbolic link. This is often seen with prior
installations of PHP.

Their fix was to delete the symlink and create it as a directory, then reinstall Zend Core. But, I don't know why this article is no longer on their site. Perhaps the problem was eliminated in newer versions?

The symptom (if it was a symlink) was that the RSTLICPGM command to install Zend Core would fail with "Zend Core will not install. QM.0003 in QTEMP was not restored".

So on my system, /usr/local is a regular directory, and /qopensys/usr/local is symlinked to /usr/local. That way, /usr/local and /qopensys/usr/local point to the same place.


Dennis Lovelady wrote:

There was a licpgm (Zend server, perhaps?) that wouldn't install
properly if one or the other was a symlink. Now I can't remember which
way caused the problem... but it failed to install to a symlinked
directory, so you had to do the link in the other direction.

It was annoying.

Yes, don't you love it when program products decide their own standards for
the way YOUR system should be set up?!?!

Well, unless Zend server (or whatever it was) has been made i-aware, it
wouldn't know about /QOpenSys. So perhaps that tells us which symlink was a
problem. Would that imply that it's safest to create /usr/local as a
directory, and /QOpenSys/usr/local as a symlink to that? Then (worst case)
only i-specific programs might fail for this cause. Something to ponder,
perhaps.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Guidelines for Bureaucrats:
(1) When in charge ponder.
(2) When in trouble delegate.
(3) When in doubt mumble."
-- James H. Boren