INFO-VAX Fri, 28 Sep 2007 Volume 2007 : Issue 529 Contents: Re: Article of Interest. Re: Article of Interest. RE: Article of Interest. Re: Article of Interest. Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Potential eBay bargain: "New" 1GB SCSI disks Re: Problem running sysman Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD Re: Soymail not working with WASD 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: wierd backup behavior Re: wierd backup behavior Re: wierd backup behavior Re: wierd backup behavior Re: wierd backup behavior ---------------------------------------------------------------------- Date: 27 Sep 2007 15:51:31 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Article of Interest. Message-ID: In article , VAXman- @SendSpamHere.ORG writes: > > http://www.bbspot.com/News/2007/09/microsoft-reveals-windows-vista-sp1-will-install-xp.html LOL MS-DOS 1.0 would be better. No networking support for those damn virii to come in through. 8-( ------------------------------ Date: Thu, 27 Sep 2007 19:27:38 -0500 From: Ron Johnson Subject: Re: Article of Interest. Message-ID: <%TXKi.52$JF5.10@newsfe19.lga> On 09/27/07 15:51, Bob Koehler wrote: > In article , VAXman- > @SendSpamHere.ORG writes: >> http://www.bbspot.com/News/2007/09/microsoft-reveals-windows-vista-sp1-will-install-xp.html >> > > LOL > > MS-DOS 1.0 would be better. No networking support for those damn > virii to come in through. Sneakernet. That's how the first PC/Mac viruses were spread. > 8-( > -- 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: Fri, 28 Sep 2007 04:13:40 +0000 From: "Main, Kerry" Subject: RE: Article of Interest. Message-ID: > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: September 27, 2007 1:14 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Article of Interest. > snip.. > 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. > Snip.. In 1995, there were 5-20 security patches per month with Windows. Fast forward to 2007. There are 5-20 security patches per month with Window= s. Help me understand what is different today. Add to all this - the sophistication of the bad guys has also increased exp= onentially. The bar is always getting raised on both sides. Help me understand what is different today. 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: Fri, 28 Sep 2007 00:41:01 -0400 From: JF Mezei Subject: Re: Article of Interest. Message-ID: Main, Kerry wrote: > In 1995, there were 5-20 security patches per month with Windows. > Help me understand what is different today. Because you live in a VMS universe where marketing and image are not permitted, you may not understand this. Why did people buy XP and why will they buy Vista ? Because of promises of the new product being safer, having better firewall, better virus protection, fewer bugs, fewer security problems. The fact that in reality, there may not be any difference is totally irrelevant. By the time companies realise that Vista has as many patches as XP, they will have already purchase and installed Vista. All Microsoft needs is to use it marketing savvy to convince people that the next version of Windows will be better. They buy it, Microsoft profits from it. And since patches and bugs continue, it allows Microsoft to continue to convince people to buy new version of its software which always promise to have fewer bugs and vulnerabilities etc. ------------------------------ Date: Thu, 27 Sep 2007 13:56:07 -0700 From: mjjerabek Subject: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: <1190926567.435722.56090@d55g2000hsg.googlegroups.com> I have been given the task of determining whether I should port/ rewrite a rather large HMI program from x-windows and 'C' to java. I went through an install of java 1.5 on an rx2620 duo core with 3gb ram, a radeon video card, mouse, keyboard, and OpenVMS 8.3. I followed the patching and tuning recommendation from the java release notes and from the java$check_environment.com DCL file. I then started running the jdk demo applications to get an idea of java performance versus the same applications running on an 2.8ghz P4 XP PC with 256mb of ram. The performance of these java apps on the OpenVMS ia64 system was extremely poor as compared to a much slower PC running XP. I followed these tests up with a re-tune of the VMS authorize and sysgen parameters, taking these parameters from their recommended values to ridiculously large values (1gb wsquo, wsmax 1gb, everything big). The performance of these apps got better, but had lots of rough spots. For example, the java2d app has a tabbed dialog where each tab displayed different classes of graphics operations. When the app ran, the graphics operations ran OK, but when I tried to select a different dialog tab, it took 4 minutes 30 seconds (clock time) to switch dialog tabs and start the display of the new graphics operations. Once the tab was fully rendered, the new graphics operations ran at a reasonable speed. I tried to get help from HP by sending en email to java-bugs@hp.com and exchanged some email with an HP engineer. The engineer blamed the applications, and not java. I pointed out that these applications came with the JDK, but that made no difference. I also tried to use the java plugin with the CSWB/Mozilla. I tried to display and operator a web page with embedded java. In my case, it was an hp procurve managed switch management interface web page. These simple html/java pages hung after a few java apps were loaded and run. The HP engineer point to the procurve web page which was generated in 2000 and specified that only IE5 and the MSVM could be used to display the procure pages (lame excuse from HP). What I am looking for (I guess) is guidance from experienced people on how to get performance out of java under OpenVMS Ia64 and Alpha systems. I need access to better information than what HP chooses to provide. I could use the following: 1) VMS tuning advice for java. What are typical authorize and sysgen values for java usage. 2) More example applications to test with. My application will be a rather large app and the demo apps that come with the JDK are not. 3) Suggest some URL's, books, etc that will guide me. Also, anyone who is willing to describe their experience in using java with OpenVMS and have a conversation with me on or off-line, please ... All help will be appreciated and acknowledged. Mjjerabek ------------------------------ Date: Thu, 27 Sep 2007 20:58:36 -0700 From: David B Sneddon Subject: Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: <1190951916.879920.258930@w3g2000hsg.googlegroups.com> On Sep 27, 8:56 pm, mjjerabek wrote: > I have been given the task of determining whether I should port/ > rewrite a rather large HMI program from x-windows and 'C' to java. > [...snip...] > > Also, anyone who is willing to describe their experience in using java > with OpenVMS and have a conversation with me on or off-line, > please ... > > All help will be appreciated and acknowledged. > > Mjjerabek I have tried to use Java on VMS on several occassions and decided it just wasn't worth the effort. Performance is abyssmal (This on an Alpha with all the recommended settings etc.) Dave ------------------------------ Date: Fri, 28 Sep 2007 00:34:10 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Potential eBay bargain: "New" 1GB SCSI disks Message-ID: <07092800340995_20200293@antinode.org> All I know is what I read, but if you seek a "new" system disk for that old MicroVAX or VAXstation, this listing may be worth a look. http://cgi.ebay.com/_W0QQitemZ320163209601 "NEW IN WRAPPER seagate st31051n SCSI hard drive 1.05 gb" ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 27 Sep 2007 19:54:17 -0500 From: David J Dachtera Subject: Re: Problem running sysman Message-ID: <46FC50B9.1CB2867A@spam.comcast.net> Jilly wrote: > > "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. Here's how we fixed it, I believe at HP's suggestion: $ diff SYS$COMMON:[SYS$STARTUP]VMS$BASEENVIRON-050_SMISERVER.COM ************ File SYS$COMMON:[SYS$STARTUP]VMS$BASEENVIRON-050_SMISERVER.COM;3 27 /ast_limit=64 /buffer_limit=192000 /dump - 28 /enqueue_limit=100 /extent=2048 /file_limit=64 /io_buffered=32 - ****** File SYS$COMMON:[SYS$STARTUP]VMS$BASEENVIRON-050_SMISERVER.COM;2 27 /ast_limit=64 /buffer_limit=40960 /dump - 28 /enqueue_limit=100 /extent=2048 /file_limit=64 /io_buffered=32 - ************ Number of difference sections found: 1 Number of difference records found: 1 DIFFERENCES /IGNORE=()/MERGED=1- SYS$COMMON:[SYS$STARTUP]VMS$BASEENVIRON-050_SMISERVER.COM;3- SYS$COMMON:[SYS$STARTUP]VMS$BASEENVIRON-050_SMISERVER.COM;2 > Off hand I don't remember how you rundown the > SMISERVER $ STOP/ID=xxxxxxxx ...should do nicely. > but if you manage to then restart it with: > > $ @SYS$SYSTEM:STARTUP SMI -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Fri, 28 Sep 2007 03:50:55 +0930 From: Mark Daniel Subject: Re: Soymail not working with WASD Message-ID: <13fnt5nn6jh6ta1@corp.supernews.com> ultradwc@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 ... Excellent. A 404 can also indicate the server account does not have permission to access the file entry in the parent directory and therefore does not 'see' it during the directory search. With a script, such as soyMAIL, it can also indicate an error originating from within the script itself. For instance, soyMAIL refuses to access private VMS Mail unless the request provides an authenticated username. Though soyMAIL uses 403s (forbidden) to report such conditions. Once authentication is going I suspect we may be back to analysing the originally reported 404 error. > the installation went fine and soymail.exe exists because > > $ dir cgi-bin:[000000]soymail > > shows it there, and purveyor can run it ... It's interesting that the two server environments can access the same executable when the standard WASD security environment explicitly prohibits any account other than those holding a specific rights identifier. $ dir /sec cgi-bin:[000000]soymail.exe Directory CGI-BIN:[000000] SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 [SYSTEM] (RWED,RWED,,) (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) (IDENTIFIER=*,ACCESS=NONE) Total of 1 file, 682KB $ dir /sec ht_root:[000000]axp-bin.dir Directory HT_ROOT:[000000] AXP-BIN.DIR;1 9KB 21-OCT-2002 02:43:55.54 [SYSTEM] (RWED,RWED,,) (IDENTIFIER=WASD_HTTP_SERVER,ACCESS=EXECUTE) (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) (IDENTIFIER=*,ACCESS=NONE) (IDENTIFIER=WASD_HTTP_NOBODY,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE) (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE) (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) Total of 1 file, 9KB Have you granted either of the the above identifiers to the Purveyor account? If not I wonder how Purveyor is accessing CGI-BIN:[000000]SOYMAIL.EXE? Please provide the results to the above and following commands. $ 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] Then list the Purveyor CONFIGxx.DB directive(s) that map(s) Purveyor into the above CGI-BIN:[000000] directory. > 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 This is in the soyMAIL not WASD configuration. If the user authentication step by WASD fails then the request stops there. Well before attempting to activate the script itself. Now, this *is* the browser username/password dialog (just checking)? > and the login still fails (Iam keying in my vms password correctly) There are other characteristics of an account that WASD takes into consideration before granting access. http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_sysuaf For example; is the password expired? Any access time restrictions? Extended privileges? Which now that it is mentioned may be an issue with a BOB account (I would not be surprised if this account had additional privileges). As described above; by default WASD does not permit privileged accounts to be used for authentication. You can explicitly override that restriction using the startup /SYSUAF qualifier keyword RELAXED. http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy You are already using the SSL keyword. So you would need to modify your HTTPD$STARTUP_SERVER logical value to be "/SYSUAF=(SSL,RELAXED)" and then $ HTTPD/DO=RESTART However, *before* we do that let's use WATCH to determine *exactly* why it's failing. http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html WATCH is a tool that if it doesn't indicate exactly the reason for any given server behaviour usually provides a very good hint. Well past time it was utilised. As described in http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config we'll now activate it by you entering at the command-line $ HTTPD/DO=AUTH=SKELKEY=_ROBERT: (underscore is significant). Then access https://your.system.name/httpd/-/admin/ which should provide you with a browser username/password dialog box requesting authentication for "SKELKEY". Enter _ROBERT (underscore is significant) and the password string. You should now have the Server Administration menu http://wasd.vsm.com.au/ht_root/doc/htd/admin.gif Access the [WATCH] item in the bottom right and in that menu, in addition to the pre-checked items, check [x]Authorization. Now you need a *completely separate* browser (*not* another window or tab on the current browser). So if you are using Mozilla then bring up Firefox or Opera or even (shudder) MSIE. If using (greater shudder) MSIE then bring up Mozilla, Firefox or Opera (etc). Or if only the one browser is available then on a second machine bring up a browser. Now in the WATCH Report window hit the [WATCH] button. In the second browser access https://your.server.name/cgi-bin/soymail/~ A report page should begin to be generated. The [x]Authorization checkbox should produce output specifically related to authentication/authorization. My development system, set up specifically to replicate your suspected problem, shows output including (my news agent, VMS Mozilla, will munge this horribly) |03:04:30.83 AUTH 1667 0001 AUTHORIZE AUTHENTICATE user:system realm:VMS| |03:04:30.85 AUTHACME 0349 0001 AUTHORIZE ACME doi:"VMS" agent:"VMS" mapped:"SYSTEM" %X074A8001 %ACME-S-NORMAL, normal successful completion| |03:04:30.86 AUTHVMS 0353 0001 AUTHORIZE GETUAI "SYSTEM" %X00000001 %SYSTEM-S-NORMAL, normal successful completion| expire:(none) pwd:20-MAY-2007:11:20(730AFA6856AB92AE) pwd2:(none)(0000000000000000) life:180-00:00 flags:00B9D40C priv:<63-32>FFFFFFFF<31-00>FFFFFFFF prime:00000060 netp:000000 nets:000000 remp:000000 rems:000000 |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| |03:04:30.86 AUTH 2316 0001 AUTHORIZE CHECK realm %X0FFFFF5A DENIED_BY_LOGIN| |03:04:30.87 ERROR 1072 0001 RESPONSE AUTH:3029 (detailed) 401(401) "Authentication failed."| The significant report item in this example is |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| If it shows this then it's the issue described above and you need to use the RELAXED keyword with the /SYSUAF startup qualifier. If it's something else then include the relevant section in your next post. Assuming it is the above 'privileges' issue then it's best you disable skeleton-key authorization by HTTPD/DO=AUTH=SKELKEY=0 before making any changes or restarts (you can always reenable it if necessary). Again assuming the /SYSUAF=(SSL,RELAXED) allows you to authenticate and you have also included the previously suggested ["WASD Admin"=VMS] /httpd/-/admin/* r+w,~bob you won't need to go through the separate browser exercise again, you'll just access /httpd/-/admin/ and provide your VMS password if required and access the Server Administration items and WATCH in particular whenever your want/need. Note I have now added a username restriction to the above authorization rule (the '~bob'). See section "Access Restriction Keywords" in http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file You don't want just any old VMS account accessing the above resources! > also, how do you get soymail to come up directly without first > getting the construction site box? I am unclear what is meant by '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? Most definitely - WATCH, WATCH, WATCH! -- Sonja: Judgment of any system, or a priori relationship or phenomenon exists in an irrational, or metaphysical, or at least epistemological contradiction to an abstract empirical concept such as being, or to be, or to occur in the thing itself, or of the thing itself. Boris: Yes, I've said that many times. [Woody Allen; Love and Death] ------------------------------ Date: Thu, 27 Sep 2007 11:58:06 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190919486.068970.122290@19g2000hsx.googlegroups.com> On Sep 27, 2:20 pm, Mark Daniel wrote: > 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 ... > > Excellent. > > A 404 can also indicate the server account does not have permission to > access the file entry in the parent directory and therefore does not > 'see' it during the directory search. > > With a script, such as soyMAIL, it can also indicate an error > originating from within the script itself. For instance, soyMAIL > refuses to access private VMS Mail unless the request provides an > authenticated username. Though soyMAIL uses 403s (forbidden) to report > such conditions. > > Once authentication is going I suspect we may be back to analysing the > originally reported 404 error. > > > the installation went fine and soymail.exe exists because > > > $ dir cgi-bin:[000000]soymail > > > shows it there, and purveyor can run it ... > > It's interesting that the two server environments can access the same > executable when the standard WASD security environment explicitly > prohibits any account other than those holding a specific rights identifier. > > $ dir /sec cgi-bin:[000000]soymail.exe > > Directory CGI-BIN:[000000] > > SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 [SYSTEM] > (RWED,RWED,,) > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,ACCESS=NONE) > > Total of 1 file, 682KB > > $ dir /sec ht_root:[000000]axp-bin.dir > > Directory HT_ROOT:[000000] > > AXP-BIN.DIR;1 9KB 21-OCT-2002 02:43:55.54 [SYSTEM] > (RWED,RWED,,) > (IDENTIFIER=WASD_HTTP_SERVER,ACCESS=EXECUTE) > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,ACCESS=NONE) > > (IDENTIFIER=WASD_HTTP_NOBODY,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE) > (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) > > Total of 1 file, 9KB > > Have you granted either of the the above identifiers to the Purveyor > account? If not I wonder how Purveyor is accessing > CGI-BIN:[000000]SOYMAIL.EXE? > > Please provide the results to the above and following commands. > > $ 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] > > Then list the Purveyor CONFIGxx.DB directive(s) that map(s) Purveyor > into the above CGI-BIN:[000000] directory. > > > 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 > > This is in the soyMAIL not WASD configuration. If the user > authentication step by WASD fails then the request stops there. Well > before attempting to activate the script itself. > > Now, this *is* the browser username/password dialog (just checking)? > > > and the login still fails (Iam keying in my vms password correctly) > > There are other characteristics of an account that WASD takes into > consideration before granting access. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_sysuaf > > For example; is the password expired? Any access time restrictions? > Extended privileges? Which now that it is mentioned may be an issue > with a BOB account (I would not be surprised if this account had > additional privileges). As described above; by default WASD does not > permit privileged accounts to be used for authentication. You can > explicitly override that restriction using the startup /SYSUAF qualifier > keyword RELAXED. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy > > You are already using the SSL keyword. So you would need to modify your > HTTPD$STARTUP_SERVER logical value to be "/SYSUAF=(SSL,RELAXED)" and > then $ HTTPD/DO=RESTART > > However, *before* we do that let's use WATCH to determine *exactly* why > it's failing. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html > > WATCH is a tool that if it doesn't indicate exactly the reason for any > given server behaviour usually provides a very good hint. Well past > time it was utilised. As described in > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config > > we'll now activate it by you entering at the command-line > > $ HTTPD/DO=AUTH=SKELKEY=_ROBERT: > > (underscore is significant). Then access > > https://your.system.name/httpd/-/admin/ > > which should provide you with a browser username/password dialog box > requesting authentication for "SKELKEY". Enter _ROBERT (underscore is > significant) and the password string. You should now have the Server > Administration menu > > http://wasd.vsm.com.au/ht_root/doc/htd/admin.gif > > Access the [WATCH] item in the bottom right and in that menu, in > addition to the pre-checked items, check [x]Authorization. > > Now you need a *completely separate* browser (*not* another window or > tab on the current browser). So if you are using Mozilla then bring up > Firefox or Opera or even (shudder) MSIE. If using (greater shudder) > MSIE then bring up Mozilla, Firefox or Opera (etc). Or if only the one > browser is available then on a second machine bring up a browser. > > Now in the WATCH Report window hit the [WATCH] button. > > In the second browser access > > https://your.server.name/cgi-bin/soymail/~ > > A report page should begin to be generated. The [x]Authorization > checkbox should produce output specifically related to > authentication/authorization. My development system, set up > specifically to replicate your suspected problem, shows output including > (my news agent, VMS Mozilla, will munge this horribly) > > |03:04:30.83 AUTH 1667 0001 AUTHORIZE AUTHENTICATE user:system > realm:VMS| > |03:04:30.85 AUTHACME 0349 0001 AUTHORIZE ACME doi:"VMS" agent:"VMS" > mapped:"SYSTEM" %X074A8001 %ACME-S-NORMAL, normal successful completion| > |03:04:30.86 AUTHVMS 0353 0001 AUTHORIZE GETUAI "SYSTEM" %X00000001 > %SYSTEM-S-NORMAL, normal successful completion| > expire:(none) pwd:20-MAY-2007:11:20(730AFA6856AB92AE) > pwd2:(none)(0000000000000000) life:180-00:00 > flags:00B9D40C priv:<63-32>FFFFFFFF<31-00>FFFFFFFF > prime:00000060 netp:000000 nets:000000 remp:000000 rems:000000 > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > |03:04:30.86 AUTH 2316 0001 AUTHORIZE CHECK realm %X0FFFFF5A > DENIED_BY_LOGIN| > |03:04:30.87 ERROR 1072 0001 RESPONSE AUTH:3029 (detailed) 401(401) > "Authentication failed."| > > The significant report item in this example is > > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > > If it shows this then it's the issue described above and you need to use > the RELAXED keyword with the /SYSUAF startup qualifier. If it's > something else then include the relevant section in your next post. > > Assuming it is the above 'privileges' issue then it's best you disable > skeleton-key authorization by HTTPD/DO=AUTH=SKELKEY=0 before making any > changes or restarts (you can always reenable it if necessary). > > Again assuming the /SYSUAF=(SSL,RELAXED) allows you to authenticate and > you have also included the previously suggested > > ["WASD Admin"=VMS] > /httpd/-/admin/* r+w,~bob > > you won't need to go through the separate browser exercise again, you'll > just access /httpd/-/admin/ and provide your VMS password if required > and access the Server Administration items and WATCH in particular > whenever your want/need. > > Note I have now added a username restriction to the above authorization > rule (the '~bob'). See section "Access Restriction Keywords" in > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file > > You don't want just any old VMS account accessing the above resources! > > > also, how do you get soymail to come up directly without first > > getting the construction site box? > > I am unclear what is meant by '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? > > Most definitely - WATCH, WATCH, WATCH! > > -- > Sonja: Judgment of any system, or a priori relationship or phenomenon > exists in an irrational, or metaphysical, or at least epistemological > contradiction to an abstract empirical concept such as being, or to be, > or to occur in the thing itself, or of the thing itself. > Boris: Yes, I've said that many times. > [Woody Allen; Love and Death]- Hide quoted text - > > - Show quoted text - /sysuaf="ssl,relaxed" failed ... I do no care about who has what rights because I am going to transfer the purveyor soymail.conf which has a list of users to allow access to ... so now I will try watch ... ------------------------------ Date: Thu, 27 Sep 2007 12:03:30 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190919810.338001.219050@g4g2000hsf.googlegroups.com> On Sep 27, 2:20 pm, Mark Daniel wrote: > 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 ... > > Excellent. > > A 404 can also indicate the server account does not have permission to > access the file entry in the parent directory and therefore does not > 'see' it during the directory search. > > With a script, such as soyMAIL, it can also indicate an error > originating from within the script itself. For instance, soyMAIL > refuses to access private VMS Mail unless the request provides an > authenticated username. Though soyMAIL uses 403s (forbidden) to report > such conditions. > > Once authentication is going I suspect we may be back to analysing the > originally reported 404 error. > > > the installation went fine and soymail.exe exists because > > > $ dir cgi-bin:[000000]soymail > > > shows it there, and purveyor can run it ... > > It's interesting that the two server environments can access the same > executable when the standard WASD security environment explicitly > prohibits any account other than those holding a specific rights identifier. > > $ dir /sec cgi-bin:[000000]soymail.exe > > Directory CGI-BIN:[000000] > > SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 [SYSTEM] > (RWED,RWED,,) > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,ACCESS=NONE) > > Total of 1 file, 682KB > > $ dir /sec ht_root:[000000]axp-bin.dir > > Directory HT_ROOT:[000000] > > AXP-BIN.DIR;1 9KB 21-OCT-2002 02:43:55.54 [SYSTEM] > (RWED,RWED,,) > (IDENTIFIER=WASD_HTTP_SERVER,ACCESS=EXECUTE) > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,ACCESS=NONE) > > (IDENTIFIER=WASD_HTTP_NOBODY,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE) > (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE) > (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) > > Total of 1 file, 9KB > > Have you granted either of the the above identifiers to the Purveyor > account? If not I wonder how Purveyor is accessing > CGI-BIN:[000000]SOYMAIL.EXE? > > Please provide the results to the above and following commands. > > $ 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] > > Then list the Purveyor CONFIGxx.DB directive(s) that map(s) Purveyor > into the above CGI-BIN:[000000] directory. > > > 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 > > This is in the soyMAIL not WASD configuration. If the user > authentication step by WASD fails then the request stops there. Well > before attempting to activate the script itself. > > Now, this *is* the browser username/password dialog (just checking)? > > > and the login still fails (Iam keying in my vms password correctly) > > There are other characteristics of an account that WASD takes into > consideration before granting access. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_sysuaf > > For example; is the password expired? Any access time restrictions? > Extended privileges? Which now that it is mentioned may be an issue > with a BOB account (I would not be surprised if this account had > additional privileges). As described above; by default WASD does not > permit privileged accounts to be used for authentication. You can > explicitly override that restriction using the startup /SYSUAF qualifier > keyword RELAXED. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy > > You are already using the SSL keyword. So you would need to modify your > HTTPD$STARTUP_SERVER logical value to be "/SYSUAF=(SSL,RELAXED)" and > then $ HTTPD/DO=RESTART > > However, *before* we do that let's use WATCH to determine *exactly* why > it's failing. > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html > > WATCH is a tool that if it doesn't indicate exactly the reason for any > given server behaviour usually provides a very good hint. Well past > time it was utilised. As described in > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config > > we'll now activate it by you entering at the command-line > > $ HTTPD/DO=AUTH=SKELKEY=_ROBERT: > > (underscore is significant). Then access > > https://your.system.name/httpd/-/admin/ > > which should provide you with a browser username/password dialog box > requesting authentication for "SKELKEY". Enter _ROBERT (underscore is > significant) and the password string. You should now have the Server > Administration menu > > http://wasd.vsm.com.au/ht_root/doc/htd/admin.gif > > Access the [WATCH] item in the bottom right and in that menu, in > addition to the pre-checked items, check [x]Authorization. > > Now you need a *completely separate* browser (*not* another window or > tab on the current browser). So if you are using Mozilla then bring up > Firefox or Opera or even (shudder) MSIE. If using (greater shudder) > MSIE then bring up Mozilla, Firefox or Opera (etc). Or if only the one > browser is available then on a second machine bring up a browser. > > Now in the WATCH Report window hit the [WATCH] button. > > In the second browser access > > https://your.server.name/cgi-bin/soymail/~ > > A report page should begin to be generated. The [x]Authorization > checkbox should produce output specifically related to > authentication/authorization. My development system, set up > specifically to replicate your suspected problem, shows output including > (my news agent, VMS Mozilla, will munge this horribly) > > |03:04:30.83 AUTH 1667 0001 AUTHORIZE AUTHENTICATE user:system > realm:VMS| > |03:04:30.85 AUTHACME 0349 0001 AUTHORIZE ACME doi:"VMS" agent:"VMS" > mapped:"SYSTEM" %X074A8001 %ACME-S-NORMAL, normal successful completion| > |03:04:30.86 AUTHVMS 0353 0001 AUTHORIZE GETUAI "SYSTEM" %X00000001 > %SYSTEM-S-NORMAL, normal successful completion| > expire:(none) pwd:20-MAY-2007:11:20(730AFA6856AB92AE) > pwd2:(none)(0000000000000000) life:180-00:00 > flags:00B9D40C priv:<63-32>FFFFFFFF<31-00>FFFFFFFF > prime:00000060 netp:000000 nets:000000 remp:000000 rems:000000 > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > |03:04:30.86 AUTH 2316 0001 AUTHORIZE CHECK realm %X0FFFFF5A > DENIED_BY_LOGIN| > |03:04:30.87 ERROR 1072 0001 RESPONSE AUTH:3029 (detailed) 401(401) > "Authentication failed."| > > The significant report item in this example is > > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > > If it shows this then it's the issue described above and you need to use > the RELAXED keyword with the /SYSUAF startup qualifier. If it's > something else then include the relevant section in your next post. > > Assuming it is the above 'privileges' issue then it's best you disable > skeleton-key authorization by HTTPD/DO=AUTH=SKELKEY=0 before making any > changes or restarts (you can always reenable it if necessary). > > Again assuming the /SYSUAF=(SSL,RELAXED) allows you to authenticate and > you have also included the previously suggested > > ["WASD Admin"=VMS] > /httpd/-/admin/* r+w,~bob > > you won't need to go through the separate browser exercise again, you'll > just access /httpd/-/admin/ and provide your VMS password if required > and access the Server Administration items and WATCH in particular > whenever your want/need. > > Note I have now added a username restriction to the above authorization > rule (the '~bob'). See section "Access Restriction Keywords" in > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file > > You don't want just any old VMS account accessing the above resources! > > > also, how do you get soymail to come up directly without first > > getting the construction site box? > > I am unclear what is meant by '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? > > Most definitely - WATCH, WATCH, WATCH! > > -- > Sonja: Judgment of any system, or a priori relationship or phenomenon > exists in an irrational, or metaphysical, or at least epistemological > contradiction to an abstract empirical concept such as being, or to be, > or to occur in the thing itself, or of the thing itself. > Boris: Yes, I've said that many times. > [Woody Allen; Love and Death]- Hide quoted text - > > - Show quoted text - "/sysuaf=(ssl,relaxed)" failed ... the above dir/sec reveals the same protection you show above ... I do not care about who has what rights because I have a list of users built for use with private access from purveyor ... I guess now its watch watch watch ... ------------------------------ Date: Thu, 27 Sep 2007 12:58:26 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190923106.551551.246640@r29g2000hsg.googlegroups.com> On Sep 27, 3:03 pm, ultra...@gmail.com wrote: > On Sep 27, 2:20 pm, Mark Daniel wrote: > > > > > > > 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 ... > > > Excellent. > > > A 404 can also indicate the server account does not have permission to > > access the file entry in the parent directory and therefore does not > > 'see' it during the directory search. > > > With a script, such as soyMAIL, it can also indicate an error > > originating from within the script itself. For instance, soyMAIL > > refuses to access private VMS Mail unless the request provides an > > authenticated username. Though soyMAIL uses 403s (forbidden) to report > > such conditions. > > > Once authentication is going I suspect we may be back to analysing the > > originally reported 404 error. > > > > the installation went fine and soymail.exe exists because > > > > $ dir cgi-bin:[000000]soymail > > > > shows it there, and purveyor can run it ... > > > It's interesting that the two server environments can access the same > > executable when the standard WASD security environment explicitly > > prohibits any account other than those holding a specific rights identifier. > > > $ dir /sec cgi-bin:[000000]soymail.exe > > > Directory CGI-BIN:[000000] > > > SOYMAIL.EXE;4697 682KB 18-AUG-2007 12:58:06.94 [SYSTEM] > > (RWED,RWED,,) > > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > > (IDENTIFIER=*,ACCESS=NONE) > > > Total of 1 file, 682KB > > > $ dir /sec ht_root:[000000]axp-bin.dir > > > Directory HT_ROOT:[000000] > > > AXP-BIN.DIR;1 9KB 21-OCT-2002 02:43:55.54 [SYSTEM] > > (RWED,RWED,,) > > (IDENTIFIER=WASD_HTTP_SERVER,ACCESS=EXECUTE) > > (IDENTIFIER=WASD_HTTP_NOBODY,ACCESS=READ+EXECUTE) > > (IDENTIFIER=*,ACCESS=NONE) > > > (IDENTIFIER=WASD_HTTP_NOBODY,OPTIONS=DEFAULT,ACCESS=READ+EXECUTE) > > (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE) > > (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) > > > Total of 1 file, 9KB > > > Have you granted either of the the above identifiers to the Purveyor > > account? If not I wonder how Purveyor is accessing > > CGI-BIN:[000000]SOYMAIL.EXE? > > > Please provide the results to the above and following commands. > > > $ 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] > > > Then list the Purveyor CONFIGxx.DB directive(s) that map(s) Purveyor > > into the above CGI-BIN:[000000] directory. > > > > 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 > > > This is in the soyMAIL not WASD configuration. If the user > > authentication step by WASD fails then the request stops there. Well > > before attempting to activate the script itself. > > > Now, this *is* the browser username/password dialog (just checking)? > > > > and the login still fails (Iam keying in my vms password correctly) > > > There are other characteristics of an account that WASD takes into > > consideration before granting access. > > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_sysuaf > > > For example; is the password expired? Any access time restrictions? > > Extended privileges? Which now that it is mentioned may be an issue > > with a BOB account (I would not be surprised if this account had > > additional privileges). As described above; by default WASD does not > > permit privileged accounts to be used for authentication. You can > > explicitly override that restriction using the startup /SYSUAF qualifier > > keyword RELAXED. > > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_policy > > > You are already using the SSL keyword. So you would need to modify your > > HTTPD$STARTUP_SERVER logical value to be "/SYSUAF=(SSL,RELAXED)" and > > then $ HTTPD/DO=RESTART > > > However, *before* we do that let's use WATCH to determine *exactly* why > > it's failing. > > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_2000.html > > > WATCH is a tool that if it doesn't indicate exactly the reason for any > > given server behaviour usually provides a very good hint. Well past > > time it was utilised. As described in > > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config > > > we'll now activate it by you entering at the command-line > > > $ HTTPD/DO=AUTH=SKELKEY=_ROBERT: > > > (underscore is significant). Then access > > > https://your.system.name/httpd/-/admin/ > > > which should provide you with a browser username/password dialog box > > requesting authentication for "SKELKEY". Enter _ROBERT (underscore is > > significant) and the password string. You should now have the Server > > Administration menu > > > http://wasd.vsm.com.au/ht_root/doc/htd/admin.gif > > > Access the [WATCH] item in the bottom right and in that menu, in > > addition to the pre-checked items, check [x]Authorization. > > > Now you need a *completely separate* browser (*not* another window or > > tab on the current browser). So if you are using Mozilla then bring up > > Firefox or Opera or even (shudder) MSIE. If using (greater shudder) > > MSIE then bring up Mozilla, Firefox or Opera (etc). Or if only the one > > browser is available then on a second machine bring up a browser. > > > Now in the WATCH Report window hit the [WATCH] button. > > > In the second browser access > > > https://your.server.name/cgi-bin/soymail/~ > > > A report page should begin to be generated. The [x]Authorization > > checkbox should produce output specifically related to > > authentication/authorization. My development system, set up > > specifically to replicate your suspected problem, shows output including > > (my news agent, VMS Mozilla, will munge this horribly) > > > |03:04:30.83 AUTH 1667 0001 AUTHORIZE AUTHENTICATE user:system > > realm:VMS| > > |03:04:30.85 AUTHACME 0349 0001 AUTHORIZE ACME doi:"VMS" agent:"VMS" > > mapped:"SYSTEM" %X074A8001 %ACME-S-NORMAL, normal successful completion| > > |03:04:30.86 AUTHVMS 0353 0001 AUTHORIZE GETUAI "SYSTEM" %X00000001 > > %SYSTEM-S-NORMAL, normal successful completion| > > expire:(none) pwd:20-MAY-2007:11:20(730AFA6856AB92AE) > > pwd2:(none)(0000000000000000) life:180-00:00 > > flags:00B9D40C priv:<63-32>FFFFFFFF<31-00>FFFFFFFF > > prime:00000060 netp:000000 nets:000000 remp:000000 rems:000000 > > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > > |03:04:30.86 AUTH 2316 0001 AUTHORIZE CHECK realm %X0FFFFF5A > > DENIED_BY_LOGIN| > > |03:04:30.87 ERROR 1072 0001 RESPONSE AUTH:3029 (detailed) 401(401) > > "Authentication failed."| > > > The significant report item in this example is > > > |03:04:30.86 AUTHVMS 0743 0001 AUTHORIZE FAIL SYSUAF privileges| > > > If it shows this then it's the issue described above and you need to use > > the RELAXED keyword with the /SYSUAF startup qualifier. If it's > > something else then include the relevant section in your next post. > > > Assuming it is the above 'privileges' issue then it's best you disable > > skeleton-key authorization by HTTPD/DO=AUTH=SKELKEY=0 before making any > > changes or restarts (you can always reenable it if necessary). > > > Again assuming the /SYSUAF=(SSL,RELAXED) allows you to authenticate and > > you have also included the previously suggested > > > ["WASD Admin"=VMS] > > /httpd/-/admin/* r+w,~bob > > > you won't need to go through the separate browser exercise again, you'll > > just access /httpd/-/admin/ and provide your VMS password if required > > and access the Server Administration items and WATCH in particular > > whenever your want/need. > > > Note I have now added a username restriction to the above authorization > > rule (the '~bob'). See section "Access Restriction Keywords" in > > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1600.html#hd_auth_file > > > You don't want just any old VMS account accessing the above resources! > > > > also, how do you get soymail to come up directly without first > > > getting the construction site box? > > > I am unclear what is meant by '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? > > > Most definitely - WATCH, WATCH, WATCH! > > > -- > > Sonja: Judgment of any system, or a priori relationship or phenomenon > > exists in an irrational, or metaphysical, or at least epistemological > > contradiction to an abstract empirical concept such as being, or to be, > > or to occur in the thing itself, or of the thing itself. > > Boris: Yes, I've said that many times. > > [Woody Allen; Love and Death]- Hide quoted text - > > > - Show quoted text - > > "/sysuaf=(ssl,relaxed)" failed ... > > the above dir/sec reveals the same protection you show above ... > > I do not care about who has what rights because I have a list > of users built for use with private access from purveyor ... > > I guess now its watch watch watch ...- Hide quoted text - > > - Show quoted text - well, I would watch watch watch, except when I enter the HTTPD/DO command, it does not recognize HTTPD as a command ... this is not setup upon server startup? Also, I have no identifiers set up, and really do not want to have to set them and manage them for over 100 users ... all I want is SSL login authenticating againset sysuaf and soymail.confs private access username list ... first, why isn't HTTPD foreign command working? ------------------------------ Date: Thu, 27 Sep 2007 13:21:01 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190924461.931899.15630@n39g2000hsh.googlegroups.com> On Sep 27, 3:58 pm, ultra...@gmail.com wrote: > On Sep 27, 3:03 pm, ultra...@gmail.com wrote: so I defined the foreign command like your startup.com does and now it syas "username too short" ... oh well ... ------------------------------ Date: Thu, 27 Sep 2007 13:22:02 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190924522.722321.290710@y42g2000hsy.googlegroups.com> On Sep 27, 4:21 pm, ultra...@gmail.com wrote: > On Sep 27, 3:58 pm, ultra...@gmail.com wrote: > > > On Sep 27, 3:03 pm, ultra...@gmail.com wrote: > > so I defined the foreign command like your startup.com does > and now it syas "username too short" ... > > oh well ... now a four letter password is too short ... if you do not first succeed ... ------------------------------ Date: Fri, 28 Sep 2007 05:56:55 +0930 From: Mark Daniel Subject: Re: Soymail not working with WASD Message-ID: <13fo4i11kln5g16@corp.supernews.com> ultradwc@gmail.com wrote: > On Sep 27, 3:03 pm, ultra...@gmail.com wrote: > >>On Sep 27, 2:20 pm, Mark Daniel wrote: 8< snip 8< > well, I would watch watch watch, except when I enter > the HTTPD/DO command, it does not recognize HTTPD > as a command ... this is not setup upon server startup? > Also, I have no identifiers set up, and really do not want > to have to set them and manage them for over 100 users ... > > all I want is SSL login authenticating againset sysuaf and > soymail.confs private access username list ... > > first, why isn't HTTPD foreign command working? Please *read* the documentation before considering it a failure. The previously referred-to section demonstrating how to access the Server Administration facilities before getting it all up and configured even has a foreign command being assigned in the example: http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config Also you can $ SHOW SYMBOL HTTPD HTTPD == "$HT_EXE:HTTPD_SSL.EXE to check. If you have built the SSL version then be sure to specify that image. Pretty basic VMS stuff. There is also a DCL procedure that can be used for this purpose: http://wasd.vsm.com.au/ht_root/doc/htd/htd_2400.html http://wasd.vsm.com.au/ht_root/example/wasdverbs.com How have you been managing to restart the server, (re)load the modified rules, etc? -- [last lines] Boris: The question is have I learned anything about life. Only that human being are divided into mind and body. The mind embraces all the nobler aspirations, like poetry and philosophy, but the body has all the fun. The important thing, I think, is not to be bitter... if it turns out that there IS a God, I don't think that He's evil. I think that the worst you can say about Him is that basically He's an underachiever. After all, there are worse things in life than death. If you've ever spent an evening with an insurance salesman, you know what I'm talking about. The key is, to not think of death as an end, but as more of a very effective way to cut down on your expenses. Regarding love, heh, what can you say? It's not the quantity of your sexual relations that counts. It's the quality. On the other hand if the quantity drops below once every eight months, I would definitely look into. Well, that's about it for me folks. Goodbye. [Woody Allen; Love and Death] ------------------------------ Date: Thu, 27 Sep 2007 13:32:06 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190925126.279316.250550@19g2000hsx.googlegroups.com> On Sep 27, 4:26 pm, Mark Daniel wrote: > ultra...@gmail.com wrote: > > On Sep 27, 3:03 pm, ultra...@gmail.com wrote: > > >>On Sep 27, 2:20 pm, Mark Daniel wrote: > 8< snip 8< > > well, I would watch watch watch, except when I enter > > the HTTPD/DO command, it does not recognize HTTPD > > as a command ... this is not setup upon server startup? > > Also, I have no identifiers set up, and really do not want > > to have to set them and manage them for over 100 users ... > > > all I want is SSL login authenticating againset sysuaf and > > soymail.confs private access username list ... > > > first, why isn't HTTPD foreign command working? > > Please *read* the documentation before considering it a failure. The > previously referred-to section demonstrating how to access the Server > Administration facilities before getting it all up and configured even > has a foreign command being assigned in the example: > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config > > Also you can > > $ SHOW SYMBOL HTTPD > HTTPD == "$HT_EXE:HTTPD_SSL.EXE > > to check. If you have built the SSL version then be sure to specify > that image. Pretty basic VMS stuff. > > There is also a DCL procedure that can be used for this purpose: > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_2400.html > http://wasd.vsm.com.au/ht_root/example/wasdverbs.com > > How have you been managing to restart the server, (re)load the modified > rules, etc? > > -- > [last lines] > Boris: The question is have I learned anything about life. Only that > human being are divided into mind and body. The mind embraces all the > nobler aspirations, like poetry and philosophy, but the body has all the > fun. The important thing, I think, is not to be bitter... if it turns > out that there IS a God, I don't think that He's evil. I think that the > worst you can say about Him is that basically He's an underachiever. > After all, there are worse things in life than death. If you've ever > spent an evening with an insurance salesman, you know what I'm talking > about. The key is, to not think of death as an end, but as more of a > very effective way to cut down on your expenses. Regarding love, heh, > what can you say? It's not the quantity of your sexual relations that > counts. It's the quality. On the other hand if the quantity drops below > once every eight months, I would definitely look into. Well, that's > about it for me folks. Goodbye. [Woody Allen; Love and Death] like I said above, I defined it and now trying to log in as robert gives a html 401 error ... ------------------------------ Date: Thu, 27 Sep 2007 13:33:14 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190925194.702850.85740@n39g2000hsh.googlegroups.com> On Sep 27, 4:26 pm, Mark Daniel wrote: > ultra...@gmail.com wrote: > > On Sep 27, 3:03 pm, ultra...@gmail.com wrote: > > >>On Sep 27, 2:20 pm, Mark Daniel wrote: > 8< snip 8< > > well, I would watch watch watch, except when I enter > > the HTTPD/DO command, it does not recognize HTTPD > > as a command ... this is not setup upon server startup? > > Also, I have no identifiers set up, and really do not want > > to have to set them and manage them for over 100 users ... > > > all I want is SSL login authenticating againset sysuaf and > > soymail.confs private access username list ... > > > first, why isn't HTTPD foreign command working? > > Please *read* the documentation before considering it a failure. The > previously referred-to section demonstrating how to access the Server > Administration facilities before getting it all up and configured even > has a foreign command being assigned in the example: > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_1900.html#hd_admin_no_config > > Also you can > > $ SHOW SYMBOL HTTPD > HTTPD == "$HT_EXE:HTTPD_SSL.EXE > > to check. If you have built the SSL version then be sure to specify > that image. Pretty basic VMS stuff. > > There is also a DCL procedure that can be used for this purpose: > > http://wasd.vsm.com.au/ht_root/doc/htd/htd_2400.html > http://wasd.vsm.com.au/ht_root/example/wasdverbs.com > > How have you been managing to restart the server, (re)load the modified > rules, etc? > > -- > [last lines] > Boris: The question is have I learned anything about life. Only that > human being are divided into mind and body. The mind embraces all the > nobler aspirations, like poetry and philosophy, but the body has all the > fun. The important thing, I think, is not to be bitter... if it turns > out that there IS a God, I don't think that He's evil. I think that the > worst you can say about Him is that basically He's an underachiever. > After all, there are worse things in life than death. If you've ever > spent an evening with an insurance salesman, you know what I'm talking > about. The key is, to not think of death as an end, but as more of a > very effective way to cut down on your expenses. Regarding love, heh, > what can you say? It's not the quantity of your sexual relations that > counts. It's the quality. On the other hand if the quantity drops below > once every eight months, I would definitely look into. Well, that's > about it for me folks. Goodbye. [Woody Allen; Love and Death] and yes, I run shutdown and it works fine and then my own startup com file and everything starts fine ... ------------------------------ Date: Thu, 27 Sep 2007 13:37:53 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190925473.392916.269740@19g2000hsx.googlegroups.com> On Sep 27, 4:33 pm, ultra...@gmail.com wrote: > > and yes, I run shutdown and it works fine and then > my own startup com file and everything starts fine ...- Hide quoted text - > > - Show quoted text - STARTUP_MYCOM.COM $ DEF/SYS HTTPD$STARTUP_SERVER "/SYSUAF=(SSL,RELAXED)" $ @DSA0:[HT_ROOT.LOCAL]STARTUP WASD_SSL=1 $ @DSA0:[HT_ROOT.LOCAL]SOYMAIL_STARTUP all logicals appear defined properly ... ------------------------------ Date: Thu, 27 Sep 2007 13:42:07 -0700 From: ultradwc@gmail.com Subject: Re: Soymail not working with WASD Message-ID: <1190925727.536371.212880@57g2000hsv.googlegroups.com> On Sep 27, 4:37 pm, ultra...@gmail.com wrote: > On Sep 27, 4:33 pm, ultra...@gmail.com wrote: > > > > > and yes, I run shutdown and it works fine and then > > my own startup com file and everything starts fine ...- Hide quoted text - > > > - Show quoted text - > > STARTUP_MYCOM.COM > > $ DEF/SYS HTTPD$STARTUP_SERVER "/SYSUAF=(SSL,RELAXED)" > $ @DSA0:[HT_ROOT.LOCAL]STARTUP WASD_SSL=1 > $ @DSA0:[HT_ROOT.LOCAL]SOYMAIL_STARTUP > > all logicals appear defined properly ... $ HTTP/DO=AUTH=SKELKEY=robert:password %HTTPD-I-DO, 1 instance notified; NODE:HTTPd:80 browser login box takes the above and errors to 401 ... ------------------------------ Date: 27 Sep 2007 13:05:22 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Time to PAK it in? Message-ID: <4k4O8$pUPLmE@eisner.encompasserve.org> In article <3bQKi.2825$H22.1583@news-server.bigpond.net.au>, "Tim E. Sneddon" writes: > 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. They might have provided those, and have done so on Alpha, but the agreements I have seen always said that the machine was supposed to have a regular VMS license already and DSPP only provided layered product licenses. ------------------------------ Date: Thu, 27 Sep 2007 19:27:43 GMT From: "John Vottero" Subject: Re: Time to PAK it in? Message-ID: "Larry Kilgallen" wrote in message news:4k4O8$pUPLmE@eisner.encompasserve.org... > In article <3bQKi.2825$H22.1583@news-server.bigpond.net.au>, "Tim E. > Sneddon" writes: >> 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. > > They might have provided those, and have done so on Alpha, but the > agreements I have seen always said that the machine was supposed to > have a regular VMS license already and DSPP only provided layered > product licenses. True. But some of us bought Itaniums before they were available with OpenVMS license PAKs and we were told not to worry because the OpenVMS PAK was in the DSPP download. Now I'm worried. ------------------------------ Date: Thu, 27 Sep 2007 19:45:36 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Time to PAK it in? Message-ID: In article , "John Vottero" writes: > > >"Larry Kilgallen" wrote in message >news:4k4O8$pUPLmE@eisner.encompasserve.org... >> In article <3bQKi.2825$H22.1583@news-server.bigpond.net.au>, "Tim E. >> Sneddon" writes: >>> 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. >> >> They might have provided those, and have done so on Alpha, but the >> agreements I have seen always said that the machine was supposed to >> have a regular VMS license already and DSPP only provided layered >> product licenses. > >True. But some of us bought Itaniums before they were available with >OpenVMS license PAKs and we were told not to worry because the OpenVMS PAK >was in the DSPP download. Now I'm worried. > Ditto... Here's a fix John: $ SET TIME="''F$time()-365-::" See me in a year's time for a new fix! ;) -- 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 21:37:37 GMT From: "John Vottero" Subject: Re: Time to PAK it in? Message-ID: "IanMiller" wrote in message news: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. > I asked DSPP about this and John Egolf has already responded, the missing PAK was a mistake which will be corrected. Very quick turn around from DSPP! ------------------------------ Date: Thu, 27 Sep 2007 18:49:40 -0400 From: JF Mezei Subject: Re: Time to PAK it in? Message-ID: <78615$46fc3386$cef8887a$28150@TEKSAVVY.COM> John Vottero wrote: > I asked DSPP about this and John Egolf has already responded, the missing > PAK was a mistake which will be corrected. Yep, watch them start to send out HP-UX PAKs with invitation to some VMS to HP-UX porting seminars :-) :-) ;-) :-) :-) :-) :-) :-) ------------------------------ Date: Thu, 27 Sep 2007 13:18:04 -0700 From: jhjr4381 Subject: Re: wierd backup behavior Message-ID: <1190924284.242260.254560@g4g2000hsf.googlegroups.com> On Sep 26, 12:11 pm, "Richard Brodie" wrote: > "jhjr4381" wrote in message > > news:1190822080.542181.314400@o80g2000hse.googlegroups.com... > > > However, the log files show very inconsistent backup activity (number > > of files stored - varies by 5-10k), only on the Vax disks, even if > > done by itself. > > One small point, that might help. I wouldn't call the files you create > with /LIST log files. They are save set listing files; useful as a record > of the contents of the tape. > > The logging information will be in the standard output of where > the backup job ran from. That would be the place to start looking > for errors. If it's run as a batch job specifying /NOLOG, fix > that first. Paul, Thanks, wasn't aware of the 'other' .log file being created and found them. There were several errors involed over the last few weeks: $ BACKUP/NOREWIND/LIST=DKA100:[BACKUP]DUA510FUL.LOG/IMAGE - /NOALIAS - /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA510: - RDAXP$MKB500:DUA510.BCK %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;198 -RMS-E-EXT, ACP file extend failed -SYSTEM-F-EXQUOTA, process quota exceeded So, I gather there's a user or system set quota getting exceeded. How can I display the user/process quota that's causing the problem? %BACKUP-E-READVERR, virtual read error on file [CMSLIB.MAN110.CMS $034]MGA410_F.I FDL;5 at block 69 -SYSTEM-F-FORCEDERROR, forced error flagged in last sector read This looks like a problem with the disk. However, it looks like it bypasses these files and continues.Use ANALYSE disk and check/fix it out. Restore if necessary/able? $ BACKUP/NOREWIND/LIST=SYS$SYSDEVICE:[BACKUP]DUA600FUL.LOG/IMAGE - /NOALIAS - /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA600: - RDAXP$MKB500:DUA600.BCK %BACKUP-F-POSITERR, error positioning RDAXP$MKB500:[000000]DUA600.BCK; -SYSTEM-F-OPINCOMPL, operation is incomplete This is on the 8th disk of the backup. It seems as if the tape drive has gotten a bit weary and can't find the EOF on the last save set to position the beginning of the last backup on this tape. I did see that there's a 'set noon' at the top of the DCL. I'm assuming that since that's there, instead of aborting on some of these errors, the batch job continued right to the "image backup has successfully completed" at the end of the .com file, letting the operator walk away fat 'n happy! guess I better take a look at the DCL manual for error checking. I'd rather it fail and know about it! Thanks to all for the suggestions! keep 'em coming, I don't mind learning ! ------------------------------ Date: Thu, 27 Sep 2007 13:27:59 -0700 From: jhjr4381 Subject: Re: wierd backup behavior Message-ID: <1190924879.979089.53460@n39g2000hsh.googlegroups.com> On Sep 27, 4:18 pm, jhjr4381 wrote: > On Sep 26, 12:11 pm, "Richard Brodie" wrote: > > > > > > > "jhjr4381" wrote in message > > >news:1190822080.542181.314400@o80g2000hse.googlegroups.com... > > > > However, the log files show very inconsistent backup activity (number > > > of files stored - varies by 5-10k), only on the Vax disks, even if > > > done by itself. > > > One small point, that might help. I wouldn't call the files you create > > with /LIST log files. They are save set listing files; useful as a record > > of the contents of the tape. > > > The logging information will be in the standard output of where > > the backup job ran from. That would be the place to start looking > > for errors. If it's run as a batch job specifying /NOLOG, fix > > that first. > > Paul, > > Thanks, wasn't aware of the 'other' .log file being created and found > them. There were several errors involed over the last few weeks: > > $ BACKUP/NOREWIND/LIST=DKA100:[BACKUP]DUA510FUL.LOG/IMAGE - > /NOALIAS - > /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA510: > - > RDAXP$MKB500:DUA510.BCK > %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;198 > -RMS-E-EXT, ACP file extend failed > -SYSTEM-F-EXQUOTA, process quota exceeded > > So, I gather there's a user or system set quota getting exceeded. How > can I display the user/process quota that's causing the problem? > > %BACKUP-E-READVERR, virtual read error on file [CMSLIB.MAN110.CMS > $034]MGA410_F.I > FDL;5 at block 69 > -SYSTEM-F-FORCEDERROR, forced error flagged in last sector read > > This looks like a problem with the disk. However, it looks like it > bypasses these files and continues.Use ANALYSE disk and check/fix it > out. Restore if necessary/able? > > $ BACKUP/NOREWIND/LIST=SYS$SYSDEVICE:[BACKUP]DUA600FUL.LOG/IMAGE - > /NOALIAS - > /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA600: > - > RDAXP$MKB500:DUA600.BCK > %BACKUP-F-POSITERR, error positioning RDAXP$MKB500:[000000]DUA600.BCK; > -SYSTEM-F-OPINCOMPL, operation is incomplete > > This is on the 8th disk of the backup. It seems as if the tape drive > has gotten a bit weary and can't find the EOF on the last save set to > position the beginning of the last backup on this tape. > > I did see that there's a 'set noon' at the top of the DCL. I'm > assuming that since that's there, instead of aborting on some of these > errors, the batch job continued right to the "image backup has > successfully completed" at the end of the .com file, letting the > operator walk away fat 'n happy! guess I better take a look at the > DCL manual for error checking. I'd rather it fail and know about it! > > Thanks to all for the suggestions! keep 'em coming, I don't mind > learning !- Hide quoted text - > > - Show quoted text - Great! I just noticed that that the backup command for the 1st disk had a / norewind. The second had /rewind, and all subsequent have /norewind. Tell me it didn't rewind and write over the 1st save set / image on the tape! BTW - I really did inherit these! ------------------------------ Date: Thu, 27 Sep 2007 16:54:51 -0400 From: "Richard B. Gilbert" Subject: Re: wierd backup behavior Message-ID: <46FC189B.3070108@comcast.net> jhjr4381 wrote: > On Sep 27, 4:18 pm, jhjr4381 wrote: > >>On Sep 26, 12:11 pm, "Richard Brodie" wrote: >> >> >> >> >> >> >>>"jhjr4381" wrote in message >> >>>news:1190822080.542181.314400@o80g2000hse.googlegroups.com... >> >>>>However, the log files show very inconsistent backup activity (number >>>>of files stored - varies by 5-10k), only on the Vax disks, even if >>>>done by itself. >>> >>>One small point, that might help. I wouldn't call the files you create >>>with /LIST log files. They are save set listing files; useful as a record >>>of the contents of the tape. >> >>>The logging information will be in the standard output of where >>>the backup job ran from. That would be the place to start looking >>>for errors. If it's run as a batch job specifying /NOLOG, fix >>>that first. >> >>Paul, >> >>Thanks, wasn't aware of the 'other' .log file being created and found >>them. There were several errors involed over the last few weeks: >> >>$ BACKUP/NOREWIND/LIST=DKA100:[BACKUP]DUA510FUL.LOG/IMAGE - >> /NOALIAS - >> /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA510: >>- >> RDAXP$MKB500:DUA510.BCK >>%BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;198 >>-RMS-E-EXT, ACP file extend failed >>-SYSTEM-F-EXQUOTA, process quota exceeded >> >>So, I gather there's a user or system set quota getting exceeded. How >>can I display the user/process quota that's causing the problem? >> >>%BACKUP-E-READVERR, virtual read error on file [CMSLIB.MAN110.CMS >>$034]MGA410_F.I >>FDL;5 at block 69 >>-SYSTEM-F-FORCEDERROR, forced error flagged in last sector read >> >>This looks like a problem with the disk. However, it looks like it >>bypasses these files and continues.Use ANALYSE disk and check/fix it >>out. Restore if necessary/able? >> >>$ BACKUP/NOREWIND/LIST=SYS$SYSDEVICE:[BACKUP]DUA600FUL.LOG/IMAGE - >> /NOALIAS - >> /RECORD/IGNORE=(INTERLOCK,LABEL,NOBACKUP)/NOASSIST $1$DUA600: >>- >> RDAXP$MKB500:DUA600.BCK >>%BACKUP-F-POSITERR, error positioning RDAXP$MKB500:[000000]DUA600.BCK; >>-SYSTEM-F-OPINCOMPL, operation is incomplete >> >>This is on the 8th disk of the backup. It seems as if the tape drive >>has gotten a bit weary and can't find the EOF on the last save set to >>position the beginning of the last backup on this tape. >> >>I did see that there's a 'set noon' at the top of the DCL. I'm >>assuming that since that's there, instead of aborting on some of these >>errors, the batch job continued right to the "image backup has >>successfully completed" at the end of the .com file, letting the >>operator walk away fat 'n happy! guess I better take a look at the >>DCL manual for error checking. I'd rather it fail and know about it! >> >>Thanks to all for the suggestions! keep 'em coming, I don't mind >>learning !- Hide quoted text - >> >>- Show quoted text - > > > Great! > > I just noticed that that the backup command for the 1st disk had a / > norewind. The second had /rewind, and all subsequent have /norewind. > Tell me it didn't rewind and write over the 1st save set / image on > the tape! BTW - I really did inherit these! > If you insist, I will lie to you! The second backup did not rewind the tape and then overwrite it. I hope that makes you feel better. Now excuse me for a moment while I wash out my mouth with soap! NEVER rely on anyone else's backup procedures, or even your own, until you have tested your ability to do a satisfactory restore! FWIW, I set an expiration date on my backup tapes, two weeks for a weekly backup, in order to catch this sort of problem. It's good to be a little paranoid about this sort of thing!! It has meant being paged occasionally when a backup fails but better that than overwriting a backup I might need. No matter how explicit the instructions, someday, somebody is going to mount the wrong tape! It might even be you! ------------------------------ Date: Thu, 27 Sep 2007 18:31:17 -0600 From: Jeff Campbell Subject: Re: wierd backup behavior Message-ID: <1190939194_1127@sp12lax.superfeed.net> Norm, This message contains HTML formatting that sets the font size to 2, making it very hard to read. 8-)

Jeff > > > > > "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 ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- ------------------------------ Date: Thu, 27 Sep 2007 19:38:42 -0500 From: Ron Johnson Subject: Re: wierd backup behavior Message-ID: On 09/27/07 15:54, Richard B. Gilbert wrote: [snip] > > FWIW, I set an expiration date on my backup tapes, two weeks for a > weekly backup, in order to catch this sort of problem. It's good to be > a little paranoid about this sort of thing!! It has meant being paged > occasionally when a backup fails but better that than overwriting a > backup I might need. No matter how explicit the instructions, someday, > somebody is going to mount the wrong tape! It might even be you! SLS is your friend. Damned shame HP isn't porting it to ia64. -- 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! ------------------------------ End of INFO-VAX 2007.529 ************************