Craig Berry quoted Chuck Aaron:

> Don't forget to hit reply-to-all, as replying directly to me severely
> limits the possibility you will get help in a reasonable time frame,
> or, in this case, reliable help at all.

> >The disk names were not changed during the upgrade and the web server is 
> >running fine and working correctly apart from PERL. I looked on this server 
> >for miniperl.exe and it is no where to be found. What would you suggest? 
> >Should I delete PERL and try to re-install it? I have CSWS installed, along 
> >with CSWS_Perl also. I noticed in the doc that the new 5.8 will not work 
> >without them. I run the OSU Web Server not Apache.

> I know nothing about OSU and can only speculate about what might be
> wrong, but I see in Alan Winston's book, "OpenVMS with Apache, OSU,
> and WASD," p. 309, , that OSU, "looks for webperl, then looks for
> perl, then looks for miniperl...."  If you don't have Alan's book,
> you shouldn't be running a VMS-based web server, or, to state it more
> positively, anyone running a VMS-based web server should have Alan's
> book.

Shucks.  If I ever manage to find the time to write the 2nd edition, can I ues
that quote?

> So the fact that it can't find miniperl means it also failed to find
> webperl and perl, one of which is probably what it really wants.
> Look for those files and check all the related symbols and logicals
> and read your OSU documentation for webperl set-up.  Also consider
> posting to the OSU mailing list.  I have a vague suspicion that you
> have to build your own Perl to use with OSU and can't just use the
> HP-supplied kit directly via SWS_PERL.

I don't think that's mandatory.  OSU doesn't necessarily have any carnal
knowledge of PERL internals, or vice versa.  (You can compile up a
"webperl.exe" that uses PERLSHR and is supposed to be optimized for CGI-ation,
but I never bothered with that; you might care on a slow VAX.  Otherwise the
DECnet task object uses vanilla PERL and puts a note in the log about
"unoptimized PERL".  I'd expect SWS_PERL to work provided WWWEXEC.COM can find
it; that means PERL_ROOT needs to be defined globally, or maybe in the
HTTP_SERVER LOGIN.COM

Absent finding PERL_ROOT, it tries for miniperl.


My offhand guess would be that Chuck had PERL_ROOT defined globally but the
definition  didn't make it into his automated startup, and the reboot
necessitated by the VMS upgrade wiped out the definition.

Chuck:

$ SHOW LOG PERL_ROOT

and let us know what you find.

-- Alan


 >
> >Thanks,
> >Chuck
> >
> >Craig A. Berry wrote:
> >
> >>At 8:54 AM -0400 8/28/06, Chuck Aaron wrote:
> >>
> >>>Group,
> >>>
> >>>Would you have a minute to advise me as to how to fix this problem
> >>>below? It occurred after upgrading from openvms 7.3-2 to openvms 8.2.
> >>
> >>
> >>
> >>It looks more like a problem with your web server set-up than with
> >>Perl.  Why not simply look to see where miniperl.exe is located (if
> >>indeed it's on your system), and then see if that's where the
> >>WWW_SYSTEM logical points?  You didn't, by chance, change disk names
> >>during the upgrade?
> >>
> >>>>    Connect request received at 23-AUG-2006 14:51:49.36
> >>>>           from remote process DIAMND::"0=HTTPD"
> >>>>           for object "WWWEXEC"
> >>>>
> >>>>       --------------------------------------------------------
> >>>>
> >>>>Unoptimized perl...
> >>>>
> >>>>(CGI_ENV)
> >>>>
> >>>> "CONTENT_LENGTH" = "152"
> >>>> "CONTENT_TYPE" = "application/x-www-form-urlencoded"
> >>>> "GATEWAY_INTERFACE" = "CGI/1.0"
> >>>> "HTTP_ACCEPT" = "*/*"
> >>>> "HTTP_ACCEPT_ENCODING" = "gzip, deflate"
> >>>> "HTTP_ACCEPT_LANGUAGE" = "en-us"
> >>>> "HTTP_AUTHORIZATION" = "Basic cHh6YTAwMzpleGNoaWphcw=="
> >>>> "HTTP_CACHE_CONTROL" = "no-cache"
> >>>> "HTTP_CONNECTION" = "Keep-Alive"
> >>>> "HTTP_HOST" = "excerpt2.ceris.purdue.edu"
> >>>> "HTTP_REFERER" = 
> >>>> "http://excerpt2.ceris.purdue.edu/FCKeditor/_samples/html/exsample01_perl.html";
> >>>> "HTTP_USER_AGENT" = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; 
> >>>> SV1; InfoPath.1)"
> >>>> "PATH_TRANSLATED" = "/HTBIN/*/HTBIN/*www_xroot:[bin]"
> >>>> "REMOTE_ADDR" = "128.210.64.36"
> >>>> "REMOTE_HOST" = "leftfield.ceris.purdue.edu"
> >>>> "REMOTE_PORT" = "3193"
> >>>> "REMOTE_USER" = "PXZA003"
> >>>> "REQUEST_METHOD" = "POST"
> >>>> "SCRIPT_NAME" = "/HTBIN/FCKTEST01.CGI"
> >>>> "SCRIPT_PATH" = "/HTBIN/"
> >>>> "SERVER_NAME" = "excerpt2.ceris.purdue.edu"
> >>>> "SERVER_PORT" = "80"
> >>>> "SERVER_PROTOCOL" = "HTTP/1.0"
> >>>> "SERVER_SOFTWARE" = "OSU/3.10a;UCX"
> >>>>%DCL-W-ACTIMAGE, error activating image WWW_SYSTEM:MINIPERL
> >>>>-CLI-E-IMAGEFNF, image file not found DKC200:[HTTPD.][SYSTEM]MINIPERL.EXE;
> >>>>CPU Ticks: 0  Buffered I/O: 91, Direct I/O: 18


> --
> ________________________________________
> Craig A. Berry
> mailto:[EMAIL PROTECTED]

> "... getting out of a sonnet is much more
>  difficult than getting in."
>                  Brad Leithauser

-- 
===============================================================================
 Alan Winston --- [EMAIL PROTECTED]
 Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056
 Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025
===============================================================================

Reply via email to