 COMMON PROBLEMS: =============== = Problems starting TENTACLE, STUB, etc: look for text messages C (unknown message type is usually a text message) in the CRINOID.LOG E file.   For example, if TENTACLE has a problem with the PERL logicals C (it needs PERL_ROOT and PERLSHR) it will show up in the CRINOID.LOG  file. @ ----------------------------------------------------------------A Problems starting CRINOID will show up in a NETSERVER.LOG file in  your OSU_HTTP home directory.   D Proxy problems and nonfunctional proxy accounts generally won't showD up in the NETSERVER.LOG files; you may need to check $ accounting orD look at the OSU_HTTP log files.  I've seen situations where you have@ to reboot (!)  to get a proxy definition to "take", but that was5 likely caused by some misconfiguration of the various  SYS$SYSTEM:*PROXY*.DAT files.   ? It's useful to log into your HTTP-server account and try things  like: 
     $ DIR 0::  and      $ DIR 0"HTTP":: %             ^^^^ or whatever username 1 ...you should get directories of the HTTP server.   @ ----------------------------------------------------------------? Script problems: make sure your scripts will run interactively! = (e.g, "perl myscript.cgi")  and use the -w flag when testing!   D It helps to have an OYSTER.CONFIG that defines a log file, and checkF that logfile for messages.  You can set the loglevel to 3 or higher toF get more verbose output, and any writes to STDERR in your scripts will go to the logfile.  F Your scripts will be running in a "virgin" process (i.e., without yourC LOGIN.COM having run) so you may need to do some manual setup to be @ able to use utilities beyond what is in Perl (PGPLOT, Databases,B etc.).  You can use AddENV and AddINC commands in OYSTER.CONFIG toF import logicals into the script's %ENV and to put directories into theF script's @INC array, but any defining of logicals/symbols will have toE be done in TENTACLE.COM.   See TENTACLE.COM for an example of setting 
 up PGPLOT.  " You might encounter messages like:W     ERROR while running: Unable to create sub named "*Blah::blah::blah" at /perl/lib... B These *can* be caused by modules not being preloaded...if they areF loaded in the process of running OYSTER but not on a preload list thenB they will not be available to the scripts.  (The script won't loadE them because they're "already loaded", but they haven't been imported C into the Safe:: partition so are not available to the script).  Set A the OYSTER logging level to 3 and look at the logfile to see what D modules are there at startup and which are preloaded into the Safe::0 partitions.  Then adjust preloads appropriately.   ----digression--- K     There's some trickiness regarding putting things into module namespaces L     that can also cause the "unable to create sub" error.  If OYSTER creates
     a symbol: 0         $(safename)::SOME_PACKAGE::SUBPKG::stuff6     The symbol tables (stashes) for SOME_PACKAGE:: andG     SOME_PACKAGE::SUBPKG are created.  _BUT_ if this occurs outside the C     Safe:: partition, the "HvNAME" on these stashes will refer back @     to the real, true "main::" rather than the Safe:: partition.       The solution is to do a:9             $safeptr->init_stash('SOME_PACKAGE::SUBPKG'); O     first, which simple creates a dummy variable using a Safe::reval procedure, @     thereby creating the symbol tables with the correct HvNAMEs.  M     This is how CGI::Carp can be made to function properly...it has an "exit" P     call that Safe would normally trap.  We first create the symbol tables, thenK     insert an "exit" procedure into the (safename)::CGI::Carp symbol table.   D     Note that CGI::Carp should not be preloaded because it overloads=     the usual Carp symbols that some scripts may want to use.   K     CGI should not be preloaded, because of it's tricky export handling and      i/o initialization.  ----end digression---     E You can change preloads for all Tentacles by editing OYSTER's preload C list near the top of the file.   One can also edit OYSTER.CONFIG to $ change preloads on a per-user basis.  ? Note that the "modules at startup" will almost certainly change E between Perl versions, requiring slight changes to the preloads.  And C I'm sure that I haven't tried all possible modules, so the need for * some preloads hasn't been encountered yet.  H ======================================================================== Script global symbol pollution:   E This *shouldn't* be a problem, at least with moderately modern Perls. A There's a little test script "test_globals.pl" that scans through D symbols like $^A, $#, etc. to see which are actually "global" (i.e.,1 changes inside a Safe partition persist outside).   E Some of these don't matter: $. (the current line number).  But others K like $\ can make real problems if they get changed by a script and persist.   M The SCRIPT.PM module tries to save/restore these globals, but future versions G of Perl might have some more.  So you can run test_globals.pl and check F against SCRIPT.PM... NOTE that there are several ways that the globalsF get reset, so just because it's not on the "save_globals" list doesn't mean it isn't saved.  H ========================================================================  D It is unlikely that you'll encounter a serious CRINOID/TENTACLE/STUBF problem that will require running one or more of these programs in the0 VMS debugger.  But if you need to, here's how...  4 Steps for running CRINOID processes in the debugger:@ ----------------------------------------------------------------C With AUTHORIZE set up an account with the same UIC, home directory, 6 etc. the same as your OSU_HTTP server, but with privs:  1     LOG_IO, PHY_IO, SYSPRV, SYSNAM, DETACH, WORLD (     [+IMPERSONATE for VMS7.2 and higher]  	 OPTION 1: I If you are going to only run one CRINOID server, and you want that server  to be "debuggable": J --------------------------------------------------------------------------J     Do a FULL shutdown of any existing CRINOID server, to remove installed     images.   K     Suppose that your OSU_HTTP server runs in account HTTP, and you've just (     added account DBGHTTP...add a proxy:           $ MCR AUTHORIZE \         UAF> ADD/PROXY mynode::HTTP  /DEFAULT=DBGHTTP      !! use your nodename for 'mynode'         UAF> SHOW/PROXY *::*  (         should then show something like:           mynode::HTTP4         DBGHTTP (D)                             HTTP  P     (you'll want to set the default back to HTTP after you switch to a non-debug     version of CRINOID)   	 OPTION 2: G If you are going to run multiple CRINOID servers, for example one being 1 a "production" server, and another for debugging: E --------------------------------------------------------------------- K     As an example, the process name of the debug-CRINOID will be "CRINOID2" I     that listens to DECNET service WWWPERL2.  It should be installed in a ,     separate directory from the main server.  I     You don't need a full shutdown...just shut down any previous CRINOID2 P     servers by using @SHUTDOWN DEINSTALL in the CRINOID2 installation directory.  6     Create a proxy, but it doesn't have to be default:           $ MCR AUTHORIZE U         UAF> ADD/PROXY mynode::HTTP  DBGHTTP        !! use your nodename for 'mynode'          UAF> SHOW/PROXY *::*  (         should then show something like:           mynode::HTTP3         HTTP(D)                             DBGHTTP   O     In your WWW_SYSTEM:HTTP_SCRIPTS.CONF file, put an exec rule something like:   J        exec /cgi/*            0::"0=WWWPERL"nl:                   ! normalX        exec /cgi2/*           0"DBGHTTP"::"0=WWWPERL2"nl:         ! extra, for debugging  S     The result will be that while "normal" CGI urls (http://mynode.etc.net/cgi/...) R     get serviced by the "normal" CRINOID, urls like http://mynode.etc.net/cgi2/...]     are handed to CRINOID2, running in the DBGHTTP account.   You'll have to put WWWPERL2.COM X     into the WWW_ROOT:[000000] directory, which the INSTALL procedure prompts you to do.     Then, in both options: ---------------------   . Build and install a debug version of the code:  A     @CONFIGURE     with "VMS-debug" option, UIC for the new acct, M                    set process name and decnet service name if doing OPTION2. 7     @BUILD CLEAN   if previous "nodebug" build was done 
     @BUILD<     @INSTALL       and copy WWWPERL*.COM if it's changed/new  C Note that if you do a @STARTUP of CRINOID, there will be complaints D about installing images linked "/TRACEBACK".  That's good, you don'tF want them installed.  But you do want to make sure that the old images are deinstalled.  L Copy the debug support files (in this directory) to the CRINOID installation
 directory:        COPY *.INI  disk:[directory]      COPY *.COM  disk:[directory]  C Because CRINOID and TENTACLE need to respond to connection requests A in a timely manner (or the net connections get wiped out), it's a 9 good idea to get them up to speed quickly when debugging.   > Sometimes that means setting your breakpoints etc. in the .INI@ file and having the program "go" initially.  (It takes two "go"s8 to actually run; the default .INI's supply one of them).  B The DO_DEBUG procedure is to make it easy to set debugging output.A For detached/network processes, the best bet is to have debugginga+ be directed to a DEC- or X-windows display.E  @ Do a @DO_DEBUG and give it the IP# or node name of the X-displayA you want to use for debugging, and answer the questions for whichb; programs you want to debug (CRINOIDLOG, CRINOID, TENTACLE). = If these processes are currently running, you'll have to shuti= them down, and new processes will get the debugging settings.O   DEBUG LOGGING:
 =============aB The command files CRINOID.COM and TENTACLE.COM have logging levels@ and flags that can be set prior to running the executables.  TheB `higher' the level, the more things get logged.  There are severalC `flags' (MS bits in the loglevel) that turn on logging from variousTB parts of the programs.  The logging from CRINOID and TENTACLE gets2 sent to CRINOIDLOG which writes it to CRINOID.LOG.  D The log level changes made in the command files will take effect the@ next time the program is run... you can stop/id the old ones, or= use @SHUTDOWN.   Log level changes made via the "control" cgir" interface take effect immediately.  C The NEWLOG.COM procedure starts a new CRINOID.LOG file, letting youg" view/edit the old one more easily.  F Note that if you run more than one CRINOID, the first one started willH start the CRINOIDLOG process which will then be used by all the CRINOIDsG and TENTACLES.  If you do a @SHUTDOWN FULL (for any of the CRINOIDs) itOI will also shut down CRINOIDLOG, which will be a problem for any remaining G CRINOIDS.  So do @SHUTDOWN DEINSTALL for all CRINOIDS but the last one,  which gets a @SHUTDOWN FULL.