INFO-VAX Tue, 09 Sep 2008 Volume 2008 : Issue 495 Contents: Re: Current status? Re: Current status? Re: Current status? Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: DEFCON 16 and Hacking OpenVMS Re: huge USB disks and VMS Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Intermittent RWSCS state Re: Looking for TSM scripts to capture and restore terminal settings. Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Loose Cannon-dian Re: Multinet NTP Re: Note to Island Computers customers ---------------------------------------------------------------------- Date: 9 Sep 2008 12:07:39 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Current status? Message-ID: <6in78aFrljutU1@mid.individual.net> In article , david20@alpha2.mdx.ac.uk writes: > In article <6ikm81Frd7puU1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes: >>In article , >> david20@alpha2.mdx.ac.uk writes: >>> In article <7h%vk.609$393.335@trnddc05>, John Santos writes: >>>>Bill Gunshannon wrote: >>>>> In article , >>>>> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >>>>> >>>>>>In article , >>>>>>=?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= >>>>>>writes: >>>>>> >>>>>> >>>> >>>>Yup. I think that many of the problems arise because MUAs use the same >>>>protocol (SMTP) and port (25) to send mail to MTAs as MTAs use to relay >>>>mail to each other. >>> >>> Modern MTAs can be configured to allow mail clients to submit mail to them on >>> the mail submission port (port 587) rather than port 25. See RFC 2476 >>> http://www.faqs.org/rfcs/rfc2476.html >> >>What does this buy you? You would still need to know who your MTA is >>andc it would still need to be willing to accept email from you. It is >>all the silly little notification apps that wree brought up here as >>justification for allowing anybody to use port 25. They have no builtin >>method of authenticating so the port number used changes nothing. I >>certainly would not accept email on my MTA from someone on port 587 that >>I would not also accept on port 25. The purpose of port 587 sand RFC >>2476 is noto to control SPAM it is to make sure outgoing email meets >>the proper formating requoirements of the other RFC's. >> > As RFC 2476 says in section 1 > > " > Separating messages into submissions and transfers allows developers > and network administrators to more easily: > > * Implement security policies and guard against unauthorized mail > relaying or injection of unsolicited bulk mail > > * Implement authenticated submission, including off-site submission > by authorized users such as travelers > " > > > In order for SMTP mail to function your MTA has to accept connections on port > 25 from pretty much anywhere. You cannot setup port 25 to only accept > unauthenticated mail from certain internal systems and to require all other > mail to be authenticated because that would stop you receiving mail from all > over the world. True. > However with the submission port you can set it up so that it > will only accept unauthenticated connections from certain internal addresses > and will REQUIRE all other connections to be authenticated using > SASL/SMTP-AUTH. Hence you can split mail into two different trust levels - > mail coming over port 25 and the more trusted mail from your own > users/internal systems coming over the submission port. I don't have a problem with my internal users being on port 25 and unauthenticated. They are "authenticated" by being inside my firewall. It's the outsiders that are the problem. None of my machines are or ever has been "zombied". > This also ties in with anti-spam measures such as SPF where you can no longer > have your homeworkers using their work domain when sending mail out through > their local ISP but instead have to have them sending via your organisation's > MTAs (since those are the only MTAs registered to be able to use that domain). > To prevent anti-relaying you will need your remote users to authenticate using > SASL/SMTP-AUTH when sending through your organisation's MTAs and this is best > accomplished using the submission port (not least because the ISP may well be > blocking direct connections to external systems over port 25 but should not be > blocking the submission port - which should be more secure since anyone setting > it up should require remote connections to it to be authenticated). Or, use a VPN and leave them on the inside, where they belong. None of this "submission port" stuff addresses the real problem in any way. My MTA must have port 25 open to the world and I am still left trying to use RBL's to identify those who should not be connecting to me. This is reactive and relies on an unreliable method and requires trust of people I have no particular reason to trust. Not a very good security model. > >>> >>> >>>> On the other hand MTAs talk to MUAs (when delivering >>>>mail) using either of 2 different protocols (that I know of), POP3 on >>>>port 110 and IMAP on port 143. (I don't think anything does POP2 on >>>>port 109 any more.) >>> >>> Logically there are three parties involved not two. >>> MTA, MUA and Message store. >> >>Not sure what you make as differnt with "Message store". Unless you >>are separating the guy MTA from the machine that runs POP or IMAP. >>I don't see that as necessarily being a separate Email function although >>it is possible and may even have some utility on a big enough system. >> > > A POP Server, IMAP Server and SMTP server are three totally different services. > The point is that POP and IMAP are not used by the MTA to deliver mail to > anybody. POP and IMAP are as explained below strictly used to access the > message store. > > ie the statement > > " > On the other hand MTAs talk to MUAs (when delivering > mail) using either of 2 different protocols (that I know of), POP3 on > port 110 and IMAP on port 143. (I don't think anything does POP2 on > port 109 any more.) > " > > is nonsense. Well, I wouldn't have gone that far but I would assume the person saying it has a very limited understanding of how email really works. That would put him/her in a group made up of 99% of email users. :-) > > >>> >>> The MTA delivers mail to another MTA or to a message store. >>> The MUA originates mail and sends it to a MTA. >>> Mail clients generally incorporate the above MUA functionality together with >>> the ability to display and manipulate mail in the message store. >>> >>> POP and IMAP are protocols used to access and manipulate the message store. >>> They are NOT used to deliver mail to the message store. >> >>Agreed, but the "Message Store" is not necessarily even a part of the >>Email system and I don't believe it has ever been considered by IETF. >>I have users who use NFS to read their email. Does that make NFS an >>Email Protocol, too? And, of course, Wessage Store is also irrelevant >>to the problem of how to get the email system to be more immune to SPAM. >> >>> >>> Note. >>> >>> The SMTP servers which come with the TCPIP stacks (TCPWARE, MULTINET or TCPIP >>> SERVICES/UCX) are NOT fully fledged modern MTAs. For that you would need either >>> PMDF or MX. >>> ( >>> PMDF is a commercial product but is available free for hobbyist use. >>> MX is now an open-source free product see >>> http://www.madgoat.com/ >>> However I'm not aware of anyone currently continuing development of MX. >>> ) >>> >> >>Maybe so, but if people played by the rules, basic SMTP is more than adequate >>to the task. If ISP's blocked port 25 for all machines in their domain other >>than their MTA I would need to filter incoming ports on my end. And RBL's >>would rapidly become redundant. >> > Unfortunately we haven't even managed to get to the position where every ISP > and company in the USA and Europe block port 25 for all bar their MTAs let > alone the rest of the world. Since that and other measures aren't likely to be > adopted soon we are left with trying to shore up our own front-door defenses. As I have said numerous times before you will never find a technological solution because this is a social problem. The solution exists. The only argument against it to date has been the administrative overhead looks immense. But, when you look at the effort spent trying to "shore up" the existing system the one time effort of my proposal plaes in comparison. > >>Sadly, we are forced to spend a lot of time effort and technology trying >>to, once again, solve a social problem. A social solution would work a >>lot better. >> > True but unfortunately it is one thing to get a small group of like minded > people to agree to and follow a social solution. It is another matter to get > everybody in the whole world to agree. You don't need to get everyone. Just the people who run the email system(s) and want to see it work and require a lot less of thier time than it does now. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 9 Sep 2008 12:28:07 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Current status? Message-ID: <6in8enFqj21fU1@mid.individual.net> In article <48c5d531$0$4543$c3e8da3@news.astraweb.com>, JF Mezei writes: > Bill Gunshannon wrote: > >> ISP's can and should be doing this now. It doesn't need another port. >> All their internal MUA's can use port 25 as it is no differnt than their >> using port 587. No one but there MTA should be sending outside their >> email domain on port 25 or accepting incoming email connection on port >> 25. Adding a "submission" port doesn't change that. > > Hotmail, Yahoo, Gmail and another "mass market" email provider would > disagree. They need a way for users to submit emails sign by their > addresses to their servers. I didn't say there was no use for the service on port 587. I said it was irrelevant to wether or not port 25 should be blocked for all machines in your email domain other than your real, legitimate MTA. If they choose to accept connection from anyone on the outside, that is their right, but again, it is irrelevant to the question of wether or not one should allow one's users to send directly to other MTA's. > > From a spam protection point of view, those services don't want people > to send emails signed by their domain via some ISP's SMTP server because > that ISP has no way to authenticate those users. When you allow your users to talk directly to other MTA's you really have little control over what domain they "sign" their emails with. Another reason why you need to force all email thru your MTA. > > 587 bypasses the port 25 blocks, and allows anyone to connect to the > yahoo/hotmail/gmail SMTP servers to authenticate and send their emails. But the problem isn't that someone uses 587 it is that contrary to what you seem to think, port 25 is not being blocked in most places, particulary ISP's. > This way, it allows people to refuse emails signedby some yahoo.com > email address unless it comes from a yahoo.com email server. (aka: SPF > checking). Once again, you are placing the burden and the cost on the receiving end. It would be better to prevent it rather than try to remediate it. And it can be done!! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 9 Sep 2008 08:50:31 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Current status? Message-ID: In article <08090813522875_20201252@antinode.info>, sms@antinode.info (Steven M. Schweda) writes: > > Perhaps those Germans could tell that you were "in the process of > learning" German. Almost certainly. What Germans speak and what is taught in schools never quite matches. Most Germans will notice and politely switch to the standard so you can communicate. You have to live in Germany for quite some time to pick up the local speach. ------------------------------ Date: Tue, 9 Sep 2008 00:46:03 -0700 (PDT) From: Volker Halle Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: On 8 Sep., 14:56, IanMiller wrote: > VAXSMGRMUP01_062, ECO Kit has been announced. This fixes SMGRTL for > VAX/VMS V6.2. > > Keep watching for more announcements. Note that you may not be able to expand this kit on OpenVMS VAX V6.2: $ run VAXSMGRMUP01_062.ZIPEXE %DCL-W-ACTIMAGE, error activating image VAXSMGRMUP01_062.ZIPEXE -CLI-E-IMGNAME, image file DSA10:VAXSMGRMUP01_062.ZIPEXE;1 -SYSTEM-F-BADIMGHDR, bad image header Expanding the kit on OpenVMS VAX V7.3 works fine, as well as installation on V6.2 Volker. ------------------------------ Date: Tue, 9 Sep 2008 07:11:57 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <08090907115775_20201252@antinode.info> From: Volker Halle > Note that you may not be able to expand this kit on OpenVMS VAX V6.2: > > $ run VAXSMGRMUP01_062.ZIPEXE > %DCL-W-ACTIMAGE, error activating image VAXSMGRMUP01_062.ZIPEXE > -CLI-E-IMGNAME, image file DSA10:VAXSMGRMUP01_062.ZIPEXE;1 > -SYSTEM-F-BADIMGHDR, bad image header > > Expanding the kit on OpenVMS VAX V7.3 works fine, as well as > installation on V6.2 The _easy_ way might not work, but I suspect that you could use your own UnZip program on the thing, too, like: unzip VAXSMGRMUP01_062.ZIPEXE Other than an ignorable warning message about some extra bytes at the beginning, it normally works. If I can do it on a Mac, it should work on a VMS V6.2 system: $ chmod a+x VAXSMGRMUP01_062.ZIPEXE $ ./VAXSMGRMUP01_062.ZIPEXE bash: ./VAXSMGRMUP01_062.ZIPEXE: cannot execute binary file $ unzip6em VAXSMGRMUP01_062.ZIPEXE Archive: VAXSMGRMUP01_062.ZIPEXE warning [VAXSMGRMUP01_062.ZIPEXE]: 50688 extra bytes at beginning or within zipfile (attempting to process anyway) inflating: vaxsmgrmup01_062.a $ The VMS team tends to use some obsolete, old, slow UnZipSFX executable(s) when it constructs its .ZIPEXE kits, so I normally use an explicit (modern, faster) UnZip when I unpack them. It saves some seconds on a large kit. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 9 Sep 2008 06:08:52 -0700 (PDT) From: IanMiller Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <54241dfb-473c-4d44-bf73-b3b493262bf4@z72g2000hsb.googlegroups.com> On Sep 9, 1:11=A0pm, s...@antinode.info (Steven M. Schweda) wrote: > From: Volker Halle > > > Note that you may not be able to expand this kit on OpenVMS VAX V6.2: > > > $ run VAXSMGRMUP01_062.ZIPEXE > > %DCL-W-ACTIMAGE, error activating image VAXSMGRMUP01_062.ZIPEXE > > -CLI-E-IMGNAME, image file DSA10:VAXSMGRMUP01_062.ZIPEXE;1 > > -SYSTEM-F-BADIMGHDR, bad image header > > > Expanding the kit on OpenVMS VAX V7.3 works fine, as well as > > installation on V6.2 > > =A0 =A0The _easy_ way might not work, but I suspect that you could use yo= ur > own UnZip program on the thing, too, like: > > =A0 =A0 =A0 unzip VAXSMGRMUP01_062.ZIPEXE > > Other than an ignorable warning message about some extra bytes at the > beginning, it normally works. =A0If I can do it on a Mac, it should work > on a VMS V6.2 system: > > $ chmod a+x VAXSMGRMUP01_062.ZIPEXE > > $ ./VAXSMGRMUP01_062.ZIPEXE > bash: ./VAXSMGRMUP01_062.ZIPEXE: cannot execute binary file > > $ unzip6em VAXSMGRMUP01_062.ZIPEXE > Archive: =A0VAXSMGRMUP01_062.ZIPEXE > warning [VAXSMGRMUP01_062.ZIPEXE]: =A050688 extra bytes at beginning or > within zipfile > =A0 (attempting to process anyway) > =A0 inflating: vaxsmgrmup01_062.a =A0 =A0 =A0 > $ > > =A0 =A0The VMS team tends to use some obsolete, old, slow UnZipSFX > executable(s) when it constructs its .ZIPEXE kits, so I normally use an > explicit (modern, faster) UnZip when I unpack them. =A0It saves some > seconds on a large kit. > > ------------------------------------------------------------------------ > > =A0 =A0Steven M. Schweda =A0 =A0 =A0 =A0 =A0 =A0 =A0 sms@antinode-info > =A0 =A0382 South Warwick Street =A0 =A0 =A0 =A0(+1) 651-699-9818 > =A0 =A0Saint Paul =A0MN =A055105-2547 Using UnZip 5.50 of 17 February 2002, on VAX/VMS V6.2 it does unzip without problem. The VAXSMGRMUP01_073 kit has been announced. I don't yet see it on the ftp site. ------------------------------ Date: Tue, 9 Sep 2008 08:14:42 -0500 (CDT) From: sms@antinode.info (Steven M. Schweda) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <08090908144201_20201251@antinode.info> From: IanMiller > Using UnZip 5.50 of 17 February 2002, on VAX/VMS V6.2 it does unzip > without problem. What could go wrong? It'd probably work even better (faster) with the curent released version ("UnZip 5.52 of 28 February 2005"). Just a thought. SMS. ------------------------------ Date: 9 Sep 2008 08:44:47 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: DEFCON 16 and Hacking OpenVMS Message-ID: <4cHdyM4mwJJ3@eisner.encompasserve.org> In article , Volker Halle writes: > On 8 Sep., 14:56, IanMiller wrote: >> VAXSMGRMUP01_062, ECO Kit has been announced. This fixes SMGRTL for >> VAX/VMS V6.2. >> >> Keep watching for more announcements. > > Note that you may not be able to expand this kit on OpenVMS VAX V6.2: > > $ run VAXSMGRMUP01_062.ZIPEXE > %DCL-W-ACTIMAGE, error activating image VAXSMGRMUP01_062.ZIPEXE > -CLI-E-IMGNAME, image file DSA10:VAXSMGRMUP01_062.ZIPEXE;1 > -SYSTEM-F-BADIMGHDR, bad image header > > Expanding the kit on OpenVMS VAX V7.3 works fine, as well as > installation on V6.2 In that case the kit should be re-issued. ------------------------------ Date: Tue, 9 Sep 2008 07:26:10 -0700 (PDT) From: Len Whitwer Subject: Re: huge USB disks and VMS Message-ID: <85991a5e-4474-44c6-b54d-b1ce39cec176@26g2000hsk.googlegroups.com> On Sep 8, 11:46=A0am, bro...@cuebid.ovms.usa.hp.nospam (Rob Brooks) wrote: > Howard S Shubs writes: > > > In article , > > =A0bro...@cuebid.ovms.usa.hp.nospam (Rob Brooks) wrote: > > >> This will theoretically allow volumes up to 2TB in size. > > > I'd be surprised if they stop there. =A0Such disks may well be out by t= hen. > > The ~2TB limit is not particularly arbitrary -- that's the max allowed wi= thin > the contraints of an unsigned 32-bit longword. > > I'm pretty sure that there are no plans to develop a new file > system whose volumes can exceed 2TB. > > -- > > Rob Brooks =A0 =A0MSL -- Marlborough =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0brook= s!cuebid.ovms.usa.hp.com We have run 300GB disks straight off a SCSI controller on Alpha and Itanium systems with no problem. If you want one let me know as we sell them all the time. Len Whitwer -Len Whitwer Puget Sound Data Systems, Inc. 19501 144th Ave. NE Suite D-100 Woodinville, WA 98072 e-mail mailto:len@psds.com Internet: http://www.psds.com Toll Free: (866)857-0710 Tel: (425) 488-0710 Fax: (425) 488-6414 ------------------------------ Date: Tue, 9 Sep 2008 11:19:15 +0100 From: "Richard Brodie" Subject: Re: Intermittent RWSCS state Message-ID: wrote in message news:OFDA6706DB.BD1EE946-ON852574BE.005D0F8B-852574BE.005D25CF@metso.com... > How about more buffers for MSCP? Depends how easy a reboot is for you; a quick tune up with AUTOGEN and a reboot might help a bit. Identifying the bottleneck is likely to be a much bigger win, if you can do something about it, and it could be caused by something simple like a duplex mismatch. ------------------------------ Date: Tue, 9 Sep 2008 04:13:53 -0700 (PDT) From: Jim Subject: Re: Intermittent RWSCS state Message-ID: <7807fb7e-e617-42ee-ac79-c93ff699e137@l64g2000hse.googlegroups.com> On Sep 9, 6:19=A0am, "Richard Brodie" wrote: > wrote in message > > news:OFDA6706DB.BD1EE946-ON852574BE.005D0F8B-852574BE.005D25CF@metso.com.= .. > > > How about more buffers for MSCP? > > Depends how easy a reboot is for you; a quick tune up with AUTOGEN and > a reboot might help a bit. Identifying the bottleneck is likely to be a m= uch bigger > win, if you can do something about it, and it could be caused by somethin= g simple > like a duplex mismatch. Or perhaps this is related to an increase in load? You might use "SHOW CLUS/CONT" and "ADD CR_WAITS". If you're seeing non-zero values here you might want considder increasing the number of buffers available for SCS via SYSGEN's CLUSTER_CREDITS (which is not dynamic). Also consider that you might have saturated your cluster interconnect. ------------------------------ Date: 9 Sep 2008 08:47:06 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Intermittent RWSCS state Message-ID: In article <03135b0e-2917-4910-961b-47054e774e89@x41g2000hsb.googlegroups.com>, AEF writes: > > I had this problem circa 1990 as a postdoc at a university. We had > three MicroVAXes networked together and to the campus network. There > was a period where many of our processes would go and stay in this > RWSCS mode and performance went to hell. I was told it was some kind > of funny network problem, but the Unix machines in our lab were > somehow not affected. I don't recall how it got cleared up, but I > don't think we did anything on the VAX side. (We didn't have a real > system manager at the time -- I was primarily a user and just trying > to keep things running as I was just starting to do system manager- > type work.) It could be due to a broadcast storm. We had a lot of these when we first introduced UNIX systems, at that time they tended to be set up with all kinds of broadcast services enabled (rwho et. al.). ------------------------------ Date: Tue, 9 Sep 2008 09:57:01 -0400 From: norm.raphael@metso.com Subject: Re: Intermittent RWSCS state Message-ID: This is a multipart message in MIME format. --=_alternative 004CA0AE852574BF_= Content-Type: text/plain; charset="US-ASCII" Jim wrote on 09/09/2008 07:13:53 AM: > On Sep 9, 6:19 am, "Richard Brodie" wrote: > > wrote in message > > > > news:OFDA6706DB.BD1EE946-ON852574BE.005D0F8B-852574BE.005D25CF@metso.com... > > > > > How about more buffers for MSCP? > > > > Depends how easy a reboot is for you; a quick tune up with AUTOGEN and > > a reboot might help a bit. Identifying the bottleneck is likely to > be a much bigger > > win, if you can do something about it, and it could be caused by > something simple > > like a duplex mismatch. > > Or perhaps this is related to an increase in load? You might use "SHOW > CLUS/CONT" and "ADD CR_WAITS". If you're seeing non-zero values here > you might want considder increasing the number of buffers available > for SCS via SYSGEN's CLUSTER_CREDITS (which is not dynamic). Also > consider that you might have saturated your cluster interconnect. There is a lot of MGA tape activity and a lot of 100MB Ethernet activity, but the SCS communication is on FDDI and nothing else is. It's all on one machine, so lock remastering should not be involved. Disks are MSCP served to a VAX, but there is virtually zero activity on said VAX. MSCP Buffers are not stressed, to wit (from autogen) MSCP_BUFFER parameter information: Feedback information. Old value was 1024, New value is 1024 MSCP server I/O rate: 1 I/Os per 10 sec. I/Os that waited for buffer space: 0 I/Os that fragmented into multiple transfers: 0 SCSCONNCNT parameter information: Feedback information. Old value was 18, New value is 18 Peak number of nodes: 3 Number of CDT allocation failures: 0 SCSRESPCNT parameter information: Feedback information. Old value was 300, New value is 300 RDT stall count: 0 SCSBUFFCNT parameter information: Feedback information. Old value was 512, New value is 512 CIBDT stall count: 0 [This may wrap ugly is some readers] View of Cluster from system ID 1029 node: NODEA 9-SEP-2008 09:50:30 +---------------------------------------------------------------------------------------------------+ | SYSTEMS| CIRCUITS| COUNTERS | |--------+---------+--------------------------------------------------------------------------------| | NODE | NUM_CON | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S | KB_RCVD | KB_MAPP | CR_WAITS | |--------+---------+-----------+-----------+--------+--------+------+----------+---------+----------| | NODEA | 0 | | | | | | | | | | NODEB | 4 | 410394 | 773572 | 0 | 35669 | 0 | 30349 | 130759 | 0 | | | | 249969 | 249969 | 0 | 0 | 0 | 0 | 0 | 0 | | | | 249971 | 249937 | 0 | 0 | 0 | 0 | 0 | 11 | | | | 303127951 | 135155195 | 473 | 231660 | 296 | 109387 | 129875 | 2594 | | VAX_C | 3 | 3238038 | 3238038 | 0 | 0 | 0 | 0 | 3637418 | 0 | | | | 249956 | 249922 | 0 | 0 | 0 | 0 | 0 | 24 | | | | 775863838 | 373422366 | 1 | 95 | 1 | 44 | 11453 | 33599 | +---------------------------------------------------------------------------------------------------+ Can you explain what each of the connections is and what the CR_WAITS data points represent? --=_alternative 004CA0AE852574BF_= Content-Type: text/html; charset="US-ASCII"



