1 INFO-VAX	Tue, 19 Dec 2006	Volume 2006 : Issue 696       Contents:? Re: Accessing an Alpha running DECwindows from a Windows XP box ! Re: An example of a backup oddity ! Re: An example of a backup oddity ! Re: An example of a backup oddity ! Re: An example of a backup oddity ! Re: An example of a backup oddity ! Re: An example of a backup oddity ? Re: BACKUP questions  (cache, DVD and multiple container files)  Re: Bad Shadow set member # Re: Problem with HSJ50 Disk device. 
 Re: thank you  RE: The Evil within! Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic RE: The Hole in Cerner's Logic RE: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: The Hole in Cerner's Logic Re: VMS$AUDIT_SERVER.DAT  F ----------------------------------------------------------------------  % Date: Tue, 19 Dec 2006 00:27:19 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>H Subject: Re: Accessing an Alpha running DECwindows from a Windows XP box7 Message-ID: <51327$45877857$cef8887a$4740@TEKSAVVY.COM>    Gremlin wrote:/ > That is what I'm doing - just very inelegant!   H If you ave an XDM process running, then you need to look inside the XDM H directory (I suspect [sys$sysdevice:[SYS0.TCPIP$XDM]  and then read the : TCPIP Services management manual chapter on the XDM setup.  K You can setup the XAXCCESS.TXT file to contain specific hosts to be served  
 by this host.   I And you can setyp the other files that are more generic, but you need to  E setup some of the MIT cookie keys on the more recent versions of XDM.   K Make sure you download the Manager Manual that is equial to or inferior to  I the version of software you are running. If you have a doc that is older  = than the version, then you need to look at the release notes.    ------------------------------    Date: 18 Dec 2006 14:46:04 -0800' From: "bclaremont" <msi1@earthlink.net> * Subject: Re: An example of a backup oddityC Message-ID: <1166481964.234858.277850@n67g2000cwd.googlegroups.com>   ! I think what you wanted was this:   . $BACKUP/LOG SOURCE:[000000...]*.*  [.NEWS*...]   ------------------------------    Date: 18 Dec 2006 17:06:05 -0800$ From: "AEF" <spamsink2001@yahoo.com>* Subject: Re: An example of a backup oddityB Message-ID: <1166490365.286193.206860@f1g2000cwa.googlegroups.com>   JF Mezei wrote: G > There was some discussion in the past where most said that backup had % > very logical and correct behaviour.  >  > 1 > Here is an example of not so obvious behaviour:  > B > $define/trans=(conc,term) source $disk2:[rebuild.<mumble>.NEWS.]  C This couldn't have worked as logical translation would have stopped F with the first translation of SOURCE since you specified term. Without term it should work.   > 5 > $SET DEF USRDIR:[JFMEZEI._MOZILLA.DEFAULT.<mumble>]  > / > $BACKUP/LOG SOURCE:[000000...]*.*  [.NEWS...]  > I > Expectation was that it could recreate the hiearchy contained in source F > under the .NEWS directory. Instead, BACKUP created everything in theG > [.NEWS] subdirectory. (the original has 3 directories under which are G > definitions applicable to each news server). Backyup did create the 3 P > directories in the source hiearchy, but it did not populate those directories.  F Yep, it's a bug. And my experiments (on a my VAX/VMS V6.2 test system)E showed that the fact that it's a concealed rooted device (or whatever D the official terminology is) doesn't matter. Using [*...] instead ofA [000000...] would have worked except that it wouldn't have copied $ anything in [rebuild.<mumble>.news].  ? COPY works correctly except that you have to have the top level E existing beforehand. One problem with copy is that if your input is a E physical disk with [000000...], COPY will try to copy the *.SYS files 5 whereas BACKUP skips all of them except SECURITY.SYS.    > F > Quite the mess to clean up now because there were valid files in theF > target [.news] directory so I can't delete everything and start from > scratch again.  E Well, we didn't say there aren't any bugs. Your problem is the result D of a bug in BACKUP, not a problem with the ellipsis wildcard per se.F Either backup is throwing away 000000. or it is treating [000000] as a top-level directory.     AEF    ------------------------------    Date: 18 Dec 2006 17:14:49 -0800$ From: "AEF" <spamsink2001@yahoo.com>* Subject: Re: An example of a backup oddityC Message-ID: <1166490889.238579.254470@l12g2000cwl.googlegroups.com>   
 AEF wrote: > JF Mezei wrote: I > > There was some discussion in the past where most said that backup had ' > > very logical and correct behaviour.  > >  > > 3 > > Here is an example of not so obvious behaviour:  > > D > > $define/trans=(conc,term) source $disk2:[rebuild.<mumble>.NEWS.] > E > This couldn't have worked as logical translation would have stopped H > with the first translation of SOURCE since you specified term. Without > term it should work. >  > > 7 > > $SET DEF USRDIR:[JFMEZEI._MOZILLA.DEFAULT.<mumble>]  > > 1 > > $BACKUP/LOG SOURCE:[000000...]*.*  [.NEWS...]  > > K > > Expectation was that it could recreate the hiearchy contained in source H > > under the .NEWS directory. Instead, BACKUP created everything in theI > > [.NEWS] subdirectory. (the original has 3 directories under which are I > > definitions applicable to each news server). Backyup did create the 3 R > > directories in the source hiearchy, but it did not populate those directories. > H > Yep, it's a bug. And my experiments (on a my VAX/VMS V6.2 test system)G > showed that the fact that it's a concealed rooted device (or whatever F > the official terminology is) doesn't matter. Using [*...] instead ofC > [000000...] would have worked except that it wouldn't have copied & > anything in [rebuild.<mumble>.news].   make that "anything from..."   > A > COPY works correctly except that you have to have the top level G > existing beforehand. One problem with copy is that if your input is a G > physical disk with [000000...], COPY will try to copy the *.SYS files 7 > whereas BACKUP skips all of them except SECURITY.SYS.  >  > > H > > Quite the mess to clean up now because there were valid files in theH > > target [.news] directory so I can't delete everything and start from > > scratch again. > G > Well, we didn't say there aren't any bugs. Your problem is the result F > of a bug in BACKUP, not a problem with the ellipsis wildcard per se.H > Either backup is throwing away 000000. or it is treating [000000] as a > top-level directory.  E I meant top-level as in first level, as in [TOP], not "MFD level", or  "root level".    >  > AEF    ------------------------------  % Date: Tue, 19 Dec 2006 00:08:18 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>* Subject: Re: An example of a backup oddity8 Message-ID: <7ecf9$458773e2$cef8887a$12824@TEKSAVVY.COM>   Another example:  > $ backup/log $disk7:[000000...]*.*;* $disk4:[bike1...]/by=orig   It creates [bike1]allin1.dir  @ But instead of creating [bike1.allin1]admin_data.dir it creates  [bike1]admin_data.dir   I I stopped it as soon as I noticed. However, the files in admin_data were  G created under the admin_data directory. So backup seems to flatten the   structure by one level.   E There really should be some good documentation on exactly how backup  I handles disk to disk copies with the target specifications and hierarchy  	 handling.    ------------------------------  % Date: Tue, 19 Dec 2006 01:17:05 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>* Subject: Re: An example of a backup oddity8 Message-ID: <38419$45878402$cef8887a$24043@TEKSAVVY.COM>   Damned !  & My previous enthousiasm was misplaced.D $ backup/log/ignore=nobackup $disk7:[000000...]*.*;* [*...]*.*;*/log   DID NOT WORK !  K This does not recreate the source hiearchy below where you are. It created  & it from the root of your current disk.    / But I think I have *finally* found my solution:     4 $define/trans=(conc,term)  LOCATION $2$DQA0:[BIKE1.]  7 $ backup/log/ignore=nobackup $disk7:[000000...]*.*;*  -         location:[*...]*.*;*/log      Results in something like:F %BACKUP-S-CREATED, created LOCATION:[ALLIN1.ADMIN_DATA]ZUIIWHEZ8.DAT;1  I and fileview confirms that the files are being created under the [bike1]  
 subdirectory.    ------------------------------  % Date: Tue, 19 Dec 2006 01:01:06 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>* Subject: Re: An example of a backup oddity7 Message-ID: <716e8$45878044$cef8887a$6686@TEKSAVVY.COM>   I Eureka ! After much time spent with trial and error, I finally found the  A magic incantation of BACKUP needed to do a very simple operation.   D $ backup/log/ignore=nobackup $disk7:[000000...]*.*;* [*...]*.*;*/log  I with the default directory being where one wants to see the tree located.    aka:  8 set def $disk4:[bike1] and then issue the above command.  K On a MAC, I would have clicked on the drive icon, and then just dragged it  G into the derired folder destination and not have to worry about backup  K deciding to forego one level of directories because the instinctive BACKUP   syntax doesn't actually work.     K BTW, my 10 disk brisk, is currently precariously perched on top of a naked  F vaxstation 3100. Note to the Vaxstation 3100 engineers: make the SCSI  cables inside a bit longer :-).   = On the 3100, the console showed the drive as being 500 megs !     >> show dev@   VMS/VMB  ULTRIX    ADDR    DEVTYP  NUMBYTES  RM/FX  WP  DEVNAM@   -------  ------  --------  ------  --------  -----  --  ------$   ESA0     SE0     08-00-2B-11-1F-81  >   DUA2     RX2               DISK               RM        RX23  A   DKA200   RZ2     A/2/0/00  DISK     1.05 GB   FX        ST31055 A   DKA500   RZ5     A/5/0/00  DISK      500 MB   FX        SX91080 "   ...HostID....    A/6       INITR    L (and the tests generate a ? for the scsi test). But so far, backup has been O able to extract data from this drive (last used a little less than a year ago).    ------------------------------  % Date: Mon, 18 Dec 2006 23:04:51 +0100 4 From: Jur van der Burg <"vdburg at hotmail dot com">H Subject: Re: BACKUP questions  (cache, DVD and multiple container files)4 Message-ID: <45871089$0$323$e4fe514c@news.xs4all.nl>  ? Well, LDdriver V9.0 (now in fieldtest) has a virtual magtape so I that you can do a BACKUP *.* LMA1:SAVESET/SAVE where the tape is actually G a file on disk. No production quality yet, but ok for test. It supports  volume switching as well.   @ I'll probably put up a new fieldtest release sometime next week.   Jur.     JF Mezei wrote:  > Eberhard Heuser wrote:I >> 1. create a volume set of logical disks, each with the size of 4,3 GB. B >> Do a backup, dismount the volume set and burn each logical disk >> separetely. >  > G > Oh my ! do I detect a modern use of bound volumes ?  So for a 30 gig  K > full drive, I create 7 4,3 gig files, then use LD driver to map 7 drives  
 > to it, :G > then MOUNT/BIND=MYBACKUP LDA1:,LDA2:,LDA3:,LDA4:,LDA5:,LDA6:,LDA7 etc  > J > Then I backup to the bound volume set. Ingenious idea. But aren't bound C > volumes to be avoided ? Seems they are not recommended. And this  K > requires a disk of identical size as the first one (or bigger) to act as   > a staging area.  > C > Didn't backup have capabilities to write to multiple volumes for  0 > removable disks (RA60s and earlier RL08 etc) ? > C > What would be neat would be a way for BACKUP/IMAGE mydisk:  LDA1:  > E > and once it has filled LDA1, it behaves as for tapes, asks for new  I > volume to be mounted, and you would then have the ability to map LDA1:  J > to a new file, let backup continue. While it fills the second file, you C > can write the first file to the DVD.  This way, you could backup  > > terabytes with only 2  4,3gig files to stage the DVD images.   ------------------------------  % Date: Mon, 18 Dec 2006 17:00:17 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>" Subject: Re: Bad Shadow set member8 Message-ID: <12dbd$45870f91$cef8887a$14470@TEKSAVVY.COM>  / Phillip Helbig---remove CLOTHES to reply wrote: I > For example, consider two members with each having a direct connection  G > to only one node.  Node A fails, thus B is the shadow master.  Now B  K > fails.  Now A comes back up, and A becomes the new master.  When B comes  J > up, its disk gets overwritten, thus data created after the failure of A $ > before it comes back up gets lost.  J Very correct. You need written procedures for operators to follow in this L case.  And you may have to involve the end user who owns the data to make a H decision. Ideally, you need to wait until B is fixed and back up before  making A active again.  F In the case of SWIFT software for instance, the use might decide that I bringing up A  ASAP is better than waiting for B to come back up because  G you really need to send transactions out ASAP.  They will then have to  J reconciliate the missing transactions. (A may go from 1 to 1000, and then G jump to 1300 to 2000, so they know that transactions 1001 to 1299 were  ' processed by B and not reloaded onto A.   J In the case of SWIFT, they could request a certain number of transactions H to be retransmitted on the same day. But they would have to ensure that H they aren't processe twice in-house (eg: processed while B was up and A 0 down, and processed again during retransmittal).  H You could theoretically also bring B back up outside of the cluster and / then access those transactions that only B has.    ------------------------------    Date: 18 Dec 2006 11:14:55 -0800 From: mckinneyj@saic.com, Subject: Re: Problem with HSJ50 Disk device.B Message-ID: <1166469294.981496.294770@73g2000cwn.googlegroups.com>  # dave.baxter@bannerhealth.com wrote: B > I have a 9GB hard drive in my disk storage (HSJ50's, CI CLuster,G > OpenVMS 7.2-1) which has ended up write-locked (I have no idea how.).  >  > vis; > % > AXPA$SYSMGR>> mount $1$dua2: path44 , > %MOUNT-I-WRITELOCK, volume is write locked8 > %MOUNT-I-MOUNTED, PATH44 mounted on _$1$DUA2: (HSJ500) > ' > AXPA$SYSMGR>> show dev /full $1$dua2:  > G > Disk $1$DUA2: (HSJ500), device type MSCP served SCSI disk, is online,  > allocated,= >     deallocate on dismount, mounted, software write-locked,  > file-oriented I >     device, shareable, served to cluster via MSCP Server, error logging  > is >     enabled. > ! > AXPA$SYSMGR>> dismount $1$dua2: " > AXPA$SYSMGR>> init $1$dua2: temp# > %INIT-F-WRITLCK, write lock error  > AXPA$SYSMGR>>  > I > clearly this device is software write-lockied.     The question is "How  > do I remove the write-lock??"  > I > The disk is an RZ40-VA.    Do these devices have a "write-lock" switch? H >  (I'm not aware of any).  At the controller level, it looks like this; >  > HSJ50_0> show d23 > MSCP unit                                    Uses @ > --------------------------------------------------------------6 >   D2                                         DISK120 >         Switches: D >           RUN                    NOWRITE_PROTECT        READ_CACHE >           NOWRITEBACK_CACHE - >           MAXIMUM_CACHED_TRANSFER_SIZE = 32  >         State: >           AVAILABLE  >           No exclusive access  >           NOPREFERRED_PATH! >           WRITE_PROTECT - DRIVE  >         Size: 17769177 blocks 
 > HSJ50_0> > = > I have never seen the "WRITE_PROTECT - DRIVE" entry before.  > & > All suggestions greatfully received. >  > Dave.   C Interesting that the state is WRITE_PROTECT and the configuation is  NOWRITE_PROTECT.  F Never had occasion to use it, but, many of the HSx controllers support< "SET unit {NO}WRITE_PROTECT" commands. You might try "SET D2C NOWRITE_PROTECT" and see if the state changes. I have no idea why a 9 unit might enter this state without operator instruction.    ------------------------------    Date: 18 Dec 2006 14:46:05 -0800) From: "DaveG" <david.gudewicz@abbott.com>  Subject: Re: thank youC Message-ID: <1166481964.900687.232870@j72g2000cwa.googlegroups.com>   
 Sue wrote: > Dear Newsgroup,  > G > I just sent this and now wanted to post it hear since you are also so  > important to me. > 
 > Big hug, > sue  > # > Distribution lists (Dear Friends)  > I > At this time of the year I always like to take some time to think about I > all the reasons I have to be thankful and there are so many.  But I can I > honestly say after 21 years at the same company (sort of) to still wake H > up in the morning and to be happy to go to work is a huge reason to be > happy. > D > My dear friends I know most of you personally.  You are an amazingC > group of folks that every day surprises me in one way or another. F > Normally, it's by your loyalty to OpenVMS and you show that, usuallyF > by helping each other or by getting upset when you feel we have beenG > slighted, and sometimes it's by sending me information or a very cool @ > tidbit about VMS. Thank you for making my days so interesting. > D > Those of you who have been to an awards dinner know that one of my7 > favorite sayings is from Martin Luther King which is; H > "...the ultimate measure of a man is not where he stands in moments ofG > convenience and moments of comfort, but where he stands in moments of F > challenge and moments of controversy."  These are extremely powerfulD > words, it's easy to be friends and stick together when there is noH > challenge the true test is where you will be when hardship comes.  YouH > who are Customers and Partners have stuck with us through two mergers,H > 7 CEO's, 3 architectures and countless rumors of our demise. Thank youI > for your loyalty and courage  The internal folks you have done all that C > in addition to deal with all the internal family things and still @ > manage to deliver an amazingly elegant Operating System.  I amF > privileged and honored to work with and for you every day. Thank you4 > all for letting me have the best job in the world. > H > We have so many new and exciting things to look forward to in 2007 and$ > I look forward to working with you >  > Warm regards as always,  >  > Sue Skonetski   C Many thanks to you Sue for all you've managed to do for the OpenVMS  community over the past year/s.   @ And here's wishing you and yours a very Happy and Joyous Holiday Season.    Dave...    ------------------------------  % Date: Mon, 18 Dec 2006 20:27:10 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com>  Subject: RE: The Evil within! T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401F189B6@tayexc19.americas.cpqcorp.net>   > -----Original Message-----? > From: prep@prep.synonet.com [mailto:prep@prep.synonet.com]=20 " > Sent: December 17, 2006 11:39 AM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: The Evil within!  >=20@ > "Barratt, Chris \(FMC\)" <Chris.Barratt@fmc.sa.gov.au> writes: >=20< > > P.S. If any other VMS-based hospitals were interested inG > > joint-development in some sort of open-source arrangement, I'm sure A > > we would be interested in hearing from you to discuss what is 
 > > possible.  >=20D > Serveral hospitals used to run on VMS back when, Illawarra Region,= > RNS, RPH, and lots more I'm sure. Plus all the MUMPS sites.  >=20 > --=20 > > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda. B >                                              West Australia 6076  H Many health and hospital org's run OpenVMS with numerous different app's today.     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: 18 Dec 2006 12:58:16 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ' Subject: Re: The Hole in Cerner's Logic 3 Message-ID: <gcG8kVdtI0l4@eisner.encompasserve.org>   [ In article <4unu35F18d5l3U2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > G > Dream on.  They actively teach Windows at every level from Private to 
 > Colonel. [...]   E    They actively teach you what they want you to know.  Do they teach C    you what's on that 707-based electronic surveillance plane?  How C    about the bomb control circuitry of a B1?  I doubt it, you don't     have a need to know.   B    They teach some things to just about everybody (everyone in theC    Army is supposed to know how to fire a rifle).  They teach other D    things to only those who need to know (very few pilots in the Air,    Force were ever checked out in an SR-71).  $    And I'm only stating the obvious.   ------------------------------   Date: 18 Dec 2006 19:42:12 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4uo98kF18astkU1@mid.individual.net>  3 In article <gcG8kVdtI0l4@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:] > In article <4unu35F18d5l3U2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  >>  H >> Dream on.  They actively teach Windows at every level from Private to >> Colonel.  > [...]  > G >    They actively teach you what they want you to know.  Do they teach E >    you what's on that 707-based electronic surveillance plane?  How E >    about the bomb control circuitry of a B1?  I doubt it, you don't  >    have a need to know.   H Of course not.  I don't have to maintain it.  But the statement was thatF "The Military" was one of VMS's biggest customers.  Well, that 707  (IH assume you mean JStars here) is a contractor item.  The military doesn'tF give a rat's patootie what OS it runs on. They bought JStars.  Period.E The contractor decided to use VMS.  There is just as much chance that E the next version will be Windows as VMS.  And the military won't care  one way or the other.   F As for the bomb control circuitry on the B1, I am not in the Air ForceD so I really have no experience with it, but I do doubt it is runningH VMS.  It is most likely a totally embeded system developed independantlyF of any OS in Ada.  And, just like JStars, maintained by the contractor who developed it.    > D >    They teach some things to just about everybody (everyone in theE >    Army is supposed to know how to fire a rifle).  They teach other F >    things to only those who need to know (very few pilots in the Air. >    Force were ever checked out in an SR-71). > & >    And I'm only stating the obvious.  I And when I was talking about the people who are taught Windows, Linux and K Cisco (among other things not including VMS) I was talking about the people F who write, install, maintain and manage the IT resources for the Army.F If the Army's IT infrastructure contain no visible elements using VMS,I it seems silly to think it is an important part.  If the military is "one I of VMS's biggest customers" and yet it makes up so small of percentage of K their infrastructure that it doesn't even warrant a mention in any of their < IT schools what conclusion would most people draw from this?   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: Mon, 18 Dec 2006 15:33:32 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>' Subject: Re: The Hole in Cerner's Logic 7 Message-ID: <3c17b$4586fb3c$cef8887a$7504@TEKSAVVY.COM>    Bob Koehler wrote:D >    They teach some things to just about everybody (everyone in theE >    Army is supposed to know how to fire a rifle).  They teach other F >    things to only those who need to know (very few pilots in the Air. >    Force were ever checked out in an SR-71).    K But this confirms the other persons's statement: VMS is not widely used in  K the US military. And if it isn't known even internally that VMS is used in  C the military, then you can't expect it to be known publically, for  J marketing purposes. In other words, whatever presence VMS may have within K the US military, whether it just be an instance aboard 10 spy aircraft, or  F deployment of 10,000 VMS instances doesn't matter because in the end,  nobody knows about it.   ------------------------------  % Date: Mon, 18 Dec 2006 15:39:33 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> ' Subject: Re: The Hole in Cerner's Logic : Message-ID: <XuadnZpnfO4dYRvYnZ2dnUVZ_r_inZ2d@comcast.com>   JF Mezei wrote:    > Bob Koehler wrote: > E >>    They teach some things to just about everybody (everyone in the F >>    Army is supposed to know how to fire a rifle).  They teach otherG >>    things to only those who need to know (very few pilots in the Air / >>    Force were ever checked out in an SR-71).  >  >  > J > But this confirms the other persons's statement: VMS is not widely used H > in the US military. And if it isn't known even internally that VMS is I > used in the military, then you can't expect it to be known publically,  I > for marketing purposes. In other words, whatever presence VMS may have  G > within the US military, whether it just be an instance aboard 10 spy  I > aircraft, or deployment of 10,000 VMS instances doesn't matter because  $ > in the end, nobody knows about it.  0 ISTR that the Aegis weapons system is VMS based.   ------------------------------   Date: 18 Dec 2006 21:07:54 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4uoe9aF192d6fU1@mid.individual.net>  : In article <XuadnZpnfO4dYRvYnZ2dnUVZ_r_inZ2d@comcast.com>,6 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes: > JF Mezei wrote:  >  >> Bob Koehler wrote:  >>  F >>>    They teach some things to just about everybody (everyone in theG >>>    Army is supposed to know how to fire a rifle).  They teach other H >>>    things to only those who need to know (very few pilots in the Air0 >>>    Force were ever checked out in an SR-71). >>   >>   >>  K >> But this confirms the other persons's statement: VMS is not widely used  I >> in the US military. And if it isn't known even internally that VMS is  J >> used in the military, then you can't expect it to be known publically, J >> for marketing purposes. In other words, whatever presence VMS may have H >> within the US military, whether it just be an instance aboard 10 spy J >> aircraft, or deployment of 10,000 VMS instances doesn't matter because % >> in the end, nobody knows about it.  > 2 > ISTR that the Aegis weapons system is VMS based.  F Afraid not.  The AEGIS is based on the AN/UYK43-44. These are militaryD specific systems for embeded applications.  Support VME bus and are,H supposedly, about to be replaced service wide by a COTS HP Unix systems.     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: 18 Dec 2006 16:46:10 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: The Hole in Cerner's Logic 3 Message-ID: <SOaDHByXyMgg@eisner.encompasserve.org>   [ In article <4uo98kF18astkU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 5 > In article <gcG8kVdtI0l4@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  H >>    They actively teach you what they want you to know.  Do they teachF >>    you what's on that 707-based electronic surveillance plane?  HowF >>    about the bomb control circuitry of a B1?  I doubt it, you don't >>    have a need to know. > J > Of course not.  I don't have to maintain it.  But the statement was thatH > "The Military" was one of VMS's biggest customers.  Well, that 707  (IJ > assume you mean JStars here) is a contractor item.  The military doesn'tH > give a rat's patootie what OS it runs on. They bought JStars.  Period.$ > The contractor decided to use VMS.  G As a taxpayer, I would hope the contractor actually had to convince the - government that their design was appropriate.   # > There is just as much chance that * > the next version will be Windows as VMS.  D I gather you have never had direct interaction with people from that contractor.    ------------------------------   Date: 18 Dec 2006 22:51:49 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4uokc4F19f29lU1@mid.individual.net>  3 In article <SOaDHByXyMgg@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:] > In article <4uo98kF18astkU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 6 >> In article <gcG8kVdtI0l4@eisner.encompasserve.org>,A >> 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  > I >>>    They actively teach you what they want you to know.  Do they teach G >>>    you what's on that 707-based electronic surveillance plane?  How G >>>    about the bomb control circuitry of a B1?  I doubt it, you don't  >>>    have a need to know.  >>  K >> Of course not.  I don't have to maintain it.  But the statement was that I >> "The Military" was one of VMS's biggest customers.  Well, that 707  (I K >> assume you mean JStars here) is a contractor item.  The military doesn't I >> give a rat's patootie what OS it runs on. They bought JStars.  Period. % >> The contractor decided to use VMS.  > I > As a taxpayer, I would hope the contractor actually had to convince the / > government that their design was appropriate.   D Nope.  That's not the way contracting works.  All they have to do isC meet the spec.  Thus the reason why we often get real fiascoes.  If E the spec is badly written the product while meeting the letter of the E spec may be totally unsuitable for the job for which it was intended. ! Been on both sides of that game!!    > $ >> There is just as much chance that+ >> the next version will be Windows as VMS.  > F > I gather you have never had direct interaction with people from that
 > contractor.   G Actually, you would be wrong.  Not only have I worked on the government D side of contracts with said vendor, I used to work for them as well.  D Just because I work for a dinky college in the middle of nowhere now/ doesn't mean that's the only experience I have.    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: 18 Dec 2006 16:58:02 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: The Hole in Cerner's Logic 3 Message-ID: <5IJSyF9rW2oC@eisner.encompasserve.org>   [ In article <4uokc4F19f29lU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 5 > In article <SOaDHByXyMgg@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  G >> I gather you have never had direct interaction with people from that  >> contractor. > I > Actually, you would be wrong.  Not only have I worked on the government F > side of contracts with said vendor, I used to work for them as well.  D I was not sufficiently specific.  I meant with the end of that giantC corporation responsible for that project.  They even had an exhibit  at last year's VMS boot camp.    ------------------------------   Date: 19 Dec 2006 00:06:33 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4uooo8F18vijpU1@mid.individual.net>  3 In article <5IJSyF9rW2oC@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:] > In article <4uokc4F19f29lU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: 6 >> In article <SOaDHByXyMgg@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > H >>> I gather you have never had direct interaction with people from that >>> contractor.  >>  J >> Actually, you would be wrong.  Not only have I worked on the governmentG >> side of contracts with said vendor, I used to work for them as well.  > F > I was not sufficiently specific.  I meant with the end of that giantE > corporation responsible for that project.  They even had an exhibit  > at last year's VMS boot camp.   6 You cutoff one of the relevant parts of this exchange.  $ >> There is just as much chance that+ >> the next version will be Windows as VMS.   C OK, they had one at the bootcamp.  and just how does that prove the C next version is guaranteed to be done on VMS?  If they like so many A other vendors see VMS as a dead end they are not going to build a C product on it that they expect to have to support for any length of E time.  I don't remember where I saw the article, but I seem to recall F hints already in the trade press (gov contracting, not necessarily IT)C that the next generation of JStars is likely to be COTS Unix based. B Of course, in today's climate that may have aleady been changed to@ Linux based.  In any event, legacy VMS apps today do  not ensure continued use of VMS tomorrow.   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: Mon, 18 Dec 2006 19:52:02 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>' Subject: Re: The Hole in Cerner's Logic 8 Message-ID: <96418$458737d2$cef8887a$18635@TEKSAVVY.COM>   Bill Gunshannon wrote:E > OK, they had one at the bootcamp.  and just how does that prove the / > next version is guaranteed to be done on VMS?     J SWIFT was very committed to VMS, and then at one point, they were told by C Palmer to get off VMS. From that point on, they announced to their  K members/customers that the VMS product would be end of lifed at some point  9 and that new platforms would be used for future products.   L Consider all that has happened at HP in the last year. La Carly kicked out, L Hurd brought in. Hurd is cleaning up the company. If Hurd was told that VMS L   was declining and without future and that VMS customers could be moved to G HP-UX, then Hurd would have no problems starting to tell folks such as  6 Cerner that they should focus on HP-UX instead of VMS.  K So what have folks like Livermore and Stallard been telling Hurd about VMS?   F If Cerner appeared committed to VMS not so long ago, but is no longer J committed, then it means that HP has sent them the message in very recent  times.  K The people here who always complain about the naysayers should now reflect  I on whether they were right in trusting HP to create an environment where  J VMS could succeed. If there had been very strong and unified message from G the community to Hurd, perhaps Hurd might have questioned Stallard and  B Livermore,s assertions that VMS had no future and could be canned.   Is too late now ?    ------------------------------  % Date: Mon, 18 Dec 2006 20:11:17 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: The Hole in Cerner's Logic T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401F189AB@tayexc19.americas.cpqcorp.net>   > -----Original Message-----$ > From: bill@triangle.cs.uofs.edu=20A > [mailto:bill@triangle.cs.uofs.edu] On Behalf Of Bill Gunshannon ! > Sent: December 18, 2006 7:07 PM  > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: The Hole in Cerner's Logic  >=205 > In article <5IJSyF9rW2oC@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:7 > > In article <4uokc4F19f29lU1@mid.individual.net>,=20 , > bill@cs.uofs.edu (Bill Gunshannon) writes:8 > >> In article <SOaDHByXyMgg@eisner.encompasserve.org>,5 > >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > >=20< > >>> I gather you have never had direct interaction with=20 > people from that > >>> contractor.  > >>=20 @ > >> Actually, you would be wrong.  Not only have I worked on=20 > the government> > >> side of contracts with said vendor, I used to work for=20 > them as well.  > >=20H > > I was not sufficiently specific.  I meant with the end of that giantG > > corporation responsible for that project.  They even had an exhibit ! > > at last year's VMS boot camp.  >=208 > You cutoff one of the relevant parts of this exchange. >=20& > >> There is just as much chance that- > >> the next version will be Windows as VMS.  >=20E > OK, they had one at the bootcamp.  and just how does that prove the E > next version is guaranteed to be done on VMS?  If they like so many C > other vendors see VMS as a dead end they are not going to build a E > product on it that they expect to have to support for any length of G > time.  I don't remember where I saw the article, but I seem to recall H > hints already in the trade press (gov contracting, not necessarily IT)E > that the next generation of JStars is likely to be COTS Unix based. D > Of course, in today's climate that may have aleady been changed toB > Linux based.  In any event, legacy VMS apps today do  not ensure  > continued use of VMS tomorrow. >=20 > bill >=20     Bill,   G Perhaps I am missing something, but please help me understand something  here.   E If I am a SysAdmin in the military and I get an email from a civilian H (or part time military) contractor stating something like "please let meE know what OS your application runs on", would I be incented to ignore F your email or respond letting you know what OS platform my environment uses?   C DOD is a massive environment - likely bigger in terms of budget and D people etc than many small countries. In such a large security awareG environment, how can you be sure you have reached all corners of DOD to D make such statements that you are actively engaged and have platform$ feedback from all those in the know?  G Again, perhaps you are, but I am just struggling to understand how this  could be the case.   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: Mon, 18 Dec 2006 20:19:53 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> ' Subject: RE: The Hole in Cerner's Logic T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401F189B5@tayexc19.americas.cpqcorp.net>   > -----Original Message-----: > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca]=20! > Sent: December 18, 2006 7:52 PM  > To: Info-VAX@Mvb.Saic.Com ) > Subject: Re: The Hole in Cerner's Logic  >=20 > Bill Gunshannon wrote:G > > OK, they had one at the bootcamp.  and just how does that prove the 1 > > next version is guaranteed to be done on VMS?  >=20 >=20A > SWIFT was very committed to VMS, and then at one point, they=20  > were told by=20 G > Palmer to get off VMS. From that point on, they announced to their=20 A > members/customers that the VMS product would be end of lifed=20  > at some point=20; > and that new platforms would be used for future products.  >=20  H Makes for a nice bedtime fairy tale story, but that's not what happened.    C Hey, I did not like Palmer anymore than you or anyone else did, but @ that's not the real story as it unfolded. Lots of internal SWIFTD politics that were way beyond the influence of any single vendor.=20  % AIX also got hit with similar issues.   	 [snip...]    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: 19 Dec 2006 02:37:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4up1ilF19aqg4U1@mid.individual.net>  T In article <FA60F2C4B72A584DBFC6091F6A2B868401F189AB@tayexc19.americas.cpqcorp.net>,* 	"Main, Kerry" <Kerry.Main@hp.com> writes: >  >> -----Original Message----- % >> From: bill@triangle.cs.uofs.edu=20 B >> [mailto:bill@triangle.cs.uofs.edu] On Behalf Of Bill Gunshannon" >> Sent: December 18, 2006 7:07 PM >> To: Info-VAX@Mvb.Saic.Com* >> Subject: Re: The Hole in Cerner's Logic >>=20 6 >> In article <5IJSyF9rW2oC@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: 8 >> > In article <4uokc4F19f29lU1@mid.individual.net>,=20- >> bill@cs.uofs.edu (Bill Gunshannon) writes: 9 >> >> In article <SOaDHByXyMgg@eisner.encompasserve.org>, 6 >> >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: >> >=20 = >> >>> I gather you have never had direct interaction with=20  >> people from that  >> >>> contractor. >> >>=20A >> >> Actually, you would be wrong.  Not only have I worked on=20  >> the government ? >> >> side of contracts with said vendor, I used to work for=20  >> them as well. >> >=20 I >> > I was not sufficiently specific.  I meant with the end of that giant H >> > corporation responsible for that project.  They even had an exhibit" >> > at last year's VMS boot camp. >>=20 9 >> You cutoff one of the relevant parts of this exchange.  >>=20 ' >> >> There is just as much chance that . >> >> the next version will be Windows as VMS. >>=20 F >> OK, they had one at the bootcamp.  and just how does that prove theF >> next version is guaranteed to be done on VMS?  If they like so manyD >> other vendors see VMS as a dead end they are not going to build aF >> product on it that they expect to have to support for any length ofH >> time.  I don't remember where I saw the article, but I seem to recallI >> hints already in the trade press (gov contracting, not necessarily IT) F >> that the next generation of JStars is likely to be COTS Unix based.E >> Of course, in today's climate that may have aleady been changed to C >> Linux based.  In any event, legacy VMS apps today do  not ensure ! >> continued use of VMS tomorrow.  >>=20  >> bill  >>=20  >  >  > Bill,  > I > Perhaps I am missing something, but please help me understand something  > here.    I think you missed a lot.    > G > If I am a SysAdmin in the military and I get an email from a civilian J > (or part time military) contractor stating something like "please let meG > know what OS your application runs on", would I be incented to ignore H > your email or respond letting you know what OS platform my environment > uses?   H First of all, I didn't ask that way.  There are thousands upon thousandsE of Army SysAdmins.  Asking them what OS they are running individually I would be an imposible task.  But, just like other IT communities there is H a lot of communications among peers.  And much of it is through officialG channels which increases the odds of getting a real answer.  Until last D year when budget problems canceled it we have held an annual "SignalJ Symposium" at Ft. Gordon.  Signal people (The Signal Corp is the proponentH for all Army IT and has been since the mid 80's) from all over the worldG gather at our Regimental Home and discuss all matters Signal.  Oh yeah, F and there is a "Vendor Tent".  The last one took up a parking lot thatE occupied about two city blocks of ground space.  Guess what Operating A System was not mentioned by any vendor least of all by its owner?    > E > DOD is a massive environment - likely bigger in terms of budget and F > people etc than many small countries. In such a large security awareI > environment, how can you be sure you have reached all corners of DOD to F > make such statements that you are actively engaged and have platform& > feedback from all those in the know?  G I haven't "reached all corners of DOD".  I only tried the Army.  If VMS F has such widespread use you would think I would have run into at leastC one person using it today.  I have found none.  Zero.  Zilch. Nada.  The silence is deafening.    > I > Again, perhaps you are, but I am just struggling to understand how this  > could be the case.  G Just as I am struggling to understand how "the military is one of VMS's E biggest users" and yet I can not find even one of my peers in Army IT E who has ever seen a VMS system in use by the Army.  Oh, and there was D mention of a bunch of VAX systems in the Pentagon that got taken outE by a certain jet.  Not to rain on anyone's parade, but many moons ago E in another life I did some work adding networking to a bunch of VAXen F in the bowels of the puzzle palace.  While they did belong to DOD theyE were not military systems.  It was just the most secure location near # to the department that owned them.    D And that was almost 20 years ago!  They were the last VMS machines I! personally saw being used by DOD.    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: Mon, 18 Dec 2006 20:40:39 -0600 3 From: David J Dachtera <djesys.no@spam.comcast.net> ' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <45875127.53F43FF9@spam.comcast.net>   Rob Brooks wrote:  > + > ChrisQuayle <nospam@devnul.co.uk> writes:  > > Rob Brooks wrote: . > >> ChrisQuayle <nospam@devnul.co.uk> writes: > >> > >>>Some newsM > >>>feature recently showed hp monitors, so I guess hp hardware is involved, G > >>>at least on the desktop, but why are hp not pursuing this business - > >>>agressively with vms for the back end ?.  > >>; > >> What evidence do you have to support your supposition?  > > < > > Rob - are you asking me and if so, what supposition ?... > K > Your above-stated supposition that "...hp [is] not pursuing this business ) > agressively with vms for the back end?"   C Like the rest of us, he's basing his statement on visible evidence.   M If there's something the rest of us have missed, please quote the publication F name, date and page number and/or mass-media outlet and air time where. (recordings of) the promotionals can be found.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Mon, 18 Dec 2006 21:59:48 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>' Subject: Re: The Hole in Cerner's Logic 8 Message-ID: <7a5c8$458755c4$cef8887a$12052@TEKSAVVY.COM>   Main, Kerry wrote:J > Makes for a nice bedtime fairy tale story, but that's not what happened.    K SWIFT told its members that Digital had advised to switch from VMS to Unix  3 or Windows.  Remember the "affinity" programme ????   I Whatever went on internally, this is what SWIFT customers were told. And  H since this fits very well within all the other stories about Palmer and  VMS, it is quite credible.  I Also, remember that large multinational banks were aware that Palmer was  K negotiating with Compaq well before the news were announced. At the time I  J was told by a long time customer that to maintain the job I would have to K bid on anything BUT DEC equipment/software, I didn't quite understand. But  J when Palmer went on CNN to proudlay proclaim that he had been negotiating K with Compaq for 3 years prior to merger announcement and shedding portions  L of Digital Compaq was not interested in, I understood why those large banks   told me not to deal in DEC gear.   ------------------------------   Date: 19 Dec 2006 04:01:02 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)' Subject: Re: The Hole in Cerner's Logic 0 Message-ID: <4up6fuF198pljU1@mid.individual.net>  : In article <p9mdnddfxeBWyxrYnZ2dnUVZ_syunZ2d@comcast.com>,5 	pechter@pechter.dyndns.org (William Pechter) writes: 2 > In article <4up1ilF19aqg4U1@mid.individual.net>,+ > Bill Gunshannon <bill@cs.uofs.edu> wrote:  >>In articleK >><FA60F2C4B72A584DBFC6091F6A2B868401F189AB@tayexc19.americas.cpqcorp.net>, , >>	"Main, Kerry" <Kerry.Main@hp.com> writes: >>>  >>>> -----Original Message----- % >>>> From: bill@triangle.cs.uofs.edu  D >>>> [mailto:bill@triangle.cs.uofs.edu] On Behalf Of Bill Gunshannon$ >>>> Sent: December 18, 2006 7:07 PM >>>> To: Info-VAX@Mvb.Saic.Com, >>>> Subject: Re: The Hole in Cerner's Logic >>>>  8 >>>> In article <5IJSyF9rW2oC@eisner.encompasserve.org>,5 >>>> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: 8 >>>> > In article <4uokc4F19f29lU1@mid.individual.net>, / >>>> bill@cs.uofs.edu (Bill Gunshannon) writes: ; >>>> >> In article <SOaDHByXyMgg@eisner.encompasserve.org>, 8 >>>> >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: >>>> >  = >>>> >>> I gather you have never had direct interaction with   >>>> people from that  >>>> >>> contractor. >>>> >> A >>>> >> Actually, you would be wrong.  Not only have I worked on   >>>> the government ? >>>> >> side of contracts with said vendor, I used to work for   >>>> them as well. >>>> >  K >>>> > I was not sufficiently specific.  I meant with the end of that giant J >>>> > corporation responsible for that project.  They even had an exhibit$ >>>> > at last year's VMS boot camp. >>>>  ; >>>> You cutoff one of the relevant parts of this exchange.  >>>>  ) >>>> >> There is just as much chance that 0 >>>> >> the next version will be Windows as VMS. >>>>  H >>>> OK, they had one at the bootcamp.  and just how does that prove theH >>>> next version is guaranteed to be done on VMS?  If they like so manyF >>>> other vendors see VMS as a dead end they are not going to build aH >>>> product on it that they expect to have to support for any length ofJ >>>> time.  I don't remember where I saw the article, but I seem to recallK >>>> hints already in the trade press (gov contracting, not necessarily IT) H >>>> that the next generation of JStars is likely to be COTS Unix based.G >>>> Of course, in today's climate that may have aleady been changed to E >>>> Linux based.  In any event, legacy VMS apps today do  not ensure # >>>> continued use of VMS tomorrow.  >>>>  	 >>>> bill  >>>>   >>>  >>> 	 >>> Bill,  >>> K >>> Perhaps I am missing something, but please help me understand something 	 >>> here.  >> >>I think you missed a lot.  >> >>> I >>> If I am a SysAdmin in the military and I get an email from a civilian L >>> (or part time military) contractor stating something like "please let meI >>> know what OS your application runs on", would I be incented to ignore J >>> your email or respond letting you know what OS platform my environment	 >>> uses?  >> > I > Having been a Sysadmin at Fort Monmouth working as a contractor for the F > military... I'd have probably not answered the question at the time.  C So, what your telling me is your sitting in a room full of military D Sysadmins.  Discussing military sysadmin matters.  And when they gotD around the table to you and said what kind of system are you runningC you would have said something like, "I'ld tell you but then I would  have to kill you."     > F > I was amazed at my DEC days how deep the VMS penetration was at Fort9 > Monmouth in the mid 80's and how soon it began to wane.   J I am not arguing that there was never a lot of VMS in use by the military.G The first VMS machine I ever used belonged to the Army.  And, yes, that D was 25 years ago!  I am saying that the numbers have dwindled to theG point that if "the military is one of VMS's biggest customers" then VMS 4 is in a lot worse shape than even people here think.   > H > However, since my days there are at least 10 years past... I know theyK > were phasing out VMS then and new R&D work and development  was on HP-UX  H > and Solaris 2.4 when I left.   And... you may find this interesting...C > they had moved to early Linux for their "Unix" when they ran into 1 > problems with a major project which was behind.   C When I became an IT Warrant Officer the Unix of choice was Solaris. A Now, they no longer teach Solaris and Linux is the favored child. @ VMS is not even worthy of a mention anywhere in the schoolhouse.C That means the Army considers it so unikely that an IT Warrant will C ever find himself standing in front of one that  no time is devoted E to preparing for that possibility.  The Army even has special courses B on Logistics IT Systems because we may have to maintain them.  ButC nothing on VMS.  Maybe you don't, but I can read a lot out of that.    >  > J >>First of all, I didn't ask that way.  There are thousands upon thousandsG >>of Army SysAdmins.  Asking them what OS they are running individually K >>would be an imposible task.  But, just like other IT communities there is J >>a lot of communications among peers.  And much of it is through officialI >>channels which increases the odds of getting a real answer.  Until last F >>year when budget problems canceled it we have held an annual "SignalL >>Symposium" at Ft. Gordon.  Signal people (The Signal Corp is the proponentJ >>for all Army IT and has been since the mid 80's) from all over the worldI >>gather at our Regimental Home and discuss all matters Signal.  Oh yeah, H >>and there is a "Vendor Tent".  The last one took up a parking lot thatG >>occupied about two city blocks of ground space.  Guess what Operating C >>System was not mentioned by any vendor least of all by its owner?  > H > Yup... Fort Monmouth was beginning to look at moving off All-In-1 backH > in the '93 to 95 timeframe IIRC.  The old 8650 wasn't looking too good@ > performance-wise and all the new infrastructure was WindowsNT A > desktops replacing Novell servers and Solaris on the Unix side.  > I > DEC fans were being replaced with C and Unix types from the engineering  > schools.   > H > That's how AT&T and BSD Unix systems spread.  And how PDP's did in theJ > 60's and 70's.  The 80's were in the bag for DEC until 84 or so when theB > PC and Unix workstations killed them in the educational markets. > F > Fort Monmouth was the major site for the Signal Corp back in the old
 > days...   D Well, one of them. :-)  Ft. Gordon and "Signal Towers" have been the; Regimental HQ since before 1969 when The Towers were built.    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: 18 Dec 2006 13:03:17 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: VMS$AUDIT_SERVER.DAT 3 Message-ID: <oVBAvasCqGCV@eisner.encompasserve.org>   [ In article <JAHDDH.MJy@news.boeing.com>, "Milt Zlatic" <milton.t.zlatic@boeing.com> writes: L > Is the format of this file documented anywhere? I need to write a program J > that would check if the security settings are correct without having to ! > parse the output of SHOW AUDIT. 	 > Thanks,  > Milt  H    There is a documented API to the audit data.  You should find and useH    it rather than try to parse the file or the SHOW AUDIT output as both"    of those are subject to change.   ------------------------------   End of INFO-VAX 2006.696 ************************