INFO-VAX Thu, 27 Sep 2007 Volume 2007 : Issue 528 Contents: Re: Alphaserver DS20 for sale - Italy RE: Article of Interest. RE: Article of Interest. Re: Article of Interest. Re: Article of Interest. Re: Article of Interest. Re: ba356 box Re: ba356 box Re: ba356 box Problem running sysman Re: Problem running sysman Re: Problem running sysman Re: Problem running sysman Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Time to PAK it in? Re: Time to PAK it in? Re: Time to PAK it in? Re: Time to PAK it in? Re: Time to PAK it in? Re: Time to PAK it in? Re: Time to PAK it in? Tomcat OpenVMS file system access problem Re: username/nocom vs. sylogin Re: username/nocom vs. sylogin Who is the Dead-eater ?? Re: Who is the Dead-eater ?? Re: Who is the Dead-eater ?? Re: Who is the Dead-eater ?? Re: Who is the Dead-eater ?? Re: Who is the Dead-eater ?? Re: wierd backup behavior Re: wierd backup behavior ---------------------------------------------------------------------- Date: Thu, 27 Sep 2007 11:35:04 -0000 From: Vanjkos Subject: Re: Alphaserver DS20 for sale - Italy Message-ID: <1190892904.253609.140640@n39g2000hsh.googlegroups.com> Up! ;-) Anyone interested ? ------------------------------ Date: Thu, 27 Sep 2007 10:18:00 +0000 From: "Main, Kerry" Subject: RE: Article of Interest. Message-ID: > -----Original Message----- > From: IanMiller [mailto:gxys@uk2.net] > Sent: September 26, 2007 4:02 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Article of Interest. > > On Sep 26, 4:02 am, "Main, Kerry" wrote: > > Perhaps. Its also possible they did not install all the well > publicised security patches > > for the platforms in question and the bad guys simply attacked known > holes. > > > > That would also count as operational incompetence. Depends on circumstances. If the OS platform is getting 5-20 security patches per month and the compa= ny policy dictates that important business apps must be tested against patches (norma= l best practice) before rolling into production, then it is not always possible fo= r Operations to line up the App testing and QA groups and resources every single month t= o re-test all the important business apps. If this were the situation and Operations had requested the time to do mont= hly re-testing QA's on the important Apps, but had been turned down by the busi= ness and App groups, then you can not blame the Operations group if their servers ge= t hacked (externally or internally). That is part of the risk a company takes when implementing an OS platform t= hat has so many security patches released each and every month. Although not insignifi= cant, it is not the monthly patch roll out and server reboots that is really expensive,= it is the QA re-testing and scheduling of App testing resources which has the highest= impact. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 27 Sep 2007 07:15:44 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: RE: Article of Interest. Message-ID: <8qa3WVPsBEaT@eisner.encompasserve.org> In article , "Main, Kerry" writes: > > If the OS platform is getting 5-20 security patches per month and the compa= > ny policy > dictates that important business apps must be tested against patches (norma= > l best > practice) before rolling into production, then it is not always possible fo= > r Operations > to line up the App testing and QA groups and resources every single month t= > o re-test all > the important business apps. Then company policy should dictate the use of an OS with fewer security patches. So maybe "operations" isn't where the incompetence lies, but it's in there somewhere. ------------------------------ Date: Thu, 27 Sep 2007 10:48:23 -0500 From: Ron Johnson Subject: Re: Article of Interest. Message-ID: On 09/27/07 07:15, Bob Koehler wrote: > In article , "Main, Kerry" writes: >> If the OS platform is getting 5-20 security patches per month and the compa= >> ny policy >> dictates that important business apps must be tested against patches (norma= >> l best >> practice) before rolling into production, then it is not always possible fo= >> r Operations >> to line up the App testing and QA groups and resources every single month t= >> o re-test all >> the important business apps. > > Then company policy should dictate the use of an OS with fewer > security patches. So maybe "operations" isn't where the incompetence > lies, but it's in there somewhere. MSFT would then send out fewer patches. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 27 Sep 2007 13:14:09 -0400 From: JF Mezei Subject: Re: Article of Interest. Message-ID: Bob Koehler wrote: > Then company policy should dictate the use of an OS with fewer > security patches. So maybe "operations" isn't where the incompetence > lies, but it's in there somewhere. Operations will just answer "Then we must upgrade to Windows Vista sooner rather than later because Microsoft has promised fewer patches with each new release of Windows. And in fairness to Microsoft, I think that the security of windows is slowly being improved from its absolutely dismal state. And as long as there are promised improvements on security (and number of patches), then operations can argue to management that Windows is being improved and that there is no need to change OS because of that. Remember that just like there are still americans who really believe the invasion of Iraq was a good thing and would vote republican no matter what, there are people who really believe Windows is an absolutely great operating system and will continue to fight for it within their employer's IT infrastructure. ------------------------------ Date: Thu, 27 Sep 2007 17:46:28 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Article of Interest. Message-ID: In article , JF Mezei writes: > > >Bob Koehler wrote: >> Then company policy should dictate the use of an OS with fewer >> security patches. So maybe "operations" isn't where the incompetence >> lies, but it's in there somewhere. > > >Operations will just answer "Then we must upgrade to Windows Vista >sooner rather than later because Microsoft has promised fewer patches >with each new release of Windows. http://www.bbspot.com/News/2007/09/microsoft-reveals-windows-vista-sp1-will-install-xp.html -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 27 Sep 2007 07:21:38 -0700 From: etmsreec@yahoo.co.uk Subject: Re: ba356 box Message-ID: <1190902898.852496.313690@g4g2000hsf.googlegroups.com> On 26 Sep, 20:58, "Carl Friedberg" wrote: > Richard, > > You are quite correct, the flaw was in my message. I did not > mean to imply that there was a requirement for dual power > supplies, in order to split the bus. To split the bus, you > need the BA356 manual, which IIRC shows how to flip > over a couple of connectors on the BA356 backplane; then > I believe the two SCSI connectors on the DWZZI?? will feed > each half-bus separately. I know I've done it, but this was > more than 10 years ago, so I don't trust my recollection. > > I've never had a BA356 with only one power supply installed. > I have had a BA356 with only one power supply working, > and I never noticed that the other supply had died... doh... > > Carl > > On 9/26/07, Richard B. Gilbert wrote: > > > > > Carl Friedberg wrote: > > > It's been awhile, but IIRC, the BA356 is capable of operating in a split > > > bus mode, so that there are two independent SCSI buses. Assuming > > > two power supplies, that allows you to connect to two channels on a > > > SWXCR. > > > AFAIK two power supplies are not a requirement for split bus operation. > > They are a very good thing to have however; those power supplies have > > been known to fail and it's nice to be able to swap out the bad supply > > without having your management know there was a problem (unless you > > choose to tell them).- Hide quoted text - > > - Show quoted text - I don't think it was jumpers - there was actually a conversion kit to go from split bus to single bus because of the termination etc required on the shelf. ------------------------------ Date: Thu, 27 Sep 2007 07:52:22 -0700 From: "johnhreinhardt@yahoo.com" Subject: Re: ba356 box Message-ID: <1190904742.419811.47710@r29g2000hsg.googlegroups.com> On Sep 27, 10:21 am, etmsr...@yahoo.co.uk wrote: > On 26 Sep, 20:58, "Carl Friedberg" wrote: > > > > > Richard, > > > You are quite correct, the flaw was in my message. I did not > > mean to imply that there was a requirement for dual power > > supplies, in order to split the bus. To split the bus, you > > need the BA356 manual, which IIRC shows how to flip > > over a couple of connectors on the BA356 backplane; then > > I believe the two SCSI connectors on the DWZZI?? will feed > > each half-bus separately. I know I've done it, but this was > > more than 10 years ago, so I don't trust my recollection. > > > I've never had a BA356 with only one power supply installed. > > I have had a BA356 with only one power supply working, > > and I never noticed that the other supply had died... doh... > > > Carl > > > On 9/26/07, Richard B. Gilbert wrote: > > > > Carl Friedberg wrote: > > > > It's been awhile, but IIRC, the BA356 is capable of operating in a split > > > > bus mode, so that there are two independent SCSI buses. Assuming > > > > two power supplies, that allows you to connect to two channels on a > > > > SWXCR. > > > > AFAIK two power supplies are not a requirement for split bus operation. > > > They are a very good thing to have however; those power supplies have > > > been known to fail and it's nice to be able to swap out the bad supply > > > without having your management know there was a problem (unless you > > > choose to tell them).- Hide quoted text - > > > - Show quoted text - > > I don't think it was jumpers - there was actually a conversion kit to > go from split bus to single bus because of the termination etc > required on the shelf. You could order the shelf in either single or split bus mode. There was also an option kit available to change a single bus to split bus. It consisted of a small circuit card that replaces another card that acted as a jumper. The option card broke the bus and provided termination for the second bus. To access the second bus you may have needed a different SCSI personality module. I can't remember. John H. Reinhardt ------------------------------ Date: Thu, 27 Sep 2007 11:35:31 -0400 From: "Richard B. Gilbert" Subject: Re: ba356 box Message-ID: <46FBCDC3.7050208@comcast.net> etmsreec@yahoo.co.uk wrote: > On 26 Sep, 20:58, "Carl Friedberg" wrote: > >>Richard, >> >>You are quite correct, the flaw was in my message. I did not >>mean to imply that there was a requirement for dual power >>supplies, in order to split the bus. To split the bus, you >>need the BA356 manual, which IIRC shows how to flip >>over a couple of connectors on the BA356 backplane; then >>I believe the two SCSI connectors on the DWZZI?? will feed >>each half-bus separately. I know I've done it, but this was >>more than 10 years ago, so I don't trust my recollection. >> >>I've never had a BA356 with only one power supply installed. >>I have had a BA356 with only one power supply working, >>and I never noticed that the other supply had died... doh... >> >>Carl >> >>On 9/26/07, Richard B. Gilbert wrote: >> >> >> >> >>>Carl Friedberg wrote: >>> >>>>It's been awhile, but IIRC, the BA356 is capable of operating in a split >>>>bus mode, so that there are two independent SCSI buses. Assuming >>>>two power supplies, that allows you to connect to two channels on a >>>>SWXCR. >>> >>>AFAIK two power supplies are not a requirement for split bus operation. >>> They are a very good thing to have however; those power supplies have >>>been known to fail and it's nice to be able to swap out the bad supply >>>without having your management know there was a problem (unless you >>>choose to tell them).- Hide quoted text - >> >>- Show quoted text - > > > I don't think it was jumpers - there was actually a conversion kit to > go from split bus to single bus because of the termination etc > required on the shelf. > All the boxes I've seen had both a terminator and a jumper plug. There was a "storage position" where you put the one you were not using. If you installed the jumper in the working position you had a seven slot bus. If you installed the terminator in the working position you got a split bus. ------------------------------ Date: Thu, 27 Sep 2007 06:30:23 -0700 From: Big John Subject: Problem running sysman Message-ID: <1190899823.673579.167680@y42g2000hsy.googlegroups.com> Hi. I wonder if anyone can help me n this. On an alphaServer DS15 running OpenVMS V7.3-2, I cannot run any commands at all on another node via SYMAN. BEP1->mc sysman SYSMAN> set env /node=bep2 %SYSMAN-I-ENV, current command environment: Individual nodes: BEP2 Username SEMA_INS will be used on nonlocal nodes SYSMAN> do show time %SYSMAN-I-OUTPUT, command execution on node BEP2 %SYSMAN-I-NODERR, error returned from node BEP2 -LIB-F-INSVIRMEM, insufficient virtual memory SYSMAN> Exit I have looked at the help for this message,and tried thumping up pgflquo to enormously inflated value. Before I suggest the customer go out and buy more memory, has anybody any bright ideas on how to narrow down the cause of this problem. (Is it with the user, the page files, or the physical memory, or is there any known problems with running sysman on this venerable old version of VMS? TIA for any bright ideas - John ------------------------------ Date: Thu, 27 Sep 2007 13:59:13 +0000 (UTC) From: gartmann@nonsense.immunbio.mpg.de (Christoph Gartmann) Subject: Re: Problem running sysman Message-ID: In article <1190899823.673579.167680@y42g2000hsy.googlegroups.com>, Big John writes: >On an alphaServer DS15 running OpenVMS V7.3-2, I cannot run any >commands at all on another node via SYMAN. > >BEP1->mc sysman >SYSMAN> set env /node=bep2 >%SYSMAN-I-ENV, current command environment: > Individual nodes: BEP2 > Username SEMA_INS will be used on nonlocal nodes > >SYSMAN> do show time >%SYSMAN-I-OUTPUT, command execution on node BEP2 >%SYSMAN-I-NODERR, error returned from node BEP2 >-LIB-F-INSVIRMEM, insufficient virtual memory >SYSMAN> Exit > >I have looked at the help for this message,and tried thumping up >pgflquo to enormously inflated value. Before I suggest the customer go >out and buy more memory, has anybody any bright ideas on how to narrow >down the cause of this problem. (Is it with the user, the page files, >or the physical memory, or is there any known problems with running >sysman on this venerable old version of VMS? The first thing to try is to use a different username, e.g. SYSTEM, just to see whether the problem is with the account or the system. If the latter, try AUTOGEN. Regards, Christoph Gartmann -- Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 Immunbiologie Postfach 1169 Internet: gartmann@immunbio dot mpg dot de D-79011 Freiburg, Germany http://www.immunbio.mpg.de/home/menue.html ------------------------------ Date: Thu, 27 Sep 2007 12:55:24 -0400 From: "Jilly" Subject: Re: Problem running sysman Message-ID: <46fbdfef$0$24889$ec3e2dad@news.usenetmonster.com> "Big John" wrote in message news:1190899823.673579.167680@y42g2000hsy.googlegroups.com... > Hi. I wonder if anyone can help me n this. > > On an alphaServer DS15 running OpenVMS V7.3-2, I cannot run any > commands at all on another node via SYMAN. > > BEP1->mc sysman > SYSMAN> set env /node=bep2 > %SYSMAN-I-ENV, current command environment: > Individual nodes: BEP2 > Username SEMA_INS will be used on nonlocal nodes > > SYSMAN> do show time > %SYSMAN-I-OUTPUT, command execution on node BEP2 > %SYSMAN-I-NODERR, error returned from node BEP2 > -LIB-F-INSVIRMEM, insufficient virtual memory > SYSMAN> Exit > > I have looked at the help for this message,and tried thumping up > pgflquo to enormously inflated value. Before I suggest the customer go > out and buy more memory, has anybody any bright ideas on how to narrow > down the cause of this problem. (Is it with the user, the page files, > or the physical memory, or is there any known problems with running > sysman on this venerable old version of VMS? > > TIA for any bright ideas - John > You may need to edit the SYS$STARTUP:VMS$BASEENVIRON-050_SMISERVER.COM to give it more pagefile quota. Off hand I don't remember how you rundown the SMISERVER but if you manage to then restart it with $ @SYS$SYSTEM:STARTUP SMI ------------------------------ Date: Thu, 27 Sep 2007 13:34:34 -0400 From: JF Mezei Subject: Re: Problem running sysman Message-ID: Big John wrote: > SYSMAN> do show time > %SYSMAN-I-OUTPUT, command execution on node BEP2 > %SYSMAN-I-NODERR, error returned from node BEP2 > -LIB-F-INSVIRMEM, insufficient virtual memory > SYSMAN> Exit Is BEP2 a VAX ? On VAX, there is a SYSGEN parameter VIRTUALPAGECNT which limits the virtual address space for any process. This was also on ALpha until 7.0 Note that the error seems to be returned from the remote node (BEP2), so this is where you should be concentrating. If you have a terminal window/session on BEP2, I would do a SHOW PROC/CONT on the SMISERVER process, and once it has started, press the letter Q . This will switch the display to show you the process quotas for SMISERVER and you might see something odd there. (The "Q" trick doesn't work on VAX 7.3) Another thing you can try is to write a small command procedure which will take a lot of time to complete. (some long loop for instance). Then try to execute it (DO @myproc.com ) and watch carefully to see if the error message is returned immediatly, or if it takes time to come back. The fact that the error message is from LIB-F-INSVIRMEM would lead me to uninformed speculation that in your case, it is the SHOW command which is failing as opposed to process creation issues. (LIB instead of SYS for the facility). Another thing, if you can make that command procedure run for a long time in some infinite loop, you could then a SHOW PROC/CONT or SHOW PROC/ALL on the created SMI process to see what sort of quotas it has been given and how much its "virtual pages" is at and its working set size. It might get its quotas from the default PQL parameters since it is a detached process in which case, the PQL_DPGFLQUOTA and PQL_MPGFLQUOTA (first is the default value given to process, second is the minimum value any process gets even if the parent asks for a lower value). ------------------------------ Date: Thu, 27 Sep 2007 22:10:30 +0930 From: Mark Daniel Subject: Re: Soymail not working with WASD Message-ID: <13fn97eqsasggae@corp.supernews.com> ultradwc@gmail.com wrote: > followed Alans book ... SSL webserver is running and serving Excellent. Just as well someone documented WASD adequately! http://wasd.vsm.com.au/ht_root/doc/misc/resources.html > static pages, but the moment the /soymail switch is added > to the URL, only the soymail page under construction comes > up ... > > clicking on /ht_root/src/soymail/ works Assuming this means that it gives a directory listing of the content - that establishes that the soyMAIL kit has been installed in the location suggested for WASD. This makes it more straight-forward. > but /cgi-bin/soymail/~ does not, gets err 404 http://wasd.vsm.com.au/cgi-bin/does_not_exist http://wasd.vsm.com.au/httpd/-/status4xx.html http://wasd.vsm.com.au/httpd/-/status4xx.html#404 "The server has not found anything matching the Request-URI." The path /cgi-bin/ is customarily used by WASD (and other server environments) to access scripts. It's only a convention though and relies on mappings (between the logical web-space of the URL and the actual 'executable' located somewhere in the file-system) in a server's configuration. (Of course you can have 'scripts' in any and multiple locations.) http://wasd.vsm.com.au/ht_root/doc/htd/htd_1400.html With WASD this configuration resides in the file located by the logical name HTTPD$MAP. The rule used by WASD to indicate a directory of executable content is 'exec' (execute). http://wasd.vsm.com.au/ht_root/doc/htd/htd_1400.html#hd_map_rule_exec_script exec This is interpreted as URIs beginning with a string matching that of being transformed into file specifications beginning . Hence the mapping rule exec /cgi-bin/* /cgi-bin/* transforms the URI /cgi-bin/soymail into the file-system specification cgi-bin:[000000]soymail (not case-sensitive and only by connivance the same strings). WASD always assumes that the leading path /part/ is a concealed device logical name and manipulates an MFD component in and out as required. http://wasd.vsm.com.au/ht_root/doc/htd/htd_1400.html#hd_map_vms Hence on a WASD system there will be a logical name CGI-BIN available into the file system $ show log /full cgi-bin "CGI-BIN" [exec] = "$1$DKA0:[HT_ROOT.CGI-BIN.]" [concealed] (LNM$SYSTEM_TABLE) = "$1$DKA0:[HT_ROOT.AXP-BIN.]" [concealed] and you can therefore $ dir cgi-bin:[000000]soymail Directory CGI-BIN:[000000] SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 Total of 1 file, 682KB I'd suggest the 404 indicates there is no SOYMAIL.EXE located in CGI-BIN:[000000] where it is being told to activate it from. The instructions http://wasd.vsm.com.au/ht_root/src/soymail/doc/soymail_admin.html#2.5.WASD|outline suggest $ @INSTALL INSTALL WASD copying the SOYMAIL.EXE and SOYMAIL_STARTUP.COM to the WASD suggested locations (but of course could do the same thing manually). > HTTPD$AUTH.CONF contains > > ["Default"=REALM] > /cgi-bin/soymail/~* r+w I will concede WASD authentication is perhaps the most convoluted and difficult part of it's configuration. (I think it's also fairly versatile but that's the two-edged sword.) If you are using /SYSUAF on the startup http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy then you are enabling the VMS realm of authentication http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file and the HTTPD$AUTH configuration rules should be more like ["soyMAIL Access"=VMS] /cgi-bin/soymail/~* r+w with the important change '=VMS' telling the server to authenticate against the SYSUAF (for historical reasons it's not '=SYSUAF' though I might do it that way today - hindsight is the best foresight) The content between the quotes is just what's displayed in the browser username/password dialog. After an edit of the HTTPD$MAP or HTTPD$AUTH you need to reload the new rules using $ HTTPD/DO=MAP or $ HTTPD/DO=AUTH respectively. Changes to other configuration files require a $ HTTPD/DO=RESTART. > HTTPD$MAP.CONF contains > > pass /soymail/-/* /ht_root/src/soymail/* This allows soyMAIL to access [.THEME], [.LANG], etc., using the URI beginning /soymail/-/ > set /cgi-bin/soymail/~* map=once This saves a little server processing. > the WASD server startup command is > > $ DEF/SYS HTTPD$SERVER "SYSUAF=SSL" This should be $ DEFINE /SYSTEM HTTPD$STARTUP_SERVER "/SYSUAF=SSL" Note that this is different again to your subsequent correction. This qualifier is instructing the server to provide authentication using the SYSUAF but only when the request is via SSL. http://wasd.vsm.com.au/ht_root/doc/htd/htd_0500.html#hd_account_support_files > $ @DSA0:[HT_ROOT.LOCAL]STARTUP WASD_SSL=1 Start the server SSL image. > soymail.conf contains > > [private-access] > username/*/USERNAME It seems you are again taking the text too literally. The relevant section of the documentation http://wasd.vsm.com.au/ht_root/src/soymail/doc/soymail_admin.html#3.4.[private-access]|outline provides a description of a directive where the authenticated username can be mapped into an actual VMS username (if required). Where there is a one-to-one correspondence (as there would be with a SYSUAF-authenticated username) the directive should be [private-access] */*/* > can the owner of soymail or anyone else familiar with You can use my name Bob. It's not that of some ancient deity which must remain unspoken lest unwittingly be summoned. > WASD give some insight as to why following the book > and docs failed and why a site under work page shows > instead of authentication box then mail? > > PS I can redirect purveyor to run the WASD built soymail > .exe and it works, so the compile is fine ... I would strongly recommend the WATCH facility http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html to assist in a general understanding of WASD behaviour and then specifically for trouble-shooting configuration issues. You can permanently (recommended) configure it (and all the WASD reporting facilities) http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html using something like ["WASD Admin"=VMS] /httpd/-/admin/* r+w or you can actually use it *before configuration* using the WASD skeleton-key http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config -- Sonja: Violence is justified in the service of mankind. Boris: Who said that? Sonja: Attila the Hun. Boris: You're quoting a Hun to me? [Woody Allen; Love and Death] ------------------------------ Date: Thu, 27 Sep 2007 06:34:58 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190900098.033097.190200@n39g2000hsh.googlegroups.com> On Sep 27, 8:40 am, Mark Daniel wrote: HTTPD$MAP contains exec /cgi-bin/* /cgi-bin/* $ show log /full cgi-bin "CGI-BIN" [exec] = "$1$DKA0:[HT_ROOT.CGI-BIN.]" [concealed] (LNM$SYSTEM_TABLE) = "$1$DKA0:[HT_ROOT.AXP-BIN.]" [concealed] correct ... > and you can therefore $ dir cgi-bin:[000000]soymail correct ... I'd suggest the 404 indicates there is no SOYMAIL.EXE located in CGI-BIN:[000000] where it is being told to activate it from. The instructions well. it is actually in the [.axp-bin] directory because that is where $ @INSTALL INSTALL WASD put it ... the installation went fine and soymail.exe exists because $ dir cgi-bin:[000000]soymail shows it there, and purveyor can run it ... the startup_server is there with the /sysuaf=ssl (another type error) after applying the rule ["soymail_access"=VMS] I now get the login box, but it fails and does not log me in ... remember, for private access I have bob/*/BOB and the login still fails (Iam keying in my vms password correctly) also, how do you get soymail to come up directly without first getting the construction site box? but more importantly, the login is failing ... everything you described above is how soymail and I configured the package ... the only change I had to make was the =VMS rule ... any other suggestions? ------------------------------ Date: Thu, 27 Sep 2007 06:43:56 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190900636.157938.126370@w3g2000hsg.googlegroups.com> On Sep 27, 9:34 am, ultra...@gmail.com wrote: > On Sep 27, 8:40 am, Mark Daniel wrote: > > HTTPD$MAP contains exec /cgi-bin/* /cgi-bin/* > > $ show log /full cgi-bin > "CGI-BIN" [exec] = "$1$DKA0:[HT_ROOT.CGI-BIN.]" [concealed] > (LNM$SYSTEM_TABLE) > = "$1$DKA0:[HT_ROOT.AXP-BIN.]" [concealed] > > correct ... > > > and you can therefore $ dir cgi-bin:[000000]soymail > > correct ... > > I'd suggest the 404 indicates there is no SOYMAIL.EXE located in > CGI-BIN:[000000] where it is being told to activate it from. The > instructions > > well. it is actually in the [.axp-bin] directory because that > is where > > $ @INSTALL INSTALL WASD > > put it ... > > the installation went fine and soymail.exe exists because > > $ dir cgi-bin:[000000]soymail > > shows it there, and purveyor can run it ... > > the startup_server is there with the /sysuaf=ssl (another type error) > > after applying the rule ["soymail_access"=VMS] I now get the > login box, but it fails and does not log me in ... remember, for > private access I have > > bob/*/BOB > > and the login still fails (Iam keying in my vms password correctly) > > also, how do you get soymail to come up directly without first > getting the construction site box? > > but more importantly, the login is failing ... > > everything you described above is how soymail and I configured > the package ... the only change I had to make was the =VMS > rule ... > > any other suggestions? just to expand on this, I am running this now on port 8443 but when working I will disable port 443 on purveyor and run WASD ssl site on port 443 ... I am going to use your [ht_root.axp-bin] because I only need to put the soymail exe and some pmdf exes there ... you soymail install routine put soymail_startup.com in the [HT_ROOT.STARTUP] dir, but I put the soymail.conf and all the other coms and confs in the [HT_ROOT.LOCAL] dir ... the soymail and httpd logicals all look correct ... I also let the package set up security which I assume will be adequate ... ------------------------------ Date: Thu, 27 Sep 2007 15:27:57 GMT From: VAXman- @SendSpamHere.ORG Subject: Time to PAK it in? Message-ID: <1_PKi.773$JD3.524@newsfe12.lga> DSPP is not providing the PAK for OpenVMS on Itanium. I just downloaded a new set of PAKs and there's no PAK for the OS. Does anyone want a 2U rack mounted space heater, or should I just put Linux on it and abandon OpenVMS altogether? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 27 Sep 2007 15:41:51 GMT From: "Tim E. Sneddon" Subject: Re: Time to PAK it in? Message-ID: <3bQKi.2825$H22.1583@news-server.bigpond.net.au> VAXman- @SendSpamHere.ORG wrote: > DSPP is not providing the PAK for OpenVMS on Itanium. I just downloaded a > new set of PAKs and there's no PAK for the OS. Does anyone want a 2U rack > mounted space heater, or should I just put Linux on it and abandon OpenVMS > altogether? > Our set of DSPP PAKs has one called OPENVMS-I64-MCOE. AFAIK this is the PAK for the Mission Critical Operating Environment which is equivalent to OPENVMS-ALPHA + OPENVMS-ALPHA-USER + some other things like volume shadowing. Regards, Tim. ------------------------------ Date: Thu, 27 Sep 2007 10:52:29 -0500 From: Ron Johnson Subject: Re: Time to PAK it in? Message-ID: <2lQKi.333384$dA7.104100@newsfe16.lga> On 09/27/07 10:27, VAXman- @SendSpamHere.ORG wrote: > DSPP is not providing the PAK for OpenVMS on Itanium. I just downloaded a > new set of PAKs and there's no PAK for the OS. Does anyone want a 2U rack > mounted space heater, or should I just put Linux on it and abandon OpenVMS > altogether? But you'd have to apply-20-25 patches per month!!!!! -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 27 Sep 2007 16:21:22 -0000 From: IanMiller Subject: Re: Time to PAK it in? Message-ID: <1190910082.068629.10680@g4g2000hsf.googlegroups.com> There was some DSPP programme that provided paks for VMS I64. Perhaps you have to look on another part of that web site? ------------------------------ Date: Thu, 27 Sep 2007 16:30:22 -0000 From: IanMiller Subject: Re: Time to PAK it in? Message-ID: <1190910622.220380.12960@n39g2000hsh.googlegroups.com> Try this link OpenVMS for HP Integrity servers (Itanium®-based pilot program) http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=4408d7c682f02110d7c682f02110275d6e10RCRD ------------------------------ Date: Thu, 27 Sep 2007 16:36:30 -0000 From: IanMiller Subject: Re: Time to PAK it in? Message-ID: <1190910990.050042.49450@n39g2000hsh.googlegroups.com> I've just checked and now see what you mean. The DSPP-I64-NOV08-1.TXT does not have a FOE/EOE/MOE pak in it. ------------------------------ Date: Thu, 27 Sep 2007 16:39:00 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Time to PAK it in? Message-ID: In article <1190910990.050042.49450@n39g2000hsh.googlegroups.com>, IanMiller writes: > > >I've just checked and now see what you mean. The DSPP-I64-NOV08-1.TXT >does not have a FOE/EOE/MOE pak in it. BINGO! -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 27 Sep 2007 10:33:47 -0700 From: bslook@csc.com Subject: Tomcat OpenVMS file system access problem Message-ID: <1190914427.829138.17230@w3g2000hsg.googlegroups.com> I've had HP's packaging of Tomcat 5.5 installed on and OpenVMS 7.3.2 environment and am having trouble access the files system unless the APACHE$WWW account owns the file. I've had all the ACLS check and they appear to be correct. The only way that my Java program can access the file is if the directory is granted World access. I am working this through with the clients SA but he does not know or understand Java. HP support has indicated that java access the file through some CRTL "stat()" function which will not honor the ACL. Our APACHE$WWW login.com contains define decc$acl_access_check TRUE yet it still does not honor the ACL. I am told that there is no wat around this but I am not experienced in OPENVMS. Does any one have any ideas? ------------------------------ Date: Thu, 27 Sep 2007 07:19:14 -0700 From: etmsreec@yahoo.co.uk Subject: Re: username/nocom vs. sylogin Message-ID: <1190902754.208625.45420@w3g2000hsg.googlegroups.com> On 26 Sep, 23:27, Pierre wrote: > from the top of my head, logging with username/nocom as username does > not prevent the sylogin to be executed. is this documented somewhere ? > > TIA, > Pierre I'm not sure where it's documented, but I have seen it. The documentation goes something along the lines of the /NOCOMMAND stops the user running their own login.com. There is no way to stop the user running SYLOGIN.COM, the command procedure that all jobs across the whole system run when they are created. Steve ------------------------------ Date: Thu, 27 Sep 2007 07:46:50 -0700 From: AEF Subject: Re: username/nocom vs. sylogin Message-ID: <1190904410.093516.17000@n39g2000hsh.googlegroups.com> On Sep 26, 6:27 pm, Pierre wrote: > from the top of my head, logging with username/nocom as username does > not prevent the sylogin to be executed. is this documented somewhere ? > > TIA, > Pierre LOGIN /COMMAND /COMMAND[=filespec] (default) /NOCOMMAND Controls whether to execute your default login command procedure when you log in. Use the /COMMAND qualifier to specify the name of an alternate login command procedure. If you specify a file name without a file type, the default file type .COM is used. If you specify the /COMMAND qualifier and omit the file specification, your default login command procedure is executed. Use the /NOCOMMAND qualifier if you do not want your default login command procedure to be executed. LOGIN Subtopic? I don't see any mention of SYLOGIN.COM so I see no reason to assume it would be skipped. The only way I know to skip it is to log in on a minimal boot which makes sense in case that's what's causing the problem that led you to do the minimal boot in the first place. AEF ------------------------------ Date: Thu, 27 Sep 2007 13:43:23 GMT From: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= Subject: Who is the Dead-eater ?? Message-ID: <%rOKi.9816$ZA.6391@newsb.telia.net> HI. While trying to boot a XP900 I happend to hit and got the printout below. (I've removed a few cols to prevent line breaks...) So, does the "dead_beef" has anything to do with the fact that the boot hangs? Seems to be my DKA0 that is the dead beef, right ? Regards, Jan-Erik. >>>b (boot dka0.0.0.16.0 -flags A) ID PCB Program State -------- -------- ---------- ------------------------ 00000360 1ff62020 b waiting on tqe d9088 0000035f 1ff58020 pka0_poll waiting on pkq_owner 00000313 001fb680 shell waiting on 1FF62020 00000014 001fa460 mscp_poll waiting on tqe ea164 00000012 001f1bc0 rx_ewb0 waiting on rx_isr_ewb0 00000010 001e74c0 rx_ewa0 waiting on rx_isr_ewa0 00000009 001df240 shell_0 ready 00000008 001de020 dup_poll waiting on tqe c1adc 00000007 0003a340 t_control running 00000006 00034520 srom_poll ready 00000004 00030460 timer waiting on timer 00000003 0002f240 poll ready 00000002 0002e020 dead_eater waiting on dead_beef 00000001 001be790 40410 idle ready ------------------------------ Date: Thu, 27 Sep 2007 07:22:24 -0700 From: "Bart.Zorn@gmail.com" Subject: Re: Who is the Dead-eater ?? Message-ID: <1190902944.446371.38150@50g2000hsm.googlegroups.com> Well, if you hit CTRL/T at the dead-sargent prompt, you get a similar display. So it seems that that is no indication that your DKA0 is "dead_beef" (nor the dead-sargent ;-). It still looks a bit creepy, though! Bart Zorn On Sep 27, 3:43 pm, Jan-Erik S=F6derholm wrote: > HI. > > While trying to boot a XP900 I happend to > hit and got the printout below. > (I've removed a few cols to prevent line > breaks...) > > So, does the "dead_beef" has anything to do > with the fact that the boot hangs? Seems to > be my DKA0 that is the dead beef, right ? > > Regards, > Jan-Erik. > > >>>b > (boot dka0.0.0.16.0 -flags A) > > ID PCB Program State > -------- -------- ---------- ------------------------ > 00000360 1ff62020 b waiting on tqe d9088 > 0000035f 1ff58020 pka0_poll waiting on pkq_owner > 00000313 001fb680 shell waiting on 1FF62020 > 00000014 001fa460 mscp_poll waiting on tqe ea164 > 00000012 001f1bc0 rx_ewb0 waiting on rx_isr_ewb0 > 00000010 001e74c0 rx_ewa0 waiting on rx_isr_ewa0 > 00000009 001df240 shell_0 ready > 00000008 001de020 dup_poll waiting on tqe c1adc > 00000007 0003a340 t_control running > 00000006 00034520 srom_poll ready > 00000004 00030460 timer waiting on timer > 00000003 0002f240 poll ready > 00000002 0002e020 dead_eater waiting on dead_beef > 00000001 001be790 40410 idle ready ------------------------------ Date: Thu, 27 Sep 2007 07:46:39 -0700 From: "johnhreinhardt@yahoo.com" Subject: Re: Who is the Dead-eater ?? Message-ID: <1190904399.430319.133950@g4g2000hsf.googlegroups.com> On Sep 27, 9:43 am, Jan-Erik S=F6derholm wrote: > HI. > > While trying to boot a XP900 I happend to > hit and got the printout below. > (I've removed a few cols to prevent line > breaks...) > > So, does the "dead_beef" has anything to do > with the fact that the boot hangs? Seems to > be my DKA0 that is the dead beef, right ? > > Regards, > Jan-Erik. > > >>>b > (boot dka0.0.0.16.0 -flags A) > > ID PCB Program State > -------- -------- ---------- ------------------------ > 00000360 1ff62020 b waiting on tqe d9088 > 0000035f 1ff58020 pka0_poll waiting on pkq_owner > 00000313 001fb680 shell waiting on 1FF62020 > 00000014 001fa460 mscp_poll waiting on tqe ea164 > 00000012 001f1bc0 rx_ewb0 waiting on rx_isr_ewb0 > 00000010 001e74c0 rx_ewa0 waiting on rx_isr_ewa0 > 00000009 001df240 shell_0 ready > 00000008 001de020 dup_poll waiting on tqe c1adc > 00000007 0003a340 t_control running > 00000006 00034520 srom_poll ready > 00000004 00030460 timer waiting on timer > 00000003 0002f240 poll ready > 00000002 0002e020 dead_eater waiting on dead_beef > 00000001 001be790 40410 idle ready Since the SRM console is sorta, kinda based on a U*ix kernal, I think it's the process that looks for and destroys any dead or zombie like processes. John H. Reinhardt ------------------------------ Date: Thu, 27 Sep 2007 14:54:49 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Who is the Dead-eater ?? Message-ID: =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: >HI. >While trying to boot a XP900 I happend to >hit and got the printout below. >(I've removed a few cols to prevent line >breaks...) >So, does the "dead_beef" has anything to do >with the fact that the boot hangs? Seems to >be my DKA0 that is the dead beef, right ? I don't remember exactly what it is, but "dead_eater" waiting on "dead_beef" is always there as part of the SRM console. It's kind of like a null process or something (the SRM console is some sort of mini-UNIX). It may be a memory exercizer or memory manager, since DEADBEEF is a valid 64 bit hexadecimal number, often used to initialize memory so that memory unchanged since initialization sticks out like a sore thumb. ------------------------------ Date: Thu, 27 Sep 2007 10:50:34 -0500 From: Ron Johnson Subject: Re: Who is the Dead-eater ?? Message-ID: On 09/27/07 09:54, Michael Moroney wrote: > =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > >> HI. > >> While trying to boot a XP900 I happend to >> hit and got the printout below. >> (I've removed a few cols to prevent line >> breaks...) > >> So, does the "dead_beef" has anything to do >> with the fact that the boot hangs? Seems to >> be my DKA0 that is the dead beef, right ? > > I don't remember exactly what it is, but "dead_eater" waiting on > "dead_beef" is always there as part of the SRM console. It's kind of like > a null process or something (the SRM console is some sort of mini-UNIX). > It may be a memory exercizer or memory manager, since DEADBEEF is a valid > 64 bit hexadecimal number, often used to initialize memory so that memory > unchanged since initialization sticks out like a sore thumb. Actually 32-bit. Of course, DEADBEEFDEADBEEF is 64-bit... -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 27 Sep 2007 13:37:58 -0400 From: JF Mezei Subject: Re: Who is the Dead-eater ?? Message-ID: <14e09$46fbea7b$cef8887a$18378@TEKSAVVY.COM> Michael Moroney wrote: > I don't remember exactly what it is, but "dead_eater" waiting on > "dead_beef" is always there as part of the SRM console. Shouldn't it have been the eater waiting for the dead-mother ? ------------------------------ Date: Thu, 27 Sep 2007 14:04:18 +0200 From: "P. Sture" Subject: Re: wierd backup behavior Message-ID: In article <1190822080.542181.314400@o80g2000hse.googlegroups.com>, jhjr4381 wrote: > I have a problem with my backups that I can't quite nail down. We have > a two server cluster with one Alpha running VMS 6.2-1h3 and a VAX > running VMS 6.2. > I have a full backup com file executing on the Alpha system which does > an image backup of all the disks (5 drive on the Alpha, 3 on the Vax). > There are very few changes /updates made on these systems as they > pretty much just store code. These are done on a DLT drive, and it > usually only takes one tape for the whole backup. You may be seeing a manifisteation of a change in incremental BACKUP behaviour with V6.2: The following extract from an old VMS FAQ may help: (original at http://www.faqs.org/faqs/dec-faq/vms/part2/ ) ---- MGMT35. Why isn't BACKUP/SINCE=BACKUP working? If you are seeing more files backed up than previously, you are seeing the result of a change that was made to ensure BACKUP can perform an incrementation restoration of the files. In particular, if a directory file modification date changes, all files underneath it are included in the BACKUP, in order to permit incremental restoration should a directory file get renamed. See the OpenVMS V6.2 release notes for additional details. ---- The workaround after upgrading to V6.2 was to do a BACKUP/INAGE/RECORD on the affected disks, to set the backup dates on all the directories correctly. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Thu, 27 Sep 2007 09:29:17 -0400 From: norm.raphael@metso.com Subject: Re: wierd backup behavior Message-ID: This is a multipart message in MIME format. --=_alternative 004A177285257363_= Content-Type: text/plain; charset="US-ASCII" "P. Sture" wrote on 09/27/2007 08:04:18 AM: > In article <1190822080.542181.314400@o80g2000hse.googlegroups.com>, > jhjr4381 wrote: > > > I have a problem with my backups that I can't quite nail down. We have > > a two server cluster with one Alpha running VMS 6.2-1h3 and a VAX > > running VMS 6.2. > > I have a full backup com file executing on the Alpha system which does > > an image backup of all the disks (5 drive on the Alpha, 3 on the Vax). > > There are very few changes /updates made on these systems as they > > pretty much just store code. These are done on a DLT drive, and it > > usually only takes one tape for the whole backup. > > You may be seeing a manifisteation of a change in incremental BACKUP > behaviour with V6.2: > ..but he is doing FULL backups (BACKUP/IMAGE, not BACKUP/SINCE=) so he should not be experiencing this particular circumstance. > > The following extract from an old VMS FAQ may help: > (original at http://www.faqs.org/faqs/dec-faq/vms/part2/ ) > > ---- > MGMT35. Why isn't BACKUP/SINCE=BACKUP working? > > If you are seeing more files backed up than previously, you are seeing > the result of a change that was made to ensure BACKUP can perform an > incrementation restoration of the files. In particular, if a directory > file modification date changes, all files underneath it are included in > the BACKUP, in order to permit incremental restoration should a > directory file get renamed. > > > > See the OpenVMS V6.2 release notes for additional details. > > ---- > > The workaround after upgrading to V6.2 was to do a BACKUP/INAGE/RECORD > on the affected disks, to set the backup dates on all the directories > correctly. > > -- > Paul Sture > > Sue's OpenVMS bookmarks: > http://eisner.encompasserve.org/~sture/ovms-bookmarks.html --=_alternative 004A177285257363_= Content-Type: text/html; charset="US-ASCII"