Jim <mckinneyj@saic.com> wrote on 09/09/2008 07:13:53 AM:

> On Sep 9, 6:19 am, "Richard Brodie" <R.Bro...@rl.ac.uk> wrote:
> > <norm.raph...@metso.com> wrote in message
> >
> > news:OFDA6706DB.BD1EE946-ON852574BE.005D0F8B-852574BE.005D25CF@metso.com...
> >
> > > How about more buffers for MSCP?
> >
> > Depends how easy a reboot is for you; a quick tune up with AUTOGEN and
> > a reboot might help a bit. Identifying the bottleneck is likely to
> be a much bigger
> > win, if you can do something about it, and it could be caused by
> something simple
> > like a duplex mismatch.
>
> Or perhaps this is related to an increase in load? You might use "SHOW
> CLUS/CONT" and "ADD CR_WAITS". If you're seeing non-zero values here
> you might want considder increasing the number of buffers available
> for SCS via SYSGEN's CLUSTER_CREDITS (which is not dynamic). Also
> consider that you might have saturated your cluster interconnect.

There is a lot of MGA tape activity and a lot of 100MB Ethernet activity,
but the SCS communication is on FDDI and nothing else is.  It's all on
one machine, so lock remastering should not be involved.  Disks are
MSCP served to a VAX, but there is virtually zero activity on said VAX.
MSCP Buffers are not stressed, to wit (from autogen)

