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 ===============================================================================