"P. Sture" <paul.sture.nospam@hispeed.ch> wrote on 09/27/2007 08:04:18 AM:

> In article <1190822080.542181.314400@o80g2000hse.googlegroups.com>,
>  jhjr4381 <daniel.horgan@infor.com> wrote:
>
> > I have a problem with my backups that I can't quite nail down. We have
> > a two server cluster with one Alpha running VMS 6.2-1h3 and a VAX
> > running VMS 6.2.
> > I have a full backup com file executing on the Alpha system which does
> > an image backup of all the disks (5 drive on the Alpha, 3 on the Vax).
> > There are very few changes /updates made on these systems as they
> > pretty much just store code. These are done on a DLT drive, and it
> > usually only takes one tape for the whole backup.
>
> You may be seeing a manifisteation of a change in incremental BACKUP
> behaviour with V6.2:
>

...but he is doing FULL backups (BACKUP/IMAGE, not BACKUP/SINCE=) so he
should not be experiencing this particular circumstance.

>
> The following extract from an old VMS FAQ may help:
> (original at http://www.faqs.org/faqs/dec-faq/vms/part2/ )
>
> ----
> MGMT35. Why isn't BACKUP/SINCE=BACKUP working?
>
> If you are seeing more files backed up than previously, you are seeing
> the result of a change that was made to ensure BACKUP can perform an
> incrementation restoration of the files.  In particular, if a directory
> file modification date changes, all files underneath it are included in
> the BACKUP, in order to permit incremental restoration should a
> directory file get renamed.
>
> <snip>
>
>   See the OpenVMS V6.2 release notes for additional details.
>
> ----
>
> The workaround after upgrading to V6.2 was to do a BACKUP/INAGE/RECORD
> on the affected disks, to set the backup dates on all the directories
> correctly.
>
> --
> Paul Sture
>
> Sue's OpenVMS bookmarks:
> http://eisner.encompasserve.org/~sture/ovms-bookmarks.html
--=_alternative 004A177285257363_=-- ------------------------------ End of INFO-VAX 2007.528 ************************