MSCP_BUFFER parameter information:
        Feedback information.
           Old value was 1024, New value is 1024
           MSCP server I/O rate: 1 I/Os per 10 sec.
           I/Os that waited for buffer space: 0
           I/Os that fragmented into multiple transfers: 0

SCSCONNCNT parameter information:
        Feedback information.
           Old value was 18, New value is 18
           Peak number of nodes: 3
           Number of CDT allocation failures: 0

SCSRESPCNT parameter information:
        Feedback information.
           Old value was 300, New value is 300
           RDT stall count: 0

SCSBUFFCNT parameter information:
        Feedback information.
           Old value was 512, New value is 512
           CIBDT stall count: 0

[This may wrap ugly is some readers]

View of Cluster from system ID 1029  node: NODEA          9-SEP-2008 09:50:30
+---------------------------------------------------------------------------------------------------+
| SYSTEMS| CIRCUITS|                                    COUNTERS                                    |
|--------+---------+--------------------------------------------------------------------------------|
|  NODE  | NUM_CON | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S |  KB_RCVD | KB_MAPP | CR_WAITS |
|--------+---------+-----------+-----------+--------+--------+------+----------+---------+----------|
| NODEA  |       0 |           |           |        |        |      |          |         |          |
| NODEB  |       4 |    410394 |    773572 |      0 |  35669 |    0 |    30349 |  130759 |        0 |
|        |         |    249969 |    249969 |      0 |      0 |    0 |        0 |       0 |        0 |
|        |         |    249971 |    249937 |      0 |      0 |    0 |        0 |       0 |       11 |
|        |         | 303127951 | 135155195 |    473 | 231660 |  296 |   109387 |  129875 |     2594 |
| VAX_C  |       3 |   3238038 |   3238038 |      0 |      0 |    0 |        0 | 3637418 |        0 |
|        |         |    249956 |    249922 |      0 |      0 |    0 |        0 |       0 |       24 |
|        |         | 775863838 | 373422366 |      1 |     95 |    1 |       44 |   11453 |    33599 |
+---------------------------------------------------------------------------------------------------+

