1 INFO-VAX	Fri, 04 Aug 2006	Volume 2006 : Issue 430       Contents: Apache in COLPG state  Re: Apache in COLPG state / AWstats for SWS on OpenVMS working - here's how  Enabling SMTP in VAX/VMS Re: Enabling SMTP in VAX/VMS Re: Enabling SMTP in VAX/VMS" Re: FW: Linux on military aircraftN Re: high level byte code/IL (Was: querying Web Services from the command line)P high level byte code/IL (Was: querying Web Services from the command line) line) Re: InfoServer 100 success< Re: Is there a Unix /tmp directory. How dissimilar are they. Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft RE: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft RE: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft RE: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft Re: Linux on military aircraft; Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09) ; Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09) ; Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09) ; Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09) / Re: querying Web Services from the command line / Re: querying Web Services from the command line  Speaking of Clusters:  Re: Speaking of Clusters:  Re: Speaking of Clusters:  Re: Speaking of Clusters: ) Re: strange problem: satellite won't boot ) Re: strange problem: satellite won't boot ) Re: strange problem: satellite won't boot ) Re: strange problem: satellite won't boot # Re: VT420 scroll down keys sequence # RE: VT420 scroll down keys sequence   F ----------------------------------------------------------------------  % Date: Thu, 03 Aug 2006 23:50:58 +0100 # From: issinoho <issinoho@gmail.com>  Subject: Apache in COLPG state4 Message-ID: <eatuke$juj$1$8300dec7@news.demon.co.uk>   All,  C I've started having trouble with Apache processes going into COLPG  G (collided page wait) state which necessitate a reboot to clear as they   cannot then be stopped.   D Can anyone advise on (a) what might be causing this, and (b) how to & clear the state down without a reboot.  D This is happening on the VAMP server (I can supply specs if needed) I which has been rock-solid until this week. I *did* apply the latest V8.2  7 update ECos the other night, so maybe a big clue there.   . I'm currently AUTOGENing to see if that helps.  # Any & all help appreciated. Thanks.    ------------------------------  % Date: Thu, 03 Aug 2006 20:25:40 -0400 - From: bradhamilton <bradhamilton@comcast.net> " Subject: Re: Apache in COLPG state* Message-ID: <44D29404.1060606@comcast.net>   issinoho wrote:  > All, > E > I've started having trouble with Apache processes going into COLPG  I > (collided page wait) state which necessitate a reboot to clear as they   > cannot then be stopped.  > F > Can anyone advise on (a) what might be causing this, and (b) how to ( > clear the state down without a reboot. > F > This is happening on the VAMP server (I can supply specs if needed) K > which has been rock-solid until this week. I *did* apply the latest V8.2  9 > update ECos the other night, so maybe a big clue there.  > 0 > I'm currently AUTOGENing to see if that helps. > % > Any & all help appreciated. Thanks.  >    Google can help -   I Look for COLPG VMS; the performance management manual is near the top of  , the hit list.  That's a good place to start.   ------------------------------   Date: 3 Aug 2006 14:05:24 -0700 ( From: "Carl Karcher" <wolf351@gmail.com>8 Subject: AWstats for SWS on OpenVMS working - here's howB Message-ID: <1154639124.070105.209660@75g2000cwc.googlegroups.com>  + There was a previous thread on this titled:   & Is there a port of AWStats on OpenVMS?  P <http://groups.google.com/group/comp.os.vms/browse_frm/thread/d7b55bf1c1140c26/>  F The answer now is YES, with only one minor change to AWstats.pl. TheseF instructions have been tested with the following versions of software:  E OpenVMS 7.3-2 (alpha), CSWS 2.1, CSWS_PERL 2.1,  PERL V5.8-6, AWstats  6.5 and 6.6-beta  A 1. Follow the very good installation instructions for AWstats at:   0 <http://awstats.sourceforge.net/docs/index.html>  B You can use gnutar (from HP's GNV) to expand the files. Be sure toE allow read access for apache to the created files (if you plan to run D awstats under apache). One way would be to allow world RE access (if= that fits your security requirements) by setting your default 3 protection before using gnutar (set prot=w:re/def).   G The awstats_configure.pl script won't work on VMS but that's ok because D they tell you the manual steps required. One thing to note is DO NOTD place the perl scripts in a directory tree containing ODS-5 extendedG file names! E.g. Make sure the directory names (for the entire path) do ? not contain any ^ characters. This is a bug in perl that's been  submited to HP.   ? 2. The installation instructions don't explain how to configure F apache/mod_perl to execute perl scripts. Here are two ways to to that:  F a. In mod_perl.conf, add the following lines to the end of the file toE allow any file ending in .pl to be handled by modperl's perlrun (this ) may not meet your security requirements).    # C # Let any file with a .pl extension execute under ModPerl::PerlRun. E # PerlRun is one of the several modperl 'handlers' to compile and run 6 # perl scripts in a non-shared environment on the fly. #  <files *.pl>         sethandler perl-script$         PerlHandler ModPerl::PerlRun         PerlSendHeader On          Options ExecCGI  </files>   OR  A b. Add the following to mod_perl.conf (or in httpd.conf where you D define the awstats scriptalias) to allow perl scripts to be run from! the directory aliased to awstats:    <Location /awstats>      SetHandler perl-script      PerlHandler ModPerl::PerlRun     Allow from your.domain.only      Options ExecCGI      PerlSendHeader On  </Location>   D Before you go on, you should test that you can run perl scripts from6 the awstats alias by copying a sample script (say from5 apache$common:[perl]perl_rules.pl) to that directory.   F 3. Now you need to apply a minor modification (4 lines) to awstats.pl.C Following is a comment I've put in awstats.pl explaining the change F required (watch for line wrap - all the lines begin with the # comment character):   F # When running under mod_perl, override exit function with return withG # a return statement (it's not a function) adding the following 2 lines ) # immediately after this comment section:  # - #  use constant IS_MODPERL => $ENV{MOD_PERL}; G # *CORE::GLOBAL::exit = IS_MODPERL ? sub {goto Return_NOT_exit} : sub { 
 CORE::exit };  # > #  AND add the following two lines to the bottom of this file: #  #     Return_NOT_exit:
 #     return;  # F # Then an exit will jump to the label Return_NOT_exit and do a return. Ugly# # but I don't know of a better way.  # D # Exit kills the child process running mod_perl. The exit routine is8 # supposed to be overridden by mod_perl. Submitted to hp@ # as case 3215622699. To be fixed in an ECO to MOD_PERL targeted # august 2006.  D That's the only code change required. I've not submitted it as a bugG since it's only necessary as a work around to bug in HP's mod_perl that  should be fixed soon.   3 4. Almost ready to run it. Before running you must:   !  $ define DECC$EFS_CHARSET ENABLE   B Otherwise when files of the form *.tmp.nnnnnn (where nnnnnn is theB decimal process ID) are created you will receive "error in versionD number" since RMS thinks the version number is > 32K. Note that thisF logical is already defined for the VMS apache environment (though it'sC not required for awstats to run as a cgi) and is only required when ) doing an -update (reading the log files).   C If you are planning to specify awstats read the active log file you  also will need to:  "  $ define DECC$FILE_SHARING ENABLE  < 5. Now, you can try to run it. Set your default directory to ..wwwroot.cgi-bin and:  -  $ perl awstats.pl -update -config=yourconfig   F You will of course need READ access to the log file you are analyzing.G The result are files of the form awstats*^.yourconfig.txt. Keep in mind @ you must use -update on log files from the oldest to the newest.  ? There have been some performance improvements since the version D mentioned in Alan Winston's book - it now takes under two minutes toC process a 40 MB log file on an ES47/1000. If you have a cluster, be " sure to check out logresolvemerge.  B 6. While you can produce a static report (.html file) as mentioned= under "III. Run reports: Building and reading reports" in the B installation guide you can also create them dynamically (the whole2 point of this excersise) by specifying a url like:  6  http://your.site/awstats/awstats.pl?config=yourconfig  F which should work fine (after a little pause) if you've done everyting
 correctly.  E In doing this I found two bugs in awstats that have been submitted to D the bug list. Both of them have to do with OS detection an result in5 VMS not being correctly detected. See the bug report:   S https://sourceforge.net/tracker/?func=detail&atid=113764&aid=1532637&group_id=13764    --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison ; --                      karcher+n0morespam@waisman.wisc.edu    ------------------------------   Date: 3 Aug 2006 20:27:04 -0700  From: contracer11@gmail.com ! Subject: Enabling SMTP in VAX/VMS B Message-ID: <1154662024.065567.132790@75g2000cwc.googlegroups.com>   Hi VMS experts:   ? I'm looking for a way to enable SMTP protocol in my Vax system. > I need enable this protocol to send e-mail only (not receive). Can you help me ? 0 Looking in sys$manager: area I found this files: ucx$smtp_startup.com ucx$smtp_shutdown.com   
 Thanks again.    ------------------------------  * Date: Thu, 3 Aug 2006 23:26:42 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda)% Subject: Re: Enabling SMTP in VAX/VMS 2 Message-ID: <06080323264207_20200291@antinode.org>   From: contracer11@gmail.com   A > I'm looking for a way to enable SMTP protocol in my Vax system. 9                                                       VAX @ > I need enable this protocol to send e-mail only (not receive). > Can you help me ? 2 > Looking in sys$manager: area I found this files: > ucx$smtp_startup.com > ucx$smtp_shutdown.com   E    As usual, it might help to know things like the VMS version and/or  the UCX version.  E    Try "SYS$MANAGER:UCX$CONFIG.COM".  Look for "Client components" or  something similar.  :    There may not be an easy way to make it unidirectional.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Fri, 04 Aug 2006 00:39:44 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: Enabling SMTP in VAX/VMS + Message-ID: <44D2CF81.934DEB8@teksavvy.com>    contracer11@gmail.com wrote:A > I'm looking for a way to enable SMTP protocol in my Vax system. @ > I need enable this protocol to send e-mail only (not receive). > Can you help me ? 2 > Looking in sys$manager: area I found this files: > ucx$smtp_startup.com > ucx$smtp_shutdown.com   6 Looks like you have an old version of the TCPIP stack.  B In newer versions, there is @SYS$MANAGER:TCPIP$CONFIG  so I assumeG @SYS$MANABER:UCX$CONFIG might exist and in there, you can configure and  enable the SMTP service.  C Enabling send only will be tricky and you may have to then manually D disable the receiving end without disturbing the queues and logicalsE that enable you to use mail to send messages to that queue to be sent E off to the internet. Might be easier to just redefine the services to  listen to a different port.   F (this would be the UCX utility, with SHOW SERVICE SMTP and SET SERVICE SMTP )   ------------------------------   Date: 3 Aug 2006 15:16:26 -0700 - From: "Beach Runner" <Bob4Health@hotmail.com> + Subject: Re: FW: Linux on military aircraft B Message-ID: <1154643385.954253.69550@i42g2000cwa.googlegroups.com>   Doug Phillips wrote: > O'Brien Paddy wrote:] > > Sorry for top posting, but I have to go through Outhouse which makes life very difficult.  > >  > > IIRC, the bugs that arose on VMS were when such UNIXy things as TCPIP (think VHS versus Beta and TCPIP versus DECnet) were incorporated.  Also bugs in MAIL and BACKUP were created when porting from VAX to ALPHA by re-writing in C. > >  > > Thanks Mr. Ritchie for "inventing" the abysmal C language and thanks Mr. Gates for "inventing" the worst OS ever.  Betwixt the two any user is so insecure.  > >  > > -----Original Message-----6 > > From: Karsten Nyblad [mailto:nospam@nospam.nospam]* > > Sent: Wednesday, 2 August 2006 1:41 PM > > To: Info-VAX@Mvb.Saic.Com + > > Subject: Re: Linux on military aircraft  > >  > > [Big snips]  > > : > > Doug Phillips wrote: ...<snip stuff doug didn't write> > F > Doug didn't write any of that. He wrote some stuff, but not what youG > quoted. (Doug'll stop talking about himself in the third person now.)  > = > Why bother with Outleak when you can use Google Groups and:  > - >  - keep all the garbage off of your system. A >  - have access to all postings from any i-net capable computer.  >  - not need to use Outleak. % >  - not need to use Outleak Express. 8 >  - did I mention, not need to use a Microsoft product? > I > The setting "View Titles Only" on the message list screen, and "view as F > tree" on the selected message view screen, are pretty good. Also, byI > posting though GG you're less likely to break out of the thread, as you  > did here.  > G > The down-side, or up-side, is that you must provide an E-mail address H > to sign-up to post, but throw-aways such as through yahoo and netscapeG > work just fine --- and keep the clutter out of your actual e-mail box F > --- and you don't end up sending "out-of-office" replies to everyoneB > who posts. Another neat thing about having a different thow-awayB > address for each group is you can see how must spam is generated > because of that one group. > F > If you must use Outleak (I can't imagine why!) , you can adjust yourF > settings to post in Text mode only --- you have your settings set to > "both" (html & text).  >   > Re Your points about VMS bugs: > H > My recollection is that few VMS bugs have been security related --- asI > gleaned from the files being patched and the description of the problem G > (don't mention CERT or we'll have Andrew and bob here:-). VMS layered G > product bugs mostly haven't caused security breaches but just loss of  > the LP service.  >  >  - Me   9 VMS is my favorite operating system.  It provides a human ; interface into it's internals.  It is roboust, reliable and 6 clustering, from  the 80s blows away anything everyone	 else has.   9 No other system stays up for years at a time, or clusters D that maintain even Decades of uptime, all while upgrading operatings< systems, hardware, even converting from VAX to Alpha and now$ Itanium.  No one else is even close.  ; However, it continues in this day and age to send usernames 3 and passwords in plain text.  That should have been  phased out of VMS years ago.    6 The only reason it isn't the top platform out there is marketting.    ------------------------------  % Date: Thu, 03 Aug 2006 18:41:52 -0700 # From: "Tom Linden" <tom@kednos.com> W Subject: Re: high level byte code/IL (Was: querying Web Services from the command line) ) Message-ID: <op.tdqkb2h3zgicya@hyrrokkin>   H On Thu, 03 Aug 2006 18:29:57 -0700, Arne Vajhj <arne@vajhoej.dk> wrote:   > Tom Linden wrote: K >> On Thu, 03 Aug 2006 14:46:51 -0700, Arne Vajhj <arne@vajhoej.dk> wrote: 7 >>> But an interesting thought having a high level byte 8 >>> code and let the JIT compilers use standard compiler >>> techniques.  > : >>> Do you know if any VM's have ever been developed using >>> that kind of approach ?  > C >> Not in the complete sense to which you refer, but Ryan-McFarland - >> Cobol could be considered such an example.  >  > Sounds interesting.  >   > Can you give us some details ?  D It has been too many years since I looked at it, but as I recall, onE each machine which they run the install their "virtual Machine" which G executes (I think it was quads) compiled from any environment.  We have J always done the same with PL/I using n-tuples with a separate symbol spaceC which has always been adequate to represent most common programming J languages.  The n-tuples were therefore reasonably abstract and overloadedH and you could indeed write code in that representation, provided you had3 either code generator or interpreter to process it.  >  > Arne > 6 > PS: subject changed to reflect that we have left the >      original topic.   ------------------------------  % Date: Thu, 03 Aug 2006 21:29:57 -0400 7 From: =?ISO-8859-15?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> Y Subject: high level byte code/IL (Was: querying Web Services from the command line) line) - Message-ID: <oqxAg.72900$fG3.3709@dukeread09>    Tom Linden wrote: J > On Thu, 03 Aug 2006 14:46:51 -0700, Arne Vajhj <arne@vajhoej.dk> wrote:6 >> But an interesting thought having a high level byte7 >> code and let the JIT compilers use standard compiler  >> techniques.  9 >> Do you know if any VM's have ever been developed using  >> that kind of approach ?  B > Not in the complete sense to which you refer, but Ryan-McFarland, > Cobol could be considered such an example.   Sounds interesting.    Can you give us some details ?   Arne  4 PS: subject changed to reflect that we have left the      original topic.   ------------------------------  % Date: Thu, 03 Aug 2006 19:31:36 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> # Subject: Re: InfoServer 100 success + Message-ID: <4jf8h8F7qk8hU1@individual.net>   * On 2006-08-01 18:37, "Hoff Hoffman" wrote:  D >    In roughly two weeks' time (as the various wheels churn slowly G > forward), you'll be able to download many of the InfoServer giblets,  I > including keys and disk images and all, from the Freeware site and via   > the Freeware disks.  > B >    I've packaged up the InfoServer 3.5 image, and keys for most  > everything, on Freeware V8.0.   D Although I don't have an InfoServer 1000/100/150 (and probably neverH will) I appreciate making the software publicly available. After all the9 last hardware box was manufactured about a decade ago ...    Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  # Date: Thu, 03 Aug 2006 20:52:05 GMT   From: John Santos <john@egh.com>E Subject: Re: Is there a Unix /tmp directory. How dissimilar are they. ) Message-ID: <VltAg.9491$jt.3256@trnddc04>    Bill Gunshannon wrote:. > In article <44CF86BA.FC55A952@teksavvy.com>,2 > 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >  >>Another aspect:  >>H >>On VMS, there is the capacity of having "temporary" files. However, itJ >>is not well known. You can specify, when you open a file,  that the file >>is to be deleted on closing. >  >  > Sigh.....  > 4 > This is hardly unique to VMS.  Unix has tmpfile(),  F I don't think JF was saying this was unique to VMS, just that it isn'tE well known (at least on VMS.)  RSTS/E has the same facility.  I don't . know but I would bet that TOPS-10 did as well.    G >      "The tmpfile() function returns a pointer to a stream associated G >       with a file descriptor returned by the routine mkstemp(3).  The F >       created file is unlinked before tmpfile() returns, causing theF >       file to be automatically deleted when the last reference to it >       is closed. " >   H Now we're guessing if the OP had this in mind or not...  Since he hasn'tC replied in the 3+ days since his original post, we most likely will  never know.     F > It is part of the ISO/IEC 9899:1990 (``ISO C89'') standard.  And, it; > was even included in the Fortan77 Language Specification.   D RSTS/E (and VMS and most likely RSX) had this long before 1990, even0 long before 1977, but Unix probably did as well.   >  > bill >      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 03 Aug 2006 13:50:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D23742.42C7318A@teksavvy.com>   Bill Gunshannon wrote:F > what summer is for).  I will do all of this without any downtime forE > my users (beyond the time it takes for a simple re-boot, which will * > not even be noticed!)  Easy?  Elegant?    ? There are many businesses where even the reboot downtime is not > acceptable.  (or must be done at 03:00am on a sunday morning).  H Now if you had been given a responsability of 0 downtime, then you wouldG see that VMS does provide for much easier procedures to reach the goals  compared to Unix or windows.    G And lets not mention Google here: I don't think that they ever promised B 100% availability of their database. While you may always see someF results, there is no garantee that you are seeing ALL results possibleH for one search. It appears to be working all the time, but it may not be FULLY working all the time.   ? And there are many business applications where this is just not F acceptable. A banker doesn't accept to be shown only a portion of yourH monthly transactions, he needs to see them all, everytime, all the time.   ------------------------------  % Date: Thu, 03 Aug 2006 14:03:11 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D23A55.842DEE12@teksavvy.com>   "Main, Kerry" wrote:I > Scenario #1 - you need to release all your code to the Internet so that G > everyone can see what your code looks like with the idea that the few A > senior resources out there that really understand cluster, SMP, A > threading security can review it to see if there are any holes.   C Finding weaknesses isn't the issue here. The real issue is having a I vendor who actively provides resolution of problems in a timely manner.     H Let me ask you this: over the last couple of years, how much has the VMSF engineering headcount been reduced ? (include the TCPIP services groupG in that since that is functionally part of the kernel as a core feature  needed for a modern OS).  G When you reduce headcount, you cannot expect to maintain the same level . of responsiveness to problems when they arise.  I What happens when there is only Hoff, Fred and Guy left to maintain VMS ?   C In an open source environment, a core set of developpers could then E accept/coordinate input from the community and still provide state of B the art OS with timely fixes for problems.  But in a closed sourceH model, those remaining 3 would not be able to cope with the workload andE all we'd hear is silence on many issues because none of them would be 7 prioritised for those 3 extremely overworked resources.       J > Scenario #2 - like the big bank concept, Customers trust their preferredD > vendors to address and maintain high security with their products.  G Yep. And customers want to head from their vendor when they hear a CERT F advisory against BIND 8 and they know they are running BIND 8 on theirH VMS hosts, yet, years later, still not a word on whether a vulnerability affect the VMS version or not.  H Secondly, and I have news for you, Banks now buy shrinkwrapped software,D run way too much stuff on Windows, Linux etc. Quality control is wayC down. Just look at the quality of HTML on their customer facing web D sites and the number of errors on them. Inspires a lot fo confidence' about their backroom code, doesn't it ?   D Consider the Royal Bank of Canada a few years ago who had a "glitch"G that lost money in customer accounts. Bank standards have gone way down E in the last decade as banks adoppted a "we must adopt the newest .com , technology before our competitor" policies.   E Banks had 0 experience in modern technology, having been sheltered by H IBM into the MVS/SNA world for so many decades. When they awoke to .COM,H they panicked and hired anyone and everyone who claimed to be proficientF in unix and TCPIP and stuff such as ethernet which had not had a place> in banks in the past. And their quality controls for those newE technology was only as good as thoer newbie people they hired who had F great CVs but no experience.  (or recycled MVS experts who had no clue! on what TCPIP/ethernet/HTML was).    ------------------------------  % Date: Thu, 03 Aug 2006 20:48:35 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> ' Subject: Re: Linux on military aircraft = Message-ID: <44d244ec$0$60784$157c6196@dreader1.cybercity.dk>    JF Mezei wrote:  > Bill Gunshannon wrote:G >> what summer is for).  I will do all of this without any downtime for F >> my users (beyond the time it takes for a simple re-boot, which will+ >> not even be noticed!)  Easy?  Elegant?    > A > There are many businesses where even the reboot downtime is not @ > acceptable.  (or must be done at 03:00am on a sunday morning).  E There are many companies who would like their systems not to be down  G ever, but most of them will only pay so much for that advantage.  Bill  G is absolutely right.  When the managers realize that they will have to  H have two computer rooms and a high speed connection between them, it is 4 suddenly other requirements that are more important.  A > And there are many business applications where this is just not H > acceptable. A banker doesn't accept to be shown only a portion of yourJ > monthly transactions, he needs to see them all, everytime, all the time.  E Many banks use z/OS.  When it crashes, it takes hours to rebuild the  H disks, and for some reason they do not seem to be capable of postponing C the rebuilds to the following night.  Besides, I doubt a bank will  F consider it a problem if the machine is reboot in the late night on a  weekday.   ------------------------------  $ Date: Thu, 3 Aug 2006 15:21:50 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: Linux on military aircraft T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840182BF81@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20  > Sent: August 3, 2006 2:03 PM > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: Linux on military aircraft  >=20 > "Main, Kerry" wrote:= > > Scenario #1 - you need to release all your code to the=20  > Internet so that? > > everyone can see what your code looks like with the idea=20  > that the fewC > > senior resources out there that really understand cluster, SMP, C > > threading security can review it to see if there are any holes.  >=20E > Finding weaknesses isn't the issue here. The real issue is having a = > vendor who actively provides resolution of problems in a=20  > timely manner. =20 >=20A > Let me ask you this: over the last couple of years, how much=20 
 > has the VMS H > engineering headcount been reduced ? (include the TCPIP services group? > in that since that is functionally part of the kernel as a=20  > core feature > needed for a modern OS). >=20A > When you reduce headcount, you cannot expect to maintain the=20  > same level0 > of responsiveness to problems when they arise. >=20? > What happens when there is only Hoff, Fred and Guy left to=20  > maintain VMS ? >=20E > In an open source environment, a core set of developpers could then G > accept/coordinate input from the community and still provide state of D > the art OS with timely fixes for problems.  But in a closed source@ > model, those remaining 3 would not be able to cope with the=20 > workload andG > all we'd hear is silence on many issues because none of them would be 9 > prioritised for those 3 extremely overworked resources.  >=20  G Like I said - approaches to security can be a religious discussion that / is on par with what is the best OS platform.=20   G Lets agree to disagree - neither of us will convince the other that the  other way is better.   >=20 >=20? > > Scenario #2 - like the big bank concept, Customers trust=20  > their preferred F > > vendors to address and maintain high security with their products. >=20@ > Yep. And customers want to head from their vendor when they=20
 > hear a CERT H > advisory against BIND 8 and they know they are running BIND 8 on their? > VMS hosts, yet, years later, still not a word on whether a=20  > vulnerability   > affect the VMS version or not. >=20  E That was you alone as far as I know. Have any Customers ever formally B asked Engineering for this info via formal channels (and c.o.v. is$ definitely not a formal channel)?=20  ? The OpenVMS TCPIP Engineering group reviews security issues and + addresses them ASAP if they impact OpenVMS.   5 > Secondly, and I have news for you, Banks now buy=20  > shrinkwrapped software, F > run way too much stuff on Windows, Linux etc. Quality control is wayE > down. Just look at the quality of HTML on their customer facing web F > sites and the number of errors on them. Inspires a lot fo confidence) > about their backroom code, doesn't it ?  >=20  H I agree that IT standards have slipped significantly. I would also argueG that this slippage is now one of the reasons why many so many Customers @ are looking at outsourcing. Their BU's are having way to many ITG problems internally and think (rightfully or wrongly) someone *must* be  able to do it better.=20  H The internal IT groups could correctly state that part of their problemsG stem from the BU's lack of funding for IT, but that argument is usually  lost in the wind somewhere ...    F > Consider the Royal Bank of Canada a few years ago who had a "glitch"> > that lost money in customer accounts. Bank standards have=20 > gone way down G > in the last decade as banks adoppted a "we must adopt the newest .com 0 > technology before our competitor" policies.=20 >=20G > Banks had 0 experience in modern technology, having been sheltered by > > IBM into the MVS/SNA world for so many decades. When they=20 > awoke to .COM,B > they panicked and hired anyone and everyone who claimed to be=20 > proficientH > in unix and TCPIP and stuff such as ethernet which had not had a place@ > in banks in the past. And their quality controls for those newG > technology was only as good as thoer newbie people they hired who had H > great CVs but no experience.  (or recycled MVS experts who had no clue# > on what TCPIP/ethernet/HTML was).  >=20  > Many banks are in a huge panic right now because of regulatoryE compliance issues like SOX and Basel II. One of the benefits of these H regulatory requirements is that it is forcing a return to best practices from an IT perspective.      Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Thu, 03 Aug 2006 21:23:40 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> ' Subject: Re: Linux on military aircraft = Message-ID: <44d24d24$0$67261$157c6196@dreader2.cybercity.dk>    Main, Kerry wrote: >> -----Original Message----- 6 >> From: Andrew [mailto:andrew_harrison@symantec.com]   >> Sent: August 3, 2006 11:44 AM >> To: Info-VAX@Mvb.Saic.Com* >> Subject: Re: Linux on military aircraft >> >> >> Karsten Nyblad wrote: >>G >>> Kerry Main's belief that VMS is more secure simply because Digital, ? >>> Compaq and HP has not issued that many security patches is   >> nothing but a< >>> belief and may be wrong.  First of all, you can buy the  >> sources for VMS, ; >>>   and hackers may also read the machine code of, e.g.,   >> TCP/IP packages@ >>> and other parts, were you can not buy the sources.  Hackers  >> have already C >>> demonstrated that they are willing to read machine code to hack F >>> computers and that they are quite good at it.  They are capable of@ >>> finding out what M$ is patching in their security patches.   >> They have? >>> been capable of issuing viruses in just one week.  Thus it  
 >> is a claim F >>> that cannot be proved that VMS is more secure because it is partly >>> closed source. >>> I >> Since we know that there have been vunerabilites in OpenVMS which have I >> not been reported I would suggest that Kerry is on rather soft ground.  > ) > Ahhhh .. Nice to hear from you again ..  >  > :-)  > I > I never stated OpenVMS was 100% secure. In fact, I stated this a number * > of times. No OS platform is 100% secure. > E > What I have been referring to in this thread is the 5-20 *security* H > patches per month that Windows/Linux platforms have been releasing forE > the last few years. The monthly RH *security* patches are on the RH H > site, so that is well documented (23 in July alone - including bundled > kernel patches).   > J > There are two security religious concepts at play here and I am sure notE > going to be able to convince either supporter which is the best for  > their environment. > I > Scenario #1 - you need to release all your code to the Internet so that G > everyone can see what your code looks like with the idea that the few A > senior resources out there that really understand cluster, SMP, G > threading security can review it to see if there are any holes. Never J > mind that some key code that differentiates your product might be pickedI > up by competitors. This assumes those limited high end resources on the J > Internet have the time and interest (remember they are not being paid toH > review other peoples code) to actually do this review. It also assumesG > that these high end reviewers will report issues they discover to the F > vendor. Of course, the really bad folks using sophisticated tools toF > bang away at the soft copy code they picked up off the Internet willA > *not* report the issues they find, but that's seldom discussed.  > J > Scenario #2 - like the big bank concept, Customers trust their preferredI > vendors to address and maintain high security with their products. They G > assume that their preferred vendor keeps current with recent security C > issues in the industry, does code reviews and addresses any short B > comings identified with a high priority and timely fashion. ThisG > scenario depends on the vendor having a reputation of delivering what H > these Customers are looking for when it comes to security. Their trackH > record speaks for itself. The Customer does not have to ask their bankC > whether they are susceptible to the same type of break-in as what G > happened at the local corner store or some other bank last week. They G > assume their vendor will have safe guards or will put them in ASAP to  > prevent this from happening. > I > So, like I stated, pick one and go with it. The only thing I am sure of C > is that like OS religion, it is very unlikely you will be able to H > convince a supporter of security scenario #1 to convert to scenario #20 > or vice versa, so lets just agree to disagree.  I Well I really do not know why you setup these two scenarios.  First, you  H can buy the sources for VMS at a price such that a serious hacker could A buy it.  The once that do not buy the source are those who might  B actually read the code and send in error reports:  The hobbyists. I Secondly, code can be reverse engineered, and hackers will do it if they  H need to.  Banks would never give any information related to security to E anybody who do not need it.  Thus your comparison of VMS to banks is   based on sand.  H Further, for some reason you always assume that errors are very complex I and require complex fixes.  Do you really think that the errors utilized  E in zero day attacks are complex?  My experienced with fixing bugs is  G that the wast majority of bugs have a simple solution.  Unless the bad  H guys manage to employ one of the fired VMS developers, they will have a E hard time build the expertise needed to find the complex bugs.  Thus  B there is a good chance that VMS hobbyist could find the bugs that  hackers might find.    ------------------------------   Date: 3 Aug 2006 19:42:09 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: Linux on military aircraft + Message-ID: <4jf1shF7mvddU1@individual.net>   , In article <44D23742.42C7318A@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:G >> what summer is for).  I will do all of this without any downtime for F >> my users (beyond the time it takes for a simple re-boot, which will+ >> not even be noticed!)  Easy?  Elegant?    > A > There are many businesses where even the reboot downtime is not @ > acceptable.  (or must be done at 03:00am on a sunday morning).  D What's wrong with that?  Surely you don't think I am going to reboot& my servers in the middle of the day?     > J > Now if you had been given a responsability of 0 downtime, then you wouldI > see that VMS does provide for much easier procedures to reach the goals  > compared to Unix or windows.    K Maybe it does, but you keep avoiding my main issue.  How many people really < care.  In case you are inclined to answer, here it is again.I      "However, I also asked of the supposed 411,000 VMS systems, how many G       are clusters as opposed to single, standalone systems?  And, what J       percentage of all the systems in th eindustry do they comprise?  TheI       fact is that others seem to have little if any problem running 24/7 G       even without that feature. It's nice to have, but obviously not a )       show-stopper if you don't have it."    > I > And lets not mention Google here: I don't think that they ever promised D > 100% availability of their database. While you may always see someH > results, there is no garantee that you are seeing ALL results possibleJ > for one search. It appears to be working all the time, but it may not be > FULLY working all the time.   E There are much bigger problems with Google than that, like people pay D to have their sites come up even if they are only trivially related.K So, who would notice if some of the right answers aren't there.  Unreliable M data doesn't always have anything to do with the reliability of the hardware.    > A > And there are many business applications where this is just not H > acceptable. A banker doesn't accept to be shown only a portion of yourJ > monthly transactions, he needs to see them all, everytime, all the time.  E And yet, everyone isn't running VMS and of those that are, not all of & them are running clusters.  Go figure.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  $ Date: Thu, 3 Aug 2006 16:02:44 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: Linux on military aircraft T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840182BFB6@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Karsten Nyblad [mailto:nospam@nospam.nospam]=20  > Sent: August 3, 2006 3:24 PM > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: Linux on military aircraft  >=20 > Main, Kerry wrote: > >> -----Original Message----- : > >> From: Andrew [mailto:andrew_harrison@symantec.com]=20" > >> Sent: August 3, 2006 11:44 AM > >> To: Info-VAX@Mvb.Saic.Com, > >> Subject: Re: Linux on military aircraft > >> > >> > >> Karsten Nyblad wrote: > >>; > >>> Kerry Main's belief that VMS is more secure simply=20  > because Digital,C > >>> Compaq and HP has not issued that many security patches is=20  > >> nothing but a@ > >>> belief and may be wrong.  First of all, you can buy the=20 > >> sources for VMS, ? > >>>   and hackers may also read the machine code of, e.g.,=20  > >> TCP/IP packagesD > >>> and other parts, were you can not buy the sources.  Hackers=20 > >> have already E > >>> demonstrated that they are willing to read machine code to hack H > >>> computers and that they are quite good at it.  They are capable ofD > >>> finding out what M$ is patching in their security patches. =20 > >> They haveC > >>> been capable of issuing viruses in just one week.  Thus it=20  > >> is a claim H > >>> that cannot be proved that VMS is more secure because it is partly > >>> closed source. > >>> ; > >> Since we know that there have been vunerabilites in=20  > OpenVMS which haveA > >> not been reported I would suggest that Kerry is on rather=20  > soft ground. > >=20+ > > Ahhhh .. Nice to hear from you again ..  > >=20 > > :-)  > >=20@ > > I never stated OpenVMS was 100% secure. In fact, I stated=20 > this a number , > > of times. No OS platform is 100% secure. > >=20G > > What I have been referring to in this thread is the 5-20 *security* ? > > patches per month that Windows/Linux platforms have been=20  > releasing for G > > the last few years. The monthly RH *security* patches are on the RH ; > > site, so that is well documented (23 in July alone -=20  > including bundled  > > kernel patches).=20  > >=20A > > There are two security religious concepts at play here and=20  > I am sure not G > > going to be able to convince either supporter which is the best for  > > their environment. > >=20= > > Scenario #1 - you need to release all your code to the=20  > Internet so that? > > everyone can see what your code looks like with the idea=20  > that the fewC > > senior resources out there that really understand cluster, SMP, ? > > threading security can review it to see if there are any=20  > holes. Never? > > mind that some key code that differentiates your product=20  > might be picked = > > up by competitors. This assumes those limited high end=20  > resources on theA > > Internet have the time and interest (remember they are not=20  > being paid to @ > > review other peoples code) to actually do this review. It=20 > also assumes< > > that these high end reviewers will report issues they=20 > discover to the H > > vendor. Of course, the really bad folks using sophisticated tools toH > > bang away at the soft copy code they picked up off the Internet willC > > *not* report the issues they find, but that's seldom discussed.  > >=20? > > Scenario #2 - like the big bank concept, Customers trust=20  > their preferred ? > > vendors to address and maintain high security with their=20  > products. They< > > assume that their preferred vendor keeps current with=20 > recent security E > > issues in the industry, does code reviews and addresses any short D > > comings identified with a high priority and timely fashion. This< > > scenario depends on the vendor having a reputation of=20 > delivering what A > > these Customers are looking for when it comes to security.=20 
 > Their track B > > record speaks for itself. The Customer does not have to ask=20 > their bankE > > whether they are susceptible to the same type of break-in as what A > > happened at the local corner store or some other bank last=20  > week. TheyA > > assume their vendor will have safe guards or will put them=20  > in ASAP to  > > prevent this from happening. > >=20A > > So, like I stated, pick one and go with it. The only thing=20  > I am sure ofE > > is that like OS religion, it is very unlikely you will be able to A > > convince a supporter of security scenario #1 to convert to=20 
 > scenario #2 2 > > or vice versa, so lets just agree to disagree. >=20B > Well I really do not know why you setup these two scenarios. =20 > First, you=20 ? > can buy the sources for VMS at a price such that a serious=20  > hacker could=20 
 > buy it. =20 < > The once that do not buy the source are those who might=20F > actually read the code and send in error reports:  The hobbyists.=20B > Secondly, code can be reverse engineered, and hackers will do=20 > it if they=20  > need to. =20  G So you think that we should reduce the hacker effort required by giving H them all the code in soft copy to reduce the effort they need to put in?  6 > Banks would never give any information related to=20 > security to=20I > anybody who do not need it.  Thus your comparison of VMS to banks is=20  > based on sand. >=20    Security religion. Lets move on.  ? > Further, for some reason you always assume that errors are=20  > very complex=20 = > and require complex fixes.  Do you really think that the=20  > errors utilized=20I > in zero day attacks are complex?  My experienced with fixing bugs is=20 < > that the wast majority of bugs have a simple solution. =20  F Most of the security issues are not simple i.e. usually relate to someG combination of events and configurations. Clusters, large SMP, multiple 7 CPU configs are not the typical hobbyist configuration.    > Unless the bad=20 @ > guys manage to employ one of the fired VMS developers, they=20 > will have a=20I > hard time build the expertise needed to find the complex bugs.  Thus=20 F > there is a good chance that VMS hobbyist could find the bugs that=20 > hackers might find.  >=20    Security religion. Lets move on.   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  # Date: Thu, 03 Aug 2006 20:47:35 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)' Subject: Re: Linux on military aircraft 6 Message-ID: <00A59A8B.D711206B@SSRL.SLAC.STANFORD.EDU>  V In article <4jf1shF7mvddU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:, In article <44D23742.42C7318A@teksavvy.com>,1 >	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: J >> And lets not mention Google here: I don't think that they ever promisedE >> 100% availability of their database. While you may always see some I >> results, there is no garantee that you are seeing ALL results possible K >> for one search. It appears to be working all the time, but it may not be  >> FULLY working all the time. > F >There are much bigger problems with Google than that, like people payE >to have their sites come up even if they are only trivially related. L >So, who would notice if some of the right answers aren't there.  UnreliableN >data doesn't always have anything to do with the reliability of the hardware.  K Um, are you accusing Google of selling ranking in the search results?  They M certainly sell the right to have your little ad appear in the ad column based O on keywords, but as far as I know their search results are uncorrupted - that's  one of their major appeals.    -- Alan    ------------------------------   Date: 3 Aug 2006 22:10:50 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: Linux on military aircraft + Message-ID: <4jfajaF7oicsU1@individual.net>   6 In article <00A59A8B.D711206B@ssrl.slac.stanford.edu>,O 	winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) writes: X > In article <4jf1shF7mvddU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:. > In article <44D23742.42C7318A@teksavvy.com>,2 >>	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:K >>> And lets not mention Google here: I don't think that they ever promised F >>> 100% availability of their database. While you may always see someJ >>> results, there is no garantee that you are seeing ALL results possibleL >>> for one search. It appears to be working all the time, but it may not be >>> FULLY working all the time.  >>G >>There are much bigger problems with Google than that, like people pay F >>to have their sites come up even if they are only trivially related.M >>So, who would notice if some of the right answers aren't there.  Unreliable O >>data doesn't always have anything to do with the reliability of the hardware.  > M > Um, are you accusing Google of selling ranking in the search results?  They O > certainly sell the right to have your little ad appear in the ad column based Q > on keywords, but as far as I know their search results are uncorrupted - that's  > one of their major appeals.  >   A I have long known that they were easy to fool.  I often have done A searches where the results I got had nothing to do with the terms B I was searching for.  And then there are the examples of searchingA for PDP-11 Module numbers and getting the same results everytime. C An on the fly built page from a dozen or so re-sellers who probably ? don't have the part, but return the same page for anything that & looks like a DEC PDP-11 Module Number.  C And if that isn't enough, I recently heard an ad that said to "Just B type Pontiac into Google and see the results".  Well, Pontiac is aB bit more than a car from GM but that's about all your going to getB now.  Maybe Google isn't involved, but being a cynic (and becoming9 more cynical everyday) I really don't trust them anymore.    bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Fri, 04 Aug 2006 00:00:19 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> ' Subject: Re: Linux on military aircraft = Message-ID: <44d271dc$0$60778$157c6196@dreader1.cybercity.dk>    Main, Kerry wrote: >> -----Original Message----- 6 >> From: Karsten Nyblad [mailto:nospam@nospam.nospam]  >> Sent: August 3, 2006 3:24 PM  >> To: Info-VAX@Mvb.Saic.Com* >> Subject: Re: Linux on military aircraft >> >> Main, Kerry wrote:  >>>> -----Original Message----- 8 >>>> From: Andrew [mailto:andrew_harrison@symantec.com] " >>>> Sent: August 3, 2006 11:44 AM >>>> To: Info-VAX@Mvb.Saic.Com, >>>> Subject: Re: Linux on military aircraft >>>> >>>> >>>> Karsten Nyblad wrote: >>>>9 >>>>> Kerry Main's belief that VMS is more secure simply   >> because Digital, A >>>>> Compaq and HP has not issued that many security patches is   >>>> nothing but a> >>>>> belief and may be wrong.  First of all, you can buy the  >>>> sources for VMS, = >>>>>   and hackers may also read the machine code of, e.g.,   >>>> TCP/IP packagesB >>>>> and other parts, were you can not buy the sources.  Hackers  >>>> have already E >>>>> demonstrated that they are willing to read machine code to hack H >>>>> computers and that they are quite good at it.  They are capable ofB >>>>> finding out what M$ is patching in their security patches.   >>>> They haveA >>>>> been capable of issuing viruses in just one week.  Thus it   >>>> is a claim H >>>>> that cannot be proved that VMS is more secure because it is partly >>>>> closed source. >>>>> 9 >>>> Since we know that there have been vunerabilites in   >> OpenVMS which have ? >>>> not been reported I would suggest that Kerry is on rather   >> soft ground. + >>> Ahhhh .. Nice to hear from you again ..  >>>  >>> :-)  >>> > >>> I never stated OpenVMS was 100% secure. In fact, I stated  >> this a number, >>> of times. No OS platform is 100% secure. >>> G >>> What I have been referring to in this thread is the 5-20 *security* = >>> patches per month that Windows/Linux platforms have been   >> releasing forG >>> the last few years. The monthly RH *security* patches are on the RH 9 >>> site, so that is well documented (23 in July alone -   >> including bundled >>> kernel patches).   >>> ? >>> There are two security religious concepts at play here and   >> I am sure notG >>> going to be able to convince either supporter which is the best for  >>> their environment. >>> ; >>> Scenario #1 - you need to release all your code to the   >> Internet so that = >>> everyone can see what your code looks like with the idea   >> that the few C >>> senior resources out there that really understand cluster, SMP, = >>> threading security can review it to see if there are any   >> holes. Never = >>> mind that some key code that differentiates your product   >> might be picked; >>> up by competitors. This assumes those limited high end   >> resources on the ? >>> Internet have the time and interest (remember they are not   >> being paid to> >>> review other peoples code) to actually do this review. It  >> also assumes : >>> that these high end reviewers will report issues they  >> discover to theH >>> vendor. Of course, the really bad folks using sophisticated tools toH >>> bang away at the soft copy code they picked up off the Internet willC >>> *not* report the issues they find, but that's seldom discussed.  >>> = >>> Scenario #2 - like the big bank concept, Customers trust   >> their preferred= >>> vendors to address and maintain high security with their   >> products. They : >>> assume that their preferred vendor keeps current with  >> recent securityE >>> issues in the industry, does code reviews and addresses any short D >>> comings identified with a high priority and timely fashion. This: >>> scenario depends on the vendor having a reputation of  >> delivering what? >>> these Customers are looking for when it comes to security.   >> Their track@ >>> record speaks for itself. The Customer does not have to ask 
 >> their bank E >>> whether they are susceptible to the same type of break-in as what ? >>> happened at the local corner store or some other bank last  
 >> week. They ? >>> assume their vendor will have safe guards or will put them  
 >> in ASAP to   >>> prevent this from happening. >>> ? >>> So, like I stated, pick one and go with it. The only thing   >> I am sure of E >>> is that like OS religion, it is very unlikely you will be able to ? >>> convince a supporter of security scenario #1 to convert to   >> scenario #22 >>> or vice versa, so lets just agree to disagree.A >> Well I really do not know why you setup these two scenarios.    >> First, you > >> can buy the sources for VMS at a price such that a serious  >> hacker could  >> buy it.  ; >> The once that do not buy the source are those who might  E >> actually read the code and send in error reports:  The hobbyists.  A >> Secondly, code can be reverse engineered, and hackers will do   >> it if they 
 >> need to.    > I > So you think that we should reduce the hacker effort required by giving J > them all the code in soft copy to reduce the effort they need to put in?  F I do not understand how you can get that idea from what I wrote.  Say F somebody want to hack a bank.  Do you think it will be any problem to E pay $3000 for the source listing?  Well it will if the purpose is to  A have some fun defacing the bank's website, but if the purpose is  I emptying bank accounts, then $3000 would not stop the criminals.  So the  L sources are already available to those hackers that are in it for the money.  F When I read your answer, I get the impressions that you try making my F opinions fit into your prejudices about what I think.  I do not think H open source by nature is more secure than closed source.  I do not know I which model is best when it comes to security.  What I am saying is that  C VMS _is_ partly open source.  Further, even if you do not have the  D source, you still have the options of disassembling the code.  Thus * comparing VMS to banks just does not work.   ------------------------------  % Date: Thu, 03 Aug 2006 21:29:48 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D2A30A.84EF2669@teksavvy.com>   Bill Gunshannon wrote:E > And if that isn't enough, I recently heard an ad that said to "Just D > type Pontiac into Google and see the results".  Well, Pontiac is aD > bit more than a car from GM but that's about all your going to get > now.    E There is a big marketing agreement between Pontiac/GM and Google. And G yes, Google "cheats" and puts the "paid for" Pomtiac content at the top 0 of the list. It isn't just the ads on the right.   ------------------------------  $ Date: Thu, 3 Aug 2006 21:54:08 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: Linux on military aircraft T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840182C07B@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Karsten Nyblad [mailto:nospam@nospam.nospam]=20  > Sent: August 3, 2006 6:00 PM > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: Linux on military aircraft  >=20
 [snip ...]  ? > >> The once that do not buy the source are those who might=20 I > >> actually read the code and send in error reports:  The hobbyists.=20 E > >> Secondly, code can be reverse engineered, and hackers will do=20  > >> it if they=20 > >> need to. =20  > >=20; > > So you think that we should reduce the hacker effort=20  > required by giving? > > them all the code in soft copy to reduce the effort they=20  > need to put in?  >=20J > I do not understand how you can get that idea from what I wrote.  Say=20J > somebody want to hack a bank.  Do you think it will be any problem to=20I > pay $3000 for the source listing?  Well it will if the purpose is to=20 E > have some fun defacing the bank's website, but if the purpose is=20 : > emptying bank accounts, then $3000 would not stop the=20 > criminals.  So the=20 B > sources are already available to those hackers that are in it=20 > for the money. >=20  H Not all the sources are available. Hoff and others have explained in the+ past which modules are not and the reasons.   H You are correct that the source listings of many modules can be obtainedF but they are far from being able to automatically build, link etc VMS.  F But you are correct that the initial price is enough to scare away the script kiddies.   G Imho - I actually think what OpenVMS does with its code might rather be B called "smart source" i.e. let legitimate Customers have access toF certain modules so that they can better develop interfaces, drivers orA other custom code, but still maintain strict control of the code.   J > When I read your answer, I get the impressions that you try making my=20J > opinions fit into your prejudices about what I think.  I do not think=20@ > open source by nature is more secure than closed source.  I=20 > do not know=20> > which model is best when it comes to security.  What I am=20 > saying is that=20 G > VMS _is_ partly open source.  Further, even if you do not have the=20 H > source, you still have the options of disassembling the code.  Thus=20, > comparing VMS to banks just does not work. >=20  H My primary point about the banks and OpenVMS is that in both cases, whenF it comes to security, their Customers have a high level of respect andE trust their proven track records. Even though neither is 100% secure, ? they remain confident that should something come up, their bank H [OpenVMS] will place this as a very high priority and get it fixed ASAP.  E Not all OS vendor platforms have this proven track record or level of @ trust. It has to be earned over time and if you ask most OpenVMSE Customers (even some competitors for that matter), I believe you will  find they agree with this.   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  # Date: Fri, 04 Aug 2006 02:19:09 GMT   From: John Santos <john@egh.com>' Subject: Re: Linux on military aircraft * Message-ID: <x8yAg.10245$j9.6885@trnddc02>   Karsten Nyblad wrote:  > Doug Phillips wrote: >  >> Main, Kerry wrote:  >> >>>> -----Original Message----- 7 >>>> From: Karsten Nyblad [mailto:nospam@nospam.nospam] ! >>>> Sent: August 1, 2006 1:56 PM  >>>> To: Info-VAX@Mvb.Saic.Com, >>>> Subject: Re: Linux on military aircraft >>>> >>>> Main, Kerry wrote:  >>>>@ >>>>>> I think there would be a lot more OpenVMS security issues >>>> >>>> if it was in  >>>>> >>>>>> wider distribution with a platform that was more easily >>>>>> accessible to the >>>>>> hacker community. >>>>>>J >>>>> Ohhh yeah, hear we go .. If only .. That old wives statement is likeH >>>>> saying the big banks have poor security because most people do notJ >>>>> understand the security they use, so there must be problems with it.A >>>>> Now, if the banks only would publish each of their security  >>>> >>>> plans on the  >>>>: >>>>> Internet, now then - they would have real security ! >>>>> I >>>>> ROTFL ..Lets re-phrase what you just stated and see how it sounds:: @ >>>>> "I think there would be a lot more Bank (OpenVMS) security >>>> >>>> issues if it  >>>>D >>>>> was in wider distribution with a platform that was more easily8 >>>>> accessible to the bank robber (hacker) community." >>>>>  >>>>> Does this sound right? >>>>> < >>>>> Lets face it, most people believe banks have very high >>>> >>>> security (albeit  >>>>I >>>>> not 100%), and trust that those running the bank take security very 8 >>>>> seriously. They trust those running the bank to be >>>> >>>> aggressive in keeping >>>> >>>>> their security very high.  >>>>A >>>> First of all.  Comparing security in the physical world with  >>>> security on? >>>> computer systems is not without problems.  In the physical  >>>> world thereA >>>> will always be a way around all the security surrounding the  >>>> strongroom. >>> ; >>> Which is why my comments included "(albeit, not 100%)".  >>> A >>>>   However, OSes are mathematical objects, and you can reason  >>>> about what ? >>>> would happen if somebody tries to hack it.  If VMS, Linux,  >>>> Unix, z/OS,= >>>> etc. were good enough there would be such ways to bypass  >>>> security.  We@ >>>> could compare OSes to encryption in stead.  In the world of >>>> encryption ; >>>> it is the experience that algorithms should be public,  >>>> because the holes1 >>>> are only found when many people are looking.  >>>>J >>> In some areas - yes, In others - no. It depends. If it were always theL >>> case, then banks would publish their plans on the Internet with the viewG >>> that when people found potential holes, they would notify the bank.  >>> K >>> Course, the other view is that the bad guys would also review the plans L >>> and *not* tell the bank - rather they would tell other bad people and/or' >>> simply act on the holes they found.  >>> F >>>> Secondly, the military world is not like the civil world.  If KimJ >>>> Jong-Il, China or Iran have people trying to hack OSes, then they are( >>>> not going to send in error reports. >>> H >>> Exactly my point above. Should the various vendors provide complete,J >>> detailed plans for the bad folks of the universe to review and dissectJ >>> with sophisticated tools using the full soft copy of sources they haveE >>> access to knowing full well that these types have no intention of # >>> reporting any issues they find?  >>>  >>>> Rather, they will try to  >>>> use theirB >>>> knowledge at a time where they can do maximum damage to their
 >>>> enemies. = >>>> Thus militaries have to build their protection under the  >>>> assumption that% >>>> the OSes they use can be hacked.  >>>> >>@ >> These ASW tactical & navigation systems use *imbedded* and/orF >> *restricted* Linux. Little or none of the OS is exposed to anythingH >> other than the very special purpose application(s) it is running. WhyJ >> would anyone think that military software is as exposed and volatile asE >> commercial stuff? Once the "device" is doing it's job and the OS & I >> application are working as expected, there's no need to screw with the ? >> OS. It's the application and/or device that does the work...  >>G >> If you want to worry about such things, consider that the B-2 bomber : >> crew receives target coordinates via Microsoft Outlook. >>I > Which also means that the US military does not base its IT security on  G > the applications being secure.  And that my whole point.  Militaries  J > will not let their security base on OSes and applications being secure, K > and they are not going to base their security on VMS being secure.  They  I > will rather have their own physically separated network for waging war.  > F > Kerry Main's belief that VMS is more secure simply because Digital, K >  Compaq and HP has not issued that many security patches is nothing but a  > belief and may be wrong.  B That is *NOT my belief and I am pretty certain it is *NOT* Kerry's, belief.  You are confusing cause and effect.  E I believe that VMS is more secure because it has security designed in C (which covers a lot of ground that I won't repeat for the umpteenth F time), and because it avoids techniques (e.g. null-terminated strings)1 that are known to be prone to exploitable errors.   E One predicted effect of this is there will be fewer security patches. F If this effect didn't obtain, then one could argue that the techniquesE used by VMS are ineffective, or were applied incompetently, etc., and E VMS really is less secure or no more secure than other OSes.  But the E effect does obtain, there *are* fewer VMS security patches, so if you F want to argue that VMS is less secure, the onus is on you to cite someB real security problems, and not just hand wave, and claim (in trueE Gin Rummy fashion) that just because you can't find them doesn't mean  they aren't there.    . First of all, you can buy the sources for VMS,H >  and hackers may also read the machine code of, e.g., TCP/IP packages K > and other parts, were you can not buy the sources.  Hackers have already  B > demonstrated that they are willing to read machine code to hack E > computers and that they are quite good at it.  They are capable of  H > finding out what M$ is patching in their security patches.  They have H > been capable of issuing viruses in just one week.  Thus it is a claim E > that cannot be proved that VMS is more secure because it is partly   > closed source. >  > I > The bad guys will start attacking VMS the moment they consider it more  H > profitable to attack VMS than M$ and Linux and be sure they will find  > critical security errors.   F I don't understand this sentence.  Are you saying "one of the criteriaE the bad guys will use to decide whether they will start attacking VMS H is if they are sure they will find security problems", or are you sayingD "If and when bad guys decide to attack VMS, we (the audience to thisD thread), should understand that they will definitely find problems"?E In other words, is the implied subject of the clause that starts with 7 "and be sure" the bad guys or us (comp.os.vms readers)?   ,    Also, on Linux and Windows there are manyI > good guys that hunt security bugs.  In the short term these guys are a  J > pain because they discover bugs that must be fixed and the patches must G > installed by the users.  In the long term it might lead to these two  J > platforms becoming more secure than platform without white hat security  > bug hunters.  G For Linux, they probably are making progress...  For Windows, it's like $ emptying the sea with a bucket.  :-)     --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 03 Aug 2006 22:42:31 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D2B40F.BE28B9DC@teksavvy.com>   "Main, Kerry" wrote:H > But you are correct that the initial price is enough to scare away the > script kiddies.     # Nicole Kidman in "The Peacemakers":   G "I'm not affraid of the person who wants a dozen nuclear missiles, I am & scared of the one who wants just one".  F If a "script kiddie" is really serious, he will get the source listingD and do serious harm to your installation. Some script kiddies may beD very well funded by organisations that thrive from harming competing corporations for instance.  G So doN't be affraid of the script kiddies that are just playing around. F Be afraid of the well funded single script kiddie with serious intents to cause harm.   ------------------------------  # Date: Fri, 04 Aug 2006 02:37:12 GMT   From: John Santos <john@egh.com>' Subject: Re: Linux on military aircraft * Message-ID: <spyAg.10292$j9.6395@trnddc02>   Dave Froble wrote: > Doug Phillips wrote: >  >> Dave Froble wrote:  >> >>> Karsten Nyblad wrote:  >>>  >>>> Bill Gunshannon wrote:  >>>>G >>>>> And somehow, I doubt this is true either.  Why would someon Email $ >>>>> target coordinates to the B-2? >>>>J >>>> During the attack on Iraq, half of the bombers took of before gettingK >>>> their targets.  In Afghanistan commanding officers can call in and ask K >>>> for air support, and the enemies will be attacked by planes already in L >>>> the air.  I do not know how the planes are getting the coordinates, butI >>>> it would not surprise me if they get them by some messaging tool so  	 >>>> that H >>>> they have them in writing.  I am a bit skeptical that they would beL >>>> using ordinary E-mail considering that the people on the ground need to2 >>>> be sure that the pilots the information fast. >>> H >>> I don't know, but I'm also finding the e-mail claim hard to believe.E >>> I'd think that such data would be desired to be fed directly into I >>> on-board systems.  Why would anyone want a human entering data that's J >>> already in electronic form?  A real chance of errors being introduced. >>> 5 >>> Yeah, it's got to be entered once, but not twice.  >>>  >>D >> Well, sure I just made it up. God forbid anyone should google it.I >> Here's a first-hand account published in the Christian Science Monitor ! >> (presuming they're not lying):  >  > K > It's to be hoped that there's not too much on this forum that's made up.  D >  I'd not intended that.  It's possible that someone could pass on J > something on which they were misinformed.  I'm sure it's happened to me. > 8 >> <http://www.csmonitor.com/2003/0512/p25s01-usmi.html> >> >> Here's an article on COTS:  >>0 >> <http://www.armada.ch/02-5/complete_02-5.pdf> >>H >> For secure communications, it's not the application that matters, itsI >> the way the data is communicated; the level of encryption; the privacy H >> of the channel. Military software is not exposed to the public in anyG >> way what-so-ever. While physical access to *anything* can compromise E >> security, planting a trojan, worm or virus in one of these systems D >> would be as likely as walking out of Fort Knox with a bar of gold >> stuffed down your trousers. >> > I > It wasn't the security that bothered me.  I'd think that systems would  I > be designed to decrease operator workload.  Loading data directly into  - > on-board systems would have been my choice.  >   E I could easily believe that someone trying to describe how the system C worked to someone non-technical (management, reporter, their cousin A Vinny) could say something like "then the system passes a message B electronically to the bomber..." and the non-technical person saysG "you mean, like e-mail?", and the answer is "Yeah, exactly like email." ! and thus an urban legend is born.   E On the other hand, they might really be using Outlook, in which case, 	 LOOK OUT!    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 03 Aug 2006 23:02:02 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D2B8A1.3040963D@teksavvy.com>   John Santos wrote:G > I believe that VMS is more secure because it has security designed in   G > One predicted effect of this is there will be fewer security patches.     E OK, let me challenge this: When you look at all the patches for Linux G and Windows, how many affect services that have an equivalent in VMS or F TCPIP Services, and how many affect services/applications that have no equivalent on VMS ?     E If Windows/Linux come with a richer set of services and applications, C then comparing the number of patches with those on VMS is not fair.    ------------------------------  # Date: Fri, 04 Aug 2006 03:20:30 GMT   From: John Santos <john@egh.com>' Subject: Re: Linux on military aircraft + Message-ID: <22zAg.15582$c11.2965@trnddc08>    Bill Gunshannon wrote:. > In article <44D23742.42C7318A@teksavvy.com>,2 > 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >  >>Bill Gunshannon wrote: >>G >>>what summer is for).  I will do all of this without any downtime for F >>>my users (beyond the time it takes for a simple re-boot, which will+ >>>not even be noticed!)  Easy?  Elegant?    >>A >>There are many businesses where even the reboot downtime is not @ >>acceptable.  (or must be done at 03:00am on a sunday morning). >  > F > What's wrong with that?  Surely you don't think I am going to reboot( > my servers in the middle of the day?   >  >   / Sure!  Why not?  Just cluster them.  (SMOM) [*]    [*] Small Matter Of Money      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Thu, 03 Aug 2006 19:35:44 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)0 Message-ID: <kesAg.1524$sX.180@news.cpqcorp.net>  P > I know that moving their fabs from Alpha on VMS to Itanium on VMS would be theO > simplest solution and almost certainly was the plan a few years ago. If it is N > still the plan then it suggests that Intel still has faith in Itanium's longN > term future - if on the otherhand they were less certain of Itanium's futureK > they might be looking for alternatives (and possibly stocking up on spare < > alphas to tide them over until that alternative is ready).  $    Fabs are production environments.  G    Having worked directly in large-scale manufacturing (the full-scale  A locomotive and the freight train that pulled entirely inside the  I building -- and to be entirely dwarfed by it -- and by the 20-some miles  G of railroad track on the site -- was a reality adjustment), and having  @ worked with enough customers with OpenVMS installations in such D environments, production equipment in production environments isn't C swapped out until and unless needed, and downtime and particularly  4 unscheduled downtime is costly and is to be avoided.  G    Seeing comparatively old gear running for as long as the production  H line is itself running is commonplace in my experience, and large-scale ? production environments will typically involve the sourcing of  > sufficient spares for the expected lifetime of the production G installation, and the MTBF and the trending of failure rates and costs.   G    I expect any production environment would be looking at new systems  F when they are building new lines or new facilities, and -- outside of A those efforts -- only at the incremental work as necessitated by  ( operational and production requirements.  G    The production line I was working at was one of the few places I've  H been that easily rivals the scale of the NASA Vehicle Assembly Building E (VAB).  Big.  Really big.  Big input.  Big output.  Really Big Bucks.   Q > (I wonder if Intel have approached HP about porting VMS to x86-64 so that they  ! > could use that in their fabs ?)   I    I'd expect (but don't know) that Intel already uses IA-32, IA-32e and  I other series Intel processors in their processes and in their operations.   B    And as for the intended question, if something is sufficiently F profitable to percolate to the top of the stack, then someone will be C interested in fulfilling the requirement.  But when you're picking  H between funding an operating system port, or funding the purchase of an H existing operating system port and some new Integrity boxes, most folks C will tend to find the Integrity boxes are a rather better and more   economical purchase.   	--   G    And my usual "AFAIK" porting refrain follows: there are no plans to  H port OpenVMS to the Intel IA-32, nor to Intel IA-32e, nor to AMD AMD64, G nor to try to set Mr Peabody's Way-Back machine to the formative years  I of some of the regular posters here -- the late 1970s, apparently -- and  H to try to stuff OpenVMS onto the megabyte of memory found on the 16-bit G segmented Intel 8086 series processor.  HP Itanium is the platform for  D OpenVMS I64 and for OpenVMS in general in the post-Alpha world, and F there are no plans to port OpenVMS to a new or different architecture.I Folks have also certainly seen the recent Intel announcement of its 9000   series Itanium 2 processors.   ------------------------------  $ Date: Fri, 4 Aug 2006 01:10:48 +0200" From: "Dr. Dweeb" <spam@dweeb.net>D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)= Message-ID: <44d2827a$0$67256$157c6196@dreader2.cybercity.dk>    Tom Linden wrote: 2 > On Wed, 02 Aug 2006 16:55:18 -0700, Keith Parris' > <keithparris_NOSPAM@yahoo.com> wrote:  >  >> Neil Rieck wrote:A >>> I wonder if OpenVMS on Alpha is used to manufacture Itaniums?  >>> >> I had the pleasure of working at an Intel site in 2003 on aG >> consulting assignment and they were most definitely using OpenVMS on E >> Alpha to run the fab, having completed a successful migration from  >> VAX to Alpha. > B > Do you recall what the source language of their application was?  H Was it not COBOL/DBMS - Consillium or some similar name was the package  IIRC?   
 Dr. Dweeb    ------------------------------  % Date: Thu, 03 Aug 2006 18:09:19 -0700 # From: "Tom Linden" <tom@kednos.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)) Message-ID: <op.tdqittxazgicya@hyrrokkin>   E On Thu, 03 Aug 2006 16:10:48 -0700, Dr. Dweeb <spam@dweeb.net> wrote:    > Tom Linden wrote: 3 >> On Wed, 02 Aug 2006 16:55:18 -0700, Keith Parris ( >> <keithparris_NOSPAM@yahoo.com> wrote: >> >>> Neil Rieck wrote: B >>>> I wonder if OpenVMS on Alpha is used to manufacture Itaniums? >>> ? >>> I had the pleasure of working at an Intel site in 2003 on a I >>> consulting assignment and they were most definitely using OpenVMS on=   F >>> Alpha to run the fab, having completed a successful migration from >>> VAX to Alpha.  >>C >> Do you recall what the source language of their application was?  > I > Was it not COBOL/DBMS - Consillium or some similar name was the packag=  e  > IIRC?  >  Consillium was PL/I    > Dr. Dweeb  >  >    ------------------------------  % Date: Thu, 03 Aug 2006 21:18:45 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09), Message-ID: <44D2A074.DA8D91E8@teksavvy.com>   Hoff Hoffman wrote: H > there are no plans to port OpenVMS to a new or different architecture.  0 What would it take to get such plans announced ?  G Could you confirm if there has been a preliminaty evaluation on whether > it was feasable to port VMS to the current 8086 architecture ?  H If such feasability has not been done, what would it take to convince HP to allocated budget for this ?   ------------------------------  % Date: Thu, 03 Aug 2006 17:46:51 -0400 7 From: =?ISO-8859-15?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> 8 Subject: Re: querying Web Services from the command line. Message-ID: <f9uAg.72877$fG3.66907@dukeread09>   Tom Linden wrote: J > .NET intermediate language is a disappointingly low level of abstractionH > and otherwise very amateur.  Compiler technology was considerably more > sophisticated 40 years ago.   7 MSIL is supposed to be an assembly language for a stack  based virtual processor.  : Assembly languages are usually at a low abstraction level.   :-)   3 But an interesting thought having a high level byte 4 code and let the JIT compilers use standard compiler techniques.   6 Do you know if any VM's have ever been developed using that kind of approach ?    Arne   ------------------------------  % Date: Thu, 03 Aug 2006 18:15:47 -0700 # From: "Tom Linden" <tom@kednos.com> 8 Subject: Re: querying Web Services from the command line) Message-ID: <op.tdqi4ly0zgicya@hyrrokkin>   H On Thu, 03 Aug 2006 14:46:51 -0700, Arne Vajhj <arne@vajhoej.dk> wrote:   > Tom Linden wrote: K >> .NET intermediate language is a disappointingly low level of abstraction I >> and otherwise very amateur.  Compiler technology was considerably more  >> sophisticated 40 years ago. > 9 > MSIL is supposed to be an assembly language for a stack  > based virtual processor. > < > Assembly languages are usually at a low abstraction level. >  > :-)  > 5 > But an interesting thought having a high level byte 6 > code and let the JIT compilers use standard compiler
 > techniques. @ Not in the complete sense to which you refer, but Ryan-McFarland* Cobol could be considered such an example. > 8 > Do you know if any VM's have ever been developed using > that kind of approach ?  >  > Arne   ------------------------------   Date: 3 Aug 2006 13:45:15 -0700 - From: "Doug Phillips" <dphill46@netscape.net>  Subject: Speaking of Clusters:C Message-ID: <1154637915.320679.239410@i42g2000cwa.googlegroups.com>   G The discussions about *nix vs. OpenVMS touting clustering as one of the B VMS advantages reminds me that one of the reasons HP sited for notD merging Tru-64 clustering into HP-UX was the availability of VeritasD Cluster Server. Maybe I haven't been paying attention, but I haven't heard much about VCS recently.  A I have no need for this product, but curiosity leads me to ask if E anyone here has experience with both Veritas and OpenVMS clusters and > how they compare? The white papers & sales stuff make VCS seem% impressive, but how about real-world?    ------------------------------  # Date: Thu, 03 Aug 2006 21:50:12 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> " Subject: Re: Speaking of Clusters:0 Message-ID: <ocuAg.1539$r%.739@news.cpqcorp.net>   Doug Phillips wrote: > curiosity leads me to ask ifG > anyone here has experience with both Veritas and OpenVMS clusters and  > how they compare?   E As I understand it, the basic capability that Veritas Cluster Server  H provides is a cluster-wide file system, which is a prerequisite for any I sort of failover capabilities within a cluster (e.g. you have to be able  I to see the files before you can start up an application which uses those  K files), and some support for application failover operations between nodes.   G MC/Serviceguard did not have a cluster-wide file system before, so for  1 them it undoubtedly seemed the logical next step.   F What it does not provide is a Distributed Lock Manager, or any of the H file-sharing and coordination functions within a cluster that are built  on top of a DLM.  H So access to disks is still on a one-node-at-a-time basis -- you'd need I to scale up within an SMP box for more horsepower, since you can't scale  I out across multiple nodes running the same workload and sharing the same  I files (except presumably for Oracle RAC, which has its own DLM built in).    ------------------------------  % Date: Thu, 03 Aug 2006 19:18:04 -0400 ( From: Bill Todd <billtodd@metrocast.net>" Subject: Re: Speaking of Clusters:G Message-ID: <OvmdnT84wPKyGU_ZnZ2dnUVZ_sidnZ2d@metrocastcablevision.com>    Keith Parris wrote:  > Doug Phillips wrote: >> curiosity leads me to ask if H >> anyone here has experience with both Veritas and OpenVMS clusters and >> how they compare? > G > As I understand it, the basic capability that Veritas Cluster Server  J > provides is a cluster-wide file system, which is a prerequisite for any K > sort of failover capabilities within a cluster (e.g. you have to be able  K > to see the files before you can start up an application which uses those  M > files), and some support for application failover operations between nodes.  > I > MC/Serviceguard did not have a cluster-wide file system before, so for  3 > them it undoubtedly seemed the logical next step.  > H > What it does not provide is a Distributed Lock Manager, or any of the J > file-sharing and coordination functions within a cluster that are built  > on top of a DLM. > J > So access to disks is still on a one-node-at-a-time basis -- you'd need K > to scale up within an SMP box for more horsepower, since you can't scale  K > out across multiple nodes running the same workload and sharing the same  K > files (except presumably for Oracle RAC, which has its own DLM built in).   ? Well, not using a conventional, monolithic file system, anyway.   F What Unix environments sometimes do in such cases is to partition the A content of the file system into multiple file systems mounted at  E strategic common locations - so everyone sees the same 'file system'  G hierarchy but the sub-components of that hierarchy are spread out over   multiple servers.   F Now, it would certainly be possible to design a file system which did F this automatically, internally, and transparently, such that even the A contents of an individual file could be spread across the entire  F complement of cluster systems.  This approach would still not require H any centralized lock management (at least for file-access purposes) and G could still use simple fail-over availability mechanisms (typically at  G the server rather than the disk level, though local disk-sharing would  F still be an option if inexpensive facilities were available - SAS may G qualify before too long), since any given datum would be accessed at a  I single server which would coordinate globally-shared access to it.  This  H is a bit reminiscent of DB2's mechanism for distributing a table across 3 multiple clustered systems by hashing, for example.   H No, it wouldn't (at least in the absence of SAS) have shared storage at I the same level that VMS does, but then again it wouldn't require storage  A that costs nearly as much as shared VMS storage does.  And while  B non-shared, fail-over-managed storage would concentrate loads for C specific data on a single server, that server could still at least  G off-load some of the bandwidth by instructing its fail-over partner to  E serve up a portion of the data (and if that's still not enough, it's  I possible to distribute the copies of the data on one server across *all*  I the other servers so that they can help carry even the most concentrated  G loads, though this has availability implications unless there's also a  C remote mirror site - or backup copies can serve, as in the case of  I something like a video-on-demand server - to keep mean time to data loss   under control).   I I used to be a strong believer in VMS-style shared storage, but that was  G before commodity storage became so incredibly inexpensive and at least  I started to approach FC/SCSI MTBFs and features (such as command queuing)  I - plus for a few SATA enterprise-rated drives high-duty-cycle ratings as  F well.  Nowadays, doubling or tripling up on direct-attached commodity D storage is far less expensive than even the cheapest shared-storage D array solution, plus provides superior performance to boot to heavy  parallelizable loads.   F So I'm now a believer in the kind of distributed, shared-nothing file H server cluster that I just described, and think I've finally worked out & most of the kinks in such an approach.   - bill   ------------------------------   Date: 3 Aug 2006 18:28:51 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett) " Subject: Re: Speaking of Clusters:, Message-ID: <ugliT97g4cSn@malvm3.mala.bc.ca>  G In article <OvmdnT84wPKyGU_ZnZ2dnUVZ_sidnZ2d@metrocastcablevision.com>, -    Bill Todd <billtodd@metrocast.net> writes:  > K > I used to be a strong believer in VMS-style shared storage, but that was  I > before commodity storage became so incredibly inexpensive and at least  K > started to approach FC/SCSI MTBFs and features (such as command queuing)  K > - plus for a few SATA enterprise-rated drives high-duty-cycle ratings as  H > well.  Nowadays, doubling or tripling up on direct-attached commodity F > storage is far less expensive than even the cheapest shared-storage  > array solution,   B   Fortunately if you don't mind trailing edge gear you can get allG that sort of stuff on Ebay for pennies on the dollar. Dual HSG80 MA2200 1 controller shelves typically sell for under $100.    ------------------------------  * Date: Thu, 3 Aug 2006 20:55:16 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: strange problem: satellite won't boot$ Message-ID: <eatnrk$i9p$1@online.de>  5 In article <44D10309.BB46303C@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes:     > Hoff Hoffman wrote: G > >    As others have commented, I would not expect a bootp error to be ' > > generated for a MOP operation, BTW.  > L > Have VAXes ever been able to issue bootp requests at the >>> prompt ??????   The satellite is an ALPHA.   ------------------------------  * Date: Thu, 3 Aug 2006 20:56:46 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: strange problem: satellite won't boot$ Message-ID: <eatnue$i9p$2@online.de>  5 In article <44D10C75.514236B7@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes:    I > Philip, since you don't use DECNET, did you try to go into LANCP of the H > boot node to ensure the satellite node ws properly configured and that$ > the service was properly enabled ?  3 No, didn't try.  (I needed to do some work.  :-|  )   J > If you temporarily lost access to some disks, perhaps LANCP got disabled5 > ? (which would explain why a revboot fixed things).   I I think that's probably what happened.  The shadowing problem led to two  F nodes rebooting themselves, but when they came back up, not all disks  were available.    ------------------------------  * Date: Thu, 3 Aug 2006 21:03:29 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: strange problem: satellite won't boot$ Message-ID: <eatob1$i9p$4@online.de>  = In article <7E9Ag.1479$On.456@news.cpqcorp.net>, Hoff Hoffman " <hoff-remove-this@hp.com> writes:    > Bob Koehler wrote:{ > > In article <eaqp6e$r4f$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  > D > >> That's the error message.  I might not have all the terminologyE > >> straight, but it's the standard setup for a LAVC without DECnet.  > > B > >    DECnet is irrelavent since MOP and DECnet are different LAN > >    protocols.  > G >    So you're really booting cluster satellite nodes over bootp/tftp?  K > Cool.  I had no idea that even worked (for cluster satellite bootstraps)  K > prior to the work that was recently added into OpenVMS in support of the  B > EFI console (and its use of bootp/tftp) required by OpenVMS I64 E > satellites (and InfoServer client bootstraps) on Integrity servers.   D I'm pretty sure I'm not.  As I mentioned in my post of a few secondsH ago, this is a very, very vanilla satellite setup, nothing fancy, which D just worked out-of-the-box (which is why I've never had a reason to 4 delve into the depths of MOP, ethernet booting etc).  J >    I'd tend to expect to see the SRM console set to OpenVMS, and to see F > the satellite bootstraps to use MOP.  SCS-based clusters have never G > operated over DECnet and have never needed DECnet, but clusters have  J > long used MOP (whether part of DECnet, or part of LANCP) to perform the  > satellite bootstraps,   B Right: vanilla set up, except for the "_LAN" in the configuration ' procedure (since DECnet isn't running).   - > and (prior to V6.2) for cluster management  2 > purposes and particularly tools such as MONITOR.  G Does that mean that MONITOR can run (between nodes) with neither DECnet  nor IP?    ------------------------------  # Date: Thu, 03 Aug 2006 22:23:23 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>2 Subject: Re: strange problem: satellite won't boot1 Message-ID: <vHuAg.1544$601.271@news.cpqcorp.net>   / Phillip Helbig---remove CLOTHES to reply wrote:   . >> and (prior to V6.2) for cluster management 3 >> purposes and particularly tools such as MONITOR.  > I > Does that mean that MONITOR can run (between nodes) with neither DECnet 	 > nor IP?   I    No, it means that the requirement for DECnet for use with MONITOR was  C removed at V6.2.  Specifically, IP was added to the transports for  G MONITOR.  AFAIK, there has been no change to MONITOR to add an IPC/SCS  I transport, for instance -- it operates over IP or DECnet, or (obviously)   from log files written to disk.    ------------------------------   Date: 3 Aug 2006 11:33:35 -0700 " From: chris_doran@postmaster.co.uk, Subject: Re: VT420 scroll down keys sequenceB Message-ID: <1154630014.967164.16390@b28g2000cwb.googlegroups.com>   apogeusistemas@gmail.com wrote:  > Hi folks:  > 5 > Can you tell me which keys sequence need I press to 1 > scrow down in a VT420 terminal ? I forgot that.  > 	 > thanks.    Control/Up-arrow.    Chris    ------------------------------  $ Date: Thu, 3 Aug 2006 16:12:29 -0400, From: "Zehel, Samuel M" <smzehel@switch.com>, Subject: RE: VT420 scroll down keys sequenceN Message-ID: <3D7A5969DC27E747A85F69D1AFF86495016BF74B@exchptc2.uss.switch.com>  > I should have read this closer, or I would have posted sooner. =20 H As mentioned earlier, <CTRL>-<UP ARROW> or <CTRL>-<DOWN ARROW> are the == key sequences used to scroll around in the terminal's buffer.  =20 @ Don't forget to check to see if the VT-420 is set up with > 24 =H lines/page of memory. I forget what key is terminal setup, <F3> perhaps? =20 F This is your scroll buffer, and I think you can set it as high as 96 =C lines or higher.  The more lines, the farther back you can scroll = C (provided the data wasn't erased by a clear screen, or some other = % malicious control character sequence)  =20  --=20 ) Samuel M. Zehel Jnr.          Engineer=20 # Automation & Information Systems=20 . Union Switch & Signal Inc. (ANSALDO SIGNAL)=20D                       A Finmeccancia Company 1000 Technology Drive = Pittsburgh, PA 15219-3120=20 Ph.: 412-688-2856=20 Fax: 412-688-2552=20$ E-mail: smzehel(at)switch(dot)com=20J Life at its noblest leaves mere happiness far behind; and indeed cannnot =H endure it.... Happiness is not the object of life: life has no object: =B it is an end in itself; and courage consists in the readiness to =3 sacrifice happiness for an intenser quality of life  -George Bernard Shaw=20     ________________________________  H From: chris_doran@postmaster.co.uk [mailto:chris_doran@postmaster.co.uk] Sent: Thu 8/3/2006 2:33 PM To: Info-VAX@Mvb.Saic.Com , Subject: Re: VT420 scroll down keys sequence         apogeusistemas@gmail.com wrote:  > Hi folks:  > 5 > Can you tell me which keys sequence need I press to 1 > scrow down in a VT420 terminal ? I forgot that.  > 	 > thanks.    Control/Up-arrow.    Chris    ------------------------------   End of INFO-VAX 2006.430 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        yKZ4OumD@Xg(6j(Q@-JWUuV},}_.w2&-	L)x_sXP fq{䠜_ײ&?w8OWGYr_
ڳZ6)RNp`	o|DH/07tIԜ))#=n&m~[LH6F,tK/Krۇ@i$p)rf'sN62JD0:
I|g1(yHx^u;K
Ψ0+ƅ]m~xGJ.{U	^JJP)ۂTf)cb226OM/{h8
c%Ml٠_N5rÓȧ=L#=[9om%f=va VHi DH',Uq 
aJx]XMRp*^6[SƦJ!eE|)Z"H$t# GP $A&2n\ͦV:=2* .= j7;{h'QHhٟKG[rF
Z8EXbVUlvdq
F;\SjT "3$>ׇC 4]<wݚ
m8F
WRUR2{>7DGץdfp8<ZMӠTސ&(h06xԓ!dhbM<Ff8V1һmx+0yf]Å1qr6s8h{vfYGI?e駬3G( !G">1^/P mF!ލA48b2{ccpv!6O)L鐚XC)7^`"IrЬ=3\}]6f?([%[^xלhxuLxP9QEV,T]#w4^CL,eޱSB'A>	-iLѼW'i,i rxC:y,5>X$9!։C␲|Q%Sݕ{+JcͳYibXe\O 24PBd@T>[bu$jCMh Hב3h,(;z}\^J2<HV*hɏH^Jf?_ g}܊JGR5UU!Qʵ;V#|A7Z#cRRzb0C "aZ`(eR܊KB˸
!Rʦ{:p
6ۣnT;sV^+"
EvO2G(BFFxOSTh'yvCeU-"[XNkOQ
	DT'˼RYQ4 ,;KD 5?+dK5MEhp*k:KkyV9(m}bgMӲ]%B|FދÙG{/ׁ2m"TE\`Q/8Hzݏ!*rt_Vrf0
p~Y@u,e 8{njPM$ 
EwvlM1ϟMff{"rN<l3ވ=eͅrGwNaBL~_F%Q04"oǚ'4$Ll-W+q@ %^ňv}(Lbsupa9)~xwש"K[
-s\΂(K;}6΋+; 2l\g.x<P&U<)9!C&UtOva![Q'ߥ!un07 U~u'IիGA2ԑ+%-"rȝ]7Zc{ϙE|yDL͒#9&c