1 INFO-VAX	Fri, 04 Aug 2006	Volume 2006 : Issue 431       Contents:/ "mount /foreign dva0:" much slower in VMS V8.2? 3 Re: "mount /foreign dva0:" much slower in VMS V8.2? 3 Re: "mount /foreign dva0:" much slower in VMS V8.2? 3 Re: "mount /foreign dva0:" much slower in VMS V8.2? 3 Re: "mount /foreign dva0:" much slower in VMS V8.2? * Re: ACCOUNTING Utility report presentation* Re: ACCOUNTING Utility report presentation Re: Apache in COLPG state  Re: Apache in COLPG state  Re: Apache in COLPG state  Re: Apache in COLPG state  Re: Apache in COLPG state  Re: Apache in COLPG state  Re: Enabling SMTP in VAX/VMS Re: Enabling SMTP in VAX/VMS" Re: FW: Linux on military aircraft 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: 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: 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: 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: OpenVMS, Alpha still rule roost in Intel fabs (2005-09) % Re: PIPE redirection as stream file ?  Re: Speaking of Clusters:  Re: Speaking of Clusters:  Re: Speaking of Clusters:  Re: Speaking of Clusters:  USB numeric keypad anyone? Re: USB numeric keypad anyone? Re: USB numeric keypad anyone?  F ----------------------------------------------------------------------  * Date: Fri, 4 Aug 2006 09:38:50 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda)8 Subject: "mount /foreign dva0:" much slower in VMS V8.2?2 Message-ID: <06080409385026_20200290@antinode.org>  B    This came up recently in the ITRC forum, and I was wondering ifG anyone else thought that it was an "enhancement" (rather than a "bug"), 4 or had a more detailed justification for the change.  G    In VMS V8.2 (and up, I assume), MOUNT /FOREIGN for a floppy disk has ! gotten much slower.  For example:   B ALP2 $ pipe show time ; mount /noassist /foreign dva0: ; show time    4-AUG-2006 09:44:01) %MOUNT-I-MOUNTED,  mounted on _ALP2$DVA0:     4-AUG-2006 09:47:23         (Time = 202s.)    While on V7.3-2 (same diskette):  A ALP $ pipe show time ; mount /noassist /foreign dva0: ; show time     4-AUG-2006 09:52:31( %MOUNT-I-MOUNTED,  mounted on _ALP$DVA0:    4-AUG-2006 09:52:34         (Time = 4s.)    : The closest thing to an explanation in the ITRC forum was:  E       Due to changes made for I64 in OpenVMS V8.2 common sources (the B       home block of an I64 system disk can't be at LBN 1 anymore),H       MOUNT/FOREIGN will scan the disk for up to 255. blocks looking for       a home block.   L http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1047587    G    I'm mystified as to why it's necessary to make the floppy drive this E much less convenient to use.  (And, of course, CTRL/Y won't interrupt E the scan, either.)  I'd assume that if I am allowed to use the floppy G drive, and I say "mount /foreign", that I can do whatever I want to the E data on the diskette, and thus that the OS has no business wasting my H time scanning the thing (for what?).  At least, I'd expect there to be a way to disable this annoyance.  H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  $ Date: Fri, 4 Aug 2006 16:24:53 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>< Subject: Re: "mount /foreign dva0:" much slower in VMS V8.2?, Message-ID: <eavos5$9fs$1@south.jnrs.ja.net>  8 "Steven M. Schweda" <sms@antinode.org> wrote in message , news:06080409385026_20200290@antinode.org...  H >   I'm mystified as to why it's necessary to make the floppy drive thisG > much less convenient to use.  (And, of course, CTRL/Y won't interrupt G > the scan, either.)  I'd assume that if I am allowed to use the floppy I > drive, and I say "mount /foreign", that I can do whatever I want to the G > data on the diskette, and thus that the OS has no business wasting my & > time scanning the thing (for what?).  ? You can mount a volume without privileges if you are the owner. : A possible use would be making a physical backup of one of; your own Files-11 volumes. This is long standing documented ; behaviour, if somewhat counterintuitive as to what /FOREIGN  is mainly used for.   B >At least, I'd expect there to be a way to disable this annoyance.   That would be nice.    ------------------------------  * Date: Fri, 4 Aug 2006 10:43:06 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda)< Subject: Re: "mount /foreign dva0:" much slower in VMS V8.2?2 Message-ID: <06080410430595_2027368D@antinode.org>  * From: "Richard Brodie" <R.Brodie@rl.ac.uk>  A > You can mount a volume without privileges if you are the owner. < > A possible use would be making a physical backup of one of= > your own Files-11 volumes. This is long standing documented = > behaviour, if somewhat counterintuitive as to what /FOREIGN  > is mainly used for.   F    Plausible, but if I have all the privileges I need whether or not IB own the volume, what's the point in (wasting my time) checking theE volume ownership to see if I could do it without all the privileges I  have?   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 17:08:58 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>< Subject: Re: "mount /foreign dva0:" much slower in VMS V8.2?2 Message-ID: <KaLAg.1567$Bp1.1347@news.cpqcorp.net>   Steven M. Schweda wrote:D >    This came up recently in the ITRC forum, and I was wondering ifI > anyone else thought that it was an "enhancement" (rather than a "bug"), 6 > or had a more detailed justification for the change.  F    Some of the updated search algorithms make the mounting of certain H (slow) media slower, or so I've noticed -- IIRC, these were updates for  searching for the home block.    ------------------------------   Date: 4 Aug 2006 12:41:13 -0500  From: briggs@encompasserve.org< Subject: Re: "mount /foreign dva0:" much slower in VMS V8.2?3 Message-ID: <Hk4UPDIL2HfK@eisner.encompasserve.org>   a In article <KaLAg.1567$Bp1.1347@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes:  > Steven M. Schweda wrote:E >>    This came up recently in the ITRC forum, and I was wondering if J >> anyone else thought that it was an "enhancement" (rather than a "bug"),7 >> or had a more detailed justification for the change.  > H >    Some of the updated search algorithms make the mounting of certain J > (slow) media slower, or so I've noticed -- IIRC, these were updates for  > searching for the home block.   4 For mag tape, you can override this kind of behavior  D $ MOUNT MKA0: /FOREIGN /OVERRIDE=(OWNER_ID,EXPIRATION,ACCESSIBILITY)  @ You get a mount operation that doesn't have to do any device I/OI beyond the PACKACK.  (And a truly mind-boggling performance improvement).   D Is there something about disk that precludes the use of some similar /OVERRIDE= options?   & The online HELP doesn't show anything.  A Yes, we don't want someone who is not the volume owner to be able D to mount and destroy a FILES-11 volume.  Yes, we don't want somebodyJ mounting a shadow set member /FOREIGN and forgetting to bump the shadowset generation number.  D But shouldn't we have a way to say "it's not labelled -- just do the' PACKACK and give me a mounted volume"?     ------------------------------  # Date: Fri, 04 Aug 2006 12:32:33 GMT F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)3 Subject: Re: ACCOUNTING Utility report presentation . Message-ID: <B7HAg.37$6g7.124@news.oracle.com>  e In article <1154616288.724857.67610@m73g2000cwd.googlegroups.com>, "Ian Miller" <ijm@uk2.net> writes: E >the format of accounting records is documented so you can write your F >own reporting tool. There was a DTR defintion around someplace so you >could do reports from DTR.  >  >   ? The format of the accounting records is such that things are in D variable places in different records.  This makes it a bit difficult@ to read directly with Datatrieve (DTR) and some other utilities.  < Back around 1987 I wrote a program that reads the accounting> records and writes it out in a fixed record definitions formatB so it can be read with Datatrieve and other programs.  It's called= ACC_CONVERT.MAR, and it's been in a number of DECUS and other B software collections.  In 2000 I did a few touchups to make it run> better on Alpha.  It's 15 KBytes, so it's a little large for a@ Usenet News posting, but I suppose it could be done if you can't> find it on the Internet somewhere.  Or I can make it available@ on a web page somewhere.  But try a web search first, the format> of the accounting record hasn't changed in a long time, so the( program shouldn't have to change either.  C There is a related program that converts PSI Accounting records the ? same way, but I haven't tried to run it in over a decade, and I 5 don't know what the current OSI/PSI product set does.    Bart.    ------------------------------   Date: 4 Aug 2006 08:38:20 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 3 Subject: Re: ACCOUNTING Utility report presentation 3 Message-ID: <COoqmksoavlZ@eisner.encompasserve.org>   _ In article <1154615102.713611.20160@h48g2000cwc.googlegroups.com>, andrewr@cornasys.com writes:  > Hi,  > B > I have a requirement to set up the ACCOUNTING utility to extract. > reports on the OpenVMS resource utilisation. > I > I can extract the reports, but the rporting format is pretty limited. I H > would like to also have some charts and graphs. I am sure that I could? > modiy the current reports so that they may be imported into a I > spreadsheet, and then charted or graphed (/FORMAT=...). Has anybody got  > any tips on this?   D    I always used monitor/record and then monitor/input to meet these    kinds of needs.  ,    Are you sure you're using the right tool?   ------------------------------   Date: 4 Aug 2006 02:05:49 -0700   From: "Ian Miller" <ijm@uk2.net>" Subject: Re: Apache in COLPG stateC Message-ID: <1154682349.851320.262540@i42g2000cwa.googlegroups.com>   E You must be getting a lot of page faults as COLPG is waiting for page B to be read in (hard page fault) which is already being read in for' another process (which will be in PFW).   E Did something get bigger? As you have been updating software then you G may find revised WSDEFAULT, WSQUOTA, WSEXTENT values are necessary (and  parhaps other things).   ------------------------------  $ Date: Fri, 4 Aug 2006 11:58:30 +0100% From: "issinoho" <issinoho@gmail.com> " Subject: Re: Apache in COLPG state0 Message-ID: <12d6a6fp8ns8taa@corp.supernews.com>  , "Ian Miller" <ijm@uk2.net> wrote in message = news:1154682349.851320.262540@i42g2000cwa.googlegroups.com... G > You must be getting a lot of page faults as COLPG is waiting for page D > to be read in (hard page fault) which is already being read in for) > another process (which will be in PFW).  > G > Did something get bigger? As you have been updating software then you I > may find revised WSDEFAULT, WSQUOTA, WSEXTENT values are necessary (and  > parhaps other things). >   I Very curious. From a clean boot, as soon as I hit Apache, within about 3  H pages being accessed, one of the Apache subprocesses goes straight into  COLPG.L The odd thing is that no other process is in any kind of 'odd' state, there  are no processes in PFW.  M The DIO looks fine, I've checked with both MONITOR DISK/ITEM=QUEUE & MONITOR  + PROCESS/TOPDIO and nothing looks excessive.   C I've checked the process quotas for APACHE$WWW and they are all as  J recommended in the manual (I even increased some to account for a heavier K load, although I would in no way describe the load of this box as 'heavy')   and I've also AUTOGENed.  H I can't help feeling that all this happened directly as a result of ECO 2 patching, could a system bug have been introduced?  F I'm going to try reinstalling Apache. Any ideas/help would be greatly E appreciated (I can arrange a guest login if anyone fancies a spot of   detective work)   J Needless to say the VAMP service is, to all intents & purposes, currently  down.    ------------------------------   Date: 4 Aug 2006 05:20:31 -0700 / From: "Volker Halle" <volker_halle@hotmail.com> " Subject: Re: Apache in COLPG stateC Message-ID: <1154694031.316482.301670@i42g2000cwa.googlegroups.com>   	 issinoho,   F this looks like some bug in OpenVMS. A COLPG wait should only last forD a few seconds, until the page has been brought into memory. Does theE process really 'hang' in COLPG ? Does it's Page Flts counter increase  (SHOW SYS/STATE=COLPG) ?  C To get back into business, try to remove the latest ECOs installed. A Consider to force a system crash with a process hanging in COLPG,  before you remove the patches.  . Are the APACHE processes are using PTHREADS ?    Volker.    ------------------------------   Date: 4 Aug 2006 05:48:12 -0700 / From: "Volker Halle" <volker_halle@hotmail.com> " Subject: Re: Apache in COLPG stateA Message-ID: <1154695692.346691.6560@b28g2000cwb.googlegroups.com>   	 issinoho,   F to find out how long the process has been in the COLPG wait state, use these command:  
 $ ANAL/SYS3 SDA> SET PROC/IND=<pid-of-process-hanging-in-COLPG>  SDA> READ SYSDEF SDA> SHOW PROCESS 7 SDA> exa pcb+pcb$l_waitime      ! abs time of last wait ; SDA> exa pcb+pcb$l_onqtime     ! abs time of entering queue ; SDA> exa exe$gl_abstim_tics     ! abs time in tics (=10 ms) 	 SDA> EXIT   G If there is a significant difference between abstim_tics and onqtime or ' waitime, the process seems to be stuck.    Volker.    ------------------------------   Date: 4 Aug 2006 06:12:51 -0700 % From: "issinoho" <issinoho@gmail.com> " Subject: Re: Apache in COLPG stateC Message-ID: <1154697171.879033.253680@m73g2000cwd.googlegroups.com>    Volker Halle wrote:  > issinoho,  > H > to find out how long the process has been in the COLPG wait state, use > these command: >  > $ ANAL/SYS5 > SDA> SET PROC/IND=<pid-of-process-hanging-in-COLPG>  > SDA> READ SYSDEF > SDA> SHOW PROCESS 9 > SDA> exa pcb+pcb$l_waitime      ! abs time of last wait = > SDA> exa pcb+pcb$l_onqtime     ! abs time of entering queue = > SDA> exa exe$gl_abstim_tics     ! abs time in tics (=10 ms)  > SDA> EXIT  > I > If there is a significant difference between abstim_tics and onqtime or ) > waitime, the process seems to be stuck.  > 	 > Volker.   E Thanks for the tips. Yes the page faults were increasing in the COLPG  process.A I did a PRODUCT UNDO PATCH which got to 40% and then aborted (?). 	 Rebooted.  Removed Apache.  Reinstalled Apache.   F Thus far (touch wood) everything is back to normal and VAMP is running! properly with no sign of a COLPG.    I'll watch closely.    ------------------------------  $ Date: Fri, 4 Aug 2006 16:55:44 +0100% From: "issinoho" <issinoho@gmail.com> " Subject: Re: Apache in COLPG state0 Message-ID: <12d6rjpi8iejk36@corp.supernews.com>  1 "issinoho" <issinoho@gmail.com> wrote in message  = news:1154697171.879033.253680@m73g2000cwd.googlegroups.com...  >  > Volker Halle wrote:  >> issinoho, >>I >> to find out how long the process has been in the COLPG wait state, use  >> these command:  >>
 >> $ ANAL/SYS 6 >> SDA> SET PROC/IND=<pid-of-process-hanging-in-COLPG> >> SDA> READ SYSDEF  >> SDA> SHOW PROCESS: >> SDA> exa pcb+pcb$l_waitime      ! abs time of last wait> >> SDA> exa pcb+pcb$l_onqtime     ! abs time of entering queue> >> SDA> exa exe$gl_abstim_tics     ! abs time in tics (=10 ms) >> SDA> EXIT >>J >> If there is a significant difference between abstim_tics and onqtime or* >> waitime, the process seems to be stuck. >>
 >> Volker. > G > Thanks for the tips. Yes the page faults were increasing in the COLPG 
 > process.C > I did a PRODUCT UNDO PATCH which got to 40% and then aborted (?).  > Rebooted.  > Removed Apache.  > Reinstalled Apache.  > H > Thus far (touch wood) everything is back to normal and VAMP is running# > properly with no sign of a COLPG.  >  > I'll watch closely.  >   G OK, scratch that last post. It took longer but it's still happening, I  + presently have 2 Apache processes in COLPG.   J Volker, I've tried your sequence above, but when I type in READ SYSDEF in L SDA the cursor drops to the next line then just sits blinking at me. Ctrl-Y 2 doesn't work and I have to close down the session.  M I'm tearing my hair out on this one. Will VMS let me re-apply the latest ECO   patches? I could try that.   ------------------------------  % Date: Fri, 04 Aug 2006 09:46:27 -0400 # From: sol gongola <sol@adldata.com> % Subject: Re: Enabling SMTP in VAX/VMS 0 Message-ID: <1154699279.719721@nntp.acecape.com>   contracer11@gmail.com wrote: > Hi VMS experts:  > 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  >  > Thanks again.  >   9 Do you have to have disable incoming, or are you just not  interested in having it work. : You may not be able to receive errors/bounces if you don't allow incoming emails.   ------------------------------  # Date: Fri, 04 Aug 2006 16:59:50 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>% Subject: Re: Enabling SMTP in VAX/VMS 1 Message-ID: <a2LAg.1563$Pm1.511@news.cpqcorp.net>    contracer11@gmail.com wrote:  A > I'm looking for a way to enable SMTP protocol in my Vax system.   "    VAX is hardware.  Not software.  D    Various VAX systems can boot and run ULTRIX VAX, OpenVMS VAX and G various other operating systems.  (And VAX/VMS tends to imply software   versions prior to V5.5 or so.)  D    These distinctions may seem and may reasonably be interpreted as F pedantic, but it's not intended to be.  With the name of the software H involved (and materials such as the versions), we can better target our D answers to your questions, and we can (try to) avoid cases where we A might not understand and/or answer the question you had intended.   @ > I need enable this protocol to send e-mail only (not receive).  B    If you only need client, then configure your chosen client for E communications with an SMTP server elsewhere.  How you configure the  * client depends on which client, obviously.  H    On OpenVMS, the default MAIL client assumes a local SMTP server, but ? there are clients available that can and do use remote servers.   G    The mail client in Mozilla, for instance, can be configured and can  F connect and use a remote SMTP server to send mail, and can use POP or ! IMAP to receive and process mail.    > Can you help me ? 2 > Looking in sys$manager: area I found this files: > ucx$smtp_startup.com > ucx$smtp_shutdown.com   F    The central configuration tool for TCP/IP Services product (in the : product version range that you are apparently running) is:      @SYS$MANAGER:UCX$CONFIG  F    The constituent procedures for the various clients and servers are ) not generally intended for direct access.   F    The TCP/IP Services product manuals -- including the configuration G and management materials for the current releases -- are available for  F viewing at <http://www.hp.com/go/openvms/doc/>.  Your TCP/IP Services D version is clearly prior to V5.0, which makes it comparatively old. I These manuals can be invaluable sources of information, particularly for  I questions such as this one.  (Versions prior to V5.0 used the prefix UCX  F for commands and tools and files, and versions V5.0 and later use the  prefix TCPIP.)  G    And I'm assuming that there are reasons why this OpenVMS VAX system  F has not been upgraded to more current OpenVMS and more current TCP/IP # Services product versions, as well.    ------------------------------  * Date: Fri, 4 Aug 2006 10:58:50 +0000 (UTC) From: david20@alpha2.mdx.ac.uk+ Subject: Re: FW: Linux on military aircraft , Message-ID: <eav999$4ca$2@south.jnrs.ja.net>  r In article <1154643385.954253.69550@i42g2000cwa.googlegroups.com>, "Beach Runner" <Bob4Health@hotmail.com> writes: >  >Doug Phillips wrote:  >> O'Brien Paddy wrote:  > : >No other system stays up for years at a time, or clustersE >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 usernames4 >and passwords in plain text.  That should have been >phased out of VMS years ago.  >   / Well on recent versions of VMS you can use ssh.    ( N VMS is hardly alone in supporting protocols which pass usernames and passwords in clear text.   )     
 David Webb Security team leader CCSS Middlesex University   > 7 >The only reason it isn't the top platform out there is  >marketting. >    ------------------------------   Date: 4 Aug 2006 01:57:03 -0700   From: "Ian Miller" <ijm@uk2.net># Subject: Re: InfoServer 100 success B Message-ID: <1154681823.182729.95080@m73g2000cwd.googlegroups.com>  A Thank you for this. Those of us still blessed/cursed with running > INFOSERVERs will find this useful. IIRC VMS Manufacturing usedG infoservers - I gues the modern version is the infoserver software on a  Itanium VMS system.    ------------------------------    Date: 04 Aug 2006 13:28:21 -04003 From: Rich Alderson <news@alderson.users.panix.com> E Subject: Re: Is there a Unix /tmp directory. How dissimilar are they. . Message-ID: <mdd1wrwtnpm.fsf@panix5.panix.com>  " John Santos <john@egh.com> writes:   > Bill Gunshannon wrote:/ >> In article <44CF86BA.FC55A952@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:    >>> Another aspect:   J >>> On VMS, there is the capacity of having "temporary" files. However, itL >>> is not well known. You can specify, when you open a file,  that the file  >>> is to be deleted on closing.   >> Sigh.....  5 >> This is hardly unique to VMS.  Unix has tmpfile(),   H > I don't think JF was saying this was unique to VMS, just that it isn'tG > well known (at least on VMS.)  RSTS/E has the same facility.  I don't 0 > know but I would bet that TOPS-10 did as well.  O Tops-10 has a limited form, used for control files but not anything else AFAIK. M Tops-20, on the other hand, has a file status bit that can be set on any file < to mark it temporary (and cause it to be deleted at logout).   --  L Rich Alderson                                       | /"\ ASCII ribbon     |L news@alderson.users.panix.com                       | \ / campaign against |L "You get what anybody gets. You get a lifetime."    |  x  HTML mail and    |L                          --Death, of the Endless    | / \ postings         |   ------------------------------  % Date: Fri, 04 Aug 2006 09:10:55 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> ' Subject: Re: Linux on military aircraft = Message-ID: <44d2f2e7$0$67256$157c6196@dreader2.cybercity.dk>    John Santos wrote:J >> The bad guys will start attacking VMS the moment they consider it more I >> profitable to attack VMS than M$ and Linux and be sure they will find   >> critical security errors. > H > I don't understand this sentence.  Are you saying "one of the criteriaG > the bad guys will use to decide whether they will start attacking VMS J > is if they are sure they will find security problems", or are you sayingF > "If and when bad guys decide to attack VMS, we (the audience to thisF > thread), should understand that they will definitely find problems"?G > In other words, is the implied subject of the clause that starts with 9 > "and be sure" the bad guys or us (comp.os.vms readers)?   G What I am saying is that criminals are just like everybody else.  They  C pick the low hanging apples first.  The number of hackers that are  I hacking for the fun of it is going down and they are replaced by hackers  H that are in it for the money.  (Frequently it is the same humans.  They ? just change from being the likes of graffiti painters to being  H swindlers.)  The hackers that want to make money don't care if there is G more prestige in hacking VMS than hacking Windows or Linux.  They just  E want money.  The moment they start thinking that it is easier to get  I money from hacking VMS than getting results from hacking other platforms   they will attack VMS.   - >   Also, on Linux and Windows there are many J >> good guys that hunt security bugs.  In the short term these guys are a F >> pain because they discover bugs that must be fixed and the patches I >> must installed by the users.  In the long term it might lead to these  F >> two platforms becoming more secure than platform without white hat  >> security bug hunters. > I > For Linux, they probably are making progress...  For Windows, it's like & > emptying the sea with a bucket.  :-)  H Don't be so sure about Windows.  M$ know that they have to do something I about security, and so they will tighten security.  It will be difficult  A for them, because they can't get tight security and keep Windows  E backwards compatible.  I doubt Vista will be tight enough, but there  ( will be versions of Windows after Vista.   ------------------------------   Date: 4 Aug 2006 11:48:32 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: Linux on military aircraft + Message-ID: <4jgqggF810nrU1@individual.net>   + In article <22zAg.15582$c11.2965@trnddc08>, # 	John Santos <john@egh.com> writes:  > Bill Gunshannon wrote:/ >> In article <44D23742.42C7318A@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>   >>>Bill Gunshannon wrote:  >>> H >>>>what summer is for).  I will do all of this without any downtime forG >>>>my users (beyond the time it takes for a simple re-boot, which will , >>>>not even be noticed!)  Easy?  Elegant?   >>> B >>>There are many businesses where even the reboot downtime is notA >>>acceptable.  (or must be done at 03:00am on a sunday morning).  >>   >>  G >> What's wrong with that?  Surely you don't think I am going to reboot ) >> my servers in the middle of the day?    >>   >>   > 1 > Sure!  Why not?  Just cluster them.  (SMOM) [*]  >  > [*] Small Matter Of Money    E Well, money is always a matter here, but not in this regard. Remember D what I said earlier?  How many systems are clusters and how many areC single, standalons systems?  Well, with the exception of my general A use servers, all the others are single, standalone.  If they were B running VMS, this would not have changed.  As it turns out, one ofC the changes being instituted with this upgrade (at my bosses behest @ and probably due to a desire to save money by not buying as muchB hardware) is server consolidation.  Most of the light-weight tasksC are going to be moved from their individual machines to one central E machine.  This, of course, has advantages and disadvantages.  And, is D totally unrelated to VMS as those advantages and disadvantages wouldB be the same no matter what OS the machines run.  I once consideredE running a couple of Windows Servers clustered, but decided other than @ as an academic experiment it accomplished nothing.  My user baseD does not generate enough Windows traffic to justify it.  Some (many)' would consider that a good thing!!  :-)    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: 4 Aug 2006 08:35:17 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ' Subject: Re: Linux on military aircraft 3 Message-ID: <duPZMFj562Ac@eisner.encompasserve.org>   V 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: >> Bill Gunshannon wrote: H >>> what summer is for).  I will do all of this without any downtime forG >>> my users (beyond the time it takes for a simple re-boot, which will , >>> not even be noticed!)  Easy?  Elegant?   >>  B >> There are many businesses where even the reboot downtime is notA >> 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?   >   D    All you're customers are in the same time zone?  Gee, you have it    easy.   ------------------------------   Date: 4 Aug 2006 13:54:15 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: Linux on military aircraft + Message-ID: <4jh1s7F819mhU1@individual.net>   3 In article <duPZMFj562Ac@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:X > In article <4jf1shF7mvddU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:/ >> In article <44D23742.42C7318A@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>> Bill Gunshannon wrote:I >>>> what summer is for).  I will do all of this without any downtime for H >>>> my users (beyond the time it takes for a simple re-boot, which will- >>>> not even be noticed!)  Easy?  Elegant?    >>> C >>> There are many businesses where even the reboot downtime is not B >>> acceptable.  (or must be done at 03:00am on a sunday morning). >>  G >> What's wrong with that?  Surely you don't think I am going to reboot ) >> my servers in the middle of the day?    >>   > F >    All you're customers are in the same time zone?  Gee, you have it
 >    easy.  C In some cases, such as being spread out geographically, there is no E perfect time.  I too have to consider users in different time zones.  H We have students from all over the world and some of them may be workingD on projects over the summer.  But I can look for the best time to doB it based on activity on the machines.  I know when the best times,F traditionaly, have been.  I can log on at those times and see if doingC it then will have any impact.  Or, I can piggy-back my reboots with G the already scheduled Campus network downtime.  if the network is down, E it's a pretty safe bet I have no user currently logged on.  :-)  Life : isn't ever simple.  if it were, it would be no fun at all.   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: 4 Aug 2006 08:34:20 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ' Subject: Re: Linux on military aircraft 3 Message-ID: <PcFL4fSVcakd@eisner.encompasserve.org>   \ In article <44D23742.42C7318A@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > A > There are many businesses where even the reboot downtime is not @ > acceptable.  (or must be done at 03:00am on a sunday morning). >   H    I know from another contractor of commercial systems that are allowedG    to be down 20 minutes per year.  I don't know what kind of computers 9    they use, but if were my problem, I know what I'd use.   H    It's an international organization and the closest thing they have toG    an international holiday is Christmas, so that's when the 20 minutes     get scheduled.   H    3:00am Sunday at the site is Sunday afternoon at other sites.  24x365    operations are normal.    ------------------------------   Date: 4 Aug 2006 08:38:59 -0700 - From: "Doug Phillips" <dphill46@netscape.net> ' Subject: Re: Linux on military aircraft C Message-ID: <1154705939.211492.308050@p79g2000cwp.googlegroups.com>    John Santos wrote: > Dave Froble wrote: > > Doug Phillips wrote: > >  > >> Dave Froble wrote:  > >> > >>> Karsten Nyblad wrote:  > >>>  > >>>> Bill Gunshannon wrote:  > >>>>I > >>>>> And somehow, I doubt this is true either.  Why would someon Email & > >>>>> target coordinates to the B-2? > >>>>L > >>>> During the attack on Iraq, half of the bombers took of before gettingM > >>>> their targets.  In Afghanistan commanding officers can call in and ask M > >>>> for air support, and the enemies will be attacked by planes already in N > >>>> the air.  I do not know how the planes are getting the coordinates, butJ > >>>> it would not surprise me if they get them by some messaging tool so > >>>> that J > >>>> they have them in writing.  I am a bit skeptical that they would beN > >>>> using ordinary E-mail considering that the people on the ground need to4 > >>>> be sure that the pilots the information fast. > >>> J > >>> I don't know, but I'm also finding the e-mail claim hard to believe.G > >>> I'd think that such data would be desired to be fed directly into K > >>> on-board systems.  Why would anyone want a human entering data that's L > >>> already in electronic form?  A real chance of errors being introduced. > >>> 7 > >>> Yeah, it's got to be entered once, but not twice.  > >>>  > >>F > >> Well, sure I just made it up. God forbid anyone should google it.K > >> Here's a first-hand account published in the Christian Science Monitor # > >> (presuming they're not lying):  > >  > > L > > It's to be hoped that there's not too much on this forum that's made up.E > >  I'd not intended that.  It's possible that someone could pass on L > > something on which they were misinformed.  I'm sure it's happened to me. > > : > >> <http://www.csmonitor.com/2003/0512/p25s01-usmi.html> > >> > >> Here's an article on COTS:  > >>2 > >> <http://www.armada.ch/02-5/complete_02-5.pdf> > >>J > >> For secure communications, it's not the application that matters, itsK > >> the way the data is communicated; the level of encryption; the privacy J > >> of the channel. Military software is not exposed to the public in anyI > >> way what-so-ever. While physical access to *anything* can compromise G > >> security, planting a trojan, worm or virus in one of these systems F > >> would be as likely as walking out of Fort Knox with a bar of gold  > >> stuffed down your trousers. > >> > > J > > It wasn't the security that bothered me.  I'd think that systems wouldJ > > be designed to decrease operator workload.  Loading data directly into/ > > on-board systems would have been my choice.  > >  > G > I could easily believe that someone trying to describe how the system E > worked to someone non-technical (management, reporter, their cousin C > Vinny) could say something like "then the system passes a message D > electronically to the bomber..." and the non-technical person saysI > "you mean, like e-mail?", and the answer is "Yeah, exactly like email." # > and thus an urban legend is born.  > G > On the other hand, they might really be using Outlook, in which case,  > LOOK OUT!  >   G John, sorry, I should have provided more content for those without HTML D access. I thought the whole of articles too lengthy to publish here,3 and most content is not relevant to the discussion.   1 This is from the first article link I referenced:    ##C Pilots flying the bat-winged B-2 bombers over Iraq received targets @ from mission planners on the ground via e-mail. It's not exactlyF America Online. Each encrypted message bounced off military satellitesE before popping up in their onboard laptops' Microsoft Outlook in-box.  ##  D This article is not the only validating source for this "revelation"% but I thought it an interesting read.   < The second link is a 2002 .PDF article about the use of COTSD (commercial off-the-shelf) products by the military which might give( some insight into the why of the matter.   ------------------------------  $ Date: Fri, 4 Aug 2006 12:31:59 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: Linux on military aircraft T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840182C1FA@tayexc19.americas.cpqcorp.net>   > -----Original Message-----G > From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]=20  > Sent: August 4, 2006 9:34 AM > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: Linux on military aircraft  >=20: > In article <44D23742.42C7318A@teksavvy.com>, JF Mezei=20( > <jfmezei.spamnot@teksavvy.com> writes: > >=20C > > There are many businesses where even the reboot downtime is not B > > acceptable.  (or must be done at 03:00am on a sunday morning). > >=20 >=20A >    I know from another contractor of commercial systems that=20 
 > are allowed B >    to be down 20 minutes per year.  I don't know what kind of=20 > computers ; >    they use, but if were my problem, I know what I'd use.  >=20@ >    It's an international organization and the closest thing=20 > they have toA >    an international holiday is Christmas, so that's when the=20  > 20 minutes >    get scheduled.  >=20> >    3:00am Sunday at the site is Sunday afternoon at other=20 > sites.  24x365 >    operations are normal.  >=20    A Yep - at a large Telecom company who also had a big Semiconductor E mfg'ing facility, they stated their down time was in the order of CAD G $700K / hour. Essentially the cost of a batch of wafers not produced or C having to be thrown out. Since it is 24x7, any hr lost is 1 hr lost F yearly production. The company semi division has since been sold, so I  am not sure what happened to it.  E Try talking to the business unit about taking the primary system down H for a few hours anytime during the year and they would look at you as if7 you stepped out from a space craft from another planet.   B Unfortunately they needed to upgrade as their capacity was quickly getting max'ed out.=20  B We spent approx 4 months planning for 1 hour of downtime. The hour@ chosen was actually interesting - noon on a specific Thurs. TheyG reasoned that was when many on the floor went to lunch and if something C did go wrong, all the right players would be right there to address  anything that was required.   $ So what happened during that 1 hour?  : - systems were upgraded from older Alpha 4100's to GS60's./ - network converted from FDDI to 100Mb ethernet * - OS upgraded from VMS V7.2-1 to V7.3-1=20F - migrated the storage from older HSJ40/50's to newer, faster HSJ80's.   Not bad eh?    :-)   G Systems were actually not back up until 1:10pm, but they never actually H got the systems down until 12:10, so we kidded the Cust that we actually$ met our target of 1 hr. downtime.=20  ) Cust was ecstatic about how well it went.   @ Course, the "trick" to doing all of this was in that 4 months ofG planning, we installed new systems in the cluster online with different F roots and customized them to match the older environments to a tee. WeB also got backups of the data using HBVS (they could pause App from@ updating anything at key times like while breaking shadow sets).  D Essentially the one hr was used to bring the systems down and rebootF them into the new system roots and fine tune any errors on the reboot.  G Being able to work online in the middle of a prod cluster is really key H to working in mission critical clusters. Cust's who have this and expect< this when someone talks about introducing any other platform environment.   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 12:54:22 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ' Subject: Re: Linux on military aircraft 9 Message-ID: <2cGdnZDjV6TE507ZnZ2dnUVZ_sednZ2d@libcom.com>    Karsten Nyblad wrote:  > John Santos wrote:F >>> The bad guys will start attacking VMS the moment they consider it J >>> more profitable to attack VMS than M$ and Linux and be sure they will " >>> find critical security errors. >>I >> I don't understand this sentence.  Are you saying "one of the criteria H >> the bad guys will use to decide whether they will start attacking VMSK >> is if they are sure they will find security problems", or are you saying G >> "If and when bad guys decide to attack VMS, we (the audience to this G >> thread), should understand that they will definitely find problems"? H >> In other words, is the implied subject of the clause that starts with: >> "and be sure" the bad guys or us (comp.os.vms readers)? > I > What I am saying is that criminals are just like everybody else.  They  E > pick the low hanging apples first.  The number of hackers that are  K > hacking for the fun of it is going down and they are replaced by hackers  J > that are in it for the money.  (Frequently it is the same humans.  They A > just change from being the likes of graffiti painters to being  J > swindlers.)  The hackers that want to make money don't care if there is I > more prestige in hacking VMS than hacking Windows or Linux.  They just  G > want money.  The moment they start thinking that it is easier to get  K > money from hacking VMS than getting results from hacking other platforms   > they will attack VMS.   F Targetting a particular platform does not insure success.  Not saying I they cannot be successful.  I seriously doubt that the successes will be   many.  And it's possible, none.   . >>   Also, on Linux and Windows there are manyI >>> good guys that hunt security bugs.  In the short term these guys are  I >>> a pain because they discover bugs that must be fixed and the patches  J >>> must installed by the users.  In the long term it might lead to these G >>> two platforms becoming more secure than platform without white hat   >>> security bug hunters.  >>J >> For Linux, they probably are making progress...  For Windows, it's like' >> emptying the sea with a bucket.  :-)  > J > Don't be so sure about Windows.  M$ know that they have to do something K > about security, and so they will tighten security.  It will be difficult  C > for them, because they can't get tight security and keep Windows  G > backwards compatible.  I doubt Vista will be tight enough, but there  * > will be versions of Windows after Vista.   Oh shit!  Here we go again.   - It used to be "wait until NT is good enough".   # Now it's "wait until NT is secure".    Why do we have to wait?   9 How can we be sure waiting will cause the desired effect?   H You got a problem with using something that has 'it' now?  Has had 'it'  for quite some time?  C Next time you purchase an automobile, be sure to get one with some  G defects, such as no gas tank, and then you can 'WAIT' until a gas tank  
 is available.   H Has waiting been enough to have NT good enough for enterprise computing?  8 What makes you think waiting will cause it to be secure?   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Fri, 04 Aug 2006 13:03:06 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ' Subject: Re: Linux on military aircraft 9 Message-ID: <EvidnS27M5L54U7ZnZ2dnUVZ_rqdnZ2d@libcom.com>    Main, Kerry wrote: >  >> -----Original Message----- F >> From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]  >> Sent: August 4, 2006 9:34 AM  >> To: Info-VAX@Mvb.Saic.Com* >> Subject: Re: Linux on military aircraft >>9 >> In article <44D23742.42C7318A@teksavvy.com>, JF Mezei  ) >> <jfmezei.spamnot@teksavvy.com> writes: C >>> There are many businesses where even the reboot downtime is not B >>> acceptable.  (or must be done at 03:00am on a sunday morning). >>> @ >>    I know from another contractor of commercial systems that  >> are allowedA >>    to be down 20 minutes per year.  I don't know what kind of   >> computers< >>    they use, but if were my problem, I know what I'd use. >>? >>    It's an international organization and the closest thing   >> they have to @ >>    an international holiday is Christmas, so that's when the 
 >> 20 minutes  >>    get scheduled. >>= >>    3:00am Sunday at the site is Sunday afternoon at other   >> sites.  24x365  >>    operations are normal. >> >  > C > Yep - at a large Telecom company who also had a big Semiconductor G > mfg'ing facility, they stated their down time was in the order of CAD I > $700K / hour. Essentially the cost of a batch of wafers not produced or E > having to be thrown out. Since it is 24x7, any hr lost is 1 hr lost H > yearly production. The company semi division has since been sold, so I" > am not sure what happened to it. > G > Try talking to the business unit about taking the primary system down J > for a few hours anytime during the year and they would look at you as if9 > you stepped out from a space craft from another planet.  > D > Unfortunately they needed to upgrade as their capacity was quickly > getting max'ed out.  > D > We spent approx 4 months planning for 1 hour of downtime. The hourB > chosen was actually interesting - noon on a specific Thurs. TheyI > reasoned that was when many on the floor went to lunch and if something E > did go wrong, all the right players would be right there to address  > anything that was required.  > & > So what happened during that 1 hour? > < > - systems were upgraded from older Alpha 4100's to GS60's.1 > - network converted from FDDI to 100Mb ethernet * > - OS upgraded from VMS V7.2-1 to V7.3-1 H > - migrated the storage from older HSJ40/50's to newer, faster HSJ80's. > 
 > Not bad eh?    Don't know.  Maybe.   E While you probably had more to consider than you've written, I think  D that I'd enjoy the challenge of doing that with zero downtime.  Not H saying it would be possible, but as you mentioned, new systems could be F added to the cluster and phased into production while the old systems I were still running.  (I'm assuming that periodically applications are at  H some type of starting point.)  Disks could be added, shadowed/mirrored,   and old ones then taken offline.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Fri, 04 Aug 2006 13:29:39 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ' Subject: Re: Linux on military aircraft , Message-ID: <44D383FD.F87BE22F@teksavvy.com>   Doug Phillips wrote:3 > This is from the first article link I referenced:  >  > ##E > Pilots flying the bat-winged B-2 bombers over Iraq received targets B > from mission planners on the ground via e-mail. It's not exactlyH > America Online. Each encrypted message bounced off military satellitesG > before popping up in their onboard laptops' Microsoft Outlook in-box.  > ##    H If they are using the same type of system as NASA is using to send stuffF to the space station or Shuttle, then it requires that the pilot firstG shut down outlook to close the files, and the remote people deposit new G email files/indexes into his laptop's hard drive (via the MS equivalent F of NFS), and then send a voice message to the pilot telling him he can1 open outlook and find new messages in his laptop.   F While this works OK in the slow motion environment of shuttle or spaceR station, I really doubt this would be workable in live high speed combat missions.  G It is possible however that the data is loaded onto the laptop prior to D taking off giving the pilot instructions on his mission. But i doubtB that this is something that would be done "live" seconds before heH reaches a target. First, it is too slow and more important, requires way too much attention from pilot.    A Note: Outlook is not a server. Someone cannot SEND information to F Outlook.  You either deposit files while outlook is closed, or you get& outlook to connect to a remote server.   --  = Posted via a free Usenet account from http://www.teranews.com    ------------------------------   Date: 4 Aug 2006 08:37:06 -0200 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09), Message-ID: <44d30732$1@news.langstoeger.at>  _ In article <kesAg.1524$sX.180@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: H >   And my usual "AFAIK" porting refrain follows: there are no plans to L >port OpenVMS to the Intel IA-32, nor to Intel IA-32e, nor to AMD AMD64, ...   You should rephrase it: > There are unfortunately still no plans to...that I'm aware of.   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Fri, 04 Aug 2006 02:49:23 -0400 ' From: Dave Froble <davef@tsoft-inc.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)9 Message-ID: <pZmdnXec8KcWcU_ZnZ2dnUVZ_sydnZ2d@libcom.com>    JF Mezei wrote:   I > So far, HP employees are adament that VMS will not survive the death of D > IA64 since they insist there are no plans to port VMS beyond IA64.  D Either find and post a quote of what you write above, or admit that I you're full of shit.  I've NEVER seen anyone write or say that "VMS will  H not survive the death of IA64".  I don't think you have seen that claim  from HP either.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Fri, 04 Aug 2006 02:52:27 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09), Message-ID: <44D2EE93.CC84ED60@teksavvy.com>   Dave Froble wrote:J > you're full of shit.  I've NEVER seen anyone write or say that "VMS willI > not survive the death of IA64".  I don't think you have seen that claim  > from HP either.   D What does "there are no plans to port VMS" mean to you ?????????????    E If VMS' survival were assured, you'd see statements such as "should a D new platform come along that is better, we would certaintly consider> porting VMS to it". instead of "we have no plans to port VMS".  F Or perhaps "we have not seen a business case yet to port VMS to the 64B bit 8086 or anmy other platform, but should business opportunities* arise, we would port VMS to any platform".    C If you have a large investment in VMS, wouldn't you want to see the C owner make comforting statements that VMS would survive the current  architecture ?  C Note that Windows need not make such statements because there is no G question on the 8086's survival. But for IA64, there are questions from D a wide range of media and customers. So uncertainty would make salesF harder unless HP makes soothing statements that people shouldn't worryO because the operating system will survive any platform change that might occur.     A Of course, HP isn't a software company, so it prefers to milk the @ software to try to help its flagging IA64 sales instead of fullyF leveraging the software by porting it to a platform where there are no questions about its future.    ------------------------------  % Date: Fri, 04 Aug 2006 03:07:51 -0400 ( From: Bill Todd <billtodd@metrocast.net>D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)G Message-ID: <WOWdnY-zu9nab0_ZnZ2dnUVZ_ridnZ2d@metrocastcablevision.com>     Peter 'EPLAN' LANGSTOEGER wrote:a > In article <kesAg.1524$sX.180@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: I >>   And my usual "AFAIK" porting refrain follows: there are no plans to  N >> port OpenVMS to the Intel IA-32, nor to Intel IA-32e, nor to AMD AMD64, ... >  > You should rephrase it: @ > There are unfortunately still no plans to...that I'm aware of.  G That's what AFAIK means, so his phrasing appears adequate as it stands.    - bill   ------------------------------  % Date: Fri, 04 Aug 2006 09:59:09 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)= Message-ID: <44d2fe35$0$67261$157c6196@dreader2.cybercity.dk>    JF Mezei wrote:  > Dave Froble wrote:K >> you're full of shit.  I've NEVER seen anyone write or say that "VMS will J >> not survive the death of IA64".  I don't think you have seen that claim >> from HP either. > F > What does "there are no plans to port VMS" mean to you ????????????? >  > G > If VMS' survival were assured, you'd see statements such as "should a F > new platform come along that is better, we would certaintly consider@ > porting VMS to it". instead of "we have no plans to port VMS". > H > Or perhaps "we have not seen a business case yet to port VMS to the 64D > bit 8086 or anmy other platform, but should business opportunities, > arise, we would port VMS to any platform". >  > E > If you have a large investment in VMS, wouldn't you want to see the E > owner make comforting statements that VMS would survive the current  > architecture ? > E > Note that Windows need not make such statements because there is no I > question on the 8086's survival. But for IA64, there are questions from F > a wide range of media and customers. So uncertainty would make salesH > harder unless HP makes soothing statements that people shouldn't worryQ > because the operating system will survive any platform change that might occur.  >  > C > Of course, HP isn't a software company, so it prefers to milk the B > software to try to help its flagging IA64 sales instead of fullyH > leveraging the software by porting it to a platform where there are no > questions about its future.   D Your whole posting seems based on your assumption that the death of G Itanic is near.  What if it is not so?  What if HP has guaranties from  H Intel that they will not kill it any time soon?  Be sure that if VMS is H moved to AMD64, then some more ISVs will stop supporting VMS.  Suddenly 9 the idea of moving VMS does not look that great any more.   I Intel can keep Itanic alive but not well on a rather small budget.  They  H can simply put more cores and more cache on each chip while raising the H clock frequency, but without designing new cores.  They will still need F design engineers, because you cannot automatically move a design to a L finer semiconductor process, but you will not need a huge team for doing it.   ------------------------------  * Date: Fri, 4 Aug 2006 10:37:33 +0000 (UTC) From: david20@alpha2.mdx.ac.ukD Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09), Message-ID: <eav81d$4ca$1@south.jnrs.ja.net>  \ In article <44D22CB6.C15346F6@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >david20@alpha2.mdx.ac.uk wrote:Q >> But new Vaxes were still being manufactured and sold long after Alpha had come E >> out whereas the Alpha end of sale date is now approaching rapidly.  > F >Yes, but that shows that despite "justa  simple recompile", there areF >many VMS customers who resist platform changes because once they haveC >something that works, they don't want to mess with it and platform  >change is a costly endeavour. > I As I was trying to point out with VAX there was a very very large overlap L period when customers knew that if they needed a new VAX they would still be able to go out and buy it.A With the alpha - itanium transition there isn't any such period.  N Hence if intel want to fit out a new fab after the Alpha end of sale they willM either have to have arranged before hand with HP for some to be available or  < have already purchased them and have them ready and waiting.0 (or chance their arm on the second-hand market).    
 David Webb Security team leader CCSS Middlesex University    G >So if Intel stuck with VAX as long as possible, it is likely they will H >want to stick with their current platform (Alpha) as long as possible.  > E >I wouldn't read anything into the fact that they haven't migrated to  >that IA64 thing.    ------------------------------   Date: 4 Aug 2006 08:19:18 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)3 Message-ID: <fnxX1+S2WEzf@eisner.encompasserve.org>   \ In article <44D2258B.676E3DD8@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > I > So far, HP employees are adament that VMS will not survive the death of D > IA64 since they insist there are no plans to port VMS beyond IA64.      Taht doesn't follow.  FUD.    ------------------------------   Date: 4 Aug 2006 08:20:22 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)3 Message-ID: <YcBOUSZUe7Oa@eisner.encompasserve.org>   c In article <pZmdnXec8KcWcU_ZnZ2dnUVZ_sydnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  > JF Mezei wrote:  > J >> So far, HP employees are adament that VMS will not survive the death ofE >> IA64 since they insist there are no plans to port VMS beyond IA64.  > F > Either find and post a quote of what you write above, or admit that K > you're full of shit.  I've NEVER seen anyone write or say that "VMS will  J > not survive the death of IA64".  I don't think you have seen that claim  > from HP either.   ?    No, he's making an improper deduction from a faulty premise.    ------------------------------   Date: 4 Aug 2006 08:29:03 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)3 Message-ID: <Dvcth4Q5YWC4@eisner.encompasserve.org>   M In article <eav81d$4ca$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:   K > As I was trying to point out with VAX there was a very very large overlap N > period when customers knew that if they needed a new VAX they would still be > able to go out and buy it.C > With the alpha - itanium transition there isn't any such period.  P > Hence if intel want to fit out a new fab after the Alpha end of sale they willO > either have to have arranged before hand with HP for some to be available or  > > have already purchased them and have them ready and waiting.2 > (or chance their arm on the second-hand market).  E    Or do as the rest of us.  I have VAX 11/785 and VAX 4000 that just E    keep on running.  Just installed a replacement UDA on the 785, not 
    a problem.   H    What do I care that neither have been made in years.  I have a coupleF    spare VAX 4000 Model 500 sitting around which I have not yet needed    parts from.  E    We have long range plans to migrate from the 785 to a 4000, all we F    need is a good cheap used Qniverter.  We have no specific plans forG    what we'll do with the excess CPU cycles and RAM (the 785 is hosting B    an application which ran for years on a 780, so we already have    excess CPU cycles and RAM).  G    And that's just on the job.  At home I have a friend who just bought 9    a couple of perfectly good VAX 3300 at excess auction.    ------------------------------   Date: 4 Aug 2006 06:53:07 -0700  From: etmsreec@yahoo.co.ukD Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)B Message-ID: <1154699587.086485.172820@i3g2000cwc.googlegroups.com>  G As you missed in the reference from Hoff, 8086 isn't a platform that is 6 still current.  It died in favour of the present IA32.  A You'd be pushed to get Windows in the 1MB of memory that the 8086 
 provided for.   E Still, you can lead a horse to water but you can't make it learn that  8086 is long gone.   JF Mezei wrote:  > Dave Froble wrote:L > > you're full of shit.  I've NEVER seen anyone write or say that "VMS willK > > not survive the death of IA64".  I don't think you have seen that claim  > > from HP either.  > F > What does "there are no plans to port VMS" mean to you ????????????? >  > G > If VMS' survival were assured, you'd see statements such as "should a F > new platform come along that is better, we would certaintly consider@ > porting VMS to it". instead of "we have no plans to port VMS". > H > Or perhaps "we have not seen a business case yet to port VMS to the 64D > bit 8086 or anmy other platform, but should business opportunities, > arise, we would port VMS to any platform". >  > E > If you have a large investment in VMS, wouldn't you want to see the E > owner make comforting statements that VMS would survive the current  > architecture ? > E > Note that Windows need not make such statements because there is no I > question on the 8086's survival. But for IA64, there are questions from F > a wide range of media and customers. So uncertainty would make salesH > harder unless HP makes soothing statements that people shouldn't worryQ > because the operating system will survive any platform change that might occur.  >  > C > Of course, HP isn't a software company, so it prefers to milk the B > software to try to help its flagging IA64 sales instead of fullyH > leveraging the software by porting it to a platform where there are no > questions about its future.    ------------------------------  % Date: Fri, 04 Aug 2006 12:55:52 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09), Message-ID: <44D37C15.F46EBDC6@teksavvy.com>   Karsten Nyblad wrote: E > Your whole posting seems based on your assumption that the death of H > Itanic is near.  What if it is not so?  What if HP has guaranties from2 > Intel that they will not kill it any time soon?   H You forget the IDG study which HP posted on its web site which mentionedD that IA64 will cause HP to lose roughly 30% or its  "serious" server! installed base (HP-UX, NSK, VMS).   E If HP is willing to post just a bad news on its own web site, what is  the REAL number ?   A Announcing the port to the 8086 NOW would send a strong signal to E customers that they can stay on PaRisc and Alpha for an extra year or I two and then make one move to a platform whose future is not in question.        > Be sure that if VMS isI > moved to AMD64, then some more ISVs will stop supporting VMS.  Suddenly ; > the idea of moving VMS does not look that great any more.     G Au contraire. By moving VMS to a mainstream platforms, VMS will benefit F from much of the marketing HP makes, and HP will not have any problemsF marketing VMS because a VMS sale will generate a 8086 sale and that isA the real metric by which HP is measured by the wall street casino G analysts.  And with VMS on a mainstream platform whose future in not in F question, ISVs will be far more likely to invest in VMS now especially? since it would be a port that would last a very long long time.   D > Intel can keep Itanic alive but not well on a rather small budget.  C HP can keep Alpha alive and well on a smaller budget and retain its 4 installed base without losing that 30% of customers.    H Neither options are valid if you wish to give growth opportunities. IA64G is being trumped by the 8086 and of course Power.  When Intel saw AMD's G market sharte climb, it scrambled to quicken the pace of development of : its now current generation of 8086s in order to catch up.   F IA64 shows no signs of having its development quickened. If at all, itH appears to be slowing down. Not the sign of a platform with a future and# certaintly not strategic to Intel.    D I would say that IA64 is today where Alpha was on june 26 2001: someF contract that forces intel to still generate X number of iterations ofD the IA64 chip with very little defining what each new iteration must bring to marklet.          >  They I > can simply put more cores and more cache on each chip while raising the 4 > clock frequency, but without designing new cores.   C Which is what they have already been doing, and reducing/delaying a ) number of new features in each iteration.   F Do you really want VMS to be stuck on a chip that is consistently lateG to market compared to the competition ? When you consider that the last G remaining market that VMS is allowed to play in is the high performance D once, having VMS confined to a chip that is inferior to IBM's and inB some respects, inferior to Sun's doesn't exactly give VMS a boost.    H The chip should be an asset to help boost VMS sales. IA64 is a liability	 to VMS.       H Consider the potential for VMS to grow if it were available on the 8086.D From small to very large systems, ability to once again re-enter theC small/medium business market with a rock solid dependable operating  system with full support.    ------------------------------   Date: 4 Aug 2006 10:08:31 -0700  From: etmsreec@yahoo.co.ukD Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)C Message-ID: <1154711311.430272.322650@h48g2000cwc.googlegroups.com>    JF Mezei wrote:  > J > Neither options are valid if you wish to give growth opportunities. IA64I > is being trumped by the 8086 and of course Power.  When Intel saw AMD's I > market sharte climb, it scrambled to quicken the pace of development of ; > its now current generation of 8086s in order to catch up.  > E About that leading a horse to water but not making it understand IA32  vs. 8086...?     > H > Do you really want VMS to be stuck on a chip that is consistently lateI > to market compared to the competition ? When you consider that the last I > remaining market that VMS is allowed to play in is the high performance F > once, having VMS confined to a chip that is inferior to IBM's and inD > some respects, inferior to Sun's doesn't exactly give VMS a boost. >   3 So Alpha has always been on time then?  News to me!    ------------------------------  % Date: Fri, 04 Aug 2006 13:14:00 -0400 ' From: Dave Froble <davef@tsoft-inc.com> D Subject: Re: OpenVMS, Alpha still rule roost in Intel fabs (2005-09)9 Message-ID: <86Odnd2WVttu407ZnZ2dnUVZ_v6dnZ2d@libcom.com>    JF Mezei wrote:  > Dave Froble wrote:K >> you're full of shit.  I've NEVER seen anyone write or say that "VMS will J >> not survive the death of IA64".  I don't think you have seen that claim >> from HP either. > F > What does "there are no plans to port VMS" mean to you ?????????????  C Exactly what it says.  "No plans."  But the future is yet unknown.  H Plans could be made.  Such as in the event of an announcement of EOL of A the itanic.  In such an event, plans could then be made.  Or not.   G > If VMS' survival were assured, you'd see statements such as "should a F > new platform come along that is better, we would certaintly consider@ > porting VMS to it". instead of "we have no plans to port VMS".  / 'Consider' and 'plan' are two different things.   H > Or perhaps "we have not seen a business case yet to port VMS to the 64D > bit 8086 or anmy other platform, but should business opportunities, > arise, we would port VMS to any platform".  G Yeah, well I think that such has already been said, or at least hinted  I at.  You offering HP several hundred million bucks might be considered a   business opportunity.  :-)  E > If you have a large investment in VMS, wouldn't you want to see the E > owner make comforting statements that VMS would survive the current  > architecture ?  I I'd want to still see VAX and Alpha based products.  What I want doesn't   matter.   E > Note that Windows need not make such statements because there is no " > question on the 8086's survival.  C Intel had a question.  But they didn't like the answer, AMD64.  :-)   ( > But for IA64, there are questions fromF > a wide range of media and customers. So uncertainty would make salesH > harder unless HP makes soothing statements that people shouldn't worryQ > because the operating system will survive any platform change that might occur.  >  > C > Of course, HP isn't a software company, so it prefers to milk the B > software to try to help its flagging IA64 sales instead of fullyH > leveraging the software by porting it to a platform where there are no > questions about its future.      --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  * Date: Fri, 4 Aug 2006 10:51:38 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda). Subject: Re: PIPE redirection as stream file ?2 Message-ID: <06080410513844_2027368D@antinode.org>  C    This may have been mentioned before, so I apologize for any time  wasted.   F    I see in the "HP OpenVMS Version 8.2 New Features and Documentation	 Overview" R ("http://h71000.www7.hp.com/doc/82FINAL/6675/6675pro_002.html#crtl_unix_pipe_sec")F that there's a new C RTL feature switch, DECC$STREAM_PIPE, which seems3 to be (at least vaguely) related to this complaint.   F    Could a new SET PROCESS qualifier ("/[NO]STREAM_PIPE"?) be added toG get this sort of behavior in a more general DCL context?  (Or would too % much of the OS need to be rewritten?)   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------   Date: 4 Aug 2006 06:31:14 -0700 ( From: "geletine" <adaviscg1@hotmail.com>" Subject: Re: Speaking of Clusters:C Message-ID: <1154698274.404587.194710@p79g2000cwp.googlegroups.com>   D Its no brainer that Google runs linux clusters in order to cope withG the large amount of data that is accessed, Beowulf as many may know has C been around a long time. Also to note their is MOSIXand openMosix , F dragonflyBSD is BSD focused on clusterting that is developing . I have1 not mentioned all of the linux cluster solutions.   B To make my point, there are clusters besides vms clusters that are% deployed in a production environment. E Vaxcluster came to commercial market in 1984, not the first operating E system to use clusters but the first successful commercial cluster no  doubt.   ------------------------------  * Date: Fri, 4 Aug 2006 14:18:13 +0000 (UTC) From: david20@alpha2.mdx.ac.uk" Subject: Re: Speaking of Clusters:, Message-ID: <eavkv5$8b7$1@south.jnrs.ja.net>  n In article <1154698274.404587.194710@p79g2000cwp.googlegroups.com>, "geletine" <adaviscg1@hotmail.com> writes:E >Its no brainer that Google runs linux clusters in order to cope with H >the large amount of data that is accessed, Beowulf as many may know hasD >been around a long time. Also to note their is MOSIXand openMosix ,G >dragonflyBSD is BSD focused on clusterting that is developing . I have 2 >not mentioned all of the linux cluster solutions. > C >To make my point, there are clusters besides vms clusters that are & >deployed in a production environment.F >Vaxcluster came to commercial market in 1984, not the first operatingF >system to use clusters but the first successful commercial cluster no >doubt.  >   - The term cluster has many different meanings.   G Beowulf is a HPC (High Performance Computing) cluster ie making use of  + multiple CPUs to run parallel computations. 9 This is not the same as a HA (High availability) cluster.   @ I'm not familiar with MOSIX and openMOSIX but they to look to be HPC cluster solutions.          
 David Webb Security team leader CCSS Middlesex University   ------------------------------  % Date: Fri, 04 Aug 2006 11:28:33 -0400 ( From: Bill Todd <billtodd@metrocast.net>" Subject: Re: Speaking of Clusters:G Message-ID: <Hpadnd5Wrvw--k7ZnZ2dnUVZ_tSdnZ2d@metrocastcablevision.com>    david20@alpha2.mdx.ac.uk wrote: p > In article <1154698274.404587.194710@p79g2000cwp.googlegroups.com>, "geletine" <adaviscg1@hotmail.com> writes:G >> Its no brainer that Google runs linux clusters in order to cope with J >> the large amount of data that is accessed, Beowulf as many may know hasF >> been around a long time. Also to note their is MOSIXand openMosix ,I >> dragonflyBSD is BSD focused on clusterting that is developing . I have 4 >> not mentioned all of the linux cluster solutions. >>E >> To make my point, there are clusters besides vms clusters that are ( >> deployed in a production environment.H >> Vaxcluster came to commercial market in 1984, not the first operatingH >> system to use clusters but the first successful commercial cluster no	 >> doubt.  >> > / > The term cluster has many different meanings.  > I > Beowulf is a HPC (High Performance Computing) cluster ie making use of  - > multiple CPUs to run parallel computations. ; > This is not the same as a HA (High availability) cluster.   I Google clustering is their own creation, not Beowulf-based.  It provides  I both high performance and high availability (though the latter optimized  I for a read-mostly context, which makes it easier).  Most Unix clustering  I mechanisms also provide high availability and at least somewhat scalable   performance.  H VMS offers the most mature clustering facilities of anyone, but some of E the underlying technology (such as the file system) is so antiquated  H that it no longer necessarily offers the best-performing clustering (at G least at small scale:  it still may scale up better than most others).  G It also no longer enjoys any significant availability edge (though may  A continue to provide more flexible options in this area than most  D others).  zOS (on Parallel Sysplex), AIX, and of course Tru64 (RIP) I support concurrently-shared storage devices in addition to fail-overable  7 storage, so in those cases VMS enjoys fewer advantages.   H That's what happens when an OS stagnates while the competition doesn't. E   It's a real shame and in no way the fault of those who continue to  D develop it, who perform admirably under adverse circumstances (save B perhaps when they divert their energies in attempts to defend the ' situation that they've been placed in).    - bill   ------------------------------  % Date: Fri, 04 Aug 2006 19:46:32 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> " Subject: Re: Speaking of Clusters:: Message-ID: <3f69c$44d387fa$50db5015$9477@news.hispeed.ch>   JF Mezei wrote:   H > A bank cannot afford such an architecture because when a bank employeeH > pulls up your records, it needs to know it has gotten the FULL record, > not just selective ones. >   F Banks _do_ have windows when certain functions go offline, mainly for I housekeeping  purposes, but sometimes for what appear to be glitches too.   E  From experience, in the early hours or at weekends I have sometimes  C found that an ATM might have several of the menu options listed as   unavailable.  F For example, you might be able to withdraw cash, but not make account E transfers; or just execute transactions internal to the bank but not   external ones.   ------------------------------   Date: 4 Aug 2006 08:17:14 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) # Subject: USB numeric keypad anyone? 3 Message-ID: <6aLpaquctZEo@eisner.encompasserve.org>   H    My IBM T41 laptop has a nasty feature:  to get the numeric keypad youG    have to hit shift-numlock and to get out you have to hit both again. H    Compare this to my Dell which simply required holding a function key.  E    When working with VMS this is a royal pain.  I've seen USB keypads E    now in stores, featuring the full set of PC style numeric keys and -    am wondering if it's worth the investment.   D    Has anyone tried one of these keypads with any of the VT terminal$    emulators for PCs?  Any feedback?  G    Unfortunately I haven't seen one with a full LK style keypad layout, E    the last time I saw one of those it was on an ADB cable for a Mac.    ------------------------------  % Date: Fri, 04 Aug 2006 08:42:48 -0500 7 From: Staffan Tjernstrom <news@staffan.tjernstrom.name> ' Subject: Re: USB numeric keypad anyone? O Message-ID: <1154698968.24667.5.camel@linspiron.mobile.staffan.tjernstrom.name>   5 On Fri, 2006-08-04 at 08:17 -0500, Bob Koehler wrote: G >    When working with VMS this is a royal pain.  I've seen USB keypads G >    now in stores, featuring the full set of PC style numeric keys and / >    am wondering if it's worth the investment.  > F >    Has anyone tried one of these keypads with any of the VT terminal& >    emulators for PCs?  Any feedback? > A I've used the Targus PAUK001 for a little over a year with a Dell H Inspiron 8200 and Reflection v10 (X & VT), and it's worked about as well" as any non-LK solution has for me.  H The problem I've found with any non-LK solution is that PC num-locks (ieH Gold/PF1) are typically stateful keys (either on or off), so in order toE get the right effect in eg TPU/EVE/LSE you sometimes end up having to + hit num-lock twice to get the right effect.   F Not ideal, but if you don't have the option of carrying an external egF LK461 around (my preferred solution), then it's certainly a lot betterH than nothing at all. At least my debug fingers know their way around the keypad.    ------------------------------  # Date: Fri, 04 Aug 2006 17:04:26 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>' Subject: Re: USB numeric keypad anyone? 1 Message-ID: <u6LAg.1565$Pm1.730@news.cpqcorp.net>    Staffan Tjernstrom wrote:   < > ...if you don't have the option of carrying an external egH > LK461 around (my preferred solution), then it's certainly a lot better > than nothing at all...  G    The LK463 is USB, FWIW.  Rather bigger than just a keypad, but also  H rather more familiar to those of us with our fingers programmed for the  LK-style keyboard.   ------------------------------   End of INFO-VAX 2006.431 ************************                                                                                                                                                                                                                                                                                                                                    RS@K|-@l-_'!3 1/_%Sw>@^LdH-k!S6jRv*{i)ܲ;
$]rfbu/YHhTCBBb0a2B0ir)g9bJ6?
Yu<ҩGkyJɧ/ 
؃5*}}K:	.ξ֧("CRhAfF(@yTZ,W**##~^жF- YXTyv!
@;v@g!+
TH!tV\lb8sM2+EHO/v!jE[e#hk)뇋ʵ6e;o%	C5'O
KKh7|k
j5uyO	6b}1xU24)QC,xB_gv\Yt48YUPR/x71&]fmHV[=jSH)ᡍWi2I55D̺K2x{PQiE"@7uAխ<Bc}:<8J4'7u.T(y8  ㊽s \opb{ʦԂU;qŚ+VR/<}nu]]ⓂP_ǿ'8'ܧšA^BopqBGP$)MkRbVAjՕY<w0/e
7\_˰&PBQ>ր>
\Ft̔䀅ϘM48ӍuOL" w1 *!ab[M@<#_C?(I^qɿJ3!!&w)߭I0Te3WWQ%pT.1x$/1OzG ,3 eF"Ժ	ćl4}Jˇ˙C1/mcg3T/cj
CݎYޥm=j1g/DěcaZ	Gy?ϸTGu_6n$oG&`fA`VC+]`_CCscҵo>dXmY[XќJekiF3&R>beVPq7|OH!udW6OwIh
iT8TXqJnoxةr0*Ui6U]LcJO!A|0VR2C~:|(v줣#D?R"3
ڱА%QϏֆfaZBUX6|Q>wliƗ*44qKnQ2xZOJ݋R;;25#ۓi
^:kw, 0\TyGr@@6$B	\7f4`brX!b,y>)SYpa-BӺaravmƒtL$SKŭaR5|d{!}zSFSz.ݱ74wmS<lжy߰>(T2L0/$Ί/1KHAM4ߒcPMQQs!DQu9Xfu%Yj\i9skp8`A$~9JQ( pJГB';KvL
Y&y!reEm'pCiʻmٿg` mG0\?#O|4v$&CP;N>j\bq2>Ŝ+CW)qNΠ"V 6!jC"<R4=
 QR޷ޝ 
(8^g
Cl	{xA⤲]i»j!{zR2F%|0&\hGouH;P=l$*aR[
}Y}
p`
1-`gHV7I0@>} tNP(kx\!bj?͟
?IS r`p:)v)8t
"Ѷ}\xʓ[atVMDe<KM`ۥ'
j뵚`k{ @Z,`
75 ~
=)4$ΤhRm&k{Cxc-~Q*m\&{blVn >`afD@FZ~e}/7G+21K6ww+=9떅$c#*3cll{±w*aKņkCoȬZEǾx0O.+'K#3tc ]گ5tasӶOCPV:ѱuzd\%A$7*wAuBrwcvuH}hLIf^pb<}
(A"niQ5x_M4"
qS-A³q^/
>