Can you explain what each of the connections is and what the CR_WAITS data points represent? --=_alternative 004CA0AE852574BF_=-- ------------------------------ Date: Tue, 9 Sep 2008 15:06:54 +0100 From: "Richard Brodie" Subject: Re: Intermittent RWSCS state Message-ID: wrote in message news:OF6EDFA192.FC75DB10-ON852574BF.004C241C-852574BF.004CA0B0@metso.com... > Can you explain what each of the connections is and what the CR_WAITS data points > represent? You might like to add LOC_PROC_NAME. ------------------------------ Date: Tue, 9 Sep 2008 10:50:44 -0400 From: norm.raphael@metso.com Subject: Re: Intermittent RWSCS state Message-ID: This is a multipart message in MIME format. --=_alternative 00518B80852574BF_= Content-Type: text/plain; charset="US-ASCII" "Richard Brodie" wrote on 09/09/2008 10:06:54 AM: > > wrote in message > news:OF6EDFA192.FC75DB10-ON852574BF.004C241C-852574BF.004CA0B0@metso.com.. . > > > Can you explain what each of the connections is and what the CR_WAITS data points represent? Okay, thanks so now we know what they are, but not if things are good or bad. > > You might like to add LOC_PROC_NAME. > > [This may wrap ugly is some readers] View of Cluster from system ID 1029 node: NODEA 9-SEP-2008 10:39:18 +---------------------------------------------------------------------------------------------------------------------------+ | SYSTEMS| CIRCUITS | CONNECTIONS | COUNTERS | |--------+-----------------+------------------+-----------------------------------------------------------------------------| | NODE | NUM_CON | SCS_W | LOC_PROC_NAME | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S | KB_RCVD | KB_MAPP | CR_WAI | |--------+---------+-------+------------------+-----------+-----------+--------+--------+------+---------+---------+--------| | NODEA | 0 | 0 | | | | | | | | | | | | | | SCS$DIRECTORY | | | | | | | | | | | | | MSCP$TAPE | | | | | | | | | | | | | MSCP$DISK | | | | | | | | | | | | | VMS$SDA_AXP | | | | | | | | | | | | | VMS$VAXcluster | | | | | | | | | | | | | SCA$TRANSPORT | | | | | | | | | | NODEB | 4 | 0 | SCA$TRANSPORT | 410709 | 774143 | 0 | 35699 | 0 | 30374 | 130859 | 0 | | | | | VMS$DISK_CL_DRVR | 250115 | 250115 | 0 | 0 | 0 | 0 | 0 | 0 | | | | | MSCP$DISK | 250117 | 250083 | 0 | 0 | 0 | 0 | 0 | 11 | | | | | VMS$VAXcluster | 303745994 | 135439083 | 480 | 231950 | 311 | 109534 | 130050 | 2594 | | VAX_C | 3 | 0 | VMS$DISK_CL_DRVR | 3238190 | 3238190 | 0 | 0 | 0 | 0 | 3637427 | 0 | | | | | MSCP$DISK | 250102 | 250068 | 0 | 0 | 0 | 0 | 0 | 24 | | | | | VMS$VAXcluster | 778750617 | 374801466 | 1 | 95 | 1 | 44 | 11469 | 33635 | +---------------------------------------------------------------------------------------------------------------------------+ norm.raphael@metso.com wrote on 09/09/2008 09:57:01 AM: > [This may wrap ugly is some readers] > > View of Cluster from system ID 1029 node: NODEA 9-SEP-200809:50:30 > > +---------------------------------------------------------------------------------------------------+ > | SYSTEMS| CIRCUITS| COUNTERS | > |--------+---------+--------------------------------------------------------------------------------| > | NODE | NUM_CON | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S | KB_RCVD | KB_MAPP | CR_WAITS | > |--------+---------+-----------+-----------+--------+--------+------+----------+---------+----------| > | NODEA | 0 | | | | | | | | | > | NODEB | 4 | 410394 | 773572 | 0 | 35669 | 0 | 30349 | 130759 | 0 | > | | | 249969 | 249969 | 0 | 0 | 0 | 0 | 0 | 0 | > | | | 249971 | 249937 | 0 | 0 | 0 | 0 | 0 | 11 | > | | | 303127951 | 135155195 | 473 | 231660 | 296 | 109387 | 129875 | 2594 | > | VAX_C | 3 | 3238038 | 3238038 | 0 | 0 | 0 | 0 | 3637418 | 0 | > | | | 249956 | 249922 | 0 | 0 | 0 | 0 | 0 | 24 | > | | | 775863838 | 373422366 | 1 | 95 | 1 | 44 | 11453 | 33599 | > +---------------------------------------------------------------------------------------------------+ --=_alternative 00518B80852574BF_= Content-Type: text/html; charset="US-ASCII"

"Richard Brodie" <R.Brodie@rl.ac.uk> wrote on 09/09/2008 10:06:54 AM:

>
> <norm.raphael@metso.com> wrote in message
> news:OF6EDFA192.FC75DB10-ON852574BF.004C241C-852574BF.004CA0B0@metso.com...
>
> > Can you explain what each of the connections is and what the CR_WAITS data points represent?
Okay, thanks so now we know what they are, but not if things are good or bad.

>
> You might like to add LOC_PROC_NAME.
>
>
[This may wrap ugly is some readers]

View of Cluster from system ID 1029  node: NODEA            9-SEP-2008 10:39:18
+---------------------------------------------------------------------------------------------------------------------------+
| SYSTEMS|     CIRCUITS    |    CONNECTIONS   |                                   COUNTERS                                  |
|--------+-----------------+------------------+-----------------------------------------------------------------------------|
|  NODE  | NUM_CON | SCS_W |   LOC_PROC_NAME  | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S | KB_RCVD | KB_MAPP | CR_WAI |
|--------+---------+-------+------------------+-----------+-----------+--------+--------+------+---------+---------+--------|
| NODEA  |       0 |     0 |                  |           |           |        |        |      |         |         |        |
|        |         |       | SCS$DIRECTORY    |           |           |        |        |      |         |         |        |
|        |         |       | MSCP$TAPE        |           |           |        |        |      |         |         |        |
|        |         |       | MSCP$DISK        |           |           |        |        |      |         |         |        |
|        |         |       | VMS$SDA_AXP      |           |           |        |        |      |         |         |        |
|        |         |       | VMS$VAXcluster   |           |           |        |        |      |         |         |        |
|        |         |       | SCA$TRANSPORT    |           |           |        |        |      |         |         |        |
| NODEB  |       4 |     0 | SCA$TRANSPORT    |    410709 |    774143 |      0 |  35699 |    0 |   30374 |  130859 |      0 |
|        |         |       | VMS$DISK_CL_DRVR |    250115 |    250115 |      0 |      0 |    0 |       0 |       0 |      0 |
|        |         |       | MSCP$DISK        |    250117 |    250083 |      0 |      0 |    0 |       0 |       0 |     11 |
|        |         |       | VMS$VAXcluster   | 303745994 | 135439083 |    480 | 231950 |  311 |  109534 |  130050 |   2594 |
| VAX_C  |       3 |     0 | VMS$DISK_CL_DRVR |   3238190 |   3238190 |      0 |      0 |    0 |       0 | 3637427 |      0 |
|        |         |       | MSCP$DISK        |    250102 |    250068 |      0 |      0 |    0 |       0 |       0 |     24 |
|        |         |       | VMS$VAXcluster   | 778750617 | 374801466 |      1 |     95 |    1 |      44 |   11469 |  33635 |
+---------------------------------------------------------------------------------------------------------------------------+
norm.raphael@metso.com wrote on 09/09/2008 09:57:01 AM:


