1 INFO-VAX	Sat, 07 Dec 2002	Volume 2002 : Issue 675       Contents:- "VMS will be around long after we retire" ... ? Any way to stop screen monitoring  programs like Peek  and Spy? C RE: Any way to stop screen monitoring  programs like Peek  and Spy? C RE: Any way to stop screen monitoring  programs like Peek  and Spy?  Change VOLUME security3 Re: Cracking OpenVMS passwords with John the Ripper 3 RE: Cracking OpenVMS passwords with John the Ripper 3 Re: Cracking OpenVMS passwords with John the Ripper 3 Re: Cracking OpenVMS passwords with John the Ripper  Re: death of alpha on slashdot Re: death of alpha on slashdot Re: death of alpha on slashdot Re: DIRECTORY: bug or feature? Re: Endianity of Itanium Re: Endianity of Itanium Re: Endianity of Itanium	 eXcursion " Re: Future of Alpha and/or OpenVMS" Re: Future of Alpha and/or OpenVMS Future of Alpha and/or OpenVMS6 RE: Keeping of emails to abide by auditing regulations
 Lat vs TCP/IP  MTU Tape Utililty ? - Re: Netscape 2.02 & VAX/VMS 7.3 & Motif 1.2-6 * Re: OpenVMS and Tru64 binary compatibility2 Re: Performance of atomic instructions and locking@ Re: Problem with HSZ50 (access to the CLI from the console port)" RE: Province code change in Canada< RE: Request for Discussion, make comp.os.vms a moderated newB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupB Re: Request for Discussion, make comp.os.vms a moderated newsgroupO Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks! O Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks! O Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks! O Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks! O Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks! 4 Testing for status of remote host via web CGI script8 RE: Testing for status of remote host via web CGI script8 Re: Testing for status of remote host via web CGI script RE: TK70 drive bug found :-(< VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?@ Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?  Re: Webserver advice for VAX/VMS  Re: Webserver advice for VAX/VMS Re: what does this command mean  Re: what does this command mean  Re: what does this command mean  Re: XFC questionF [OT] top-posting (was: Re: Request for Discussion, make comp.os.vms...J Re: [OT] top-posting (was: Re: Request for Discussion, make comp.os.vms...  F ----------------------------------------------------------------------   Date: 6 Dec 2002 16:36:40 -0800 ( From: bob@instantwhip.com (Bob Ceculski)6 Subject: "VMS will be around long after we retire" ...< Message-ID: <d7791aa1.0212061636.8254549@posting.google.com>  @ an article on www.openvms.org just posted states OpenVMS will be9 around long after current users retire ... if they do the ? itanium port right, that will definitely be the case, esp. with @ govt and defense use, and of course all us other smart users who@ haven't jumped to other unstable os's who promise everything and< are nowhere near the level of VMS ... here is that story ...    = The OpenVMS Consultant: Report from the 1st OpenVMS Technical  Symposium: Part 1 F Posted by Robert Gezelter (Wednesday December 04 2002 @ 12:17PM EST) [ ] A I have just returned from the OpenVMS Technical Seminar hosted by C OpenVMS Engineering in Nashua, New Hampshire on November 19-21. The ? three days of sessions extensively covered topics including the C assimilation of Itanium CPUs, hands-on training for Next Generation C Alpha-based systems, E-Commerce, Probably, the hottest issue in the ? OpenVMS community is support for Intel's Itanium processor. The F presentations on the Itanium effort were made by senior engineers fromB the OpenVMS team, including Andrew Goldstein, Clair Grant, Stephen Hoffman, and Gaitan D'Antoni.   D Mark Gorham, the VP in charge of OpenVMS also presented a keynote onD policy and strategy for OpenVMS long term. He noted that while legalC restrictions prevent the publication of plans beyond a rolling five C year horizon, there is a positive commitment to OpenVMS in the form C the of the DII COE commitment (columnist's note: DII COE requires a @ long term binding commitment to the platform of approximately 20D years, it is inconceivable to this columnist that HP would choose toF limit sales and support of OpenVMS to the large, albeit finite defenseF sector, rather than amortize the expenses of the product line over the@ entire commercial space). Sales are reported to be healthy amongE existing and new customers. ISVs are joining the community, including C recent announcments from Legato and Veritas. In short, OpenVMS will ( actively be around long after we retire.  F Perhaps the best quote of the symposium came from both the engineeringD staff and management that the Itanium migration support will work atA both the source, and translation level; even for images that were E already VEST'ed from VAX to Alpha (translated on a binary, not source > recompilation basis). In short, we will be able to use VEST toD translate an image from VAX to Alpha, and re-translate the resultingD image to Itanium. While this tour-de-force was not unanticipated, it- is welcome to be in the form of a commitment.   C The technical sessions covered many aspects of the Itanium support, F including some of the mechanics of the bootstrap process, the enhanced? calling standard on Itanium, and issues relating to roadmap and D compiler capabilities, including the use of industry-standard objectC and debugger formats. All of the presentations showed an increasing F level of detail, even from similar presentations just over a month agoC in St. Louis at HPETS 2002. The presentations handily accounted for E the major technical issues, clearly showing that the "doom and gloom" D FUD is just that, fear of the unknown. For that matter, it was clearE at the outset from the Itanium architectural specifications published D by Intel that OpenVMS could feasibly assimilate Itanium. Compared toC the introduction of Alpha (where the architecture transitioned from E 32-bit to 64-bit), the differences between Alpha and Itanium are less E disruptive to code bases (see the author's presentation on "The Third B Porting", which was presented at CETS 2001 and HPETS 2002). At theC OpenVMS system level, the processor change is an order of magnitude D smaller (an "order of magnitude" is a factor of 10) than the changes, required during the VAX to Alpha transition.  F HP has also addressed the business issues which are of concern to many; installations, most every issue I raised at the time of the A Alpha/Itanium announcement in June 2001 has been addressed. Alpha F systems will continue to be available and sold, at least through 2006;> systems will be supported after active sales ceases; there areF guarantees on purchases of Itanium systems, mixed architecture cluster support, and other policies.  D OpenVMS 8.2 will be the first release of "Production Quality" on theA Itanium platform, and will be released concurrently for all three D patforms (VAX, Alpha, and Itanium). Unlike the VAX/Alpha effort, theD Itanium effort is working from the common source base with Alpha, soC there will be few, if any functional differences between OpenVMS on F the Alpha and Itanium platforms (the differences between Alpha and VAX= will be preserved with Itanium), In short, "VMS will be VMS", 0 regardless of which platform it is executing on.  E My next column will discuss some of the other interesting information C presented at the seminar (within the limits of the NDA, of course).    ------------------------------   Date: 6 Dec 2002 14:03:11 -0800 ' From: pr909001@sneakemail.com (no spam) H Subject: Any way to stop screen monitoring  programs like Peek  and Spy?; Message-ID: <340fc4a.0212061403.16a9572@posting.google.com>   A I'm writing for a programmer in my group who thinks his screen is F being monitored while working on a Open VMS box.  If this is true, hisF knowledge of the software is being stolen by another company simply by viewing his screen.   @ He's noticed a significant slowdown when he is called  on to fixA something difficult on this box.  Coincidently, the other company E would be very interested in knowing what he is doing during this time B and there are other things which point to him believing that he is being monitored.  ? Is there any way to stop this sort of monitoring?  I understand + programs like "Peek and Spy" could be used.    ------------------------------  $ Date: Fri, 6 Dec 2002 14:18:01 -0800$ From: Shane Smith <ssmith@icius.com>L Subject: RE: Any way to stop screen monitoring  programs like Peek  and Spy?0 Message-ID: <01C29D32.70E0C6E0@sulfer.icius.com>  G If the other company has compromised his system to the point where that C sort of software could be used, they don't need to use it. You need E system manager level privs to do that. If anyone's watching him, it's  probably his boss.   Shane    -----Original Message-----> From: pr909001@sneakemail.com [mailto:pr909001@sneakemail.com]' Sent: Friday, December 06, 2002 2:03 PM  To: Info-VAX@Mvb.Saic.Com F Subject: Any way to stop screen monitoring programs like Peek and Spy?    A I'm writing for a programmer in my group who thinks his screen is F being monitored while working on a Open VMS box.  If this is true, hisF knowledge of the software is being stolen by another company simply by viewing his screen.   @ He's noticed a significant slowdown when he is called  on to fixA something difficult on this box.  Coincidently, the other company E would be very interested in knowing what he is doing during this time B and there are other things which point to him believing that he is being monitored.  ? Is there any way to stop this sort of monitoring?  I understand + programs like "Peek and Spy" could be used.    ------------------------------  # Date: Fri, 06 Dec 2002 22:47:25 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")L Subject: RE: Any way to stop screen monitoring  programs like Peek  and Spy?6 Message-ID: <00A180BE.DAB3D326@SSRL.SLAC.STANFORD.EDU>  W In article <01C29D32.70E0C6E0@sulfer.icius.com>, Shane Smith <ssmith@icius.com> writes:   H >If the other company has compromised his system to the point where thatD >sort of software could be used, they don't need to use it. You needF >system manager level privs to do that. If anyone's watching him, it's >probably his boss.   N True for "PEEK and SPY."  It would be interesting to know how he's connecting,K what he's connecting to, etcetera.  For example, if he works via DECwindows M over TCP/IP (rather than DECnet), it might be possible for his X-Server to be 	 hijacked.   0 But we certainly don't have enough info to tell.  B (Also, how would this other company know what he's working on on aK minute-by-minute basis, so they'd know when to look and when not?  For that K to be true, they either have a mole in the organization or have compromised  email and phone systems.)    -- Alan      >  >Shane >  >-----Original Message----- ? >From: pr909001@sneakemail.com [mailto:pr909001@sneakemail.com] ( >Sent: Friday, December 06, 2002 2:03 PM >To: Info-VAX@Mvb.Saic.ComG >Subject: Any way to stop screen monitoring programs like Peek and Spy?  >  > B >I'm writing for a programmer in my group who thinks his screen isG >being monitored while working on a Open VMS box.  If this is true, his G >knowledge of the software is being stolen by another company simply by  >viewing his screen. > A >He's noticed a significant slowdown when he is called  on to fix B >something difficult on this box.  Coincidently, the other companyF >would be very interested in knowing what he is doing during this timeC >and there are other things which point to him believing that he is  >being monitored.  > @ >Is there any way to stop this sort of monitoring?  I understand, >programs like "Peek and Spy" could be used.  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------  $ Date: Fri, 6 Dec 2002 15:01:33 -0800* From: "Alder" <MUNDDGNTDYTV@spammotel.com> Subject: Change VOLUME security + Message-ID: <3df12c4d$1@obsidian.gov.bc.ca>   J I'd like to change the security profile of a mounted disk volume by addingL an ACL.  Would someone kindly enlighten me as to why the system freezes when I try this:   G SET SECURITY /CLASS=VOLUME /ACL=(IDENT=WASD_HTTP_NOBODY,ACCESS=EXECUTE)  DISK$NET     Thanks,    Alder    ------------------------------   Date: 6 Dec 2002 13:26:40 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) < Subject: Re: Cracking OpenVMS passwords with John the Ripper3 Message-ID: <8K7IJOuZXxle@eisner.encompasserve.org>   c In article <3DEBABD6.29C78BE0@mindspring.com>, Atlant Schmidt <atlantnospam@mindspring.com> writes:   0 > Prediction: Passwords are a thing of the past;4 > it'll all be biometrics soon anyway. Fingerprints,5 > iris scans, voiceprints, signature, finger lengths, 2 > I don't know which will win, but it will be some > sort of biometrics.   C    Not so soon.  A recent survey of biometric scanners found all of A    them to basically just be toys, easily fooled.  Heard it while 0    driving to work, so I don't have a reference.   ------------------------------   Date: 6 Dec 2002 14:13:01 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) < Subject: RE: Cracking OpenVMS passwords with John the Ripper3 Message-ID: <aW6kg5xpKbx+@eisner.encompasserve.org>   c In article <5UAaxtPvIVHJ@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > I > Whenever there is a grade crossing (road crosses the tracks without any J > bridge), engineers are required to signal the equivalent of a Morse Code& > "Q" with their horn.  It is the law.  C    Local governments have tried to overcome this by passing laws of D    their own.  This causes great headaches for engineers and usually    requires a lawsuit to stop.   ------------------------------   Date: 6 Dec 2002 14:20:15 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) < Subject: Re: Cracking OpenVMS passwords with John the Ripper3 Message-ID: <YdC+rY73FpQ6@eisner.encompasserve.org>   ` In article <asl7f0$s7kik$3@ID-135708.news.dfncis.de>, bill@cs.uofs.edu (Bill Gunshannon) writes: >>5 >> This is very common in the tonier neighborhoods of  >> suburban Massachusetts. > C > It's an NTSB regulation.  I don't believe any local ordinance can : > conflict with a Federal Law.  Not even in Taxechusettes. >   C    That doesn't stop the locals from trying.  Just like Pasadena CA F    thinks they can regulate the airspace above the town.  Just becauseD    someone spent the money to defend himself and have the court say,H    nope, that's FAA teritory, not Pasadena's, doens't actually stop themF    from continuing to issue "tickets" if they can identify an aircraft    below 1000 feet.   B    The result:  the guy in the middle get's hurt.  If the engineerG    doens't follow the local law he may have to pay for his own defence. C    If he doesn't follow federal regulation, he can loose his job as     well as get fined.    ------------------------------  % Date: Fri, 06 Dec 2002 09:46:06 +0000 ' From: Andrew Harrison SUNUK Consultancy < Subject: Re: Cracking OpenVMS passwords with John the Ripper. Message-ID: <3DF071DE.3020209@nospamn.sun.com>   David Webb wrote:  > In article <3DEF7BD9.2080303@nospamn.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: >  >> >>Bob Koehler wrote: >>[ >>>In article <3DE5E679.2030800@nospamn.sun.com>, Andrew Harrison SUNUK Consultancy writes:  >>>  >>> ? >>>>This has been untrue for years for Solaris I cannot comment  >>>>on other UNIX's. >>>  >>> L >>>This has been untrue on most UNIX for about a decade and a half.  If and H >>>only if the admin turns it on.  Has Solaris eliminated the ability of >>>the admin to turn it off? >> >>7 >>shadow password files are the default for Solaris and 9 >>there isn't as far as I know an option to turn them off  >> >  >  > Since when ? > F > You can always turn it off by just putting the passwords directly in > /etc/passwd. >   
 No you can't.   = Putting the passwords manually into the old password field in ; /etc/passwd doesn't work. I have tried it, shadow is always 7 referenced. The username has to exist in /etc/shadow if 9 it does then its password is used. If it doesn't then you  don't get to log in.  > You could of course manually cut and past the password entries< as root into the password file and then a user that had read9 access to the /etc/passwd file would be able to run crack = against it, but then you would as root be deliberately trying < to defeat the systems security, if however any users updated= their password entries then these would still go into shadow.    regards  Andrew Harrison    ------------------------------  % Date: Fri, 06 Dec 2002 12:48:14 -0800 % From: Dean Woodward <deanw@rdrop.com> ' Subject: Re: death of alpha on slashdot ( Message-ID: <3DF10D0E.1040808@rdrop.com>   Robert Deininger wrote: > > In article <c5cf6e8.0212060511.18e22344@posting.google.com>,+ > baby_p_nut@yahoo.com (Baby Peanut) wrote:  > I >>http://slashdot.org/article.pl?sid=02/12/06/0326217&mode=thread&tid=173  > 0 > The level of ignorance over there is stunning.    You spelled "hilarious" wrong...  G Of course, "frightening" and "depressing" and several other words also   fit well...    ------------------------------  # Date: Fri, 06 Dec 2002 14:19:10 GMT # From: "John Smith" <a@nonymous.com> ' Subject: Re: death of alpha on slashdot I Message-ID: <yl2I9.237215$oRV.97059@news04.bloor.is.net.cable.rogers.com>   ) http://news.com.com/2100-1001-976211.html   L "The Alpha business will lose about $200 million this fiscal year, BlackmoreJ said. Once the final chips are out the door, HP will be able to scale back> its investment and shift to what he dubbed "maintenance mode."  K "That will flow through to the bottom line," Blackmore said at HP's analyst L meeting this week. HP said that the enterprise systems business will be lessL profitable than the company hoped this year, in part because of the costs of. developing for three high-end chip families. "    I IMHO, the losses stem entirely from the idiotic manner in which Compaq/HP L handled the whole Alpha cancellation, but more importantly, the way in which VMS is NOT marketed.  L If VMS is going to remain around and viable for tens of years in the future,K why the hell isn't HP out there pounding on doors and advertising the fact? K The mantra should be "VMS isn't going away - it's a safe long term purchase L committment for any company, large or small, that wants a reilable computingL infrastructure. VMS has survived and thrived on the VAX to Alpha transition,L and it will continue to do so on the Alpha to IA-64 transition. Buying AlphaF now is not a lost investment because HP will give you genrous trade-inD credits on IA-64 when your company is ready to make the transition."  K But HP isn't doing this, or if it is, it's done only to the converted. With K $10MM in smart advertising and marketing, HP could probably have taken that E $200MM loss that Blackmore suggest is happening, and turned it into a F breakeven proposition. But no, HP insists on spending that and more on' advertising money-losing PC operations.   I I won't even comment on his remark about the 3 'high-end ' chip families. H They only have one high end chip family, and it was cancelled by Compaq.   ------------------------------  % Date: Fri, 06 Dec 2002 15:33:47 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>' Subject: Re: death of alpha on slashdot / Message-ID: <3DF109AA.6895450A@vl.videotron.ca>    John Smith wrote: N > "The Alpha business will lose about $200 million this fiscal year, BlackmoreL > said. Once the final chips are out the door, HP will be able to scale back@ > its investment and shift to what he dubbed "maintenance mode."    H Funny how, prior to June 25 2001, the "enterprise" business was the mostM profitable at Compaq, and attempts to kill VMS were killed/postoponed because J Curly was made to realise that Compaq needs the profits generated by alpha4 based business to subsidize his wintel pet projects.  F Is there any surprise that the Alpha business which is going through aI "useless" last development with not only EV7, but also new wildfire-class  machines would lose money ?   I So, not only is Alpha pronounced dead, but those customers still loyal to K alpha are waiting for EV7 which was supposed to be available "anytime soon"  back in june 2001.  L If the unit is losing money, blame it squarely on the owner's mismanagement, not on the chip or customers.    > N > profitable than the company hoped this year, in part because of the costs of0 > developing for three high-end chip families. "  G Intel is funding the IA64 port to a large extent. I don't recall Tandem K developping a new MIPS architecture, are they ? And if they have to develop K more PA-RISC stuff, it is because of the failed IA64 which, almost a decade = after its inception is still useless to enterprise computing.   M > The mantra should be "VMS isn't going away - it's a safe long term purchase N > committment for any company, large or small, that wants a reilable computing > infrastructure.   K NO! This reminds everyone that VMS is on the "endangered species list". The L owner MUST NOT spend so much time making "we'll commit to VMS for at least XG years" statements. The owner MUST start to market VMS against competing N operating systems. A real commitment to VMS would see HP advertise VMS againstM "unix" (in general) and "windows".  To HP, it doesn't matter if VMS steals an E HP-UX or windows sale because that stays inside the company. But such N advertising would also help HP steal accounts from Dell, Sun, IBM due to VMS's superior clustering.  K Until that happens, people will continue to see zero growth for VMS, and HP K just keeping VMS on maintenance (trying to retain existing customers) which 5 means that VMS is not a long term strategic OS to HP.     > > VMS has survived and thrived on the VAX to Alpha transition,B > and it will continue to do so on the Alpha to IA-64 transition.   N Alpha was seen as a winner from the get go. People had confidence in the alphaK architecture because they had confidence in the Digital engineers. The same N cannot be said of IA64. It is seen as an also ran that failed. It is a bloatedM architecture and is definitely not going to garner "industry standard" status G that Carly and Culry had banked on. So they are switching from a highly B regarded Alpha architecture to one which has little or no respect.     > Buying AlphaH > now is not a lost investment because HP will give you genrous trade-inF > credits on IA-64 when your company is ready to make the transition."  J Question is whether you should BUY Alpha now since you know you'll need toH migrate to Sun or IBM later if IA64 never delivers on its promises of anN industry leading, industry standard low cost platform that Carly and Curly had bet their business on.  K It is no wonder Carly might now refocus on the wintel business since she is K realising her enterprise business has not a bright future since she put all / her enterprise eggs in the failing IA64 basket.    ------------------------------   Date: 6 Dec 2002 18:34 CST' From: carl@gerg.tamu.edu (Carl Perkins) ' Subject: Re: DIRECTORY: bug or feature? , Message-ID: <6DEC200218340651@gerg.tamu.edu>  * Rudolf Wingert <win@fom.fgan.de> writes... }Hello,  }  }Jan-Erik S=F6derholm wrotes:  }  }>>>I }$ pipe dir/nohead/notrail sy*log*n.com,sy*gin.com | sort/nodupl sys$pipe  }sys$output  }<<< } C }Thanks for this solution. But OpenVMS engineering should add a new . }qualifier /NODUPLEX to the DIRECTORY command. }  }Regards Rudolf Wingert   I The only possible way to do this would be for it to store a complete list E of all filespecs already retruend and compare each with the list (for G speed purposes, some sort of hashing algorithm would probably be used).   < This could consume a lot of memory. Like if you were to do a& $ dir/noduplex disk:[000000...]*a*,*b*G (I just checked, using DFU, and it seems that about 75% of the files on H my main user disk have the letter A in the filespec, although specifyingF /file=*a* in DFU also catches them in the extenstion and the directoryF command above doesn't, probably because the single largest category ofG files may be mail files which all start MAIL$* - but a lot of others do C too. Still, you'd have to save about 100,000 filespecs to compare.)   B You would also presumably want thist to only function for files on5 the same device. That makes it complicated. Consider: K $ dir/nodup disk1:[000000...]*a*,disk2:[000000...]*b*,$disk1:[000000...]*c* G You'd have to remember the first set to compare to the 3rd set and emit B them at the same time, saving or delaying the 2nd set until later.  C It would also have terrible performance, but so do the alternatives D (sorting is not a high speed operation, particularly compared to not	 sorting).   > I would say that rather than "should add" it is more a case of "they should not bother".    --- Carl   ------------------------------   Date: 6 Dec 2002 13:42:55 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: Endianity of Itanium 3 Message-ID: <aNKfZpPf5sy3@eisner.encompasserve.org>   c In article <uka6NSj+jXxS@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: e > In article <LEwp$by1lMjb@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:  >>  G >>    It's relativley trivial to design in a flip in the data path in a I >>    manner which has no preference.  What's actually done is up to the  K >>    chip designer, but there's no real value in designing in a slow down.  > E > But that is not the approach that was taken with Alpha.  Big-endian 4 > requires the compiler use some extra instructions.  F    IIRC that was to fill in for something that was missed in the AlphaA    architecture design, not a general feature of bi-endian chips.    ------------------------------   Date: 6 Dec 2002 13:54:52 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: Endianity of Itanium 3 Message-ID: <sRuqmyQLdhwe@eisner.encompasserve.org>   b In article <asi8ke$q0c$1@helle.btinternet.com>, "John Wallace" <johnwallace4@yahoo.dotcom> writes:< > "Bob Koehler" <koehler@encompasserve.org> wrote in message  J >>    I would think that Intel compilers would support both modes.  NobodyG >>    has said anything about endianness as an issue in the HP-UX port.  >> > E > Bob, you may wish to check this assumption with a reputable source.       OK, so now I have heard.   K > This may be a shame really. Itanium users need the very best toolset they L > can get, in order to maximise chances of getting correct and optimal code;K > the compiler's in charge, the silicon is just a "replay engine" (new term  > from last week).    N    Kind of depends on what you mean by "best".  The Intel compilers I've used L    so far couldn't touch the useability of DEC's.  HP's compilers that I've K    used in the last 2 decades were certainly no better than Intels, though.    ------------------------------   Date: 6 Dec 2002 13:50:38 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: Endianity of Itanium 3 Message-ID: <KGOtZO$lDf02@eisner.encompasserve.org>   b In article <3DEBE399.27F33100@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > Bob Koehler wrote:L >>    Itanium's instructions must be stored little-endian, but it can accessJ >>    data in little-endian or big-endian.  IIRC this can be switched on a4 >>    per-process basis while the system is running. > J > Does a chip "access" the data in whatever endianness but once inside theH > registers for math or comparisons, the data is in a fixed endianness ?  A    To make it easy for the chip to work right, you need to simply G    change the byte order in the data path according to:  a) the size of D    the datum, and b) the current endianess setting.  The rest of the    chip doens't see the flips.  N > And how could a process have the privilege to change endianness of the CPU ?L > When a process calls a system routine, wouldn't the system routine be veryH > unhappy to be fed arguments in an aorder that doesn't match what it is
 > expecting ?   F    IIRC (I'm not that much up on IPF) it's a bit in a control registerG    which is probably saved/restored on interrupt.  Nobody said it would G    be easy to interface to the OS if one actually used it.  Simplified, B    but painfull design if you wanted to write an OS to support it:C    two versions of the OS interfaces, one of which "fixes" the data F    and alters the setting as the OS is entered/exited.  Not something /    many OS designers would want to bother with.      C    Most OS will simply ship only compilers that operate in the same F    endianness as the OS.  OBTW, I haven't heard of anyone intending toF    supply an OS that supports more than one endianness, no matter what    the chip can do.           ------------------------------  $ Date: Fri, 6 Dec 2002 09:55:13 +01009 From: "Robert TRAWISKI" <robert.trawinski@softax.com.pl>  Subject: eXcursion. Message-ID: <aspoiu$dsi$1@bozon.softax.com.pl>   Hi all,   E I've got PC with WindowsXP /MatroxGraphics MGA-G200 AGP and eXcursion E Xserver installed. I've configured high color (32 bit per pixel), but 6 xdpyinfo reports avaiability of only 8 planes visuals.  I Can anybody know how to change eXcursion configuration to get at least 16  planes visuals?    Robert   ------------------------------   Date: 6 Dec 2002 16:35:11 -0800 ( From: bob@instantwhip.com (Bob Ceculski)+ Subject: Re: Future of Alpha and/or OpenVMS = Message-ID: <d7791aa1.0212061635.44484f9a@posting.google.com>   t "val" <valegre@remove.prodigy.delete.net> wrote in message news:<rZ1I9.12392$7O2.3930@newssvr16.news.prodigy.com>... > Hello all... >  > A few newbie questions:  > L > 1) Can someone provide pointers to where HP's plans for continuing OpenVMS > development are summarized?  > L > 2) Can someone provide pointers to where the end of life roadmap for Alpha > might be found?  > G > 3) Would anyone care to share opinions on what the real., most likely 8 > end-game will be for either or both Alpha and OpenVMS? >  > Thanks in advance, >  > Val   @ an article on www.openvms.org just posted states OpenVMS will be9 around long after current users retire ... if they do the ? itanium port right, that will definitely be the case, esp. with @ govt and defense use, and of course all us other smart users who@ haven't jumped to other unstable os's who promise everything and< are nowhere near the level of VMS ... here is that story ...    = The OpenVMS Consultant: Report from the 1st OpenVMS Technical  Symposium: Part 1 F Posted by Robert Gezelter (Wednesday December 04 2002 @ 12:17PM EST) [ ] A I have just returned from the OpenVMS Technical Seminar hosted by C OpenVMS Engineering in Nashua, New Hampshire on November 19-21. The ? three days of sessions extensively covered topics including the C assimilation of Itanium CPUs, hands-on training for Next Generation C Alpha-based systems, E-Commerce, Probably, the hottest issue in the ? OpenVMS community is support for Intel's Itanium processor. The F presentations on the Itanium effort were made by senior engineers fromB the OpenVMS team, including Andrew Goldstein, Clair Grant, Stephen Hoffman, and Gaitan D'Antoni.m  D Mark Gorham, the VP in charge of OpenVMS also presented a keynote onD policy and strategy for OpenVMS long term. He noted that while legalC restrictions prevent the publication of plans beyond a rolling fivepC year horizon, there is a positive commitment to OpenVMS in the formoC the of the DII COE commitment (columnist's note: DII COE requires a @ long term binding commitment to the platform of approximately 20D years, it is inconceivable to this columnist that HP would choose toF limit sales and support of OpenVMS to the large, albeit finite defenseF sector, rather than amortize the expenses of the product line over the@ entire commercial space). Sales are reported to be healthy amongE existing and new customers. ISVs are joining the community, includingeC recent announcments from Legato and Veritas. In short, OpenVMS willi( actively be around long after we retire.  F Perhaps the best quote of the symposium came from both the engineeringD staff and management that the Itanium migration support will work atA both the source, and translation level; even for images that wereiE already VEST'ed from VAX to Alpha (translated on a binary, not sources> recompilation basis). In short, we will be able to use VEST toD translate an image from VAX to Alpha, and re-translate the resultingD image to Itanium. While this tour-de-force was not unanticipated, it- is welcome to be in the form of a commitment.e  C The technical sessions covered many aspects of the Itanium support,eF including some of the mechanics of the bootstrap process, the enhanced? calling standard on Itanium, and issues relating to roadmap anduD compiler capabilities, including the use of industry-standard objectC and debugger formats. All of the presentations showed an increasing F level of detail, even from similar presentations just over a month agoC in St. Louis at HPETS 2002. The presentations handily accounted foriE the major technical issues, clearly showing that the "doom and gloom"sD FUD is just that, fear of the unknown. For that matter, it was clearE at the outset from the Itanium architectural specifications published D by Intel that OpenVMS could feasibly assimilate Itanium. Compared toC the introduction of Alpha (where the architecture transitioned fromnE 32-bit to 64-bit), the differences between Alpha and Itanium are lessmE disruptive to code bases (see the author's presentation on "The Third B Porting", which was presented at CETS 2001 and HPETS 2002). At theC OpenVMS system level, the processor change is an order of magnitudeKD smaller (an "order of magnitude" is a factor of 10) than the changes, required during the VAX to Alpha transition.  F HP has also addressed the business issues which are of concern to many; installations, most every issue I raised at the time of the A Alpha/Itanium announcement in June 2001 has been addressed. Alpha F systems will continue to be available and sold, at least through 2006;> systems will be supported after active sales ceases; there areF guarantees on purchases of Itanium systems, mixed architecture cluster support, and other policies.  D OpenVMS 8.2 will be the first release of "Production Quality" on theA Itanium platform, and will be released concurrently for all threeeD patforms (VAX, Alpha, and Itanium). Unlike the VAX/Alpha effort, theD Itanium effort is working from the common source base with Alpha, soC there will be few, if any functional differences between OpenVMS onhF the Alpha and Itanium platforms (the differences between Alpha and VAX= will be preserved with Itanium), In short, "VMS will be VMS",n0 regardless of which platform it is executing on.  E My next column will discuss some of the other interesting informationlC presented at the seminar (within the limits of the NDA, of course).t   ------------------------------   Date: 6 Dec 2002 07:04:03 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen)a+ Subject: Re: Future of Alpha and/or OpenVMSN3 Message-ID: <4jzBA6agHMke@eisner.encompasserve.org>a  o In article <rZ1I9.12392$7O2.3930@newssvr16.news.prodigy.com>, "val" <valegre@remove.prodigy.delete.net> writes:G > Hello all... >  > A few newbie questions:o > L > 1) Can someone provide pointers to where HP's plans for continuing OpenVMS > development are summarized?  > L > 2) Can someone provide pointers to where the end of life roadmap for Alpha > might be found?n > G > 3) Would anyone care to share opinions on what the real., most likely 8 > end-game will be for either or both Alpha and OpenVMS?  I HP says they will sell new Alphas through at least 2006.  I think longer.e  C I expect the end of VMS support about when the US military goes outr of business.   ------------------------------  # Date: Fri, 06 Dec 2002 13:53:27 GMTm/ From: "val" <valegre@remove.prodigy.delete.net>n' Subject: Future of Alpha and/or OpenVMSt= Message-ID: <rZ1I9.12392$7O2.3930@newssvr16.news.prodigy.com>u   Hello all...   A few newbie questions:e  J 1) Can someone provide pointers to where HP's plans for continuing OpenVMS development are summarized?r  J 2) Can someone provide pointers to where the end of life roadmap for Alpha might be found?e  E 3) Would anyone care to share opinions on what the real., most likelyL6 end-game will be for either or both Alpha and OpenVMS?   Thanks in advance,   Val    ------------------------------   Date: 6 Dec 2002 14:29:53 -0600i; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)i? Subject: RE: Keeping of emails to abide by auditing regulationse3 Message-ID: <5Y7FLfqE6+1s@eisner.encompasserve.org>s  _ In article <CIEJLCMNHNNDLLOOGNJIKENGGCAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:n; > No offence intended, but am curious if there is a meaningi# > for gander other than male goose?-      Yes.s   ------------------------------  # Date: Fri, 06 Dec 2002 20:37:48 GMT # From: "John N." <JNixon@cfl.rr.com>s Subject: Lat vs TCP/IP= Message-ID: <wU7I9.432572$S8.8860053@twister.tampabay.rr.com>s  H I read a discussion that touched on this recently, but I cannot find it.  C Years ago, we implemented several applications based on LAT.  TheseeK applications received requests from customers and passed the requests on toeK the appropriate system.  LAT was chosen largely because of better fail-overuE and load balancing capabilities (than TCP/IP).  But it was also choseeH because it was an integral part of  VMS (This was in the VAX VMS 4/VMS 5H days).  The question is now arising as to whether this explanation stillL holds water, or should we move to TCP/IP, which is much more widely used and4 understood.   We are now on Alpha VMS 7.2-1 * 7.3-1.  E Security, Reliability and Performance (in pretty much that order) are4 extremely important to us.  K Can a case be made for keeping LAT?   What are some of the pros and cons ofe! each (as compared to each other).h   thanks.s   ------------------------------  # Date: Fri, 06 Dec 2002 11:31:41 GMTc+ From: "P.Lj" <plj@NOSPAMbyron.ext.telia.se>e Subject: MTU Tape Utililty ?1 Message-ID: <xU%H9.282$FF4.17408@newsb.telia.net>h   Hi,o  1 Can't locate the MTU Tape Utility, used to be on:e< http://www.decus.org/libcatalog/description_html/v00191.html   The FTP-button does not open...h  2 Anyone know were MTU (with sources) can be found ?   /P.Lj    ------------------------------   Date: 6 Dec 2002 13:36:37 -0600u; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler);6 Subject: Re: Netscape 2.02 & VAX/VMS 7.3 & Motif 1.2-63 Message-ID: <zYjUcH9gXtaU@eisner.encompasserve.org>e  e In article <z9xH9.291516$up.2966904@news.chello.at>, peter@langstoeger.at (Peter LANGSTOEGER) writes: e > In article <qTFBfksCrsxQ@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:t > 0 >>   Later systems willfind a simpler reference:J >>   sys$system:netscape-export.exe (shipped and IIRC installed with VMS). > 7 > Not on my systems. Can you please be more specific...s  F    I take that back.  I just installed a fresh copy of VMS on an Alpha?    and it wasn't there until I separately installed it from CD.    ------------------------------   Date: 6 Dec 2002 13:57:10 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)c3 Subject: Re: OpenVMS and Tru64 binary compatibility 3 Message-ID: <nyvGmqRtL5Uw@eisner.encompasserve.org>o  M In article <3dec5f34$1@news.post.ch>, "Jakob Erber" <erberj@yahoo.de> writes: I >>    That depends on what compiler features you are using and what mediar) >>    you are using to transfer the data.k >>K > I actually thought about an RPC mechanism. Record in/Record out should beu- > binary compatible, using the same compiler?e  G    Not if HP has made too many changes to the compiler.  (Record in/outiD    using HP-UX C compiler was not binary compatable last time I used it).   ------------------------------   Date: 6 Dec 2002 12:38:22 -0800w7 From: stephen_bainbridge@yahoo.co.uk (Steve Bainbridge)e; Subject: Re: Performance of atomic instructions and lockingo= Message-ID: <a48f6f51.0212061238.7955a785@posting.google.com>d  a Per Schrder <pesc@bredband.net> wrote in message news:<XETH9.20320$Y2.719@news2.bredband.com>...,	 > > Also, G > > because an area of memory either side of a lock is also locked downyF > > (by the processor/OS) when the lock is locked this may slow things > > down un-expectedly.c > F > Not quite. The process or OS does not "lock down" memory cells when  > you take a spinlock. > H > First you have the granularity for atomic operations which I think is G > 4 bytes (I don't have the Alpha architecture manual right now so you hF > should check this.) If all four bytes in a word is protected by the  > same lock, you are OK.  % Not quite. From the OpenVMS Wizard...   C   "In regard to topic (6984), the granularity of memory affected bygE    the hardware interlock is implementation-specific, and can involveoD    anything from the smallest grain of memory (a longword) to all ofF    system physical memory, and can also potentially be discontiguous."  F I'm trying to find a more precise value for the granularity in my caseD (OpenVMS v7.3-1 and ES40/45 hardware). I seem to recall that placingF an unused 128 byte array before and after the lock variable was enough1 to ensure that only the lock variable was locked.h   ------------------------------   Date: 6 Dec 2002 15:01:49 -0800o  From: nmanser@progis.de (Manser)I Subject: Re: Problem with HSZ50 (access to the CLI from the console port)u= Message-ID: <2178d61f.0212061501.19c1f818@posting.google.com>   e nmanser@progis.de (Manser) wrote in message news:<2178d61f.0212051622.1901f7e0@posting.google.com>...j > Alan Adams <alan.adams@orchard-way.freeserve.co.uk> wrote in message news:<4cfd969e4b.Alan.Adams@orchard-way.freeserve.co.uk>...@ > > In message <2178d61f.0212011011.3a02a8e7@posting.google.com>/ > >           nmanser@progis.de (Manser) wrote:a > >  > > > Alan Adams <alan.adams@orchard-way.freeserve.co.uk> wrote in message news:<0517399d4b.Alan.Adams@orchard-way.freeserve.co.uk>...D > > > > In message <2178d61f.0211281413.31cbdaa4@posting.google.com>3 > > > >           nmanser@progis.de (Manser) wrote:  > > > >  > > > > > Alan Adams <alan.adams@orchard-way.freeserve.co.uk> wrote in message news:<9c688a9b4b.Alan.Adams@orchard-way.freeserve.co.uk>... > > > > > > Hi,h > > > > > > Q > > > > > > OK, I'll try to remember as much as possible - I worked with an SW300wU > > > > > > (RaidArray 450) which uses the same controllers, but with a different bus' > > > > > > configuration.
 > > > > > : > > > > > Lot of thanks, that you investige in my Problem.
 > > > > >  > > > > > > ? > > > > > > I don't have access to the hardware or manuals now.r > > > > > > 
 > > > > > 7 > > > > > I have access to the manuals, (Service Guide)m
 > > > > >  > > > >  > > > > < huge snip> > > > >  > > > > > > P > > > > > > Sorry I can't point to a definite cause. I suspect your system has aT > > > > > > different configuration to the one I used, for example, removable cache. > > > > > >  > > > > > > Good luck, > > > > > >  > > > > > > Alan
 > > > > > N > > > > > i can send you a picture of the server showing how it is configured. > > > > > my question is: 
 > > > > > U > > > > > suppose the batteries are damaged or flat, does this prevent the controllerc# > > > > > to initialise correctly ?k > > > > >  e! > > > > > thanks for the answers.e > > > > R > > > > Since the system behaves the same with terminal disconnected (that bit wasT > > > > snipped), I suspect the batteries. I don't know whether a faulty battery canC > > > > prevent the controller from booting, but it seems possible.= > > > > L > > > > If not that, then it would seem that you have the same fault on bothP > > > > controllers, which seems somewhat unlikely. (Unless, as I have suggestedS > > > > before) a faulty terminal has been connected to each controller in turn and= > > > > damaged it.) > > > >  > > > R > > > the terminal i connected to is a VT500 with 3 Serial ports, 2 are connected @ > > > (1 to the alpha server, the other to the HSZ serial port.)S > > > the first time i connected the terminal, only the server console gave output.e7 > > > How can a faulty terminal damage the controller ?b > > P > > RS232 is pretty tolerant of faults - each pin should be able to tolerate +/-K > > 35 volts wrt signal ground, without damage. However RS423, used on moreSJ > > recent equipment, has lower voltages, normally +/- 5v. I just wonderedO > > whether a faulty terminal might be sending an excessive voltage on one pin,.P > > breaking through the input protection, and damaging a chip on the controllerO > > board. It is unlikely, but there aren't many things that would stop both of8" > > your controllers from booting. > >  > + > on the VT500 the input channls are RS432.  >  > > > T > > > > (You also asked about the output during boot - I can't remember the details,P > > > > but it was plain text, similar to that output by terminal servers duringQ > > > > boot. It sounds as though your controllers are failing a self test beforem3 > > > > the point where they start to output text.)s > > > >  > > >  > > > that is right. > > > R > > > > Oh, another thought. The PCMCIA memory cards contain the operating system.T > > > > The highest version for HSZ50 wqs V5.7. (I hope I remembered this right. I'mN > > > > fairly sure we ran 5.4 for a long time, then 5.7.) Have you got higher6 > > > > versions? If so, you could get a boot failure. > > > >  > > > Q > > > the hsof version is 5.1, i don't know if changing the PCMCIA card, changes n > > > this behaviour.r > > H > > This is the version in the PCMCIA card, and should be fine for those > > controllersi > >  > > >  > > > so the issues are: > > > : > > > i will change the connection cable, and try another.K > > > if it persists, then it can be either the battery or the PCMCIA card.g" > > > are there another thoughts ? > > @ > > I don't think it's PCMCIA - they are an appropriate version. > >   > > > seeing the Service manual:B > > > the LED fault code it get, tells me to reset the controller.2 > > > other LED codes tells, to change the module. > > L > > It's trying to tell you both modules are faults. I hope not, and I can't$ > > really see why both should fail. > > H > > > what i want to know is if the complete controller card is damaged.4 > > > i hope no, because i have no service contract. > > N > > You didn't say where the equipment came from - a really long shot would beI > > mains voltage differences, i.e. 110 / 230 volt. However a lot of thisaK > > equipment is auto-sensing. I don't know about the shelf power supplies.c > >  > > Getting desperate now... > >  > > Alan > $ > I finally have done the following: >  > power off 7 > disbled the ECB by pushing the battery disable switcht/ > disconnected the cable from the cache module.t > remove the programm card.T$ > loosen the screws from the trilink& > loosen the controller from the shelf+ > remove the memory battery (Type: 2032 3V)o > waited Ca. 1 hour.* > put the battery in the controller module" > put the controller in the shelf. > put back the trilink > inserted the program card0J > reconnected the cable from tha cache to the (ECB External cache battery) > powered the system on. > D > both controllers initialised OK, so i could gain access to the CLIC > the problem is that 1 LED of the ECB is not lit, it means that 1 c. > battery is not providing power to the cache. >  > D > after 5 min, the upper controller shutsdown itself (seeing the LED	 > status)3 > Green LED: LIT > 3 leftmost amber LED : LIT > 2 > the other controller continues normal operation: > # > Green LED: blinking every second.  > amber LED's : offr > G > i send you the output from the console, the first file is when i put  9 > the serial cable to the upper controller. (the problem)s& > the second from the down controller  > A > My question: What can i do that both batteries function again ?l > 	 > thanks,n >  > Nazim Manser    S I have continued working with the remaining controller, but i have another problem:a  * I can't set any settings on the controller Example: HSZ> set this prompt="HSZ02>"cM Error 4090: Module has invalid serial number.  This controller cannot be usedp             Call field service% Shelf 2 has a bad power supply or fan % Shelf 3 has a bad power supply or fan % Shelf 4 has a bad power supply or fan % Shelf 5 has a bad power supply or fani% Shelf 6 has a bad power supply or fana. Controller shelf has a bad power supply or fan Cache battery charge is lowt Write-back caching is disabled4 SWAP signal cleared - all SWAP interrupts re-enabled Other controller restarted  , Explanation for the bad power supply or fan:C i service the shelf with only one power supply, to economize power.s I service it at my Home.     Nazim Manser   ------------------------------   Date: 6 Dec 2002 13:59:29 -0600e; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) + Subject: RE: Province code change in Canadae3 Message-ID: <CmsZKvNdhy2W@eisner.encompasserve.org>i  ~ In article <BE56C50EA024184DAF48F0B9A47F5CF402660BBE@kaoexc01.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes: > / >>>> You may have to battle the Aztlaners ..<<<o > B > So how do Americans feel about having three official languages - > English, Spanish and French? >   @    We don't have an official language, but we almost had German.   ------------------------------  $ Date: Fri, 6 Dec 2002 15:22:25 -0500! From: VAXVMS <bounce@notmail.com> E Subject: RE: Request for Discussion, make comp.os.vms a moderated newsK Message-ID: <BA52530E3149734A9BAABDBBFA808E4903027BAC@rlghncst964.usps.gov>p   I concur with John.0  4 The last thing VMS needs is a less visible presence.  9 If c.o.v. were to disappear it would be seen by the worldc> at large as another indication of its moribundity and imminent
 demise.     / We know it ain't so, but many out there do not.i   WWWebb      > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3DF0E099.7B4BFFAC@swissonline.delete.ch...n > & > I have two thoughts on this subject. >oD > 1.  We should try to use the "subject" field in a way that is moreH > consistent with the nature of the posting because accurate titles will >  ....etc.  >cI > 2.  Is there some way that people who receive comp.os.vms via email canh >a
 > ....etc.   Good suggestions.   K I appreciate the desire to remove posts that are far off topic or are of an K offensive nature, but for several reasons do NOT want to see c.o.v split or J fragmented. We are a small group and the splitting of c.o.v may well causeL usage to drop below a "critical point" where most people cease to use it, as has happened to other groups.v  I We are a community and what you see here is representative of what people K do. While I think some of the posts are a waste of time, I use a newsreaderb and skip over the bulk of them.r  L Doc Cyber, John McLean's, and others suggestions regarding using the subjectJ field consistently and intelligently, and using OT in the subject field toE facilitate filtering of posts are very good and should be encouraged.n  E I  suggest that Mark Berryman consider filtering Info-VAX (or a newlytF created list), according to the criteria he has suggested - instead of altering the newsgroup itself.  I Finally, if a totally "on-topic" board is desired, I suggest setting up acL wwwboard (or equivalent) somewhere with paid subscription and registration -L not the removal or alteration of c.o.v. If the "noise" here is as bothersome5 as has been said, users should flock to such a forum.c   Stuart Johnson ssj152 AT charter DOT net    ========================  William W. Webb / DSSC/RLM, USPS OpenVMS Support Services& 4924 Green Road Raleigh, NC 27616-2800: 919.874.3043 <FirstInitialDotLastNameAtEmailDotUSPSDotGov>   ------------------------------   Date: 6 Dec 2002 11:58:19 -0800t* From: ken.randell@fortel.com (Ken Randell)K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupt= Message-ID: <8debc3ff.0212061158.39d488b3@posting.google.com>   A While I would agree in general with the principal of this (havingeF comp.os.vms postings actually have SOMETHING to do with VMS), I cannotF see how this can be made to work in the proposed 'automated' fashion.  In no certain order:  F 1) Even those folks who are the 'worst' OT offenders occasionally post, something on-topic, a useful reference, etc.? 2) What would keep someone from posting a 'useful' article, getV@ approved by a moderated, and then continue to be 'automatically' approved even if a post is OT.= 3) I haven't seen anything that defines OT material; there ist; certainly a lot of latitude in what some folks think is OT.oE 4) Most newsreaders have a 'killfile' or other mechanism for at leasth5 ignoring posts on certain topics and/or from posters.oE 5) There is at least one person (me) who might occasionally post fromcF multiple sources depending on location (i.e., home account if at home,F google if away from the office, etc.).  I would imagine that there areA others in the same position of having multiple means of accessingo USENET.M  E There are already other forums that exist, not the least of which arenF encompasserve and openvms.org.  Accessing each of these does take more time, however.  E I think that if you really want a moderated newsgroup, I believe thatwD you should bypass the 'automatic' stuff and make one or more persons- responsible for approving/disapproving posts.o   Ken Randelli   ------------------------------  * Date: Fri, 6 Dec 2002 20:39:52 +0000 (UTC). From: Dale Dellutri <ddelQQQlutr@panQQQix.com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup , Message-ID: <asr1uo$s4e$1@reader1.panix.com>  U On Thu, 05 Dec 2002 16:48:08 -0800, Mark Berryman <Mark.Berryman@mvb.saic.com> wrote:tH > I am in the process of writing up a formal RFD to begin the process to) > make comp.os.vms a moderated newsgroup.c  A I'd vote against this.  It's easy enough to ignore the off-topic   posts.   -- a7 Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)h   ------------------------------  $ Date: Fri, 6 Dec 2002 12:43:11 -0800, From: "James Gessling" <jgessling@yahoo.com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupe4 Message-ID: <asr250$u2jcg$1@ID-46415.news.dfncis.de>  = "Mark Berryman" <Mark.Berryman@Mvb.Saic.Com> wrote in message.& news:3DEF8348.64B322FE@Mvb.Saic.Com...H > I am in the process of writing up a formal RFD to begin the process toG > make comp.os.vms a moderated newsgroup.  The rationale behind this isaI > the fact that the noise level in this newsgroup has grown so large thatoI > the number of off-topic posts now exceeds the number of on-topic posts.d   Hi Mark,  G I read this earlier today and have thought about it quite a bit.  I can B see the motivation, but I must disagree with creating a new group.> As someone else has stated, the dwindling VMS population needsB every chance it can get to stay viable.  I think it's better to be@ as inclusive as possible and let the light shine in.  Hopefully,# it will germinate some new VMS'ers.e   Regards, Jim   ------------------------------   Date: 6 Dec 2002 14:53:49 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)-K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupu3 Message-ID: <JkRvXSIuSZDj@eisner.encompasserve.org>u  _ In article <3DEF8348.64B322FE@Mvb.Saic.Com>, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> writes:HH > I am in the process of writing up a formal RFD to begin the process toG > make comp.os.vms a moderated newsgroup.  The rationale behind this is<I > the fact that the noise level in this newsgroup has grown so large that J > the number of off-topic posts now exceeds the number of on-topic posts. I > Repeated requests to cease sending off-topic messages to this newsgroups, > have simply been ignored by the offenders. >   F    If I can't post a sound-off here every now and then maybe I'll just	    leave.l  =    Sorry, but there's just too little on-topic to talk about.e   ------------------------------  # Date: Fri, 06 Dec 2002 04:45:24 GMTg# From: "John Smith" <a@nonymous.com>tK Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgrouppH Message-ID: <EXVH9.19483$Q71.18647@news01.bloor.is.net.cable.rogers.com>  	 I concur.n  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3DF013F2.23253586@fsi.net...  > Mark Berryman wrote: > >tJ > > I am in the process of writing up a formal RFD to begin the process toI > > make comp.os.vms a moderated newsgroup.  The rationale behind this ishK > > the fact that the noise level in this newsgroup has grown so large that0K > > the number of off-topic posts now exceeds the number of on-topic posts.tK > > Repeated requests to cease sending off-topic messages to this newsgroupn. > > have simply been ignored by the offenders. > >sI > > Before submitting the formal proposal, however (which will need to be E > > cross-posted to news.groups and news.announce.newgroups) it seemslE > > worthwhile to begin an informal discussion with the denizens herenH > > regarding their thoughts on the subject.  It may be that no one elseI > > cares how non-VMSy this newsgroup has become (or, perhaps, not enougheL > > others see it as "noisy" as the few I've been in communication with do). > >aL > > So, in brief, the net result of the proposal being prepared would be the# > > creation of two new newsgroups:  > >n3 > > comp.os.vms.technical  which would be moderatedh5 > > comp.os.vms.advocacy   which would be unmoderated  > >s1 > > and the removal of the comp.os.vms newsgroup.  > >iE > > The charter of the technical group would be, as its name implies, K > > technical discussions that directly relate in some way to OpenVMS.  Anyo- > > posting not so related would be rejected.a > > H > > The gateway to the Info-VAX mailing list would move to the technical1 > > newsgroup and it would have the same charter.h > >hL > > Moderation would be automated.  A list would be maintained of anyone whoK > > has previously posted an on-topic message to the newsgroup.  Subsequent5G > > postings from that address would be immediately approved and, thus,uL > > experience very little delay in reaching the usenet community.  PostingsH > > from first-time posters (or from posters who posted off-topic enoughH > > times to be removed from the auto-moderation list) would be manually> > > screened by a moderator before being approved for posting. > >wL > > Forged postings, as with forged Approved: headers, would be handled on a+ > > case-by-case basis by the moderator(s).y > >yL > > Does anyone else have any thoughts they'd care to share on this subject? >hG > Well, if comp.os.vms disappears, what happens on Google Groups? Do wet: > lose the wealth of so many years of searchable articles? >g5 > If so, then I'd have to vote against this approach.  > F > I don't mind most of the off-topic stuff. In fact, I find some of itJ > quite educational. It's the nasty stuff I think we could all do without.J > I've blown my stack here more than once (posts including stuff like "YOU= > GOTTA BE S--TTING ME!" and so on), so I'm as guilty as any.  >eI > Dunno - changes are always slow to catch on, especially when there's so H > many searchable archives and articles in them pointing to comp.os.vms.D > Their loss may be sufficiently destructive of the ends you seek toG > protect that the entire effort may be self-defeating: by "strangling"iE > this group (probably the only pro-VMS contingent on the 'net), such G > efforts to gaurd VMS and its proponents may result in the accelerated>1 > death of VMS's presence on the 'net as a whole.  > H > I understand the motivation, but I think the effects may be the resultF > of causes beyond our control. I have (somewhere) a draft of a post IB > never sent - a rather long rant essentially responding to (then)F > Compaq's complaints about the negativity here. My gist was that theyA > don't understand that if they want the negativity to cease, theaI > provocations must cease first (killing off vital products, lies, brokensI > promises, etc.). Until that happens (not likely), the "venting" here ist > likely to continue.e >aF > So, trying to moderate the group may be likened to a "band-aid fix":G > covers the outward sign of the "disease", but does nothing to cure it 3 > and so the "patient" dies a more insidious death.I >nB > Also, it seems a bit too "parental": the children won't exerciseH > restraint, so we'll have to censor them. Probably very popular in HP's; > board room, but I doubt it will be so well received here.  >  > My $0.02, YMMV...i >o > -- > David J. Dachteras > dba DJE Systemsv > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Thu, 05 Dec 2002 22:35:09 -0800 " From: Koloth <koloth@telocity.com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup'+ Message-ID: <3DF0451D.5010003@telocity.com>O  & --------------0203090604040302020401079 Content-Type: text/plain; charset=us-ascii; format=flowed- Content-Transfer-Encoding: 7bit6  ; How about keeping this group but also creating a moderated i. comp.os.openvms.technical or something similarA That way those who get tired of the OT stuff will migrate to the  6 technical group.  Those who just want technical issuesH can go to the new group.  Over time comp.os.vms would most likely taper F off.  I know that on a daily basis I would see around 400 postings to 1 the group but only read about 20 to 50 of them.  t   My 100 shares of Enron worth.o   Cass Witkowski     John Smith wrote:   
 >I concur. >1= >"David J. Dachtera" <djesys.nospam@fsi.net> wrote in messagec" >news:3DF013F2.23253586@fsi.net... >  e >g >>Mark Berryman wrote: >>     >>I >>>I am in the process of writing up a formal RFD to begin the process tomH >>>make comp.os.vms a moderated newsgroup.  The rationale behind this isJ >>>the fact that the noise level in this newsgroup has grown so large thatJ >>>the number of off-topic posts now exceeds the number of on-topic posts.J >>>Repeated requests to cease sending off-topic messages to this newsgroup- >>>have simply been ignored by the offenders.n >>>eH >>>Before submitting the formal proposal, however (which will need to beD >>>cross-posted to news.groups and news.announce.newgroups) it seemsD >>>worthwhile to begin an informal discussion with the denizens hereG >>>regarding their thoughts on the subject.  It may be that no one elsetH >>>cares how non-VMSy this newsgroup has become (or, perhaps, not enoughK >>>others see it as "noisy" as the few I've been in communication with do).e >>> K >>>So, in brief, the net result of the proposal being prepared would be thet" >>>creation of two new newsgroups: >>>e2 >>>comp.os.vms.technical  which would be moderated4 >>>comp.os.vms.advocacy   which would be unmoderated >>> 0 >>>and the removal of the comp.os.vms newsgroup. >>>nD >>>The charter of the technical group would be, as its name implies,J >>>technical discussions that directly relate in some way to OpenVMS.  Any, >>>posting not so related would be rejected. >>>sG >>>The gateway to the Info-VAX mailing list would move to the technical,0 >>>newsgroup and it would have the same charter. >>> K >>>Moderation would be automated.  A list would be maintained of anyone whoeJ >>>has previously posted an on-topic message to the newsgroup.  SubsequentF >>>postings from that address would be immediately approved and, thus,K >>>experience very little delay in reaching the usenet community.  PostingssG >>>from first-time posters (or from posters who posted off-topic enougheG >>>times to be removed from the auto-moderation list) would be manually = >>>screened by a moderator before being approved for posting.I >>>cK >>>Forged postings, as with forged Approved: headers, would be handled on at* >>>case-by-case basis by the moderator(s). >>>sK >>>Does anyone else have any thoughts they'd care to share on this subject?p	 >>>      V >>> G >>Well, if comp.os.vms disappears, what happens on Google Groups? Do wee: >>lose the wealth of so many years of searchable articles? >>5 >>If so, then I'd have to vote against this approach.o >>F >>I don't mind most of the off-topic stuff. In fact, I find some of itJ >>quite educational. It's the nasty stuff I think we could all do without.J >>I've blown my stack here more than once (posts including stuff like "YOU= >>GOTTA BE S--TTING ME!" and so on), so I'm as guilty as any.  >>I >>Dunno - changes are always slow to catch on, especially when there's soiH >>many searchable archives and articles in them pointing to comp.os.vms.D >>Their loss may be sufficiently destructive of the ends you seek toG >>protect that the entire effort may be self-defeating: by "strangling"IE >>this group (probably the only pro-VMS contingent on the 'net), suchtG >>efforts to gaurd VMS and its proponents may result in the accelerated 1 >>death of VMS's presence on the 'net as a whole.  >>H >>I understand the motivation, but I think the effects may be the resultF >>of causes beyond our control. I have (somewhere) a draft of a post IB >>never sent - a rather long rant essentially responding to (then)F >>Compaq's complaints about the negativity here. My gist was that theyA >>don't understand that if they want the negativity to cease, the2I >>provocations must cease first (killing off vital products, lies, brokenaI >>promises, etc.). Until that happens (not likely), the "venting" here isw >>likely to continue.w >>F >>So, trying to moderate the group may be likened to a "band-aid fix":G >>covers the outward sign of the "disease", but does nothing to cure ito3 >>and so the "patient" dies a more insidious death.r >>B >>Also, it seems a bit too "parental": the children won't exerciseH >>restraint, so we'll have to censor them. Probably very popular in HP's; >>board room, but I doubt it will be so well received here.d >> >>My $0.02, YMMV...n >> >>-- >>David J. Dachtera  >>dba DJE Systemso >>http://www.djesys.com/ >>* >>Unofficial Affordable OpenVMS Home Page:! >>http://www.djesys.com/vms/soho/o >>     >> >o >  >  h >a    & --------------020309060404030202040107) Content-Type: text/html; charset=us-asciir Content-Transfer-Encoding: 7bith  ? <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">h <html> <head>   <title></title>i </head>  <body>T How about keeping this group but also creating a moderated comp.os.openvms.technical or something similar<br>J That way those who get tired of the OT stuff will migrate to the technical6 group. &nbsp;Those who just want technical issues <br>Q can go to the new group. &nbsp;Over time comp.os.vms would most likely taper off. O &nbsp;I know that on a daily basis I would see around 400 postings to the groupo0 but only read about 20 to 50 of them. &nbsp;<br> <br>! My 100 shares of Enron worth.<br>n <br> Cass Witkowski<br> <br> <br> John Smith wrote:<br>t <blockquote type="cite"tF  cite="midEXVH9.19483$Q71.18647@news01.bloor.is.net.cable.rogers.com">   <pre wrap="">I concur.   "David J. Dachtera" <a class="moz-txt-link-rfc2396E" href="mailto:djesys.nospam@fsi.net">&lt;djesys.nospam@fsi.net&gt;</a> wrote in messagetl <a class="moz-txt-link-freetext" href="news:3DF013F2.23253586@fsi.net">news:3DF013F2.23253586@fsi.net</a>...   </pre>   <blockquote type="cite">%     <pre wrap="">Mark Berryman wrote:o
     </pre>     <blockquote type="cite">Y       <pre wrap="">I am in the process of writing up a formal RFD to begin the process tolE make comp.os.vms a moderated newsgroup.  The rationale behind this is G the fact that the noise level in this newsgroup has grown so large that'G the number of off-topic posts now exceeds the number of on-topic posts.CG Repeated requests to cease sending off-topic messages to this newsgroup * have simply been ignored by the offenders.  E Before submitting the formal proposal, however (which will need to berA cross-posted to news.groups and news.announce.newgroups) it seemspA worthwhile to begin an informal discussion with the denizens here D regarding their thoughts on the subject.  It may be that no one elseE cares how non-VMSy this newsgroup has become (or, perhaps, not enoughmH others see it as "noisy" as the few I've been in communication with do).  H So, in brief, the net result of the proposal being prepared would be the creation of two new newsgroups:q  / comp.os.vms.technical  which would be moderatede1 comp.os.vms.advocacy   which would be unmoderatedr  - and the removal of the comp.os.vms newsgroup.   A The charter of the technical group would be, as its name implies,uG technical discussions that directly relate in some way to OpenVMS.  Anye) posting not so related would be rejected.M  D The gateway to the Info-VAX mailing list would move to the technical- newsgroup and it would have the same charter.i  H Moderation would be automated.  A list would be maintained of anyone whoG has previously posted an on-topic message to the newsgroup.  SubsequentmC postings from that address would be immediately approved and, thus,.H experience very little delay in reaching the usenet community.  PostingsD from first-time posters (or from posters who posted off-topic enoughD times to be removed from the auto-moderation list) would be manually: screened by a moderator before being approved for posting.  H Forged postings, as with forged Approved: headers, would be handled on a' case-by-case basis by the moderator(s).d  H Does anyone else have any thoughts they'd care to share on this subject?       </pre>     </blockquote>sV     <pre wrap="">Well, if comp.os.vms disappears, what happens on Google Groups? Do we8 lose the wealth of so many years of searchable articles?  3 If so, then I'd have to vote against this approach./  D I don't mind most of the off-topic stuff. In fact, I find some of itH quite educational. It's the nasty stuff I think we could all do without.H I've blown my stack here more than once (posts including stuff like "YOU; GOTTA BE S--TTING ME!" and so on), so I'm as guilty as any.o  G Dunno - changes are always slow to catch on, especially when there's sotF many searchable archives and articles in them pointing to comp.os.vms.B Their loss may be sufficiently destructive of the ends you seek toE protect that the entire effort may be self-defeating: by "strangling"-C this group (probably the only pro-VMS contingent on the 'net), suchyE efforts to gaurd VMS and its proponents may result in the accelerated2/ death of VMS's presence on the 'net as a whole.a  F I understand the motivation, but I think the effects may be the resultD of causes beyond our control. I have (somewhere) a draft of a post I@ never sent - a rather long rant essentially responding to (then)D Compaq's complaints about the negativity here. My gist was that they? don't understand that if they want the negativity to cease, theRG provocations must cease first (killing off vital products, lies, brokeniG promises, etc.). Until that happens (not likely), the "venting" here isl likely to continue.g  D So, trying to moderate the group may be likened to a "band-aid fix":E covers the outward sign of the "disease", but does nothing to cure it 1 and so the "patient" dies a more insidious death.>  @ Also, it seems a bit too "parental": the children won't exerciseF restraint, so we'll have to censor them. Probably very popular in HP's9 board room, but I doubt it will be so well received here.    My $0.02, YMMV...a   -- David J. Dachterat dba DJE SystemsfY <a class="moz-txt-link-freetext" href="http://www.djesys.com/">http://www.djesys.com/</a>e  ( Unofficial Affordable OpenVMS Home Page:k <a class="moz-txt-link-freetext" href="http://www.djesys.com/vms/soho/">http://www.djesys.com/vms/soho/</a>g
     </pre>   </blockquote>n   <pre wrap=""><!---->     </pre>
 </blockquote>s <br> </body>d </html>   ( --------------020309060404030202040107--   ------------------------------  % Date: Fri, 06 Dec 2002 10:44:34 +0000g( From: Nic Clews <sendspamhere@127.0.0.1>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup ) Message-ID: <3DF07F92.4CAC13C0@127.0.0.1>r   Mark Berryman wrote: >  ...XJ > Does anyone else have any thoughts they'd care to share on this subject?  E I browse the newsgroup with a news reader, and therefore I can filternA out by subject what I'm not interested in reading and the threads  therein.  G As a user of mailing lists as well, I'm fully aware of the problems theo@ gatewayed mail readers have, so I *always* consider not only theD relevance of what I'm posting, but also the timeliness, I think it's; unfair to repost the whole of a message with limited value.y  E While I am able to ignore (but I occasionally view the OT postings) I D appreciate there may still be some getting email by dial up, of this# list, and the noise is fairly high.   G Can we have a half way house of moderation? The INFOVAX gateway filterssE the messages sent, and perhaps unregistered posters cannot have theira5 posts gatewayed? FWIW I am registered but set NOMAIL.   F Drawbacks I see is that how, for example, would you identify a post asH being from me? I despammify the headers, and these could be forged, so aF determined poster could get through, and there are off topic champions) here, that do occasionally post on topic.r  C So after my thinking aloud, I'd like it to stay as it is, there arecH other technical resources, this is *free*, if you want real support, youF pay for it. Further, I find that the off topic discussions allow me toE see the thinking of those when discussing the on-topic  and sometimese contentious issues.e   -- o? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com-   ------------------------------   Date: 6 Dec 2002 11:34:49 -0000@4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupc3 Message-ID: <20021206113449.81.qmail@nym.alias.net>e  F On Thu, 05 Dec 2002, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> wrote:G >I am in the process of writing up a formal RFD to begin the process toaF >make comp.os.vms a moderated newsgroup.  The rationale behind this isH >the fact that the noise level in this newsgroup has grown so large thatI >the number of off-topic posts now exceeds the number of on-topic posts. dH >Repeated requests to cease sending off-topic messages to this newsgroup+ >have simply been ignored by the offenders.<  ' I can appreciate your reasoning, but....  F >Before submitting the formal proposal, however (which will need to beB >cross-posted to news.groups and news.announce.newgroups) it seemsB >worthwhile to begin an informal discussion with the denizens hereE >regarding their thoughts on the subject.  It may be that no one else F >cares how non-VMSy this newsgroup has become (or, perhaps, not enoughI >others see it as "noisy" as the few I've been in communication with do).f  B I see some people marking items as off-topic with an OT or [OT] inI subjects. Couldn't that practice be encouraged, and a filtered version oft Info-VAX made available?  I >So, in brief, the net result of the proposal being prepared would be thee  >creation of two new newsgroups: > 0 >comp.os.vms.technical  which would be moderated2 >comp.os.vms.advocacy   which would be unmoderated >u. >and the removal of the comp.os.vms newsgroup.  J Regrettably - as I understand it - the removal of c.o.v. would be requiredJ to permit the addition of these new groups. Not for technical reasons, butK something to do with the rules for the comp. hierarchy. This is the biggesteG stumbling block and I already see people objecting to the group's loss.a  B >The charter of the technical group would be, as its name implies,H >technical discussions that directly relate in some way to OpenVMS.  Any* >posting not so related would be rejected. > E >The gateway to the Info-VAX mailing list would move to the technicalI. >newsgroup and it would have the same charter. >rI >Moderation would be automated.  A list would be maintained of anyone who H >has previously posted an on-topic message to the newsgroup.  SubsequentD >postings from that address would be immediately approved and, thus,I >experience very little delay in reaching the usenet community.  PostingsrE >from first-time posters (or from posters who posted off-topic enougheE >times to be removed from the auto-moderation list) would be manually ; >screened by a moderator before being approved for posting.t  I That would be fine for me - apart from the demise of c.o.v. References tov5 the newsgroup would persist elsewhere for many years.c  I >Forged postings, as with forged Approved: headers, would be handled on ab( >case-by-case basis by the moderator(s). >aI >Does anyone else have any thoughts they'd care to share on this subject?t  J I've no actual issue with you going through the process, Though I strongly suspect it will be defeated.  G Accessing c.o.v. with a newsreader makes a huge difference in filteringdI what you want to read. Consequently I find things like broken quoting ande top-posting more irritating.       Doc. -- o6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                             https://vmsbox.cjb.netuK                                                    http://althacker.cjb.netx   ------------------------------  % Date: Fri, 06 Dec 2002 15:49:17 -0800d0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup + Message-ID: <3DF0C6FD.51E3CAC@Mvb.Saic.Com>h  G (Not a follow-up to my own posting but rather a response to some of the 0 concerns raised in the comments given thus far).    J > So, in brief, the net result of the proposal being prepared would be the! > creation of two new newsgroups:  > 1 > comp.os.vms.technical  which would be moderated 3 > comp.os.vms.advocacy   which would be unmoderatedt > / > and the removal of the comp.os.vms newsgroup.h  E The proposal is currently written this way simply because this is theuE "normal" way an existing unmoderated group is turned into a moderatedeF group.  The discussion usually involves questions similar to "so whereA do I send a posting that doesn't fit the charter of the moderatedPE group?".  So the "normal" answer is to created two new groups: one tonD handle moderated postings that adhere to the original charter of the0 newsgroup, another to handle all other postings.  F In practice, people do NOT cross-post to both groups - especially whenC the reason for making the group moderated is to weed out chaff.  OnuF topic posts get sent to the moderated group, off-topic posts end up in? the unmoderated group and, if they don't elicit any (or enough)  response, eventually die out.u  D One respondent mentioned another hierarchy where the .advocacy groupG fell into nothing but noise and eventually died.  That is, in fact, thee@ expected outcome.  When a group is moderated in order to keep itG on-topic, the unmoderated equivalent newsgroup almost always eventuallyt	 dies out.t  G All that being said, however, there is no rule that says things have tooG be done this way.  It is also permissible to simply change the existingcG group to moderated and not create any new groups or rename the existing G one.  It is, as said, somewhat less common to do it that way but if theeE consensus is that this is the better way to do it, then so let it be.  > C > The charter of the technical group would be, as its name implies,hI > technical discussions that directly relate in some way to OpenVMS.  Anyh+ > posting not so related would be rejected.a  C Some questions were asked that can summarized as "Exactly what doess< 'technical' mean?" or "Who decides what is really on-topic?"  9 The answer to the 2nd question is easy: the moderator(s).s  H It is the moderator(s) job to ensure that postings adhere to the charterD of the newsgroup.  A truly technical newsgroup would accept postingsC dealing with the hardware or software associated with VMS but wouldaF probably reject a posting whose topic was basically "VMS has no future because Carly is a boob".o  G On the other hand, if the charter were simply something along the linestG of "Issues concerning OpenVMS" then such a posting would be allowed butl> a topic along the lines of "This country has no future because0 <country's current leader> is a boob" would not.  G The desired charter is posted with the initial Call for Discussion and,hH if necessary, amended as part of the discussion.  The final, agreed upon> charter is then submitted with the formal Call for Votes.  TheB moderator(s) would then be bound by the guidelines of the charter.   > F > The gateway to the Info-VAX mailing list would move to the technical/ > newsgroup and it would have the same charter.   E Please note that Info-VAX did not originate this proposal.  This note G was included solely to answer what would happen to the Info-VAX mailinge@ list.  Info-VAX will remain gatewayed to whichever group handles0 technical discussions of VMS and related issues.   >d >   B Whenever this topic comes up, someone always mentions that the theA vmsnet.* hierarchy should be used or, sometimes, that the lack ofmE traffic in vmsnet.* shows that everyone likes comp.os.vms exactly the0H way it is.  The main reason these arguments don't work is that while theD comp.* hierarchy is ubiquitous throughout usenet - vmsnet.* is not. A Moving any discussion to vmsnet.* immediately loses a significantDB portion of the potential audience.  Unfortunately, this means thatD vmsnet.* is not a viable answer to any issues regarding comp.os.vms.  E Hmmm, it appears that the above paragraph mixes facts and opinions sol let me restate:n  G Comp.os.vms and vmsnet.* do not enjoy equal distribution throughout thet usenet community (fact).  F Accordingly, vmsnet.* is not a viable solution to any issues regarding3 comp.os.vms (opinion, so you may feel differently).t    
 Mark Berrymank Mark.Berryman@Mvb.Saic.Com   ------------------------------  % Date: Fri, 06 Dec 2002 16:06:54 -0800g" From: Brad Hughes <brad@tgsmc.com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupa( Message-ID: <3DF13B9E.3070408@tgsmc.com>  D Personally, I don't find the amount of OT posts warrants moderation.   brad   ------------------------------  % Date: Fri, 06 Dec 2002 19:29:25 -0500a( From: David Froble <davef@tsoft-inc.com>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup , Message-ID: <3DF140E5.5000808@tsoft-inc.com>   Mark Berryman wrote:  H > I am in the process of writing up a formal RFD to begin the process to) > make comp.os.vms a moderated newsgroup.     N Well, so far I can see 18 responses.  I think 4 of them are second posts from P people, so 14 distinct people.  There may be more that my ISV hasn't picked up, 7 I really don't trust their service, but it's all I got.e  > Not one of the responses favors the proposal.  Most reject it.  G In the interest of openness, could those who favor such an action make cO themselves known to the rest of us?  I for one do not think that some 'secret' s group should affect c.o.v.  L I'm assuming that this is not a unilateral action you're taking by yourself.  G Before any action is taken, perhaps a public list of posters and their o! preferences would be appropriate.s   Dave   ------------------------------  % Date: Fri, 06 Dec 2002 15:43:11 -0500i0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupe/ Message-ID: <3DF10BDE.D25A5F15@vl.videotron.ca>   I Apart for the catfight between Fred and Andrew, most of the non technicalt9 discussions generally deal with the business side of VMS.a  L While Fred Hoff and others may not appreciate such discussions, I feel it isH important that they be aware of certain customer sentiments which may beM filtered before it reaches them through the HP channels. Same applies to Sue.s  G If the only emails the VMS group at HP ever gets are nice, kind success M stories and they never see any of the concerns from the field, it would to topL their loss. Not only do these concerns sometimes get adressed, but they alsoG give the VMS group some ammunition when they try to get more freedom toaK market/push  VMS from their non-VMS superiors who don't want VMS to expand.u  M With the demise of a single "DECUS" worldwide, comp.os.vms fills an importantg5 gap in keeping the VMS folks in touch with customers.   D With a newsreader, I have no problems skipping over threads I am notG interested in.  Perhaps if you are using character cell VMSmail to wadeeM through posts from the mailing list intersperced with real email, it makes itt harder.:   ------------------------------  % Date: Fri, 06 Dec 2002 15:51:15 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>K Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroupo/ Message-ID: <3DF10DC1.D2543B1C@vl.videotron.ca>   D One of the contributors that is very valued here is our beloved Sue.  I She isn't exactly technical. But I get the impression that many very muchiH appreciate her contributions. I don't think that we would win if the newR structure were to make it harder for Sue to get in touch with us (and vice versa).  H It is much quickler to browse through one newsgroup than to have to scan multiple newsgroups.   ------------------------------  $ Date: Fri, 6 Dec 2002 13:04:19 -06002 From: "Stuart Johnson" <ssj152 AT charter DOT net>X Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks!/ Message-ID: <uv1t5n5u2tdadf@corp.supernews.com>   > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3DF0E099.7B4BFFAC@swissonline.delete.ch...  >s& > I have two thoughts on this subject. >hD > 1.  We should try to use the "subject" field in a way that is moreH > consistent with the nature of the posting because accurate titles will >  ....etc.r >6I > 2.  Is there some way that people who receive comp.os.vms via email cano > 
 > ....etc.   Good suggestions.o  K I appreciate the desire to remove posts that are far off topic or are of anaK offensive nature, but for several reasons do NOT want to see c.o.v split ormJ fragmented. We are a small group and the splitting of c.o.v may well causeL usage to drop below a "critical point" where most people cease to use it, as has happened to other groups.   I We are a community and what you see here is representative of what peopleoK do. While I think some of the posts are a waste of time, I use a newsreader  and skip over the bulk of them.l  L Doc Cyber, John McLean's, and others suggestions regarding using the subjectJ field consistently and intelligently, and using OT in the subject field toE facilitate filtering of posts are very good and should be encouraged.e  E I  suggest that Mark Berryman consider filtering Info-VAX (or a newly F created list), according to the criteria he has suggested - instead of altering the newsgroup itself.  I Finally, if a totally "on-topic" board is desired, I suggest setting up atL wwwboard (or equivalent) somewhere with paid subscription and registration -L not the removal or alteration of c.o.v. If the "noise" here is as bothersome5 as has been said, users should flock to such a forum.i   Stuart Johnson ssj152 AT charter DOT net    ------------------------------  % Date: Fri, 06 Dec 2002 13:29:39 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com>iX Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks!% Message-ID: <3DF108B3.40908@MMaz.com>-   Stuart Johnson wrote:e  ? >"John McLean" <mcleanj@swissonline.delete.ch> wrote in messager0 >news:3DF0E099.7B4BFFAC@swissonline.delete.ch... >  m > & >>I have two thoughts on this subject. >>D >>1.  We should try to use the "subject" field in a way that is moreH >>consistent with the nature of the posting because accurate titles will >> ....etc.h >>I >>2.  Is there some way that people who receive comp.os.vms via email cans >>
 >>....etc. >>     >> >t >Good suggestions. > L >I appreciate the desire to remove posts that are far off topic or are of anL >offensive nature, but for several reasons do NOT want to see c.o.v split orK >fragmented. We are a small group and the splitting of c.o.v may well causeeM >usage to drop below a "critical point" where most people cease to use it, asr >has happened to other groups. >tJ >We are a community and what you see here is representative of what peopleL >do. While I think some of the posts are a waste of time, I use a newsreader  >and skip over the bulk of them. >  u >cI The problem is that it still takes time to 'skip' over the crap when the sA topic drifts miles past the original posting subject.  C.O.V was >G originally a technical forum and, in my eyes, it should return to this sI and drop all of the peripheral non-sense that is not directly related to  E VMS; That includes the political or business aspects of HP, put that  F someone else, as I do not see that as a split but rather a refocusing ) back to the original roots of the list...i  I I, for one, would drop this list in a heartbeat if another VMS Technical xC Only list, perhaps via Encompass, could reach critical mass simply s: because the noice on this list has reach such dB levels...   Regards,   Barry    -- r  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028e   ------------------------------   Date: 6 Dec 2002 14:03:49 -0600t3 From: bradhamilton@127.0.0.1 (Bradford J. Hamilton) X Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks!3 Message-ID: <hutrJ++PWQaU@eisner.encompasserve.org>s  e In article <j08I9.491$Fq3.78493@twister.southeast.rr.com>, "Ken Farmer" <kfarmer@openvms.org> writes:lI > I'd be glad to start that list.  A poll I've run for the last of couple N > months shows 91% of 150+ voters would like an openvms-managers-list started.N > I can have that completed and tested by the end of the weekend.  Anyone want > to sign up for testing?  > N > I've already got a monthly newsletter keeping subscribers updated on monthly+ > industry news and other related subjects.n > 8 > I also have technical and general forum on OpenVM.org. > ' > Any comments from the peanut gallery?d >  > -- >  > Kenneth Farmer > http://www.Tru64.org > http://www.OpenVMS.org > http://www.LinuxHPC.orgo >   C I'd be interested in such a list, and I will volunteer for testing. J I like all kinds of nuts, but I wasn't aware there was a gallery for them! :-)s   >  >  > 8 > "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! > news:3DF108B3.40908@MMaz.com...t >> Stuart Johnson wrote: >>B >> >"John McLean" <mcleanj@swissonline.delete.ch> wrote in message3 >> >news:3DF0E099.7B4BFFAC@swissonline.delete.ch...  >> > >> >) >> >>I have two thoughts on this subject.o >> >> G >> >>1.  We should try to use the "subject" field in a way that is moreuK >> >>consistent with the nature of the posting because accurate titles willo >> >> ....etc. >> >> L >> >>2.  Is there some way that people who receive comp.os.vms via email can >> >>,
 >> >>....etc.n >> >>  >> >>  >> > >> >Good suggestions.s >> >L >> >I appreciate the desire to remove posts that are far off topic or are of > anL >> >offensive nature, but for several reasons do NOT want to see c.o.v split > orH >> >fragmented. We are a small group and the splitting of c.o.v may well > causebM >> >usage to drop below a "critical point" where most people cease to use it,S > as! >> >has happened to other groups.  >> >M >> >We are a community and what you see here is representative of what peoplesD >> >do. While I think some of the posts are a waste of time, I use a > newsreader# >> >and skip over the bulk of them.e >> > >> >K >> The problem is that it still takes time to 'skip' over the crap when theaC >> topic drifts miles past the original posting subject.  C.O.V wasnI >> originally a technical forum and, in my eyes, it should return to thiseK >> and drop all of the peripheral non-sense that is not directly related toa > G >> VMS; That includes the political or business aspects of HP, put thatoH >> someone else, as I do not see that as a split but rather a refocusing, >> back to the original roots of the list... >>K >> I, for one, would drop this list in a heartbeat if another VMS Technical'E >> Only list, perhaps via Encompass, could reach critical mass simplyt= >> because the noice on this list has reach such dB levels...s >> >> Regards,. >> >> Barry >> >> --t >>B >> Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO >>D >> E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028 >> >> >  >    ------------------------------   Date: 6 Dec 2002 14:45:41 -0600d+ From: young_r@encompasserve.org (Rob Young)sX Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks!3 Message-ID: <o5U5dQLPh3jw@eisner.encompasserve.org>   e In article <j08I9.491$Fq3.78493@twister.southeast.rr.com>, "Ken Farmer" <kfarmer@openvms.org> writes: I > I'd be glad to start that list.  A poll I've run for the last of couplepN > months shows 91% of 150+ voters would like an openvms-managers-list started.N > I can have that completed and tested by the end of the weekend.  Anyone want > to sign up for testing?f > N > I've already got a monthly newsletter keeping subscribers updated on monthly+ > industry news and other related subjects.4 > 8 > I also have technical and general forum on OpenVM.org. > ' > Any comments from the peanut gallery?  >    	Yes.  p  7 	Why isn't comp.os.vms dead or why is it still popular?n> 	Because it is text based.  Don't send HTML or Mime.  Larry K. 	will rip into ya.  ; 	The very last thing I want to do is to slog my way throughiA 	pop-up ads or "click here... click here... click here.."  Sheesho! 	we all do too much of that crud.   E 	Text Usenet is still very much alive even with whizzier GUIs and Webr 	available.t  > 	There is something very good about plain old text... the best? 	thing of all is it is lightweight.  Not unlike reading a book."B 	The day a book comes to electronics and stays there - with pop-up7 	ads to go with it - is the day I don't read new books.   B 	Nothing personal, I do like your site.  But USENET is a whole lotH 	faster and easier to slog through with a proper newsreader.(1)  I thinkC 	the issue is the poor folks that are only gatewayed.  They get the D 	brunt of trying to sort through emails off topic or topics that areF 	uninteresting to them.  It takes me all of 30 seconds to sort throughG 	100 topics with a newsreader, (looking for something interesting) and e, 	that estimate is probably on the high side.   				Robh  H (1)  Page up and page down on a text based newsreader.  Know how long itK      takes a >>STUPID<< web-based newsreader to give you the next screen ofeH      HTML and paint that?   In some ways, this Web stuff certainly isn't      progress.  - 		   c.o.v. --  "The Grumpier Older Slashdot"    ------------------------------  # Date: Fri, 06 Dec 2002 20:46:07 GMTt( From: "Ken Farmer" <kfarmer@openvms.org>X Subject: Re: Request for Discussion, make comp.os.vms a moderated newsgroup - No thanks!: Message-ID: <j08I9.491$Fq3.78493@twister.southeast.rr.com>  G I'd be glad to start that list.  A poll I've run for the last of couplemL months shows 91% of 150+ voters would like an openvms-managers-list started.L I can have that completed and tested by the end of the weekend.  Anyone want to sign up for testing?   L I've already got a monthly newsletter keeping subscribers updated on monthly) industry news and other related subjects.h  6 I also have technical and general forum on OpenVM.org.  % Any comments from the peanut gallery?A   --   Kenneth Farmer http://www.Tru64.org http://www.OpenVMS.org http://www.LinuxHPC.orge        6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message news:3DF108B3.40908@MMaz.com...e > Stuart Johnson wrote:a >nA > >"John McLean" <mcleanj@swissonline.delete.ch> wrote in messagee2 > >news:3DF0E099.7B4BFFAC@swissonline.delete.ch... > >s > >e( > >>I have two thoughts on this subject. > >>F > >>1.  We should try to use the "subject" field in a way that is moreJ > >>consistent with the nature of the posting because accurate titles will
 > >> ....etc.c > >>K > >>2.  Is there some way that people who receive comp.os.vms via email can  > >> > >>....etc. > >> > >> > >p > >Good suggestions. > > K > >I appreciate the desire to remove posts that are far off topic or are ofw anK > >offensive nature, but for several reasons do NOT want to see c.o.v splite orG > >fragmented. We are a small group and the splitting of c.o.v may wellf causefL > >usage to drop below a "critical point" where most people cease to use it, as  > >has happened to other groups. > >rL > >We are a community and what you see here is representative of what peopleC > >do. While I think some of the posts are a waste of time, I use a 
 newsreader" > >and skip over the bulk of them. > >c > > J > The problem is that it still takes time to 'skip' over the crap when theB > topic drifts miles past the original posting subject.  C.O.V wasH > originally a technical forum and, in my eyes, it should return to thisJ > and drop all of the peripheral non-sense that is not directly related to  F > VMS; That includes the political or business aspects of HP, put thatG > someone else, as I do not see that as a split but rather a refocusingi+ > back to the original roots of the list...  >oJ > I, for one, would drop this list in a heartbeat if another VMS TechnicalD > Only list, perhaps via Encompass, could reach critical mass simply< > because the noice on this list has reach such dB levels... >a
 > Regards, >  > Barryn >t > -- >cA > Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIOu >,C > E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028h >v >i   ------------------------------  $ Date: Fri, 6 Dec 2002 19:22:07 +0000, From: Ted Allwood <support@leva.leeds.ac.uk>= Subject: Testing for status of remote host via web CGI scripti3 Message-ID: <00A180E5.3AB6943C.33@leva.leeds.ac.uk>h  $ I thought this would be easy, but...  8 I have two webservers running on the Local Area Network.' Web1 is a VMS 7.1, UCX 4.2, OSU system.iG Web2 is an embedded server in a webcam which monitors a lab experiment.   F The aim is to run a non-privileged CGI DCL script on Web1 to determineC the status (up/down) of Web2.  It should report back to the user's g6 web browser in not more than 30 secs, preferably less.   Things I've tried:  7 1. Grab Web2's home page via the freeware Wget utility.;2    Then F$search to see if the file was retrieved.8    This works but, if Web2 is down, the timeout interval=    is too long at 75 secs.  Wget has a -T timeout option but,>A    as far as I can tell, relates to the file retrieval completions$    once a connection is established.   2. UCX PING or TRACEROUTE.    No good; needs privileges  t% 3. FTP (using Hunter Goatley's HGFTP)wB    Web2 doesn't run an ftp server, but that doesn't matter as the H    responses system-f-reject or system-f-timeout could be distinguished.=    But the latter takes about a minute to respond - too long.   
 4. Telnet B    Same general idea as the ftp test but (AFAIK) this couldn't be (    done from within a command procedure.     Any better ideas, please.k   Regards, Tedt   -- =K Support@leva.leeds.ac.uk                                Tel:  0113 34 32167=+ www.mech-eng.leeds.ac.uk/support/index.html"G School of Mechanical Engineering,  University of Leeds,  Leeds  LS2 9JTp   ------------------------------  $ Date: Fri, 6 Dec 2002 11:27:42 -0800$ From: Shane Smith <ssmith@icius.com>A Subject: RE: Testing for status of remote host via web CGI scripti0 Message-ID: <01C29D1A.87064200@sulfer.icius.com>  H Write a little program that opens a TCP/IP channel to the remote machineF and executes a read when nothing's expected. It'll sit there and wait,B and when the remote end goes down, the read will terminate with anC error. You could use that to raise any kind of flag you want on ther monitoring machine.o   Shane    -----Original Message-----3 From: Ted Allwood [mailto:support@leva.leeds.ac.uk]e( Sent: Friday, December 06, 2002 11:22 AM To: Info-VAX@Mvb.Saic.Come= Subject: Testing for status of remote host via web CGI scripto    $ I thought this would be easy, but...  8 I have two webservers running on the Local Area Network.' Web1 is a VMS 7.1, UCX 4.2, OSU system.eG Web2 is an embedded server in a webcam which monitors a lab experiment.   F The aim is to run a non-privileged CGI DCL script on Web1 to determineC the status (up/down) of Web2.  It should report back to the user's o6 web browser in not more than 30 secs, preferably less.   Things I've tried:  7 1. Grab Web2's home page via the freeware Wget utility.w2    Then F$search to see if the file was retrieved.8    This works but, if Web2 is down, the timeout interval=    is too long at 75 secs.  Wget has a -T timeout option but,tA    as far as I can tell, relates to the file retrieval completione$    once a connection is established.   2. UCX PING or TRACEROUTE.    No good; needs privileges  l% 3. FTP (using Hunter Goatley's HGFTP)eB    Web2 doesn't run an ftp server, but that doesn't matter as the H    responses system-f-reject or system-f-timeout could be distinguished.=    But the latter takes about a minute to respond - too long.f  
 4. Telnet B    Same general idea as the ftp test but (AFAIK) this couldn't be (    done from within a command procedure.     Any better ideas, please.r   Regards, Teds   -- sE Support@leva.leeds.ac.uk                                Tel:  0113 34) 32167b+ www.mech-eng.leeds.ac.uk/support/index.htmliG School of Mechanical Engineering,  University of Leeds,  Leeds  LS2 9JTd   ------------------------------  # Date: Fri, 06 Dec 2002 19:29:00 GMTo" From:   VAXman-  @SendSpamHere.ORGA Subject: Re: Testing for status of remote host via web CGI scripts0 Message-ID: <00A180BC.4B35BFE4@SendSpamHere.ORG>  b In article <00A180E5.3AB6943C.33@leva.leeds.ac.uk>, Ted Allwood <support@leva.leeds.ac.uk> writes:% >I thought this would be easy, but...  >r9 >I have two webservers running on the Local Area Network.,( >Web1 is a VMS 7.1, UCX 4.2, OSU system.H >Web2 is an embedded server in a webcam which monitors a lab experiment. >mG >The aim is to run a non-privileged CGI DCL script on Web1 to determinedD >the status (up/down) of Web2.  It should report back to the user's 7 >web browser in not more than 30 secs, preferably less.  >h >Things I've tried:t > 8 >1. Grab Web2's home page via the freeware Wget utility.3 >   Then F$search to see if the file was retrieved.e9 >   This works but, if Web2 is down, the timeout intervalg> >   is too long at 75 secs.  Wget has a -T timeout option but,B >   as far as I can tell, relates to the file retrieval completion% >   once a connection is established.  >a >2. UCX PING or TRACEROUTE.m >   No good; needs privilegesc > & >3. FTP (using Hunter Goatley's HGFTP)C >   Web2 doesn't run an ftp server, but that doesn't matter as the  I >   responses system-f-reject or system-f-timeout could be distinguished.e> >   But the latter takes about a minute to respond - too long. >  >4. Telnet tC >   Same general idea as the ftp test but (AFAIK) this couldn't be l) >   done from within a command procedure.U >l >a >Any better ideas, please. >n	 >Regards,i >Ted  D Does Web2 have SNMP support?  If so, a simple SNMP_REQUEST might be  your answer. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMt            d5   "Well my son, life is like a beanstalk, isn't it?" o   ------------------------------   Date: 6 Dec 2002 14:52:36 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: RE: TK70 drive bug found :-( 3 Message-ID: <MY1VzLzne3+2@eisner.encompasserve.org>   W In article <01C29C77.ED923AE0@sulfer.icius.com>, Shane Smith <ssmith@icius.com> writes:s5 > Caution: second hand unconfirmed story approaching.: > I > I used to work with someone whose Dad worked at NASA in the Apollo era./G > According to her, while the computers were working none of the lights=G > flashed. Her Dad was asked to write a program like yours to flash the-G > lights in random sequence when VIPs were showed round. Unfortunately,aD > when it was running the machines didn't have enough power left forH > actual work, so both the machines and the people were pretending to be	 > busy...  >   D    I was working on a NOAA contract at a NASA site once when someoneD    was filming for a presentation to a foreign government.  Had justI    started a long, slow command on my 11/780.  I put the VT100 into localfD    mode and started hammering away to make things look busy.  AnyoneF    who knew what was going on would notice that I had to hit line feed    after every return.   ------------------------------  $ Date: Fri, 6 Dec 2002 10:11:11 -00002 From: "Chris Sharman" <chris.sharman@sorry.nospam>E Subject: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?h4 Message-ID: <aspt4c$mdp$1$8302bc10@news.demon.co.uk>  H I installed the VMS73_SYS05 patch two weeks ago & rebooted. On rebootingH dce, pathworks & goldfax were all broken (dce fixed with another supportI call, no luck yet with the others). Talking to DPD, suppliers of Goldfax,rI they've got a similar problem with another customer, who's identified thegL VMS731_SYS02 patch as causing his problem, which was released at roughly the2 same time, and is presumably a very similar patch.  L Is anyone aware of any problem with this patch ? Is there a fix ? Is backing out advisable ?f   Thanks,p
 Chris Sharmant   ------------------------------  # Date: Fri, 06 Dec 2002 12:00:49 GMTi/ From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com>eI Subject: Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?,7 Message-ID: <Rj0I9.8144$f6.175501@twister.maine.rr.com>h  = "Chris Sharman" <chris.sharman@sorry.nospam> wrote in message . news:aspt4c$mdp$1$8302bc10@news.demon.co.uk...J > I installed the VMS73_SYS05 patch two weeks ago & rebooted. On rebootingJ > dce, pathworks & goldfax were all broken (dce fixed with another supportK > call, no luck yet with the others). Talking to DPD, suppliers of Goldfax,oK > they've got a similar problem with another customer, who's identified theaJ > VMS731_SYS02 patch as causing his problem, which was released at roughly theC4 > same time, and is presumably a very similar patch. >FF > Is anyone aware of any problem with this patch ? Is there a fix ? Is backingl > out advisable ?t >f	 > Thanks,e > Chris Sharmanh >n >g  A We had to back the VMS731_SYS02 patch out.  We had problems with:e  %  - TCPIP Services SMTP queues hangingaK  - Non-fatal INCONSTATE bugchecks in the ERRORLOG (HP had some newer imagesp to fix this one).t  E I did, however, recently upgrade all our production systems to V7.3-1mH (without the patch) and the only issue we're currently hunting down is a5 problem with slow dismounts on HSJ based tape drives.w   Jeff   ------------------------------   Date: 6 Dec 2002 16:27:03 -0800t( From: bob@instantwhip.com (Bob Ceculski)) Subject: Re: Webserver advice for VAX/VMSn= Message-ID: <d7791aa1.0212061627.22da62fd@posting.google.com>   ^ david20@alpha1.mdx.ac.uk (David Webb) wrote in message news:<asqd2r$509$1@aquila.mdx.ac.uk>...i > In article <d7791aa1.0212060618.20466b5@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:nh > >goathunter@goatley.com (Hunter Goatley) wrote in message news:<3defc799.32100478@news.process.com>...S > >> On Thu, 5 Dec 2002 12:33:15 +0000 (UTC), david20@alpha1.mdx.ac.uk (David Webb)c > >> wrote:v > >>  S > >> >I thought Purveyor when it was still being developed was a commercial productr > >> >not freeware.t > >> -
 > >> Correct.  > >> w: > >> >Can you even obtain Purveyor from Process any more ? > >> >T > >> It's available to Hobbyists for free, and we still sell licenses for it, thoughQ > >> it is unsupported (and we still do sell some licenses each year, despite the  > >> unsupported status).h > >> i > >> Hunterl > >> ------n> > >> Hunter Goatley, Process Software, http://www.process.com/= > >> goathunter@goatley.com    http://www.goatley.com/hunter/eA > >> New Robert R. McCammon site: http://www.RobertRMcCammon.com/  > >iG > >and that is because it is still a bulletproof, easy to use webserverlA > >for VMS, vax and alpha ... I think you should start up supporte > >again for it ...t > M > Or better yet release it to the public domain - then Bob can develop it andm
 > support it.e > M > I can't see any reason for Process to develop and support it. The number ofiN > companies who will be prepared to pay for it as a commercial product must beJ > pretty small - though the fact they still sell licenses each year arguesD > there are still some customers who don't want a freeware solution. >  >  >    > David Webb > VMS and Unix team leader > CCSS > Middlesex University  G no, they but it because it works and is very easy to setup and maintain:" but has many powerful features ...   ------------------------------   Date: 6 Dec 2002 06:18:48 -0800y( From: bob@instantwhip.com (Bob Ceculski)) Subject: Re: Webserver advice for VAX/VMSn< Message-ID: <d7791aa1.0212060618.20466b5@posting.google.com>  e goathunter@goatley.com (Hunter Goatley) wrote in message news:<3defc799.32100478@news.process.com>...aP > On Thu, 5 Dec 2002 12:33:15 +0000 (UTC), david20@alpha1.mdx.ac.uk (David Webb) > wrote: > P > >I thought Purveyor when it was still being developed was a commercial product > >not freeware. > 
 > Correct. > 7 > >Can you even obtain Purveyor from Process any more ?  > > Q > It's available to Hobbyists for free, and we still sell licenses for it, though0N > it is unsupported (and we still do sell some licenses each year, despite the > unsupported status). >  > Hunter > ------; > Hunter Goatley, Process Software, http://www.process.com/.: > goathunter@goatley.com    http://www.goatley.com/hunter/> > New Robert R. McCammon site: http://www.RobertRMcCammon.com/  D and that is because it is still a bulletproof, easy to use webserver> for VMS, vax and alpha ... I think you should start up support again for it ...   ------------------------------   Date: 6 Dec 2002 14:24:58 -0600b; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)g( Subject: Re: what does this command mean3 Message-ID: <tuuaCbiwSWyh@eisner.encompasserve.org>a  g In article <873024fe.0212031826.6b8bce6a@posting.google.com>, cardenas0000@yahoo.com (Valegant) writes:  > what does this command mean- >  >        TYPE/PAGE NL: > J > I know what it does, it clears the screen, but i dont know what it means    D     Help type will tell you most of what you need.  That harder part<     to dig up is that nl: is a reference to the null device.   ------------------------------   Date: 6 Dec 2002 14:25:55 -0600a; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)d( Subject: Re: what does this command mean3 Message-ID: <6ZjmY3t+WsX6@eisner.encompasserve.org>n  b In article <3DED9B9C.A65F7832@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > Shane Smith wrote: >> NL: >> wI >> This is the null device, which in this particular case behaves like an  >> empty file. > M > I was always told it was a big bit bucket. What puzzles me though is if you K > send a whole bunch of stuff to the big bit bucket, and why won't TYPE NL: 1 > bring back the stuff from that big bit bucket ?  >  > :-) :-) :-) :-) :-)   9    Peculiar thing, bit buckets.  Always seem to be leaky.t   ------------------------------   Date: 6 Dec 2002 14:27:32 -0600e; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ( Subject: Re: what does this command mean3 Message-ID: <4eg0VnQupYg7@eisner.encompasserve.org>   b In article <3DED9B9C.A65F7832@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > F > (Seriously though, such a device would have been quite interesting ,O > especially prior to the appearance of the PIPE command, it would allow you todN > create a bucket, send output to it, and then read from it. (think of it as aM > temporary in-memory file). That would have allowed piping capabilities thattO > would have been far more efficient because the command woudl execute from thel6 > same process, with no subprocess creation overhead).  B    Mailbox.  Sometimes I think it would be nice to have a stretchy    mailbox (like a UNIX pipe).   ------------------------------  % Date: Fri, 06 Dec 2002 13:18:10 +0100h9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>n Subject: Re: XFC questiona' Message-ID: <3DF09581.72DCD323@aaa.com>l   Try VCC_MAXSIZE.& And see SYSGEN> HELP SYS_PARAM VCC*  :     VCC_MAX_CACHE>  E        (Alpha only) VCC_MAX_CACHE is a special parameter reserved forC        Compaq use only.      Jan-Erik Serholms     Rudolf Wingert wrote:h >  > Hello, > ; > I would like to do the following: for all nodes I did set + > VCC_MAX_CACHE to -1 within MODPARAMS.DAT.    ------------------------------   Date: 6 Dec 2002 15:27:29 -0600n3 From: bradhamilton@127.0.0.1 (Bradford J. Hamilton)tO Subject: [OT] top-posting (was: Re: Request for Discussion, make comp.os.vms...s3 Message-ID: <y1d3gJ5neAYs@eisner.encompasserve.org>   b In article <3DF12133.C77B572D@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > Rob Young wrote:E >>         The very last thing I want to do is to slog my way throughoK >>         pop-up ads or "click here... click here... click here.."  Sheeshe+ >>         we all do too much of that crud.n > D > The end of the world must be near, because I agree with Rob Young. >  > O >>         Text Usenet is still very much alive even with whizzier GUIs and Webo >>         available.v > K > There is however a constant pressure by newbies to bring in the microsoftn< > religion (top posting and html). It is hard to fight this.  I I disagree that top-posting is a M$oft religion.  I use a text-based news.N reader, and when I format a reply (like I am doing now), the cursor appears atK the top of the page.  Way too easy to top-post - when I first started usinguJ newsgroups, I *assumed* that I was supposed to top-post.  I still have theK habit today, because it is "easy", and because I am reluctant to snip *any*fM text that I am replying to (to avoid charges of quoting another person out of-I context - anyone can refer to the text that I have quoted, usually in itsbM entirety).  *I* personally find it annoying to wade through 5+ pages of text,eK much of which I have read before, to find a person's one line answer at the  bottom.a  + I will now do something I don't usually do.    <snip> :-)-   ------------------------------   Date: 6 Dec 2002 15:54:42 -0600i- From: Kilgallen@SpamCop.net (Larry Kilgallen)qS Subject: Re: [OT] top-posting (was: Re: Request for Discussion, make comp.os.vms...03 Message-ID: <9FBpRIxBlWhd@eisner.encompasserve.org>m  i In article <y1d3gJ5neAYs@eisner.encompasserve.org>, bradhamilton@127.0.0.1 (Bradford J. Hamilton) writes:   M > habit today, because it is "easy", and because I am reluctant to snip *any*oO > text that I am replying to (to avoid charges of quoting another person out ofpK > context - anyone can refer to the text that I have quoted, usually in itse > entirety).  G If you post here, someone will not like it for some reason.  If that isoF their reason for disliking it, at least you have done the rest of us a" service by trimming appropriately.   ------------------------------   End of INFO-VAX 2002.675 ************************