> [This may wrap ugly is some readers]
>
> View of Cluster from system ID 1029  node: NODEA          9-SEP-200809:50:30
>
> +---------------------------------------------------------------------------------------------------+
> | SYSTEMS| CIRCUITS|                                    COUNTERS                                    |
> |--------+---------+--------------------------------------------------------------------------------|
> |  NODE  | NUM_CON | MSGS_SENT | MSGS_RCVD | BLKS_S | BLKS_R | KB_S |  KB_RCVD | KB_MAPP | CR_WAITS |
> |--------+---------+-----------+-----------+--------+--------+------+----------+---------+----------|
> | NODEA  |       0 |           |           |        |        |      |          |         |          |
> | NODEB  |       4 |    410394 |    773572 |      0 |  35669 |    0 |    30349 |  130759 |        0 |
> |        |         |    249969 |    249969 |      0 |      0 |    0 |        0 |       0 |        0 |
> |        |         |    249971 |    249937 |      0 |      0 |    0 |        0 |       0 |       11 |
> |        |         | 303127951 | 135155195 |    473 | 231660 |  296 |   109387 |  129875 |     2594 |
> | VAX_C  |       3 |   3238038 |   3238038 |      0 |      0 |    0 |        0 | 3637418 |        0 |
> |        |         |    249956 |    249922 |      0 |      0 |    0 |        0 |       0 |       24 |
> |        |         | 775863838 | 373422366 |      1 |     95 |    1 |       44 |   11453 |    33599 |
> +---------------------------------------------------------------------------------------------------+ --=_alternative 00518B80852574BF_=-- ------------------------------ Date: Tue, 9 Sep 2008 08:03:53 -0700 (PDT) From: AEF Subject: Re: Intermittent RWSCS state Message-ID: On Sep 9, 9:47=A0am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <03135b0e-2917-4910-961b-47054e774...@x41g2000hsb.googlegroups= .com>, AEF writes: > > > > > I had this problem circa 1990 as a postdoc at a university. We had > > three MicroVAXes networked together and to the campus network. There > > was a period where many of our processes would go and stay in this > > RWSCS mode and performance went to hell. I was told it was some kind > > of funny network problem, but the Unix machines in our lab were > > somehow not affected. I don't recall how it got cleared up, but I > > don't think we did anything on the VAX side. (We didn't have a real > > system manager at the time -- I was primarily a user and just trying > > to keep things running as I was just starting to do system manager- > > type work.) > > =A0 =A0It could be due to a broadcast storm. =A0We had a lot of these whe= n > =A0 =A0we first introduced UNIX systems, at that time they tended to > =A0 =A0be set up with all kinds of broadcast services enabled (rwho et. a= l.). Yes! I believe that's what happened, or so they told me. Thanks for jogging my memory. AEF ------------------------------ Date: Tue, 9 Sep 2008 16:09:02 +0100 From: "Richard Brodie" Subject: Re: Intermittent RWSCS state Message-ID: wrote in message news:OF1D8E67E9.7DD1DEB5-ON852574BF.00508FDB- >Okay, thanks so now we know what they are, but not if things are good or bad. I don't think the CR_WAITS in the VMS$VAXcluster sysap are good news. That's sort of locky rather than bulk traffic. LOCKDIRWT too high on an old VAX? Beyond that I would grab one of Keith Parris' presentations on cluster/ lock manager performance. ------------------------------ Date: Tue, 09 Sep 2008 09:38:20 -0700 From: Marty Kuhrt Subject: Re: Intermittent RWSCS state Message-ID: Richard Brodie wrote: > wrote in message news:OF1D8E67E9.7DD1DEB5-ON852574BF.00508FDB- >> Okay, thanks so now we know what they are, but not if things are good or bad. > > I don't think the CR_WAITS in the VMS$VAXcluster sysap are good news. > That's sort of locky rather than bulk traffic. LOCKDIRWT too high on an old > VAX? Beyond that I would grab one of Keith Parris' presentations on cluster/ > lock manager performance. > > I ran into something similar once that was triggered by my cat slightly pulling the cat-5 cable (cats and cat5 don't mix). Not so much that the network connection was completely lost, but this VAX, in a cluster of Alphas, was joining and leaving the cluster as fast as it could. Everybody else in the cluster was stalling waiting for the transition to finish, which would restart immediately. When I finally got logged into a machine console via a VT and did a reply/enable to see OPCOM stuff, I saw the endless stream of joining/leaving messages from the culprit VAX. Pulled the network cable, reseated it, and all was well when the storm subsided. I've also seen something like this as well when a hub/switch went "kinda bad". Since the VAX in OP's question is probably only talking to the cluster via its 10M network cable, it might be as simple as a that. Bad card, bad cable, bad hub/switch, etc. Babble, babble, babble, and the next thing you know you're knee deep in RWSCS. Since this is a home cluster I use for porting and development work, I don't normally have OPCOM enabled, or do much logging. VMS machines just run right, right? ;^) ------------------------------ Date: Tue, 9 Sep 2008 13:06:00 -0400 From: norm.raphael@metso.com Subject: Re: Intermittent RWSCS state Message-ID: This is a multipart message in MIME format. --=_alternative 005DEE15852574BF_= Content-Type: text/plain; charset="US-ASCII" Marty Kuhrt wrote on 09/09/2008 12:38:20 PM: > Richard Brodie wrote: > > wrote in message news:OF1D8E67E9. > 7DD1DEB5-ON852574BF.00508FDB- > >> Okay, thanks so now we know what they are, but not if things are > good or bad. > > > > I don't think the CR_WAITS in the VMS$VAXcluster sysap are good news. > > That's sort of locky rather than bulk traffic. LOCKDIRWT too high on an old > > VAX? Beyond that I would grab one of Keith Parris' presentations on cluster/ > > lock manager performance. > > > > > > I ran into something similar once that was triggered by my cat slightly > pulling the cat-5 cable (cats and cat5 don't mix). Not so much that the > network connection was completely lost, but this VAX, in a cluster of > Alphas, was joining and leaving the cluster as fast as it could. > Everybody else in the cluster was stalling waiting for the transition to > finish, which would restart immediately. When I finally got logged into > a machine console via a VT and did a reply/enable to see OPCOM stuff, I > saw the endless stream of joining/leaving messages from the culprit > VAX. Pulled the network cable, reseated it, and all was well when the > storm subsided. > > I've also seen something like this as well when a hub/switch went "kinda > bad". > > Since the VAX in OP's question is probably only talking to the cluster > via its 10M network cable, it might be as simple as a that. No such luck. Talking on FDDI for SCS traffic. 10MB network for other. > Bad card, > bad cable, bad hub/switch, etc. Babble, babble, babble, and the next > thing you know you're knee deep in RWSCS. > > Since this is a home cluster I use for porting and development work, I > don't normally have OPCOM enabled, or do much logging. VMS machines > just run right, right? ;^) --=_alternative 005DEE15852574BF_= Content-Type: text/html; charset="US-ASCII"
Marty Kuhrt <marty@spamloop.kuhrt.net> wrote on 09/09/2008 12:38:20 PM:

> Richard Brodie wrote:
> > <norm.raphael@metso.com> wrote in message news:OF1D8E67E9.
> 7DD1DEB5-ON852574BF.00508FDB-
> >> Okay, thanks so now we know what they are, but not if things are
> good or bad.
> >
> > I don't think the CR_WAITS in the VMS$VAXcluster sysap are good news.
> > That's sort of locky rather than bulk traffic. LOCKDIRWT too high on an old
> > VAX? Beyond that I would grab one of Keith Parris' presentations on cluster/
> > lock manager performance.
> >
> >
>
> I ran into something similar once that was triggered by my cat slightly
> pulling the cat-5 cable (cats and cat5 don't mix).  Not so much that the
> network connection was completely lost, but this VAX, in a cluster of
> Alphas, was joining and leaving the cluster as fast as it could.
> Everybody else in the cluster was stalling waiting for the transition to
> finish, which would restart immediately.  When I finally got logged into
> a machine console via a VT and did a reply/enable to see OPCOM stuff, I
>   saw the endless stream of joining/leaving messages from the culprit
> VAX.  Pulled the network cable, reseated it, and all was well when the
> storm subsided.
>
> I've also seen something like this as well when a hub/switch went "kinda
> bad".
>
> Since the VAX in OP's question is probably only talking to the cluster
> via its 10M network cable, it might be as simple as a that.  

No such luck.  Talking on FDDI for SCS traffic.  10MB network for other.

>                                                             Bad card,
> bad cable, bad hub/switch, etc.  Babble, babble, babble, and the next
> thing you know you're knee deep in RWSCS.
>
> Since this is a home cluster I use for porting and development work, I
> don't normally have OPCOM enabled, or do much logging.  VMS machines
> just run right, right?  ;^)
 --=_alternative 005DEE15852574BF_=-- ------------------------------ Date: Tue, 9 Sep 2008 01:09:32 -0700 (PDT) From: Volker Halle Subject: Re: Looking for TSM scripts to capture and restore terminal settings. Message-ID: <28f38b93-c88c-4fbf-9989-ec294d4189ae@34g2000hsh.googlegroups.com> WWWebb, the old Digital DECserver software kits (e.g. DS2xxx and DS7xxx) included DCL scripts to get terminal server setting: MOM$LOAD:TSM $DS*_*_GET_CHAR.COM. You could execute them (they require TSM = Termal Server Manager - now freeware - to be installed and configured) and they would create a servername_SETUP.COM file, which you could later use to re-define the settings. Volker. ------------------------------ Date: Tue, 9 Sep 2008 05:17:28 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: Loose Cannon-dian Message-ID: <5a35efc2-be6d-43d6-8f78-9b8dbe2c1f6d@c65g2000hsa.googlegroups.com> On Sep 7, 12:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <48c09bf8$0$12400$c3e8...@news.astraweb.com>, > JF Mezei writes: > > > Bill Gunshannon wrote: > > >> like is done here frequently, he once again refered to "anything ported > >> from Unix" and described it as "riddled with bugs and buffer overflow > >> risks because it is not really 'native' VMS software". > > > There are Unix concepts which work well in Unix, but when recompiled on > > VMS don't "translate" well. > > And that is Unix's fault how??? > > > > > An example was the pop server. On Unix, there is an option to define the > > filename where the log is to be written by the pop server (deamon in > > Unix terms). This was recompiled on VMS and they didn't think of the impact. > > And that is Unix's fault how??? > > > > > On VMS, the pop server image was installed with privileges. This meant > > that anyone could invoke the program, specify a filename anywhere on the > > system and the program would write a new file at that location (aka: > > ability to overwrite any system files). > > And that is Unix's fault how??? > > Get the picture? None of this is Unix's fault but it sure lays waste > the claim that VMS got all the best programmers and was soooooo much > better engineered than Unix. Don't you think if security was such a > big concern that someone might have looked at the consequences of such > a port? I have ported a lot of software, both to and from Unix and > other OSes (like Primos and DomainOS) and I can assure you I didn't > ever try just blindly compiling code and throwing it into production. > > > > > Another example is the IMAP/POP/XDM servers. They were ported from Unix > > and they did not think of adding the code needed to handle the wrong > > password logging and intrusion detection/evasion mechanisms. > > I doubt thinking had anything to do with it. Much more likely, they > just didn't care. Or didn't see the added security as worth the effort. > After all, it worked fine on Unix without it. :-) > > > So those > > packages don't adhere to VMS standards and thus lower the security of > > the VMS system compared to the good old days where all the software was > > native to VMS and written specifically for VMS using VMS constructs and > > services. > > More bullcrap. I doubt "VMS Standards" or "VMS Security" were even > given a passing glance. There is nothing to show that "security" was > the underlying principle in everything VMS did any more than that Unix > didn't consider it at all. In both cases people had an idea of what > they wanted to make their OSes do and the wrote code to do it. One was > no more guaranteed to be secure than the other. How many years between > the first release of Unix and the first reported case of one of these > "weaknesses" being exploited? It is hardly a shortcoming that Unix > didn't anticipate the change in the moral climate of the world that > has brought us "hackers". > > > > > It has become expected nowadasy to see such problems when software is > > ported from Unix to VMS. Apache excpects text files in a format that is > > not standard for VMS for instance. > > The Apache group does not write software for VMS. They have never > claimed they did. Why would you expect them to program to a "standard" > that isn't their standard? If the software gets ported to VMS it is > VMS programmers doing it. If they do it badly you can't blame the > original author because he chose not use your standard. > > > > >> I was merely > >> pointing out that SMG , while not "ported from Unix" and "really 'native' > >> VMS software" was found to have "bugs and buffer overflow risks". > > > Yes, and it is a rude awakening that even native software that dates > > back many years isn't perfect. What this shows is that quality > > assurance started to go down in the 1990s. > > Or maybe just that the quality of the code, the quality assurance of the > product and, yes, the actual capabilities of the programmers were no > different than anyone else in the industry. The desired result was > different and they produced a product accordingly. And, no matter > how big a piece of the market you would like to think it had, it never > had enough of a footprint to attract the class of people who spent (and > continue to spend) so much time looking for holes in other OSes. Like > I ahve said here before. Primos is still in use commercially. Primos > machines are on the Internet. There are even public machines for people > (read: hackers) to play with. How many CERT vulnerabilities are there > for Primos? > > > > >> That remains to be seen. Because they have never been reported or tracked > >> by any outside source (look at the reluctance to trport any of these recent > >> discoveries to CERT) > > > Personally, I am not sure who is expected to report stuff to CERT. Can > > *anyone* really report stuff, or do they expect to see reports only from > > certain qualified people and/or the vendors ? > > I believe they will take any report. But the then try to verify it with > the responsible parties. It is my understanding that in the case of > VMS the norm is to ignore requests from CERT for these verifications. > > > > >> the idea that DEC's "checks and balances" and "code reviews, walk-throughs, > >> programming standards" were any better than anyone elses. > > > They were. But since the Palmer era, there has bneen so much slash and > > burn done that VMS is no longer what it used to be. > > Sorry, but your claims that they were are no more verifiable than my > claims that they weren't. Mine, however, are probably a lot more > believable. > > > > >> I think no one outside of DEC/Compaq/HP has any idea how many exploits > >> equivalent to those found in Unix have or still exist in VMS. > > > I suspect people outside of HP have a better grasp of the > > vulnerabilities in VMS. HP doesn't care about VMS. > > Not caring and not knowing are nont synonomous. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include While there is much in what you say, your case is not helped by demonstrably dubious claims such as "There is nothing to show that "security" was the underlying principle in everything VMS did any more than that Unix didn't consider it at all". There's plenty of evidence if you look with open eyes. Native VMS code's widespread use of descriptors for varying-length items encourages careful programming and has no equivalent in Windows or any Unix I've seen (since V7, Sys V, and BSD4.1, I've seen a few). Neither Windows nor any Unix in common use has anything like the quotas which VMS has, which when used properly by people with clue provide mechanisms for protecting system integrity against various flavours of accidental or deliberate denial of service. Neither Windows nor any Unix in common use has the multiple independent privileges and object-based protections which VMS has. No Unix in common use has an equivalent of the VMS audit+alarm mechanisms and tools, and WIndows's security event log doesn't really count either. Etc. If you want to compare OSes not in common use then maybe comparing an SELinux setup with a VMS setup is appropriate, but that still leaves VMS mostly ahead (others may obviously disagree). It may be that you do not know many people who have made full use of these VMS facilities, but that does not mean they are not useful when appropriately used by people (and management) with clue. The fact that most folks don't have a clue about these things does seem to indicate that system+software mediocrity is now acceptable and indeed is often "industry standard". If it's "industry standard" it must be OK, mustn't it? ------------------------------ Date: Tue, 9 Sep 2008 07:55:42 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: Loose Cannon-dian Message-ID: <328dfff5-73d9-4dc7-be89-ae311e66bb21@k30g2000hse.googlegroups.com> On Sep 9, 2:33 pm, "Tom Linden" wrote: > On Tue, 09 Sep 2008 05:17:28 -0700, wrote: > > While there is much in what you say, your case is not helped by > > demonstrably dubious claims such as "There is nothing to show that > > "security" was the underlying principle in everything VMS did any more > > than that Unix didn't consider it at all". There's plenty of evidence > > if you look with open eyes. Native VMS code's widespread use of > > descriptors for varying-length items encourages careful programming > > and has no equivalent in Windows or any Unix I've seen (since V7, Sys > > V, and BSD4.1, I've seen a few). > > Descriptors are not part of the OS but a feature of the compilers, and the > concept really came out of languages like PL/I and Algol, we call them > dope vectors. > > -- > PL/I for OpenVMSwww.kednos.com On VMS, descriptors are an integral part of the interface between the OS (where the privileged code lives) and the user code in various languages. Descriptors are (obviously) also available to user-written code in libraries etc. If these things don't routinely use descriptors on incoming and outgoing data, much of their potential usefulness is lost. Fortunately VMS stuff generally does use descriptors. On an OS whose interface doesn't use descriptors (eg the popular ones), there's limited value in having dope vectors, descriptors, whatever, in the compilers. Equally, if the language tools don't readily support descriptors (and I'm thinking e.g. of C here, $descriptor only does half the job), they again become less useful. They're nice to have, they're part of a bigger picture. ------------------------------ Date: 9 Sep 2008 15:11:53 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian Message-ID: <6ini1pFrt3n1U1@mid.individual.net> In article , "Richard B. Gilbert" writes: > Tom Linden wrote: >> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: >> >>> While there is much in what you say, your case is not helped by >>> demonstrably dubious claims such as "There is nothing to show that >>> "security" was the underlying principle in everything VMS did any more >>> than that Unix didn't consider it at all". There's plenty of evidence >>> if you look with open eyes. Native VMS code's widespread use of >>> descriptors for varying-length items encourages careful programming >>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys >>> V, and BSD4.1, I've seen a few). >> >> Descriptors are not part of the OS but a feature of the compilers, and the >> concept really came out of languages like PL/I and Algol, we call them >> dope vectors. >> > > But the O/S can and does use descriptors. The facility is also > available to developers who wish to use it. I think that descriptors > are a little less prone to abuse than null terminated strings. Those > who, for whatever reason, wish to use null terminated strings may do so! And the use of null terminated strings does not mean that security wasn't just as much of a concern to the person using them as the persone using descriptors. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 9 Sep 2008 09:09:44 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: Loose Cannon-dian Message-ID: On Sep 9, 4:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article , > "Richard B. Gilbert" writes: > > > > > Tom Linden wrote: > >> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: > > >>> While there is much in what you say, your case is not helped by > >>> demonstrably dubious claims such as "There is nothing to show that > >>> "security" was the underlying principle in everything VMS did any more > >>> than that Unix didn't consider it at all". There's plenty of evidence > >>> if you look with open eyes. Native VMS code's widespread use of > >>> descriptors for varying-length items encourages careful programming > >>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys > >>> V, and BSD4.1, I've seen a few). > > >> Descriptors are not part of the OS but a feature of the compilers, and the > >> concept really came out of languages like PL/I and Algol, we call them > >> dope vectors. > > > But the O/S can and does use descriptors. The facility is also > > available to developers who wish to use it. I think that descriptors > > are a little less prone to abuse than null terminated strings. Those > > who, for whatever reason, wish to use null terminated strings may do so! > > And the use of null terminated strings does not mean that security wasn't > just as much of a concern to the person using them as the persone using > descriptors. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include Do you want to expand on that a little? Maybe you're not aware that null terminated strings aren't the only area where descriptors apply, but you surely must be aware that null terminated and corresponding buffer overflows and security vulnerabilities aren't exactly uncommon. They're sufficiently common in fact that the C++ experts regard functions like sprintf() as deprecated, to be replaced with band-aids like sprintf_s() and related functions which are allegedly "more secure" than their K+R ancestors. Except they're not really, but let's put that to one side for now, folks like me might be trying to understand how using a brainless and uncheckable data structure like a null terminated string (or null-terminated array of pointers, whatever) can possibly be as "secure" by design as using a structure which can potentially be checked both at compile time and at run time. ------------------------------ Date: Tue, 9 Sep 2008 09:33:10 -0700 (PDT) From: johnwallace4@yahoo.co.uk Subject: Re: Loose Cannon-dian Message-ID: <2261bae7-04f0-411f-9ec9-ba312b98c515@k30g2000hse.googlegroups.com> On Sep 9, 4:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article , > "Richard B. Gilbert" writes: > > > > > Tom Linden wrote: > >> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: > > >>> While there is much in what you say, your case is not helped by > >>> demonstrably dubious claims such as "There is nothing to show that > >>> "security" was the underlying principle in everything VMS did any more > >>> than that Unix didn't consider it at all". There's plenty of evidence > >>> if you look with open eyes. Native VMS code's widespread use of > >>> descriptors for varying-length items encourages careful programming > >>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys > >>> V, and BSD4.1, I've seen a few). > > >> Descriptors are not part of the OS but a feature of the compilers, and the > >> concept really came out of languages like PL/I and Algol, we call them > >> dope vectors. > > > But the O/S can and does use descriptors. The facility is also > > available to developers who wish to use it. I think that descriptors > > are a little less prone to abuse than null terminated strings. Those > > who, for whatever reason, wish to use null terminated strings may do so! > > And the use of null terminated strings does not mean that security wasn't > just as much of a concern to the person using them as the persone using > descriptors. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include And while you're expanding on it, perhaps you'd consider the situation of a machine shop (toolroom, whatever) where all the blade guards have been removed, and all the safety interlocks have been disabled? If I'm understanding you right, that's perfectly OK operating practice in your view, because it "does not mean that safety wasn't just as much of a concern to the person not using the safety mechanisms as it was to the person who was using them"? ------------------------------ Date: 9 Sep 2008 16:46:57 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian Message-ID: <6innk1FrikcdU1@mid.individual.net> In article , johnwallace4@yahoo.co.uk writes: > On Sep 9, 4:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article , >> "Richard B. Gilbert" writes: >> >> >> >> > Tom Linden wrote: >> >> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: >> >> >>> While there is much in what you say, your case is not helped by >> >>> demonstrably dubious claims such as "There is nothing to show that >> >>> "security" was the underlying principle in everything VMS did any more >> >>> than that Unix didn't consider it at all". There's plenty of evidence >> >>> if you look with open eyes. Native VMS code's widespread use of >> >>> descriptors for varying-length items encourages careful programming >> >>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys >> >>> V, and BSD4.1, I've seen a few). >> >> >> Descriptors are not part of the OS but a feature of the compilers, and the >> >> concept really came out of languages like PL/I and Algol, we call them >> >> dope vectors. >> >> > But the O/S can and does use descriptors. The facility is also >> > available to developers who wish to use it. I think that descriptors >> > are a little less prone to abuse than null terminated strings. Those >> > who, for whatever reason, wish to use null terminated strings may do so! >> >> And the use of null terminated strings does not mean that security wasn't >> just as much of a concern to the person using them as the persone using >> descriptors. >> >> bill >> >> -- >> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >> billg...@cs.scranton.edu | and a sheep voting on what's for dinner. >> University of Scranton | >> Scranton, Pennsylvania | #include > > Do you want to expand on that a little? Maybe you're not aware that > null terminated strings aren't the only area where descriptors apply, > but you surely must be aware that null terminated and corresponding > buffer overflows and security vulnerabilities aren't exactly uncommon. > They're sufficiently common in fact that the C++ experts regard > functions like sprintf() as deprecated, to be replaced with band-aids > like sprintf_s() and related functions which are allegedly "more > secure" than their K+R ancestors. Except they're not really, but let's > put that to one side for now, folks like me might be trying to > understand how using a brainless and uncheckable data structure like a > null terminated string (or null-terminated array of pointers, > whatever) can possibly be as "secure" by design as using a structure > which can potentially be checked both at compile time and at run time. I use null terminated strings (and not just in C, they predate C by a bit). I have never written a program that suffered from buffer over-runs. Descriptors may make it easier, but that doesn't change the fact that null terminated strings don't have to be a problem. It's the programmer, not the language. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 9 Sep 2008 16:53:33 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian Message-ID: <6ino0dFrikcdU2@mid.individual.net> In article <2261bae7-04f0-411f-9ec9-ba312b98c515@k30g2000hse.googlegroups.com>, johnwallace4@yahoo.co.uk writes: > On Sep 9, 4:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article , >> "Richard B. Gilbert" writes: >> >> >> >> > Tom Linden wrote: >> >> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: >> >> >>> While there is much in what you say, your case is not helped by >> >>> demonstrably dubious claims such as "There is nothing to show that >> >>> "security" was the underlying principle in everything VMS did any more >> >>> than that Unix didn't consider it at all". There's plenty of evidence >> >>> if you look with open eyes. Native VMS code's widespread use of >> >>> descriptors for varying-length items encourages careful programming >> >>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys >> >>> V, and BSD4.1, I've seen a few). >> >> >> Descriptors are not part of the OS but a feature of the compilers, and the >> >> concept really came out of languages like PL/I and Algol, we call them >> >> dope vectors. >> >> > But the O/S can and does use descriptors. The facility is also >> > available to developers who wish to use it. I think that descriptors >> > are a little less prone to abuse than null terminated strings. Those >> > who, for whatever reason, wish to use null terminated strings may do so! >> >> And the use of null terminated strings does not mean that security wasn't >> just as much of a concern to the person using them as the persone using >> descriptors. >> >> bill >> >> -- >> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >> billg...@cs.scranton.edu | and a sheep voting on what's for dinner. >> University of Scranton | >> Scranton, Pennsylvania | #include > > And while you're expanding on it, perhaps you'd consider the situation > of a machine shop (toolroom, whatever) where all the blade guards have > been removed, and all the safety interlocks have been disabled? If I'm > understanding you right, that's perfectly OK operating practice in > your view, because it "does not mean that safety wasn't just as much > of a concern to the person not using the safety mechanisms as it was > to the person who was using them"? What have I removed that decreases safety when I use null terminated strings? Let's make this a real comparison. Think of null terminated strings as machines that came without the guards. It is the operators responsibility to use them safely. It doesn't mean he or the shop or the machine manufacturer don't care about safety. It just changes where the responsibility lies and the actions needed to remain safe. He can work safely without the guards or he can manufacture guards himself or he can even purchase third party guards. His choice. The same is true of programming. As long as you know how to use your language of chopice properly and safely, choosing one over the other does not mean you care any less about safe programming. It merely means there may have been more than just safety involved in making your decision. It's a poor workman who blames his tools. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 9 Sep 2008 16:54:53 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Loose Cannon-dian Message-ID: <6ino2sFrikcdU3@mid.individual.net> In article , "Tom Linden" writes: > On Tue, 09 Sep 2008 06:55:43 -0700, Bob Koehler > wrote: > >> In article , "Tom Linden" >> writes: >>> On Tue, 09 Sep 2008 05:17:28 -0700, wrote: >>> >>>> While there is much in what you say, your case is not helped by >>>> demonstrably dubious claims such as "There is nothing to show that >>>> "security" was the underlying principle in everything VMS did any more >>>> than that Unix didn't consider it at all". There's plenty of evidence >>>> if you look with open eyes. Native VMS code's widespread use of >>>> descriptors for varying-length items encourages careful programming >>>> and has no equivalent in Windows or any Unix I've seen (since V7, Sys >>>> V, and BSD4.1, I've seen a few). >>> >>> Descriptors are not part of the OS but a feature of the compilers, and >>> the >>> concept really came out of languages like PL/I and Algol, we call them >>> dope vectors. >> >> The use of descriptors for many of the OS APIs is part of the OS. >> > Don't wish to nitpick, but it is the selection of compilers supporting such > constructs that is part of the OS. Languages deficient in such constructs > were enhanced to provide that capability. OS's like Multics, Primos, VOS, > MVS-z/os Burroughs were written in languages in which such constructs are > an integral part of the language. > Primos? A bunch of that was written in Fortran IV. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 9 Sep 2008 03:58:04 -0700 (PDT) From: Jim Subject: Re: Multinet NTP Message-ID: On Sep 8, 9:25=A0pm, Jeff Campbell wrote: > Richard B. Gilbert wrote: > > Jeff Campbell wrote: > >> Hi all, > > >> I decided to switch to the Multinet TCPIP stack on my hobbyist system. > >> Today when I looked at the log files, I found the NTP process > >> complaining about a file (see below). Since this is a stock installati= on > >> what do I need to do to fix the "can't open" problem? A directory > >> listing shows the file exists. > > >> Jeff > > >>> =A0 =A0Welcome to OpenVMS (TM) Alpha Operating System, Version V8.3 o= n > >>> node PWS600 > >>> =A0 =A0 Last interactive login on Monday, =A08-SEP-2008 15:37:01.49 > >>> =A0 =A0 Last non-interactive login on Monday, =A08-SEP-2008 11:29:44.= 18 > > >>> $ type multinet:ntpd.log > >>> $ Set NoOn > >>> $ VERIFY =3D F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY")) > >>> =A05-SEP-2008 12:14:24.68 NTP release v4.2 (rev 1.0). > >>> =A05-SEP-2008 12:14:24.83 Sanity value (WAYTOOBIG/PANIC) defaulted to= 4000 > >>> =A05-SEP-2008 12:14:25.15 precision =3D 976.000 usec > >>> =A05-SEP-2008 12:14:25.35 Listening on interface wildcard, 0.0.0.0#12= 3 > >>> =A05-SEP-2008 12:14:25.49 Listening on interface wildcard, ::#123 > >>> =A05-SEP-2008 12:14:25.63 Listening on interface se0, 10.0.0.100#123 > >>> =A05-SEP-2008 12:14:25.75 Listening on interface lo0, 127.0.0.1#123 > >>> =A05-SEP-2008 12:14:25.91 Using NTP configuration file: MULTINET:ntp.= conf. > >>> =A05-SEP-2008 12:17:43.60 synchronized to xxxxxxxxxxx, stratum 1 > >>> =A05-SEP-2008 12:19:52.96 time reset +1.543251 s > >>> =A05-SEP-2008 12:24:06.36 synchronized to xxxxxxxxxxx, stratum 1 > >>> =A05-SEP-2008 13:14:32.91 can't open <>:NTP.DRIFT-TEMP: no > >>> such file or directory > >>> =A05-SEP-2008 14:14:36.20 can't open <>:NTP.DRIFT-TEMP: no > >>> such file or directory > >>> =A0[snipped] > >>> =A08-SEP-2008 13:18:29.12 can't open <>:NTP.DRIFT-TEMP: no > >>> such file or directory > >>> =A08-SEP-2008 14:18:31.30 can't open <>:NTP.DRIFT-TEMP: no > >>> such file or directory > >>> =A08-SEP-2008 15:18:32.82 can't open <>:NTP.DRIFT-TEMP: no > >>> such file or directory > >>> $ > >>> $ dire multinet:ntp > > >>> Directory MULTINET_COMMON_ROOT:[MULTINET] > > >>> NTP.CONF;2 =A0 =A0 =A0 =A0 =A0NTP.DRIFT-TEMP;1 > > >>> Total of 2 files. > >>> $ > > > Try a DIR /PROT. =A0The NTPD process needs to be able to have RWED acce= ss > > to that file. > > > ALPHA5_$ dir/prot tcpip$ntp.drift > > > Directory SYS$SPECIFIC:[TCPIP$NTP] > > > TCPIP$NTP.DRIFT;18116 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(RWED,RWED,RE,) > > > Total of 1 file. > > Ok, here's the listing: > > $ dire/secu multinet:ntp* > > =A0 =A0Directory MULTINET_ROOT:[MULTINET] > > =A0 =A0NTPD.LOG;13 =A0 =A0 =A0 =A0 =A0[SYSTEM] =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(RWED,RWED,RE,) > =A0 =A0NTPD.LOG;12 =A0 =A0 =A0 =A0 =A0[SYSTEM] =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(RWED,RWED,RE,) > =A0 =A0NTPD.LOG;11 =A0 =A0 =A0 =A0 =A0[SYSTEM] =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(RWED,RWED,RE,) > =A0 =A0NTPD.LOG;10 =A0 =A0 =A0 =A0 =A0[SYSTEM] =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(RWED,RWED,RE,) > =A0 =A0NTPD.LOG;9 =A0 =A0 =A0 =A0 =A0 [SYSTEM] =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0(RWED,RWED,RE,) > > =A0 =A0Total of 5 files. > Is the NTP_SERVER process running under the username SYSTEM? If not, does that user have write access to create a MULTINET:NTP.DRIFT-TEMP? ------------------------------ Date: Tue, 9 Sep 2008 08:09:10 -0400 From: "David" Subject: Re: Note to Island Computers customers Message-ID: Don't surf - I run so yes I got out in the sun Between 60-70% humidity (low for coastal GA) and 94F I was soaked but not due to downpour - just my pores. -- David B Turner ============================================= Island Computers US Corp PO Box 86 Tybee GA 31328 Toll Free: 1-877 636 4332 x201, Mobile x251 Email: dturner@islandco.com International & Local: (001)- 404-806-7749 Fax: 912 786 8505 Web: www.islandco.com ============================================= "JF Mezei" wrote in message news:48c5682d$0$12415$c3e8da3@news.astraweb.com... > David wrote: >> The extent of damage from Hanna - a magnolia tree leaf was loosened by >> the >> 12mph gusts we had. > > Is that really it ? You were, for a while under a tripical storm watch. > I figured you would have had non-damaging but still pretty nasty storm > conditions. > > Were you able to go to the beach to surf and sun-tan the next day ? ------------------------------ End of INFO-VAX 2008.495 ************************