1 INFO-VAX	Thu, 29 Nov 2001	Volume 2001 : Issue 663       Contents: Re: Advice on CD-R & DVD-RP Re: Autoconf (was: Re: Offtopic: cross platform portability tools - a study of a Re: Careful with Mozilla 0.9.6, Re: Compaq's Secret VMS Plans (The Inquirer)
 Complie Error  Re: Complie Error  DCPS stopped, inactive problem Re: Disk Defragmenters, Re: DSSI VAXcluster manual on line anywhere? Re: F$GETQUI wildcard bug??  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Fwd: Peter J. Humble. 4 Re: Gartner and IDC say HP will effectively kill DLT Go away Kenneth Lay  Go Away Kenneth Lay  Re: Go away Kenneth Lay  Re: HP/Compaq merger Re: HP/Compaq merger! Re: logical names novice question ! Re: logical names novice question ! Re: logical names novice question ! Re: logical names novice question 6 Re: New product allows VMS to become part of a PC Lan!3 News on Oracle Rdb port to Itanium Processor Family D Re: Offtopic: cross platform portability tools - a study of autoconfD Re: Offtopic: cross platform portability tools - a study of autoconfD Re: Offtopic: cross platform portability tools - a study of autoconf Re: PGP for OpenVMS  Re: PGP for OpenVMS - Re: Problem fseeking a 4.2 million block file - Re: Problem fseeking a 4.2 million block file ( Re: Q: How to check if a file is opened?; SKC Musings on "Recent IPF Unpleasantness" at www.tru64.org  Re: Some Multia Help needed  Re: Some Multia Help needed  Re: Some Multia Help needed E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org % Re: SRM software for alpha server 800  submarine telephone booth 0 Time for the Encompass US Inc CHAD-FREE Election RE: TRIBON (for shipbuilding)  TRIBON,manual for shipbuildingE Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) 	 Re: xdmcp 1 Yahoo - IBM unseated in new supercomputer ranking 5 Re: Yahoo - IBM unseated in new supercomputer ranking 5 Re: Yahoo - IBM unseated in new supercomputer ranking 5 Re: Yahoo - IBM unseated in new supercomputer ranking   F ----------------------------------------------------------------------  % Date: Wed, 28 Nov 2001 22:36:30 -0000 ; From: "Leigh G. Bowden" <LGBowden@bowdenfamily.fsnet.co.uk> # Subject: Re: Advice on CD-R & DVD-R . Message-ID: <9u3opc$7o$1@newsg1.svr.pol.co.uk>  L I've got a Plextor CD-RW running under VMS6.2 with the Plextor switch set toJ the Unix setting. I make the disks to be burnt using Logical Disk and thenL CDrecord to burn. The Plextor had to be treated as a GK device rather than a DK disk.  K One problem I had using CD-RW disks was their lack of reflectivity and most J VMS based CD drives wouldn't recognise them at all. I had to use the disksK that could only be burnt once but once that was sorted never had a problem.   K I've made simple VMS boot disks by "putting" STABACKIT onto the CD as well.     Not bothered with DVD in anyway.   Martin Walker wrote in messageC <0262A6086BFBD411959500508B69C5EA134965@ThisAddressDoesNotExist>... K >Looking at CD-R writing from VMS, it seems that some drives work well with 2 >VMS and others don't.  I know how to set them up. > G >I'd welcome advice as to which ones people are using which work well - L >manufacturer, model etc - (using CDWRITE on VMS 7.3).  What I'm looking forI >is reasonable write speed, can mount and read CDs on VMS and, of course,  >still available to buy. > K >Also, are there DVD drives which work with VMS?  What manufacturer / model  /  >software are people using?  >  >Thanks  >  > A >This e-mail including any attachments is confidential and may be G >legally privileged. If you have received it in error please advise the @ >sender immediately by return email and then delete it from your >system.B >The unauthorised use, distribution, copying or alteration of thisG >email is strictly forbidden. If you need assistance please contact the ! >help desk on (+44)(0)870 8704820    ------------------------------  # Date: Wed, 28 Nov 2001 23:20:49 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)Y Subject: Re: Autoconf (was: Re: Offtopic: cross platform portability tools - a study of a 3 Message-ID: <ljeN7.2072$RL6.63139@news.cpqcorp.net>   [ In article <3C051D09.FF5FCA2F@mayo.edu>, Patrick Spinler <spinler.patrick@mayo.edu> writes: 1 :...Often the "portability" package "autoconf" is I :cited as a major problem in getting the package under discussion running  :on VMS.  D   AUTOCONF provides portability within a particular set of operating
   systems.  1 :Those following these topics may find this paper G :http://www.cs.columbia.edu/~ezk/research/amu/autoconfiscating_amd.html C :of interest.  It chronicals one package maintainer's experience in @ :porting his package (amd - the Berkeley auto mounter daemon) to
 :autoconf.  J   AUTOCONF is somewhat of a crock, and one that most every programmer thatI   has dealt with it has probably suffered for the experience -- though in L   the defence of AUTOCONF, it is a very powerful and flexible tool.  (In my L   opinion, that power and flexibility is also probably the greatest weaknessL   of the tool.)  My experience with it tends to be iterative -- you run it, J   hack the results, run it again, etc.  Eventually, you get something that    you can use to run the builds.  J   Another approach to this same problem of feature determination involves H   a construct such as the Windows Registry -- an approach which has its I   own set of problems, and involves a fair amount of baseline complexity  G   on each platform to store and retrieve the configuration information.   I   A simple-minded alternative to these involves the creation of a simple  H   API for each platform, one that the build tools can invoke to generateI   the header file -- this is part-way between the two.  (Then, of course, J   you have to figure out how to create the build script for the platform.)    D :While the particular package ported is likely of little interest toI :VMSers his conclusions are still interesting.  For instance, as a result F :of autoconfing, he was able to reduce his code size from 49k lines toH :30k lines, and reduce his code's conditional complexity (as measured byH :the number of C "#ifdef" statements per hundred lines of code) from 9.7  :per hundred to 6.5 per hundred.    D   I am not familiar with the specifics of the code referenced above.  H   I did port one code package that was using AUTOCONF not too long ago, E   and I completely removed the need for AUTOCONF while also removing  H   most of the latent complexity.  The results of the port were simpler, F   faster, and arguably more portable than the original.  (Some of the C   constructs used in the code were truely perverse, and were quite  >   unnecessary.  No, I will not identify the specific package.)  D :After reading this, I'd draw the conclusion that unix based packageH :authors have a powerful motivation for autoconfing their code, and thatD :we in the VMS world are likely to be stuck with having to deal withB :this.  It seems likely that we'll either have to make ourselves aI :working autoconf facility, provide some similar package that runs on VMS G :but is compellingly better enough to tempt authors away from autoconf, > :or be stuck in our current "unix code == hell" statis for the :indeterminate future.  B   One of the locals has created an AUTOCONF-like tool for OpenVMS =   that I'm hoping to get onto the next Freeware distribution.   B   My preference would be a different approach to AUTOCONF -- everyD   platform gets to port this system-identification routine, then theA   data gets passed around.  (An analogous approach is used by the C   ACPI definitions and the ACPI-compliant data provided by various  B   hardware vendors offering up the weirder hardware widgets -- theB   standard widgets are already understood.  With ACPI, there is a =   platform interface definition, and room for information and A   enhancements and data provided by the software and the hardware C   folks.)  I won't claim ACPI isn't also a crock :-), but I prefer  A   its approach to the problem over the approach used by AUTOCONF.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 29 Nov 2001 05:23:38 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle) ' Subject: Re: Careful with Mozilla 0.9.6 , Message-ID: <9u4goq$crk@gap.cco.caltech.edu>  W >In article <3C04F75D.8030203@compaq.com>, John Reagan <john.reagan@compaq.com> writes:  >>Vance R. Haemmerle wrote:  >>J >>>   I just wanted to warn people that if they install Mozilla 0.9.6 theyG >>> might want to copy their bookmarks.html file to a safe place first. L >>> Mozilla ate mine and I had to get mine from a backup.  There's also some8 >>> other strange problems, like window focus problems.  >>> D >>>   Yes, I've reported these and some other bugs through bugzilla. >>>  >>> -- >>> Vance Haemmerle  >>> vance@alumni.caltech.edu >>>  >>K >>That is odd.  I updated from 0.9.3 to 0.9.6 and didn't have any problems  N >>with my bookmarks.  I also haven't seen any problems with window focus, etc.  H   I guess I missed this original reply so I'll reply using Brian's post.M I upgraded from 0.9.5 and I didn't have a problem with my bookmarks at first. K At least the first few runs.  Then Mozilla decided to overwrite my bookmark N file with a bare minimum entry.  Perhaps it did it when it decided to clear myO cache (which it sometimes does on exit).  Anyway, I didn't do anything special, J just quit normally and the next time I ran Mozilla my bookmarks were gone.K I used Import Bookmarks to get them back from a backup copy.  I differenced F the new version with my old version and did notice a difference in theH way the personal toolbar items were identified.  Perhaps Mozilla wanted M a version of bookmarks.html compatible with 0.9.6.  A day later and it hasn't M happened again.  *crosses fingers*  At least I'm leaving a spare copy around.   I   I'm not sure why the window focus problem is so reproducible for me and . Colin Blakes can't reproduce it on his system.   -- Vance Haemmerle  vance@alumni.caltech.edu   ------------------------------  % Date: Wed, 28 Nov 2001 15:38:38 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer) , Message-ID: <3C054B4B.541852C7@videotron.ca>   "Terry C. Shannon" wrote: N > Funny thing: none of the Himalaya NSK users seem to complain about accessing > the Web via Exploder...   M That is because NSK has never had a half decent character cell interface. VMS P has had not only a decent character cell interface but also X-windows interface.  L Compaq are downgrading VMS by removing its user interface applicationsand inG doiwng so further narrowing its potential marketplace should it one day  decision to promote VMS.  J Every step Compaq takes to forget about VMS on workstations is yet another nail in VMS's coffin.    ------------------------------  % Date: Thu, 29 Nov 2001 11:27:14 +0900   From: "ȼ" <syahn@icols.com> Subject: Complie Error( Message-ID: <9u46ec$kud$1@news.nuri.net>   when C lib link time Occured following error. I don't know why....   Please E-mail and Answer....          " A: USER:[~.~.~.SOURCE.FBI_SST] dir2 SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB;1/dat/siz$ Directory SYS$COMMON:[000000.SYSLIB]5 DECWINDOWS.OLB;1         702  12-MAR-1996 15:37:32.20  Total of 1 file, 702 blocks.  & A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz. SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE/dat$ Directory SYS$COMMON:[000000.SYSLIB]5 DECW$XLIBSHR.EXE;2      2282  21-JAN-1998 11:08:54.76 5 DECW$XLIBSHR.EXE;1      2283  21-MAR-1996 21:42:04.76  Total of 2 files, 4565 blocks.  & A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz2 SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE/dat/sec$ Directory SYS$COMMON:[000000.SYSLIB]? DECW$XLIBSHR.EXE;2      2282  21-JAN-1998 11:08:54.76  [SYSTEM]  (RWED,RWED,RWED,RE) ? DECW$XLIBSHR.EXE;1      2283  21-MAR-1996 21:42:04.76  [SYSTEM]  (RWED,RWED,RE,RE)  Total of 2 files, 4565 blocks.  & A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz0 SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB/dat/sec$ Directory SYS$COMMON:[000000.SYSLIB]? DECWINDOWS.OLB;1         702  12-MAR-1996 15:37:32.20  [SYSTEM]  (RWED,RWED,RE,RE)  Total of 1 file, 702 blocks.  , A: USER:[~.~.~.SOURCE.FBI_SST] ty cclink.com  4 $ IF P1 .EQS. "" THEN INQUIRE P1 " *** SOURCE FILE "	 $ SET VER  $ IF P1 .NES. "" THEN $ CC 'P1' 4 $ LINK FBI_SST, GR2D, KEYINPUT, SST_ENDCUT, SST_SUB,$ STR_LST,STR_SHEET,STR_TOKEN, FB_DLG,, SYS$COMMON:[000000.SYSLIB]DECWINDOWS/LIBRARY $ SET NOVER   & A: USER:[~.~.~.SOURCE.FBI_SST] @cclink  *** SOURCE FILE : $ IF P1 .NES. "" THEN $ CC4 $ LINK FBI_SST, GR2D, KEYINPUT, SST_ENDCUT, SST_SUB,$ STR_LST,STR_SHEET,STR_TOKEN, FB_DLG,* SYS$COMMON:[000000.SYSLIB]DECWINDOWS/LIBRA RYH %LINK-I-DATMISMCH, creation date of 21-JAN-1998 11:08 in shareable image, SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE;2I         differs from date of 21-MAR-1996 21:41 in shareable image library * SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB;1 $ SET NOVER    ------------------------------  % Date: Thu, 29 Nov 2001 13:43:30 +0900   From: "ȼ" <syahn@icols.com> Subject: Re: Complie Error( Message-ID: <9u4edu$roa$1@news.nuri.net>  	 Answer is   2 $ LIBRARY/REPLACE/SHARE SYS$LIBRARY:decwindows.olb SYS$LIBRARY:decw$xlibshr.exe  + "ȼ" <syahn@icols.com> wrote in message " news:9u46ec$kud$1@news.nuri.net... > when C lib link time > Occured following error. > I don't know why.... >  > Please E-mail and Answer.... >  >  >  >  > $ > A: USER:[~.~.~.SOURCE.FBI_SST] dir4 > SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB;1/dat/siz& > Directory SYS$COMMON:[000000.SYSLIB]7 > DECWINDOWS.OLB;1         702  12-MAR-1996 15:37:32.20  > Total of 1 file, 702 blocks. > ( > A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz0 > SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE/dat& > Directory SYS$COMMON:[000000.SYSLIB]7 > DECW$XLIBSHR.EXE;2      2282  21-JAN-1998 11:08:54.76 7 > DECW$XLIBSHR.EXE;1      2283  21-MAR-1996 21:42:04.76   > Total of 2 files, 4565 blocks. > ( > A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz4 > SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE/dat/sec& > Directory SYS$COMMON:[000000.SYSLIB]A > DECW$XLIBSHR.EXE;2      2282  21-JAN-1998 11:08:54.76  [SYSTEM]  > (RWED,RWED,RWED,RE) A > DECW$XLIBSHR.EXE;1      2283  21-MAR-1996 21:42:04.76  [SYSTEM]  > (RWED,RWED,RE,RE)   > Total of 2 files, 4565 blocks. > ( > A: USER:[~.~.~.SOURCE.FBI_SST] dir/siz2 > SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB/dat/sec& > Directory SYS$COMMON:[000000.SYSLIB]A > DECWINDOWS.OLB;1         702  12-MAR-1996 15:37:32.20  [SYSTEM]  > (RWED,RWED,RE,RE)  > Total of 1 file, 702 blocks. > . > A: USER:[~.~.~.SOURCE.FBI_SST] ty cclink.com > 6 > $ IF P1 .EQS. "" THEN INQUIRE P1 " *** SOURCE FILE " > $ SET VER ! > $ IF P1 .NES. "" THEN $ CC 'P1' 6 > $ LINK FBI_SST, GR2D, KEYINPUT, SST_ENDCUT, SST_SUB,& > STR_LST,STR_SHEET,STR_TOKEN, FB_DLG,. > SYS$COMMON:[000000.SYSLIB]DECWINDOWS/LIBRARY
 > $ SET NOVER  > ( > A: USER:[~.~.~.SOURCE.FBI_SST] @cclink >  *** SOURCE FILE : > $ IF P1 .NES. "" THEN $ CC6 > $ LINK FBI_SST, GR2D, KEYINPUT, SST_ENDCUT, SST_SUB,& > STR_LST,STR_SHEET,STR_TOKEN, FB_DLG,, > SYS$COMMON:[000000.SYSLIB]DECWINDOWS/LIBRA > RYJ > %LINK-I-DATMISMCH, creation date of 21-JAN-1998 11:08 in shareable image. > SYS$COMMON:[000000.SYSLIB]DECW$XLIBSHR.EXE;2K >         differs from date of 21-MAR-1996 21:41 in shareable image libraryl, > SYS$COMMON:[000000.SYSLIB]DECWINDOWS.OLB;1
 > $ SET NOVER  >  >u >o >M >    ------------------------------  % Date: Thu, 29 Nov 2001 14:07:26 +0010u' From: <paddy.o'brien@zzz.tg.nsw.gov.au>u' Subject: DCPS stopped, inactive problem 5 Message-ID: <01KBA1VTCE9E000WCE@tgmail.tg.nsw.gov.au>M  F Since our contractors have forced boots on DCPS printers, I have been I having problems on my machines.  The contractors have absolutely no idea  H what to do.  These queues have been working with no problems for years, H until our new contractors did something on their machine from which the  printers boot.  I The boot machine is a VAX running VMS 6.2.  My machines are a VAX at 6.2   and two Alphas at 7.2.  K I can start the DCPS queue and it will happily sit there idle.  Submitting rK a print job (ordinary text) via a generic queue, the queue goes busy for a aK while and then is shown as stopped with autostart inactive.  The print job t( is back on the generic queue as pending.  E The operator log shows the following sequence of events at this time:M  8 %%%%%%%%%%%  OPCOM  27-NOV-2001 09:55:11.86  %%%%%%%%%%%! Message from user SYSTEM on GECKOaI Process SYMBIONT_53: %SYSTEM-F-ACCVIO, access violation, reason mask=00, i3 virtual address=7FF60A00, PC=81F4B595, PSL=03C00004   8 %%%%%%%%%%%  OPCOM  27-NOV-2001 09:55:12.05  %%%%%%%%%%%' Message from user QUEUE_MANAGE on GECKO 7 %QMAN-E-SYMDEL, unexpected symbiont process termination   8 %%%%%%%%%%%  OPCOM  27-NOV-2001 09:55:12.05  %%%%%%%%%%%' Message from user QUEUE_MANAGE on GECKOe< -SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual + address=00000000, PC=0001DC6C, PSL=03C000006  8 %%%%%%%%%%%  OPCOM  27-NOV-2001 09:55:12.05  %%%%%%%%%%%' Message from user QUEUE_MANAGE on GECKOe? %QMAN-I-QUEAUTOOFF, queue DCPS$P1201L is now autostart inactivee  L Can anyone suggest anything that I can do on my machines, or anything I can  tell the contractors to fix?   TIA    Regards, Paddy   ------------------------------    Date: 28 Nov 2001 13:32:00 -0800< From: alphaman-nixspam@hsv.sungardtrust.com (Aaron Sakovich) Subject: Re: Disk Defragmentersi= Message-ID: <8af17fe1.0111281332.23b97245@posting.google.com>T  j bes@pbsbank.ch (Bernard Straehl) wrote in message news:<76f61726.0111230940.c772399@posting.google.com>... > As a hint:H > I also installed DFO on my systems and did execute "setfilenomove.com"G > an all my disks. Then I had the idea to backup my normal sysdsk (in a G > RA8000) to a not used internal disk, boot from this internal disk andk$ > run DFO against the normal sysdsk. > H > The result: I could not boot anymore from my normal sysdsk. This was aH > real bad idea. The way to resolve this was to restore my normal sysdskA > from this internal disk ( this means trad. VMS defragmentation)   E Not surprising. SetFileNoMove only sets the bit on files that are not D open.  Therefore, it did not get set on many of your OS files.  When< you ran DFO from the other cloned drive, you should have run0 SetFileNoMove _again_ against the original disk.  @ It's hypothetically safe to run SetFileNoMove then DFO on a liveF system disk, since any files which are open and can't be set would not1 subsequently be defragged (because they're open).   F This is not theory, as I've never dared try it myself.  Best bet: bootB from CD-ROM and do a SetFileNoMove on your system disk.  Then boot, normally and defrag to your heart's content!   Cheers," AaronK   ------------------------------  % Date: Wed, 28 Nov 2001 23:09:52 +0000e1 From: Robert DiRosario <rdirosario@starpower.net>E5 Subject: Re: DSSI VAXcluster manual on line anywhere?w- Message-ID: <3C056EC0.EED7B0A5@starpower.net>    "B.Eckstein" wrote:h   > a.carlini wrote: > * > > There is a console command (one of the' > > TEST commands, but I forget exactlyl) > > which one) that flips it from KA50 toR > > KA52 and back. >I& > Do you remember the exact commands ?/ > It would be nice to connect my 3190 over DSSI  > to my 4500 and 4600. > ' > > There was (AFAIK) nothing to stop ak' > > customer turning a MicroVAX 3100-90 + > > into a VAX 4000-100 ... as long as they + > > did not mind the higher licensing costss) > > and could scrounge the right case fori > > DSSI and Q-bus to work.t > % > I don't see any licensing probs ...i > ... for hobbyists ;-)   D The DSSI cable doesn't go directly to the system board, it goes to aC small card that plugs into the system board, under the disk drives.n  F My 4000/100 has the Qbus connector on the top of the case and the backG of the case is flat, like other 3100 systems.  The DSSI cable mounts inr4 one of the removable covers on the back of the case.  C Only one end of the DSSI cable comes out of the case, so the system-' needs to be at the end of the DSSI bus.L  G I can open my system and look for a part numbers on the board and cablei if you want.   Robert   ------------------------------  % Date: Wed, 28 Nov 2001 23:37:42 -0000 3 From: "Malcolm" <malcolm@neverness.freeserve.co.uk>r$ Subject: Re: F$GETQUI wildcard bug??/ Message-ID: <9u3sb6$9l1$1@newsg4.svr.pol.co.uk>e  F "Brian Tillman" <tillman_brian@notnoone.notnohow.com> wrote in message news:3c03dac2$1@news.si.com...H > >What I am trying to do is to group print and batch queues using queueJ > >characteristics. I investigated multiple queue managers, but there is aH > >limit of five (why five?), which is too few for what I want to do. My nextL > >idea was to set each queue with a characteristic according to which group > >they were in. I couldI > >then write a wrapper command file called WITH_CHAR, which would take aiK > >characteristic name and a command and perform that command on each queuee > >with L > >that characteristic. So I could do for instance, WITH_CHAR SITE1_PRINTERS > >STOP/QUEUE/NEXT, and so on. >tI > I do something similar, but based on different symbionts.  If I want tobI > separate queue functions, I create separate symbionts for them (even ifiG > they're simply copies of existing symbionts).  I then use F$GETQUI to 3 > operate on the queues based on symbiont so I can:a >n, > $ queue_control stop all ! Stop all queues >  > or > : > $ queue_control start generic ! Start all GENERIC queues >l > or > 0 > $ queue_control stop lpr ! Stop the lpr queuesK Hmm. That's quite a neat solution. I might try that one. But it would use ae9 lot of disk space, or be dangerous (SET FILE /ENTER ...).o  	 -Malcolm.  > --C > Brian Tillman                   Internet: tillman_brian at si.comWC > Smiths Aerospace                          tillman at swdev.si.comV? > 3290 Patterson Ave. SE, MS      Addresses modified to preventr> > Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@": >        This opinion doesn't represent that of my company >o >e   ------------------------------    Date: 28 Nov 2001 14:21:54 -0600+ From: young_r@encompasserve.org (Rob Young)  Subject: Re: Future of VMS ?3 Message-ID: <Zc87ul4oSlCo@eisner.encompasserve.org>v  i In article <3C0526FA.7A739645@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:e > H > My recent postings about Compaq have been quite negative and there's aI > very good reason for this;  personally I believe that the best prospecttF > of a future for VMS lies with killing the merger with HP dead in its	 > tracks.e >  > Why do I think this ?s > H > 1.  There is no current indication that the merger will do anything atF > all to improve the situation for VMS.  At best it looks like will beC > more of the same (niche markets, no promotion, no press releases,dH > retiring products ...etc.).  At worst it could be another e3000, maybe= > not right away but some time in the not too distant future.a > F > 2.  The current management of Compaq - the same individuals who willE > have a strong influence on the merged company - are people who haveuD > directed billions of dollars into the product that makes the leastC > profit, and neglected to make any serious efforts to market their E > best-earners.  To do this for one year would be unfortunate, but topG > persist in doing this year after year really makes one question theirgF > competence.  It looks like the stockmarket is also losing confidenceJ > because when Capellas took over the stock price was about $28, then roseH > slowly to $35 (up 20%) but is now down at less than $10 (down 70% from > that $35). >   ? 	But HP at a corporate level does get how to do margins.  HP/UX ? 	has more seats than Tru64 and VMS combined.  Hopefully someone > 	at HP sees VMS is doing real good on margins and might wonderA 	how best to sustain or grow that.  After all, we can sigh, groanaH 	moan and all that but in the end it really is about running a business.D 	The reasonable measure of how a business is doing is how much money0 	it is making, not how many parts it is selling.  I > 3.  The current roadmap expects the IPF processor to be on schedule and-F > meet performance specifications but this must be regarded as wishfulB > thinking when delivery is several years away.   Right now VMS isD > slipping into "coasting" mode, no foot on the pedal, just driftingF > along.  If IPF slips by even a few months (as is Intel's habit) thenI > even more VMS users will desert it and quite possibly this will reach aIH > point where it casts doubt upon the viability of the porting exercise. >   ? 	But as discussed before, Itanium servers today are quite a bitw@ 	cheaper than Alpha servers.  Yes, you may have to purchase Dell? 	to see those good prices , but I don't expect Compaq kit to beoF 	more than 15% more expensive which leaves Compaq IA64 servers cheaper 	than AlphaServers.b  C 	Personally, it will be pretty cool someday to run VMS on somethingeA 	cheaper than $5000 and yes ... that day is coming when a low-endm 	Deerfield box fits the bill.h    J > 4.  In direct terms the termination of Alpha and the move to IPF bothersB > me only because so many assumptions are being made about the IPFE > processor.  (To call these assumptions baseless would be unfair, so'J > perhaps overly-optimistic is the best description.)  Most alarming aboutJ > this transfer of technology is the flakiness of Compaq's justifications,I > first commercial and then technical.  In both cases these were promptlysF > contradicted or counter-argued from within and without the company. C > These poor justifications, which had to almost be squeezed out ofaI > Compaq, have further eroded confidence in the company.  Their assertionaE > that ISVs would be attracted to Intel/VMS is looking just as shaky.o >   C 	There are a lot of assumptions.  Fact is that Intel has the entiret? 	corporation success pinned on IA64 so that pig will eventually D 	fly and they bought 200 of the best engineers (Alpha developers) to 	ensure that pig will fly.  I > 5.  Even if Compaq management "got religion" (to use Winkler's words towH > Alan Greig), their collective credibility is less than 10% of zero andH > the market would be extremely skeptical about any utterance of supportH > for Compaq's high-end products.  If past events are a guide, a lack ofI > market reaction would see Compaq declaring that there was no market foreI > the high-end when in actual fact it no-one was buying their statements.> >   - 	Not sure about what this means.  VMS is VMS.f  J > 6.  The abandoning of the merger should mean that Capellas is out on hisF > ear, hopefully accompanied by the coterie who supported him.  I, forJ > one, would be very happy to see a bunch of over-paid under-achievers getH > their marching orders.  In about 30 months Capellas has not managed toG > check the slide in the performance of Compaq - this year alone, up toaH > 30th September Compaq has lost almost $1.8 million every day in the PC	 > sector.f >   @ 	They stated time and again they have full BOD approval.  If the1 	naysayers had a hope , I'm not sure where it is.o  G > 7.  If Capellas (et al) depart, the market will at least give the newED > management a chance to prove themselves, which means that Compaq'sD > credibility rating would go from "negative" to "neutral", which of$ > course would be a big improvement. >   ? 	Maybe a few years after the merger.  Generally, you get a year < 	of honeymoon from Wall Street, etc.  Yes, they have already 	been beat up prior to merger.  F > 8.   If Compaq sincerely lacks the will or motivation to do anythingI > productive with VMS, then it should be made available to an alternativeSI > buyer as soon as practicable. If the merger goes ahead but in 12 monthsRG > the new company decides to rid itself of VMS, the market value of the.I > platform will have fallen even further and the job of restoring some ofXJ > its attractiveness becomes that much more difficult.  (A few weeks ago IC > noticed a favourable response to the rumour of an IBM purchase of G > Compaq.  This indicates to me that the posters to this newsgroup haveWJ > greater confidence in IBM's ability than Compaq's when it comes to doing! > something positive with VMS.)  ] >   A 	Makes too much money.  Somebody isn't going to let it go away...O  	beat this horse time and again.   > J > I want a new company management team to be responsible for VMS.  I don'tI > care much if it still within Compaq but free of the wanton stupidity of*A > concentrating on the PC market, or if it in a whole new companyKJ > somewhere.  I believe that without these changes we will continue to getD > more of the same neglect that has dogged VMS for the last 5 years. >    	Yeah.   				RobB   ------------------------------  % Date: Wed, 28 Nov 2001 15:31:15 -0500S- From: JF Mezei <jfmezei.spamnot@videotron.ca>S Subject: Re: Future of VMS ?, Message-ID: <3C054991.1C8A08DB@videotron.ca>   John McLean wrote:F > along.  If IPF slips by even a few months (as is Intel's habit) thenI > even more VMS users will desert it and quite possibly this will reach a1H > point where it casts doubt upon the viability of the porting exercise.  H On a certain angle, I disagree. The more IA64 is delayed, the longer theK remaining VMS customers still stay on Alpha. Customers will only migrate toeJ IA64 if/when they are forced to or if the performance difference is really worth all the trouble.  L The longer it takes for IA64 to materialise with some competitive speed, the6 longer Compaq will have to keep Alpha on life support.  I I dare Compaq to come out in public and announce VMS , like MPE  is beingmN terminated. Is it really worth the aggravation of witnessing VMS wither slowly day after day ?0  L The longer the slow agony of VMS lasts, the longer people who loved VMS will be mad , saddened etc etc.  I Might as well get it over with ASAP, and perhaps 5-6 years down the road,SI former VMS customers will have new decision makers who would not have any , grudges against Compaq and return to Compaq.   ------------------------------  % Date: Wed, 28 Nov 2001 15:27:26 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>5 Subject: Re: Future of VMS ?3 Message-ID: <zPbN7.2067$RL6.62887@news.cpqcorp.net>]  I John McLean wrote in message <3C0526FA.7A739645@swissonline.delete.ch>...S >EG >My recent postings about Compaq have been quite negative and there's a H >very good reason for this;  personally I believe that the best prospectE >of a future for VMS lies with killing the merger with HP dead in its~ >tracks. >S    H While I cannot say anything specific about the merger, I will say that I6 support it 100%.  I think it will be good for OpenVMS.  F The only thing I will comment on in your post is the IPF reference.  IC believe merger or not, the Alpha/IPF decision will not be revisted.    ------------------------------  % Date: Wed, 28 Nov 2001 16:40:37 -0500 . From: Chuck McCrobie <mccrobie@cablespeed.com> Subject: Re: Future of VMS ?. Message-ID: <3C0559D5.10F9BA8B@cablespeed.com>   Fred Kleinsorge wrote: > K > John McLean wrote in message <3C0526FA.7A739645@swissonline.delete.ch>...c > > I > >My recent postings about Compaq have been quite negative and there's a J > >very good reason for this;  personally I believe that the best prospectG > >of a future for VMS lies with killing the merger with HP dead in itst
 > >tracks. > >N > J > While I cannot say anything specific about the merger, I will say that I8 > support it 100%.  I think it will be good for OpenVMS. > H > The only thing I will comment on in your post is the IPF reference.  IE > believe merger or not, the Alpha/IPF decision will not be revisted.2  G Not quite an unbiased opinon!  My personal take is that OpenVMS will becB killed in the new HP just like Alpha was killed in the new Compaq.   -- t --.   ------------------------------  % Date: Wed, 28 Nov 2001 23:24:50 +0100e, From: Didier Morandi <Didier.Morandi@gmx.ch> Subject: Re: Future of VMS ?& Message-ID: <3C056431.8A6A9712@gmx.ch>   John McLean wrote: > ' > My recent postings about Compaq ../..   A John, when do you start the "John Mclean knows COMPAQ" nwsletter?    D. -- eG   ---------------------------------------------------------------------sE MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmllE Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670q/ 19, chemin de la Butte, 31400 Toulouse, France.s  I Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseeH On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Wed, 28 Nov 2001 17:26:11 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>B Subject: Re: Future of VMS ?, Message-ID: <3C05647D.E2DA8D82@videotron.ca>   Rob Young wrote:H >         But as discussed before, Itanium servers today are quite a bit& >         cheaper than Alpha servers.    Today ? Are you sure ? n  N Is it a case of Alpha servers being artificially jacked up in price to prevent their competing against PCs ?u   ------------------------------  # Date: Wed, 28 Nov 2001 22:24:53 GMTs  From: cjt <cheljuba@prodigy.net> Subject: Re: Future of VMS ?+ Message-ID: <3C05641A.32D663D7@prodigy.net>%   Chuck McCrobie wrote:u >  > Fred Kleinsorge wrote: > >-M > > John McLean wrote in message <3C0526FA.7A739645@swissonline.delete.ch>...a > > > K > > >My recent postings about Compaq have been quite negative and there's a?L > > >very good reason for this;  personally I believe that the best prospectI > > >of a future for VMS lies with killing the merger with HP dead in itsv > > >tracks. > > >s > >rL > > While I cannot say anything specific about the merger, I will say that I: > > support it 100%.  I think it will be good for OpenVMS. > >0J > > The only thing I will comment on in your post is the IPF reference.  IG > > believe merger or not, the Alpha/IPF decision will not be revisted.T > I > Not quite an unbiased opinon!  My personal take is that OpenVMS will benD > killed in the new HP just like Alpha was killed in the new Compaq.   But the question is, "When?" >  > -- >    ------------------------------  # Date: Wed, 28 Nov 2001 23:06:21 GMTt* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Future of VMS ?< Message-ID: <N5eN7.61962$YD.5501533@news2.aus1.giganews.com>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C0526FA.7A739645@swissonline.delete.ch.... >hH > My recent postings about Compaq have been quite negative and there's aI > very good reason for this;  personally I believe that the best prospect F > of a future for VMS lies with killing the merger with HP dead in its	 > tracks.a  J That's definitely the first necessary step, since the fact that HP intendsH to incorporate most of Compaq's current top management into the combinedH entity strongly indicates that policy toward VMS under that entity wouldL continue largely unchanged.  But simply derailing the merger won't in itself guarantee change either.  L Terry has stated multiple times that VMS use has remained roughly steady forH years due to a balance between approximately 15% annual attrition in theL existing base and the same accrual of new business to compensate.  June 25thL clearly changed that - probably dramatically, but even if it only results inL a rise in annual attrition to 30% and a decline in compensating new businessJ to 5% that will shrink the customer base at 25% annually (from a base that% isn't all that robust to start with).   L Any more than a year of such decline and the current Compaq brain trust willL certainly be loath to continue to supply VMS with even the nominal resourcesI it has today.  So any current users who won't be satisfied with at best adH stagnant product need either to find another platform or figure out whatL action can be taken to change things from the outside (because under currentJ management it should be abundantly clear by now that change from within is just not going to happen).  J Going directly to the BoD is certainly one option:  while their statementsE continue to indicate unequivocal support for the merger and current Q J leadership, they really couldn't be expected to say anything else right upH to the moment they let the axe fall, and sufficient external input (of aI "you're about to lose my business" nature) might be what it would take tonI tip the balance.  And there's always the stockholders' meeting, but while:I some of the sheep have at least started to bleat more loudly here I don't:G think I see the kind of commitment that organizing an effective assault. there on the BoD would take.   >i > Why do I think this ?  >tH > 1.  There is no current indication that the merger will do anything atF > all to improve the situation for VMS.  At best it looks like will beC > more of the same (niche markets, no promotion, no press releases,hH > retiring products ...etc.).  At worst it could be another e3000, maybe= > not right away but some time in the not too distant future.    Agreed.e   >IF > 2.  The current management of Compaq - the same individuals who willE > have a strong influence on the merged company - are people who havenD > directed billions of dollars into the product that makes the leastC > profit, and neglected to make any serious efforts to market theirtE > best-earners.  To do this for one year would be unfortunate, but totG > persist in doing this year after year really makes one question theirvF > competence.  It looks like the stockmarket is also losing confidenceJ > because when Capellas took over the stock price was about $28, then roseH > slowly to $35 (up 20%) but is now down at less than $10 (down 70% from > that $35).  I Yup - that's why I believe it's time for them to go if VMS is to have anyp hope at all.   >'I > 3.  The current roadmap expects the IPF processor to be on schedule anddF > meet performance specifications but this must be regarded as wishfulB > thinking when delivery is several years away.   Right now VMS isD > slipping into "coasting" mode, no foot on the pedal, just driftingF > along.  If IPF slips by even a few months (as is Intel's habit) thenI > even more VMS users will desert it and quite possibly this will reach apH > point where it casts doubt upon the viability of the porting exercise.  I I don't think this applies in the porting time-frame:  it's already clearrI that IPF isn't going to match Alpha performance before 2005, even if theyn8 hold to current schedules (unless Compaq kills EV7 too).   >lJ > 4.  In direct terms the termination of Alpha and the move to IPF bothersB > me only because so many assumptions are being made about the IPFE > processor.  (To call these assumptions baseless would be unfair, sooJ > perhaps overly-optimistic is the best description.)  Most alarming aboutJ > this transfer of technology is the flakiness of Compaq's justifications,I > first commercial and then technical.  In both cases these were promptlyiE > contradicted or counter-argued from within and without the company.aC > These poor justifications, which had to almost be squeezed out of)I > Compaq, have further eroded confidence in the company.  Their assertioneE > that ISVs would be attracted to Intel/VMS is looking just as shaky.o  B They have dealt VMS a mortal blow and show no indication of takingK compensatory emergency measures to even stem the bleeding let alone promotehK a full recovery (and of course even a full recovery would only return it tofC the status quo ante, which is not exactly what we were hoping for).d  J To address Rob's comment about making the Itanic pig fly:  of course IntelF will.  An old aviation adage is that you can make a barn door fly withI enough power, and Itanic uses power like an electric furnace (thus making 3 the adage apply both metaphorically and literally).   I However, while a pig with wings may actually get off the ground, it stillrH won't compete with the real birds out there (except in producing exhaust' that you wouldn't wish to stand under).    >PI > 5.  Even if Compaq management "got religion" (to use Winkler's words toaH > Alan Greig), their collective credibility is less than 10% of zero andH > the market would be extremely skeptical about any utterance of supportH > for Compaq's high-end products.  If past events are a guide, a lack ofI > market reaction would see Compaq declaring that there was no market for I > the high-end when in actual fact it no-one was buying their statements.r  K Any evidence that current management 'got religion' about VMS should almost I certainly be treated as an outright lie designed to deflect the otherwiseg& natural consequences of their actions.   > J > 6.  The abandoning of the merger should mean that Capellas is out on hisF > ear, hopefully accompanied by the coterie who supported him.  I, forJ > one, would be very happy to see a bunch of over-paid under-achievers getH > their marching orders.  In about 30 months Capellas has not managed toG > check the slide in the performance of Compaq - this year alone, up toiH > 30th September Compaq has lost almost $1.8 million every day in the PC	 > sector.a  = That alone is sufficient reason to work to derail the merger.o   >VG > 7.  If Capellas (et al) depart, the market will at least give the new D > management a chance to prove themselves, which means that Compaq'sD > credibility rating would go from "negative" to "neutral", which of$ > course would be a big improvement.  K Almost any change would be likely to be (and to be seen as) an improvement.,   > F > 8.   If Compaq sincerely lacks the will or motivation to do anythingI > productive with VMS, then it should be made available to an alternativenI > buyer as soon as practicable. If the merger goes ahead but in 12 monthslG > the new company decides to rid itself of VMS, the market value of the I > platform will have fallen even further and the job of restoring some ofoJ > its attractiveness becomes that much more difficult.  (A few weeks ago IC > noticed a favourable response to the rumour of an IBM purchase of G > Compaq.  This indicates to me that the posters to this newsgroup have J > greater confidence in IBM's ability than Compaq's when it comes to doing > something positive with VMS.)e  F I doubt that VMS is a salable entity without its support organization.   >n >mJ > I want a new company management team to be responsible for VMS.  I don'tI > care much if it still within Compaq but free of the wanton stupidity oflA > concentrating on the PC market, or if it in a whole new company  > somewhere.   Whole-heartedly agree.  >   I believe that without these changes we will continue to getD > more of the same neglect that has dogged VMS for the last 5 years.  J No:  without these changes, VMS will rapidly either become comatose or die	 outright.h   - bill   ------------------------------  # Date: Thu, 29 Nov 2001 00:13:38 GMTy4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Future of VMS ?; Message-ID: <S4fN7.1589$29.1550706@typhoon.ne.mediaone.net>i  9 "Didier Morandi" <Didier.Morandi@gmx.ch> wrote in message   news:3C056431.8A6A9712@gmx.ch... > John McLean wrote: > >e) > > My recent postings about Compaq ../..a >sC > John, when do you start the "John Mclean knows COMPAQ" nwsletter?m >n  @ Well, he's welcome to start when I launch "Shannon KNEW Compaq!"  G Or even soomer... not being from the Andy Grove or Bill Gates school oftA thought, I happen to think that competition is good, both for thel> competitors and for the end users of the competitive products!   ------------------------------  % Date: Wed, 28 Nov 2001 20:51:32 -0600 % From: Keith Brown <kbrown780@isd.net>e Subject: Re: Future of VMS ?/ Message-ID: <u0b7ogbhdmfs52@corp.supernews.com>    JF Mezei wrote:    > John McLean wrote:G >> along.  If IPF slips by even a few months (as is Intel's habit) thengJ >> even more VMS users will desert it and quite possibly this will reach aI >> point where it casts doubt upon the viability of the porting exercise.R > J > On a certain angle, I disagree. The more IA64 is delayed, the longer theJ > remaining VMS customers still stay on Alpha. Customers will only migrateH > to IA64 if/when they are forced to or if the performance difference is > really worth all the trouble.t > J > The longer it takes for IA64 to materialise with some competitive speed,< > the longer Compaq will have to keep Alpha on life support. > K > I dare Compaq to come out in public and announce VMS , like MPE  is being I > terminated. Is it really worth the aggravation of witnessing VMS wither  > slowly day after day ? > I > The longer the slow agony of VMS lasts, the longer people who loved VMSn! > will be mad , saddened etc etc.C > K > Might as well get it over with ASAP, and perhaps 5-6 years down the road,iK > former VMS customers will have new decision makers who would not have anyg. > grudges against Compaq and return to Compaq.    G If Compaq kill VMS then I will never buy another product from Compaq.   B There will be no returning to patronize the vendor who screwed me.   -- r Keith Brown< kbrown780@isd.nete   ------------------------------    Date: 28 Nov 2001 20:47:19 -0600+ From: young_r@encompasserve.org (Rob Young)n Subject: Re: Future of VMS ?3 Message-ID: <GbYDkShIeL8t@eisner.encompasserve.org>s  \ In article <3C05647D.E2DA8D82@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Rob Young wrote:I >>         But as discussed before, Itanium servers today are quite a bit ' >>         cheaper than Alpha servers. t >  > Today ? Are you sure ? l > P > Is it a case of Alpha servers being artificially jacked up in price to prevent > their competing against PCs ?   ? 	No.  Do a Google search.  Exec Summary:  Bill asked me to back > 	up such "nonsense" and I trotted out Dell numbers compared to? 	fairly recent ES40 numbers... to which it became an issue that # 	those weren't Compaq IA64 numbers.l   				Robe   ------------------------------  % Date: Wed, 28 Nov 2001 22:00:04 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Future of VMS ?, Message-ID: <3C05A498.4997E7B1@videotron.ca>   Keith Brown wrote:G > If Compaq kill VMS then I will never buy another product from Compaq.aD > There will be no returning to patronize the vendor who screwed me.  L But as you change jobs, the guy who will replace you at your old job may notL have that anti-Compaq attitude and Compaq might be able to wine and dine him" to become a Compaq customer again.   ------------------------------  % Date: Thu, 29 Nov 2001 06:30:02 +01004, From: Didier Morandi <Didier.Morandi@gmx.ch> Subject: Re: Future of VMS ?& Message-ID: <3C05C7D9.5ADD5328@gmx.ch>   "Terry C. Shannon" wrote:l > B > Well, he's welcome to start when I launch "Shannon KNEW Compaq!"  	 Hi Terry,   ' well, you may start to prepare SKHP :-)l   D.   ------------------------------  # Date: Thu, 29 Nov 2001 05:42:00 GMTt* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Future of VMS ?B Message-ID: <IUjN7.168687$dk.12068132@bin1.nnrp.aus1.giganews.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:GbYDkShIeL8t@eisner.encompasserve.org...17 > In article <3C05647D.E2DA8D82@videotron.ca>, JF Mezei.& <jfmezei.spamnot@videotron.ca> writes: > > Rob Young wrote:K > >>         But as discussed before, Itanium servers today are quite a bits( > >>         cheaper than Alpha servers. > >. > > Today ? Are you sure ? > >bJ > > Is it a case of Alpha servers being artificially jacked up in price to preventr! > > their competing against PCs ?s >t@ > No.  Do a Google search.  Exec Summary:  Bill asked me to back? > up such "nonsense" and I trotted out Dell numbers compared toc@ > fairly recent ES40 numbers... to which it became an issue that$ > those weren't Compaq IA64 numbers.  J While the inability of Compaq to compete effectively with Dell on price isL indeed relevant to the question of whether Compaq could make Itanic boxes toL sell for less than Alpha boxes, a second issue was that the Dell product wasL in no way a match for the ES40.  And AFAIK you can still buy a DS10 for wellL under the price of even the cheapest (Dell) Itanic box.  Finally, additionalE discussion elicited the information that a large portion of the pricegG difference between an ES40 and a Dell Itanic box with considerably lessoI performance was attributable to Compaq's significant mark-up on the AlphasG memory (a mark-up which would apply equally to a Compaq Itanic box, one-H would assume - unless Alpha's significantly superior performance allowedB them to soak Alpha customers more, as seems to be the case today).   - bill   ------------------------------    Date: 29 Nov 2001 00:11:26 -0600+ From: young_r@encompasserve.org (Rob Young)u Subject: Re: Future of VMS ?3 Message-ID: <9pueAaha4WC3@eisner.encompasserve.org>   o In article <IUjN7.168687$dk.12068132@bin1.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:z > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:GbYDkShIeL8t@eisner.encompasserve.org... 8 >> In article <3C05647D.E2DA8D82@videotron.ca>, JF Mezei( > <jfmezei.spamnot@videotron.ca> writes: >> > Rob Young wrote:rL >> >>         But as discussed before, Itanium servers today are quite a bit) >> >>         cheaper than Alpha servers.i >> > >> > Today ? Are you sure ?- >> >K >> > Is it a case of Alpha servers being artificially jacked up in price tob	 > prevente" >> > their competing against PCs ? >>A >> No.  Do a Google search.  Exec Summary:  Bill asked me to back @ >> up such "nonsense" and I trotted out Dell numbers compared toA >> fairly recent ES40 numbers... to which it became an issue thate% >> those weren't Compaq IA64 numbers.e > L > While the inability of Compaq to compete effectively with Dell on price isN > indeed relevant to the question of whether Compaq could make Itanic boxes toN > sell for less than Alpha boxes, a second issue was that the Dell product wasN > in no way a match for the ES40.  And AFAIK you can still buy a DS10 for wellN > under the price of even the cheapest (Dell) Itanic box.  Finally, additionalG > discussion elicited the information that a large portion of the priceoI > difference between an ES40 and a Dell Itanic box with considerably lesstK > performance was attributable to Compaq's significant mark-up on the AlphaeI > memory (a mark-up which would apply equally to a Compaq Itanic box, one-J > would assume - unless Alpha's significantly superior performance allowedD > them to soak Alpha customers more, as seems to be the case today). >   * 	Signifcantly higher memory and cpu costs:  B 	Itanium servers are quite a bit cheaper than AlphaServers today,  	never mind the future.s  E 	Have you priced out 16 GBytes of memory for an AlphaServer lately?   F 	The memory is considerably more expensive for an AlphaServer.  I was I 	looking at 16 GBytes of AlphaServer memory... around $48000* U.S.  That hD 	same 16 GBytes of memory for a 4-way Itanium server is $25000 U.S.:  ` http://configure.us.dell.com/dellstore/config.asp?customer_id=04&order_code=pe7150&keycode=6w300  A 	What about quad processor?  If you load that Itanium box up withV> 	CPUs (4MByte L2 - top of the line at 800 MHz) you add a totalE 	of $20K to the cost.  That puts a quad Itanium server with 16 GByteseD 	of RAM, 4 CPUs at $63K U.S.  The same config for an ES40 would mostD 	likely be in the neighborhood of $115K U.S.  ($48K* for memory, 27KD 	base system, each processor add 13K.  I may be $10K low on the base 	system, but what's $10K ?).  B 	The cost of making that Dell system a quad-processor is $19000 , 7 	quite a bit cheaper than the cost to uplift an ES40 tonE 	quad status.  I don't expect that to change much when McKinley showsyD 	up, should actually go down as McKinley is in a smaller process and> 	L2 comes on CPU.  That separate L2 is very costly stuff.  You& 	are off the mark on McKinley pricing.  @ 	Itanium servers will continue to be substantially cheaper than D 	AlphaServers and CPU cost is - and will continue to be - a sizable  	factor.   				Robo    G *   8 - 2 GByte modules at $6000K each.  Cheaper than going 4 - 4 GByteh modules,      see for example:   c http://www.google.com/search?q=cache:b2a8v5mqzGc:www.geminidigital.com/specials.html+ms610-FA&hl=en    ------------------------------  % Date: Wed, 28 Nov 2001 21:35:47 +0000s1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>m Subject: Fwd: Peter J. Humble.6 Message-ID: <3C0558B3.3D3C4368@ipl.demon.co.nospam.uk>  A I'm not sure whether anyone has already seen this or not, but thelG following was sent to me earlier this week by a former colleague.  This D is all of the information I have.  Hopefully he has now found peace. Steve Reece.    I >Peter Humble collapsed with acute pancreatitis within the last fortnight'B >and has since been in Intensive Care at Croydon May Day Hospital.F >He died this weekend. I don't have any further details at the moment.   ------------------------------   Date: 28 Nov 2001 21:57:06 GMT) From: wkb@freebie.xs4all.nl (Wilko Bulte)r= Subject: Re: Gartner and IDC say HP will effectively kill DLT 9 Message-ID: <3c055db1$0$227$e4fe514c@newszilla.xs4all.nl>u  F In <9u2rc5$13i$1@plonk.apk.net> Chris Petersen <havoc@apk.net> writes:  7 >In comp.sys.dec Alan Greig <a.greig@virgin.net> wrote: @ >: More evidence of the supposed 'synergies' HP's Carly has beenG >: detailing to analysts seems to be emerging. In a feature on SuperDLTwF >: vs Ultrium in this week's "Computing" (UK) IDC and Gartner are bothH >: quoted as saying that DLT as originally developed by DEC and SuperDLTI >: as developed by Quantum will be dead end products after the HP merger. H >: Supposedly DLT/SuperDLT sales are still mainly through Compaq brandedD >: products or related sales. WIth HP a co-developer of Ultrium bothD >: Gartner and IDC predict that the new HP will phase out Compaq DLTH >: products in favour of Ultrium. Both further predict that Quantum willD >: not be able to keep SuperDLT alive without the backing of a major
 >: vendor.  C >: So there we have the final wreckage of yet another DEC developed D >: technology. First flogged off by Palmer then nailed stone dead by" >: Curly's love affair with Carly.  B >: I think I'll setup an IT analysis company. Then I can rake in aH >: fortune by simply inviting Carly and Curly for dinner then repeating,H >: for a fee of course,  whatever nonsense they whisper in my ear as "my >: predictions". >: --l >: Alant  M >I'll believe this one when I see it.  I just came off a 3 year contract at abK >major manufacturer's site in North Eastern Ohio.  We had a pretty good mixiD >of boxes, Compaqs, HP 9000 Unix machines, Dells, IBMs, and the onlyM >consistent backup media format was DLT.  Never seen so many DLT drives in mykK >life.  And I dealt with 3 other international locations of theirs that allm9 >specifically requested DLT drives with any new hardware.r  L >Heck, I spec'ed out some new HP 9000 A-class hardware for them a few monthsL >back and HP wouldn't even offer me an Ultrium drive in their "Unix" storageJ >lineup.  All they have for Unix & HP 3000-class machines are DATs and DLTL >drives.  If this is going to happen HP's really going to have to get behindK >Ultrium and push it, something they haven't done since they introduced thec >format 2-3 years ago...  M >I just can't see it happening, myself...Especially when HP just made a buncheF >of hoopla over introducing their first SuperDLT drive very recently. G >Actually, I've seen a new SuperDLT drive mechanism out there recently,oE >instead of the traditional 5.25" full-height form factor it's a moreuH >reasonable half-height form factor like a DAT drive.  And I believe theL >mechanism was being built by a new manufacturer other than Quantum, though C >I can't quite recall the builder's name.  I will say that having ae   Tandberg, from Norway.   W/ --- |   / o / /_  _   		email: 	wilko@FreeBSD.orgi1 |/|/ / / /(  (_)  Bulte		Arnhem, The Netherlands	w   ------------------------------  % Date: Wed, 28 Nov 2001 12:26:59 -0800 ' From: David Mathog <mathog@caltech.edu>  Subject: Go away Kenneth Lay+ Message-ID: <3C054893.626ADE5A@caltech.edu>l  H Anyone else been paying attention to the Enron scandal?  It seems that aC lot of extremely questionable business dealings took place. See forq	 instance:   8   http://dailynews.yahoo.com/h/ap/20011128/bs/enron.html  D The past and present CEO of that soon to be bankrupt company is none
 other than KennethpH Lay, who currently sits on  the Compaq BOD.  Shouldn't Q stockholders be	 demandingtH this guy leave the BOD ASAP?  I mean, do we really need to find out if a
 Q directorB can serve from his jail cell?  And assuming Mr. Lay doesn't resign! voluntarily - and soon - it wouldnH seem very appropriate for the rest of the BOD to throw him out (assuming they can).  And if theyiF don't, at the next stockholder meeting there's surely going to be hell to pay for letting him remain.  H I've got to add that, given recent Q actions, it surprises me not at all
 that a memberb@ of the Q BOD is riding his own company going down in flames over business ethics  and poor business practices.   Regards,   David Mathog mathog@caltech.edu   ------------------------------  % Date: Wed, 28 Nov 2001 12:32:45 -0800q' From: David Mathog <mathog@caltech.edu>b Subject: Go Away Kenneth Lay+ Message-ID: <3C0549ED.C83D67FE@caltech.edu>h  A Anyone else been paying attention to the Enron scandal?  It seems B that a lot of extremely questionable business dealings took place. See for instance:c  8   http://dailynews.yahoo.com/h/ap/20011128/bs/enron.html  ? The past and present CEO of that soon to be bankrupt company iso> none other than Kenneth Lay, who currently sits on  the CompaqB BOD.  Shouldn't Q stockholders be demanding this guy leave the BOD@ ASAP?  I mean, do we really need to find out if a Q director can> serve from his jail cell?  And assuming Mr. Lay doesn't resign? voluntarily - and soon - it would seem very appropriate for thetB rest of the BOD to throw him out (assuming they can).  And if theyA don't, at the next stockholder meeting there's surely going to bet# hell to pay for letting him remain.t  A I've got to add that, given recent Q actions, it surprises me not @ at all that a member of the Q BOD is riding his own company down; in flames over business ethics and poor business practices.w   Regards,   David Mathog mathog@caltech.edu   ------------------------------  # Date: Wed, 28 Nov 2001 22:08:46 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net>  Subject: Re: Go away Kenneth Lay; Message-ID: <OfdN7.1412$29.1467527@typhoon.ne.mediaone.net>S  4 "David Mathog" <mathog@caltech.edu> wrote in message% news:3C054893.626ADE5A@caltech.edu...nJ > Anyone else been paying attention to the Enron scandal?  It seems that aE > lot of extremely questionable business dealings took place. See forl > instance:g  B Yeah, they sure did. On the bright side, one of the apparent earlyI casualties was one "JrSysAdmin," an individual who graced this forum withr- some rather, umm, interesting commentary. ;-}-   No great loss!   ------------------------------  % Date: Wed, 28 Nov 2001 20:53:08 +0000m1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>- Subject: Re: HP/Compaq mergero6 Message-ID: <3C054EB4.5762445A@ipl.demon.co.nospam.uk>  E This may have been suggested elsewhere, but I'm a little behind on mya reading at the moment....n  D Should the HP-Compaq deal go ahead, maybe the thing for the combinedH company to do is to pull the non-PeeCee business under one banner calledG something like HP.  The PeeCee business could then be put under anotherdH banner (maybe Compaq) and be made to sink or swim.  Profitability on theG PeeCee side could be made more visible by setting it up as a subsidiarye company rather than a division.-  B Might make a few people within the PeeCee divisions of the present, companies wake up and smell the coffee......   Steve.   JF Mezei wrote:b > N > You know, I am not sure I really care about the merger. What I would like toN > see is Winkler given the boot and Compaq told that it should drop its wintelU > focus and leverage their VMS/Tru64/Alpha/Tandem businesses, including workstations.  > P > Perhaps there is better chance of that happening if Compaq is dropped and toldL > to reorganise by itself to survive. That might be a big enough slap in theM > face and vote of non-confidence to instill REAL change. But I am not reallyoK > convinced this would happen. It is more likely that the slap inb the face D > would tell Compaq to ficx its PC business to compete against Dell. > N > I am still wondering if the PC business will eventually come to be dominated2 > by Asians with US companies not able to compete.   -- nG "A shadow fell over her face; clear, as if the composure were rent liketE a veil.  And her lips parted, but only with a short intake of breath.lA Then she said, 'Well, then you are right.  Indeed, we are even.'"c% 		Louis, "Interview with the Vampire"    ------------------------------  # Date: Wed, 28 Nov 2001 22:10:24 GMTw4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: HP/Compaq mergert; Message-ID: <khdN7.1413$29.1468446@typhoon.ne.mediaone.net>a  > "Steve Reece" <SYSTEM@ipl.demon.co.nospam.uk> wrote in message0 news:3C054EB4.5762445A@ipl.demon.co.nospam.uk...G > This may have been suggested elsewhere, but I'm a little behind on myv > reading at the moment....o >_F > Should the HP-Compaq deal go ahead, maybe the thing for the combinedJ > company to do is to pull the non-PeeCee business under one banner calledI > something like HP.  The PeeCee business could then be put under anothernJ > banner (maybe Compaq) and be made to sink or swim.  Profitability on theI > PeeCee side could be made more visible by setting it up as a subsidiaryu! > company rather than a division.  >vD > Might make a few people within the PeeCee divisions of the present. > companies wake up and smell the coffee......  L Could be. Seems to me that the peecee space is a veritable leech on Compaq'sG profits. A de-leeching might be in order, so that more modern emergencynK medical techniques could be employed in an effort to restore the patient to- health.-   ------------------------------  # Date: Wed, 28 Nov 2001 19:22:44 GMTe  From: jlsue <jlsuexxxz@home.com>* Subject: Re: logical names novice question8 Message-ID: <0ada0ug386b0fbif2q68s7cckbjpaavnv5@4ax.com>  B If logicals are used correctly in your application, you can alwaysE check-for, and remove any process-level logicals that try to overridey system-level logicals.  B However, I've found this process-level override to be very useful.; Taking a cue from the JCL DD statements, I began developingmD applications such that all data files are opened via a logical name.= Now, for most users this logical name is in the system table.M8 However, when there's something I need to do in testing,F troubleshooting, etc., I would define my process-level logical name toF point to a non-production data file instead.  This eliminated the needF for commenting code between development->test->production (and all theB inherent possibilities of forgetting to comment important lines ofB code).  The code would remain *exactly* the same between the three
 environments.$  D I have also worked with applications that had their own logical nameE tables - ever use SLS or TAPESYS?  The benefits of these app-specificgD tables is that most of the names are not of use to the general usersE of the system, and thus you don't want a typical SHOW LOGICAL commandtB to list them all.  Also, you can protect the individual lnm tablesF such that you can control who has access to the logical names as well.  C I have run into many problems with vendors who try to play with therA LNM$FILE_DEV definition to stick their tables in the search list. D Some of them *assume* a specific list (and order) of entries in thatD logical translation.  Then along came the decwindows table, and many? things went haywire all of a sudden.  And when VMS 7.3 adds theoB cluster-wide table, the process breaks once again.  Of course, theC simple solution is to not "assume" the make-up of LNM$FILE_DEV, buthD instead decompose it and re-build it on-the-fly (i.e., when needed).A You'd be surprised how many vendors don't get this right, though.   E The flexibility of logical names is an amazingly powerful part of thefE VMS operating system.  When I tended VMS systems & clusters it was mye= practice create at least one system-level logical for *every*fD application I installed (and there were over 250 on one VMScluster).B Take for example MASS11 - I'd create a system-level logical calledE M11$DISK (define/sys/trans=(conc,term) m11$disk dua0:).  I'd use thisbD in the installation of the product - and with some products I'd haveE to go back and edit the startup files to make use of the logical nameeC appropriately.  The benefit of this was that, if dua0 began filling2F up, or became bogged-down with I/O load (probably not as big a problemA today), I could copy the product directory to another disk (usingrD BACKUP), and often "uninstall" the images, define the logical to theF new place, and re-execute the product startup.  Many, many times I didF this on a running system and was able to alleviate bottlenecks without. causing any outage from an end-user viewpoint.1 Not speaking for anyone, certainly not DEC/Compaqn- (get rid of the xxxz in my address to e-mail)r   ------------------------------   Date: 28 Nov 2001 13:00:17 CDT= From: wayne@tachysoft.xxx.524703.killspam.00bd (Wayne Sewell)>* Subject: Re: logical names novice question. Message-ID: <U69bH5DgK0ZC@tachxxsoftxxconsult>  [ In article <0ada0ug386b0fbif2q68s7cckbjpaavnv5@4ax.com>, jlsue <jlsuexxxz@home.com> writes:r   [stuff deleted]  > F > I have also worked with applications that had their own logical nameG > tables - ever use SLS or TAPESYS?  The benefits of these app-specificeF > tables is that most of the names are not of use to the general usersG > of the system, and thus you don't want a typical SHOW LOGICAL commandnD > to list them all.  Also, you can protect the individual lnm tablesH > such that you can control who has access to the logical names as well. >   O Another benefit is that you can get rid of the whole table in one shot.  During I tapesys shutdown, it is not necessary to deassign all the logicals.  Justi3 deassign the table logical and the table goes away.n       [stuff deleted]r   -- tO ===============================================================================rM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxc: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O ===============================================================================iN Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------   Date: 28 Nov 2001 20:36:13 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones)o* Subject: Re: logical names novice question: Message-ID: <9u3hrt$shn$1@charm.magnus.acs.ohio-state.edu>   Pino Gargiulo wrote:E > Any body care to give me an example of sofisticate use of logicals?n >u  M At my site, we attempt to do near-real-time enforcement of page print quotas.0C One of the components of this setup is a daemon that defines in itsVG LNM$PROCESS_DIRECTORY logical name table the name LNM$TEMPORARY_MAILBOXK? as LNM$GROUP_000001 and then creates a temporary mailbox with aoD logical name of ACCOUNTNG.  It then tells the job_control process toG start a new accounting file via SYS$SNDJBC(), effectively directing all D accounting records to this daemon's mailbox.  By putting the name in; the group table, only system processes see the redirection.m      < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:pL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  1 Disclaimer: I'm looking for marbles all day long.e   ------------------------------  # Date: Thu, 29 Nov 2001 04:40:09 GMTn3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk> * Subject: Re: logical names novice question/ Message-ID: <3C05BB67.9DE9C91C@cableinet.co.uk>0   "Richard D. Piccard" wrote:  > K > Once upon a time, on a VAX long since retired, we had both Tektronix 4010cM > emulating terminals and ReGIS graphics terminals.  We didn't have enough of-I > either type for the number of students who should use them, so we got a O > licensed copy of the source code for PLOT-10 (which, in my limited experienceDM > at the time, set a new extreme for FORTRAN spaghetti-code) and made another Q > copy that had all the same subroutines and arguments, but which generated ReGIS Q > output.  Each subroutine library got built into a sharable executable.  One wasoQ > then linked to the program code by way of a logical name.  When you sat down tonO > run the program, all it took was redefining that logical name in order to uses > the other type of terminal.I >   J yeah, I used a human interface package that had VT, UIS and Motif bindingsN that worked the same way, decide which one to use at run time using a logical.  4 Oh dear you reminded me of PLOT10 and Tek 4010's :-)   -- e Tim.Llewellyn@cableinet.co.uk  c  C Standard disclaimer applies. My views in no way represent those of n! my employers or service provider.p   ------------------------------    Date: 28 Nov 2001 16:23:34 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen):? Subject: Re: New product allows VMS to become part of a PC Lan!r3 Message-ID: <Mb4QyUKM4nWY@eisner.encompasserve.org>D  c In article <LKB0LPX64wO1@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes: j > In article <d7791aa1.0111271509.4f1bf490@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes: > F >> Just ran across this amazing product as we were looking to make our >> AlphaB >> VMS system part of our local PC Lan and ran across this amazing >> product ...H >> they also have a product that allows VMS pc disk access ... amazing! 
 >> here is' >> the link if anyone is interested ...h > J >    Nothing like being 15 years behind the times, and 10 years behind the >    freeware.  > It looks suspiciously like the first message I ever saw postedA by Bob Ceculski (a few months ago, before he was in my killfile).   > Perhaps he is repeating the information about his product just0 to let us know he has learned how to capitalize.   ------------------------------  % Date: Wed, 28 Nov 2001 18:53:41 -0500 6 From: "norman lastovica" <norman.lastovica@oracle.com>< Subject: News on Oracle Rdb port to Itanium Processor Family4 Message-ID: <pYeN7.95$9f2.8834@inet16.us.oracle.com>   Dear Rdb Customer:  ? On June 29, shortly after Compaq announced plans to consolidaten  E Compaq's entire 64-bit server family on the Itanium architecture fromD  C Intel, I wrote to you regarding Oracle Rdb, Oracle CODASYL DBMS ando  @ the Itanium Processor Family. At that time, I said we would work  @ closely with Compaq and our customers to determine the best path  : forward for Rdb. I am writing to you now with an update on  9 developments regarding a port of Rdb and DBMS to Itanium.y  F From our discussions with you, our customers, over the past months, it  C is clear that many of you are very interested in seeing Oracle Rdb,a  A Oracle CODASYL DBMS and Oracle9i available on OpenVMS on Itanium.f  E As a result of this interest, Juan Jones, Oracle's Vice President fora  @ the Systems Platforms Division, recently, released the following  
 statement:  7 Oracle and Compaq have a long and successful history ofr  < delivering enterprise solutions to our OpenVMS customers. In  8 July, Oracle released Rdb 7.1 for OpenVMS. In September,  8 Oracle9i for OpenVMS was released. Given Compaq's recent  = announcement to consolidate its 64-bit servers on the Itanium,  < Processor Family (tm), Oracle's current plan is to team with  < Compaq and work toward a delivery of Oracle Rdb and Oracle9i  : for OpenVMS on IPF based upon Compaq's current engineering   roadmap.  F Consistent with this direction we have developed a preliminary project  C plan for our porting activities for both Rdb and CODASYL DBMS. Thisw  A preliminary plan was developed with the assistance of the OpenVMSe  > Engineering Group at Compaq. This plan is based on the current  ( delivery dates provided to us by Compaq.   Highlights of the plan include:e  D * By early next year, Compaq will provide us with cross compilers to  < allow us to begin initial testing of our code in the Itanium   environment.  @ * In 2003, Compaq will deliver to us and their other partners an  C early version of OpenVMS for Itanium that will allow us to completel  : the port and begin testing of Rdb in this new environment.  > * In 2004, Compaq will deliver the first production release of   OpenVMS on Itanium.   @ Oracle normally ships supported versions of Rdb and CODASYL DBMS  D within 90 days of Compaq's production release date for new operating  A systems and processors. Assuming Compaq delivers Itanium softwared  E according to their announced schedule and that this software performsb  D as expected, we will deliver the first production release of Rdb and  F CODASYL DBMS for Itanium within 90 days of Compaq's production release   date for OpenVMS on Itanium.  E These are still early days and Compaq's plans and road maps are still   D evolving. We expect to learn more as we and Compaq progress with our  ? respective porting efforts. In the meantime we will continue too  0 enhance and improve Rdb on the OpenVMS platform.  C We will provide an updated report on our progress on Itanium at the   E Rdb Forum at Oracle Headquarters near San Francisco on December 1 andd  E 2 as well as at other Rdb Forums to be scheduled throughout the worldn  A in 2002. I hope to see you at one of these events. (You can stilll  D register for the Forum at our web site, http://www.oracle.com/rdb/.)  
 Best regards,    Kevin Duffyn   Oracle Rdb Development Directors   ------------------------------  % Date: Wed, 28 Nov 2001 16:57:22 -0500p4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq>M Subject: Re: Offtopic: cross platform portability tools - a study of autoconfs4 Message-ID: <3C055DC2.6050007@dskwld.zko.dec.compaq>   Patrick Spinler wrote:  E  > From time to time the topic of porting tools of unix origin to VMS ?  > comes up in this newsgroup.  Often the "portability" package F  > "autoconf" is cited as a major problem in getting the package under  > discussion running on VMS.-  G Anything that eases programming on OpenVMS should be on topic for this n forum.  I While it is inherently difficult to port autoconf with out having a 100% 7A GNU programming environment, close functionality can be achieved.g  F Most of the problem is solved by doing a search against the reference @ copy of the Compaq C header files, and the contents of the file G config.h.in or the many other names that it could un(g)zip or detar to.   H A small bit of DCL programming is able to do that nicely.  Of course to A be more correct, it should search the shared image and tlb files.a    D But I have recently discovered that some of autoconf's tests may be H returning incorrect answers because of the testing methods are assuming F that the C compiler has a minimal level of optimization, and that the I associated run time libraries only provide support of one incarnation of p; the various ways that a function may have been implemented.i  C This of course is package dependent, and may only be affecting the d2 particular packages that I have been playing with.  F This results in autoconf indicating that a feature is either broken orF unimplemented simply because the test C program that it generated did E not include the proper header files, so the compiler defaulted to be    compatible with older practices.   > 2 > Those following these topics may find this paperH > http://www.cs.columbia.edu/~ezk/research/amu/autoconfiscating_amd.htmlD > of interest.  It chronicals one package maintainer's experience inA > porting his package (amd - the Berkeley auto mounter daemon) to  > autoconf.h > E > While the particular package ported is likely of little interest to J > VMSers his conclusions are still interesting.  For instance, as a resultG > of autoconfing, he was able to reduce his code size from 49k lines tooI > 30k lines, and reduce his code's conditional complexity (as measured byoI > the number of C "#ifdef" statements per hundred lines of code) from 9.7n! > per hundred to 6.5 per hundred.     I  From personal experience of seeing the resulting source code of a large pF package, that number can be missleading.  One side effect is that you F end up with a master include file that includes every possible header  file that any module.d  D This pushes up the overhead for all the compiles, and lengthens the G build times.  But that two can be fixed, by adding a few of the dreadedA #ifdefs.  I Now does this conditional complexity measure the number of #ifdef's that nE   the compiler sees, or only the number left in the code?  Of course V@ that could open up the debate of which number is more important.      D And of course any change to this master include file, or any of the F project specific include files that it pulls in, must be configure to E rebuild the world, even if that include file is only used by a small  H fraction of the modules in the package.  Again, this greatly slows down ? the build process, and thus the porting process of the package.e  I You can actually add several hours to the compilation time if you have a  H big enough project just from the incremental extra load on the compiler.    E > After reading this, I'd draw the conclusion that unix based packagehI > authors have a powerful motivation for autoconfing their code, and thatiE > we in the VMS world are likely to be stuck with having to deal witheC > this.  It seems likely that we'll either have to make ourselves a J > working autoconf facility, provide some similar package that runs on VMSH > but is compellingly better enough to tempt authors away from autoconf,? > or be stuck in our current "unix code == hell" statis for thec > indeterminate future.o    H What ever the reason, if you are trying to make sure an OpenVMS variant E of a program that uses autoconf is current, you have to deal with it.-    D And another issue with Autoconf, is that it is self modifying code, H starting from a set of template files, and is then mixed with some hand F coded files, and then run iteratively on the target platform until it F gets the results expected.  Hand tweaking is done by someone familiar F with the package.  [Check the CVS logs of the package to see the hand  tweaks.]  E So autoconf is a good concept.  It is just that it's implimentation, eJ inspite of what is implied is manual, except for the simplest of packages.  D Autoconf works well on a particular platform and package as long as I there is someone manually babysitting it.  Go to a UNIX variant that the uG   package has never been built on, and autoconf may or may not work at  I all.  It just depends on how closely that UNIX variant looks like one of n4 the ones that someone manually tweaked autoconf for.    H But instead of trying to exactly implement autoconf, maybe it is better F to just look at what inputs it uses, and what it is trying to output, B and then just find a better way of doing so.  Since for any major @ package, the autoconf files are hand tweaked by each platform's F maintainer and then merged back where they may interfere with another H platform, it really is no more difficult to maintain a DCL VMS specific * implementation written in DCL or whatever.    8 Of course this just covers generating the config.h file.    ; I have found it is faster to generate the MMS file by hand.t    I I could probably automate that part, but so far, while the config.h file  H may change a lot from minor releases, the MMS file seems to only change D when a module is either added or removed.  And the MMS files that I E generate to take advantage of OpenVMS features, do not look anything d' like the source UNIX makefile.in files.-   -Johne malmberg@dskwld.zko.dec.compaq Personal Opinion Onlye   ------------------------------  % Date: Wed, 28 Nov 2001 23:33:02 +0100o& From: Michael Joosten <joost@c-lab.de>M Subject: Re: Offtopic: cross platform portability tools - a study of autoconfu$ Message-ID: <3C05661E.1F1A@c-lab.de>   John Malmberg wrote: >   J > While it is inherently difficult to port autoconf with out having a 100%C > GNU programming environment, close functionality can be achieved.f >   B One should distinguish between the need to have a 'GNU programming< environemt' for creating autoconf files/setup and just usingD ./configure, which should not require a 'GNU' but rather/only a UNIX programming/tool environment.e    G > Most of the problem is solved by doing a search against the referenceiA > copy of the Compaq C header files, and the contents of the filefI > config.h.in or the many other names that it could un(g)zip or detar to.l >    Yes, this is also my feeling.   I > A small bit of DCL programming is able to do that nicely.  Of course todC > be more correct, it should search the shared image and tlb files.a >   E But, still, it should be possible to have VMS 'profiles' which simply 6 detail which functionality is available and which not.    H > This results in autoconf indicating that a feature is either broken orG > unimplemented simply because the test C program that it generated did-F > not include the proper header files, so the compiler defaulted to be" > compatible with older practices. >   H That alone is one of my arguments against having autoconf such a 'let meF see if I can figure out this and that and...' approach. Not to mentionB that you definitely don't want to use that on an old, underpoweredH machine. Again, preconfigured 'profiles' like config.cache.${OS} withoutE the installation-specific parts like installdir would be good thing. s      I > > of autoconfing, he was able to reduce his code size from 49k lines to K > > 30k lines, and reduce his code's conditional complexity (as measured byoK > > the number of C "#ifdef" statements per hundred lines of code) from 9.7 # > > per hundred to 6.5 per hundred.  >   @ Though 'amd' is just the sort of program that I rather would notG 'autoconfiscate'. Far too many nitty-gritty details and dependencies onsH OS (Unices) specific stuff. A good example of 'Used a new platform (like6 Mac OS X), and ./configure bombed on me'. Of course...  E I went through this with 'PLP', the precursor of 'LPRng' (then by the=G original author of 'plp', Patrick Powell). Porting it back to old boxeshG running BSD 4.2 and 4.3 variants needed additional tests to be written,hF and sometimes these tests could not be performed because the behaviourA was only visible if running as 'root' (set(e)uid() and the like).=    G > > After reading this, I'd draw the conclusion that unix based packageeK > > authors have a powerful motivation for autoconfing their code, and that-G > > we in the VMS world are likely to be stuck with having to deal with E > > this.  It seems likely that we'll either have to make ourselves a L > > working autoconf facility, provide some similar package that runs on VMSJ > > but is compellingly better enough to tempt authors away from autoconf,A > > or be stuck in our current "unix code == hell" statis for theu > > indeterminate future.t >   C Mostly, the motivation is partly the already existing framework andiC partly that it is now considered 'ill mannered' if you provide yourn& portable software without autoconf....       > E > Autoconf works well on a particular platform and package as long as J > there is someone manually babysitting it.  Go to a UNIX variant that theH >   package has never been built on, and autoconf may or may not work atJ > all.  It just depends on how closely that UNIX variant looks like one of6 > the ones that someone manually tweaked autoconf for. >    Exactly.  I > But instead of trying to exactly implement autoconf, maybe it is better.G > to just look at what inputs it uses, and what it is trying to output,uC > and then just find a better way of doing so.  Since for any major-A > package, the autoconf files are hand tweaked by each platform'siG > maintainer and then merged back where they may interfere with anothernI > platform, it really is no more difficult to maintain a DCL VMS specificd, > implementation written in DCL or whatever. >   D Yes! Just as the 'vms' directories of Emacs 19 and so on have used aE hand-crafted config.h.vms, it should be possible to solve most of thetH #define HAS_XXX_H or #define HAS_XXX by a static profile with a (perhapsF DCL proc) that parses config.h.in, compares the used HAS_ XXX with the( profiles and fills in the right answers.  : > Of course this just covers generating the config.h file. > = > I have found it is faster to generate the MMS file by hand.p > J > I could probably automate that part, but so far, while the config.h fileI > may change a lot from minor releases, the MMS file seems to only changenE > when a module is either added or removed.  And the MMS files that InF > generate to take advantage of OpenVMS features, do not look anything) > like the source UNIX makefile.in files.o >   A So, automating this makes no sense? One could still submit such am% hand-made MMS file to the maintainer.dD On the other hand, would it make sense to 'extend', say, GNU make toC have built-in functions and rules that are the right ones for VMS ?h     --  * Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  # Date: Thu, 29 Nov 2001 05:21:26 GMTe- From: "John E. Malmberg" <wb8tyw@qsl.network>pM Subject: Re: Offtopic: cross platform portability tools - a study of autoconf7* Message-ID: <3C05CC77.1060906@qsl.network>   Michael Joosten wrote:    > John Malmberg wrote:>  >E  >> While it is inherently difficult to port autoconf with out havingpB  >> a 100% GNU programming environment, close functionality can be
  >> achieved..  >>>E  > One should distinguish between the need to have a 'GNU programming ?  > environemt' for creating autoconf files/setup and just usingtG  > ./configure, which should not require a 'GNU' but rather/only a UNIXf   > programming/tool environment.  I Unfortunately some of the configure scripts are specifically looking GNU bG   specific tools to run the tests.  If that tool at a minimum required  9 version level has not been ported to the platform, no go.o  H There was some debates on one of the packages's public developer's list D about what tools they could assume could be on the target computer. @ They wanted to use some special GNU tool during the setup phase.E I do not remember which one.  The consensus was that it would not be  9 available on some of the existing supported UNIX targets.l  H But other packages may not take the care to just use the tools that are  normally on a target platform.   [snip]  >H  >> A small bit of DCL programming is able to do that nicely.  Of courseA  >> to be more correct, it should search the shared image and tlbo
  >> files.  >>sH  > But, still, it should be possible to have VMS 'profiles' which simply9  > detail which functionality is available and which not.   H It is an issue of maintaining the 'profiles'.  The problem is that we doI not know in advance what small snippet of information that the configure e script will be looking for.a  C There are some conventions that make it easier, but there are some n! things that are done differently.   H Of course there is also the case where the program totally ignores what   the configure program generated.  I  > and sometimes these tests could not be performed because the behaviourSD  > was only visible if running as 'root' (set(e)uid() and the like).  E I forgot about those type of tests, especially the ones that want to nI find out if your set(e)uid() and setgid() really work.  They are looking yA for "trap door" systems.  Ones that allow a daemon to lower it's a% privileges, but not raise them again.i  A  >> It really is no more difficult to maintain a DCL VMS specificd-  >>implementation written in DCL or whatever.d  >G  > Yes! Just as the 'vms' directories of Emacs 19 and so on have used abH  > hand-crafted config.h.vms, it should be possible to solve most of theB  > #define HAS_XXX_H or #define HAS_XXX by a static profile with a@  > (perhaps DCL proc) that parses config.h.in, compares the used=  > HAS_ XXX with the profiles and fills in the right answers.q  G The information is already in the Compac C header files.  However it isnC not easy to detect if the feature is only available for a specific lB version of OpenVMS with out actually writing a program to let the * compiler determine if the option is there.  I That is if you are looking for 100% accuracy.  If you can tolerate a few ,I   wrong guesses, the look up program is not hard to tweak for a specific   package.  E The more config.h.in from packages that are processed by the command aG file to find the syntax variations, the more useful the script becomes r for general purpose.  G Then to catch the exceptions, what I do is have the generated config.h  ! file then #include "config_vms.h"e  H The config_vms.h file contains all of the manual edits needed to handle 5 what the automated process could not guess correctly.r  > It also handles things encountered during the porting process.   [make file generation]D  > So, automating this makes no sense? One could still submit such a(  > hand-made MMS file to the maintainer.G  > On the other hand, would it make sense to 'extend', say, GNU make todF  > have built-in functions and rules that are the right ones for VMS ?  7 That assumes that you want to have GNU make in use. :-)e  H It is the issues on how to make shared images and object libraries that A are useful.  Any tool can be used, it is just that the resulting uE makefile or mms script will not really have much relationship to the u source template.  I I have been making the assumptions that the maintainers of the UNIX port pE will not make any accomodation for OpenVMS, or such accomodation may 0F dissapear with a later release because a programmer would not realize.  F So I keep the VMS specific source separate, and use logical names and # search lists to set the precedence.@  E I have started to use TPU edit scripts when I must patch an original t@ source module, so that I have less modules to manually maintain.F If the UNIX maintainers accept the changes into the build, then I can  remove the patch scripts.i  H And since the hobbyist license includes CMS, I use one set of libraries C to track changes from the UNIX sources, and a different set of CMS  ' libraries for the VMS specific sources.n   -Johnt wb8tyw@qsl.network Personal Opinion Onlyn   ------------------------------    Date: 28 Nov 2001 13:22:57 -0800< From: alphaman-nixspam@hsv.sungardtrust.com (Aaron Sakovich) Subject: Re: PGP for OpenVMS= Message-ID: <8af17fe1.0111281322.5d061777@posting.google.com>   m hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<NDVM7.2019$RL6.62489@news.cpqcorp.net>... M >   You'll also want to look at/for GnuPG, as well.  I do not know if a port n( >   of that tool exists for OpenVMS yet.   Hoff, et. al.,  E Yes, it does.  A Google groups search of comp.os.vms for gnupg shouldtF turn up some pointers from myself and Dave Mathog regarding his port. C This program is compatible with current revs of PGP and runs rather D nicely on OpenVMS.  It is also many years newer than the 2.6 version of PGP for OpenVMS!e   Aarona   ------------------------------  # Date: Wed, 28 Nov 2001 23:37:31 GMTi2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: PGP for OpenVMS3 Message-ID: <%yeN7.2075$RL6.63105@news.cpqcorp.net>t  | In article <8af17fe1.0111281322.5d061777@posting.google.com>, alphaman-nixspam@hsv.sungardtrust.com (Aaron Sakovich) writes:n :hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<NDVM7.2019$RL6.62489@news.cpqcorp.net>...N :>   You'll also want to look at/for GnuPG, as well.  I do not know if a port ) :>   of that tool exists for OpenVMS yet.r :e :Hoff, et. al.,e  I   I didn't run a search for it, I just figured I'd mention its existence.f  F :Yes, it does.  A Google groups search of comp.os.vms for gnupg shouldG :turn up some pointers from myself and Dave Mathog regarding his port. sD :This program is compatible with current revs of PGP and runs ratherE :nicely on OpenVMS.  It is also many years newer than the 2.6 version  :of PGP for OpenVMS!  N   And y'all were planning on submitting it to the OpenVMS Freeware _when_? :-)  J   But rather more seriously, the US regulations around the exportation of K   encryption have changed in recent times, and I should be able to provide tJ   versions of most open-source encryption packages -- those with less thanF   the military-grade encryption threshold -- via the OpenVMS Freeware.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 28 Nov 2001 19:01:48 +0000t! From: Andy Burns <andy@burns.net>e6 Subject: Re: Problem fseeking a 4.2 million block file8 Message-ID: <02da0u88easj4gtbke1oujcm2vpooarl6t@4ax.com>  A On 28 Nov 2001 10:44:53 -0800, steve_p@trigent.com (Steve Porter)  wrote:  % >Since fseek expects a signed int forsB >the offset, will there be a problem if the offset passed in is soA >large it 'overwrites' the sign bit?  Will this affect subsequentfB >fseeks, assuming all fseeks start from the beginning of the file?  F rather than doing absolute seeks from the start of the file, could youA try relative seeks for a point already seeked to halfway into thewB file? or pehaps absolute seeks from the end rather than the start?   messy I know ... -- f
 Andy Burns   ------------------------------  # Date: Wed, 28 Nov 2001 23:32:46 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)6 Subject: Re: Problem fseeking a 4.2 million block file3 Message-ID: <yueN7.2074$RL6.63167@news.cpqcorp.net>n  h In article <4983a326.0111281044.688c9ddd@posting.google.com>, steve_p@trigent.com (Steve Porter) writes:      Follow-ups set to comp.os.vms.  @ :I have an application that performs an fseek on a file that hasF :recently grown to be 4.2 million blocks.  The VMS version is 7.1; theG :application uses DEC C V6.0-001. Does anybody know of any issues fseeksG :has accessing a file this large?  Since fseek expects a signed int foraB :the offset, will there be a problem if the offset passed in is soA :large it 'overwrites' the sign bit?  Will this affect subsequentoB :fseeks, assuming all fseeks start from the beginning of the file?  C   All current versions of the C RTL have limits on the size of the e:   file, when using C calls such as fseek or lseek or stat.  B   The limit is a result of the current longword size of the off_t    field.  B   An extension to the size of the off_t field is expected in the CE   RTL to be shipped with a future version of OpenVMS Alpha.  My best t2   current guess for shipment of this is in V7.3-1.  C   Please see the OpenVMS Ask The Wizard topics (6916), (6884), and e@   (1550) for details on the limits, code that allows you to get B   around this, and on some related file system operations details.  7   I've queued some text to the next edition of the FAQ.e    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 28 Nov 2001 19:30:49 GMTo  From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Q: How to check if a file is opened?r8 Message-ID: <nqea0u0932ho2mf56sobhugfoa87aqt02p@4ax.com>   What do you do in a VMScluster?l  0 On Wed, 28 Nov 2001 09:31:59 -0500, WILLIAM WEBB <WWEBB1@email.usps.gov> wrote:   >e# >Here's an example of how I did it.- >-6 >I wanted it to *not* be open, so I used .nes. to make >that option come up first.s > ! >It's kinda kludgy, but it works.o >:@ >$ show dev/files/nosystem/out=xtmp.txt disk_that_the_file_is_on; >$ search/nooutput xtmp.txt filename_you_want_to_know_about  >$ file_search_status = $statust+ >$ if file_search_status .nes. "%X00000001"  >$ thenn >n: >  [then filename_you_want_to_know_about doesn't appear in: >   the search, which means that the file *isn't* opened.] >  >$ elset >o >  [file is open]  >e >$ endif >u >$ delete/nolog xtmp.txt;* >o >Hope this helps,G >  >WWWebbr >l >-----Original Message-----v0 >From: Info-VAX-Request@Mvb.Saic.Com at INTERNET+ >Sent: Wednesday, November 28, 2001 8:53 AMyC >To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNETg2 >Subject: RE: Q: How to check if a file is opened? >  >a >Dmitry Bessonov wrote:s >>I >> A file is opened and can be seen in SHOW DEVICE/FILES output. Is thereyH >> a way to determine in DCL command procedure, if the file is opened on1 >> this node or not? I thought it can be done vial >o@ >It the file is opened using DCL, an F$TRNLNM("logical-name") is >non-blank.  >c >e.g.  > , >$ OPEN/READ datafile disk:[dir]filename.ext >..e5 >$ IF F$TRNLNM("datafile").NES."" THEN CLOSE datafilee >sH >Perhaps if your application also uses a logical name, you can translate5 >that logical for that processes' logical name table?e  1 Not speaking for anyone, certainly not DEC/Compaq - (get rid of the xxxz in my address to e-mail)I   ------------------------------  # Date: Thu, 29 Nov 2001 04:56:02 GMTd4 From: "Terry C. Shannon" <terryshannon@mediaone.net>D Subject: SKC Musings on "Recent IPF Unpleasantness" at www.tru64.org; Message-ID: <CdjN7.1677$29.1742554@typhoon.ne.mediaone.net>    Folks,  @ Given the controversy that my special SKC issue entitled "CompaqF Cartographers Drew the IPF Roadmap" (.html | .pdf) precipitated when IK posted the piece, it seemed like the best thing to do was wite a follow-up.eL If you haven't read the original document, feel free to do so. Draw your ownJ conclusions, but please take a moment to review the follow-up as per below (Nov 10, 2001)         Shannon knows Compaq&       An Outpouring of Alphacide Angst       (Nov 28, 2001)      F And remember, the Encompass US Inc. Board of Directors election is nowB underway. Be sure to take the time to download the PDF ballot from  0 http://www.encompassus.org/whatsnew/bodElec.html    J For those of you who are members of Encompass US Inc, the time has come to? cast your vote for the four open BoD slots this election cycle.r  K The Encompass BoD ballot is available in PDF format from the aforementioned)> URL. Please take the time to download the PDF and vote for theG candidate(s) of your choice. You have the option to vote for up to fourr/ candidates or a lesser number of your choosing.    Thank you for your support!k         -- Terry C. Shannon Consultant and Publisher Shannon Knows Compaq% Director at Large, Encompass US, Inc.o  email: terryshannon@mediaone.net3 Web (info on SKC):  www.acersoft.com, www.tru64.orgt   ------------------------------  # Date: Wed, 28 Nov 2001 21:21:43 GMTr  From: "jmd" <jmd5@earthlink.net>$ Subject: Re: Some Multia Help needed: Message-ID: <20011128.131931.492067917.4934@earthlink.net>  > In article <9u0rb0$1vvl$1@info.cs.uofs.edu>, "Bill Gunshannon"" <bill@triangle.cs.uofs.edu> wrote:  @ my multia had a card similar to yours. i thought it was useless.  = you might try: http://www.starshipcorp.com/starshipcomputers/a  D a bit pricey but there are some good products there. also a *latest*F firmware. i understand this firmware allows for booting VMS too (don't	 quote me)e  G ebay has dec multias often and recently the prices have plummeted. pulle* the necessary parts from it and resell it.   hth  jeff duncane  H > After a long wait, the price of parity memory has suddenly dropped andF > it looks like I will get to try running the Multia I got from island > some time ago. > ; > But, I have some hardware questions if nobody here minds.t > J > The PCI riser in my box has no connectors on it.  It looks like it had aI > 50 pin cable, which likely went to the internal hard disk, but that wasnJ > apparently pulled off at some point. There appear to be locations on the< > riser for a mini-scsi connector and even for a PCI socket. > D > Now the questions.  can I assume that if I soldered a cable to theH > mini-scsi spot on the board and mounted a connector on the back of theI > case it would work??  Can I also assume that if I soldered a PCI socket I > on the riser I could use something like an Adaptec scsi card to give men > external SCSI capabilities?? > H > One last question.  I read somewhere that the SRM can be updated usingJ > MOP.  Can I also assume this machine can be booted from the network if I( > have a suitable MOP server available?? > I > Thanks for any help.  I look forward to seeing what this little box canS > actually do. >  > bill >a   ------------------------------   Date: 28 Nov 2001 21:55:18 GMT) From: wkb@freebie.xs4all.nl (Wilko Bulte)u$ Subject: Re: Some Multia Help needed9 Message-ID: <3c055d45$0$221$e4fe514c@newszilla.xs4all.nl>r  W In <9u0rb0$1vvl$1@info.cs.uofs.edu> bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:c  C >After a long wait, the price of parity memory has suddenly droppedoB >and it looks like I will get to try running the Multia I got from >island some time ago.  : >But, I have some hardware questions if nobody here minds.  G >The PCI riser in my box has no connectors on it.  It looks like it had2F >a 50 pin cable, which likely went to the internal hard disk, but thatF >was apparently pulled off at some point. There appear to be locationsB >on the riser for a mini-scsi connector and even for a PCI socket.  B 50 pin is a SCSI connector. The mini-SCSI is for the std embedded  2.5" SCSI disk.t  C >Now the questions.  can I assume that if I soldered a cable to thesC >mini-scsi spot on the board and mounted a connector on the back ofsA >the case it would work??  Can I also assume that if I soldered acC >PCI socket on the riser I could use something like an Adaptec scsih- >card to give me external SCSI capabilities??f   Yes, that would work.i  	 See also:n  . http://people.freebsd.org/~wilko/ncr_hack.html   for some info.  A >One last question.  I read somewhere that the SRM can be updatedeB >using MOP.  Can I also assume this machine can be booted from the4 >network if I have a suitable MOP server available??  3 Should work, I never tried it lacking a MOP server.u   --- |   / o / /_  _   		email: 	wilko@FreeBSD.orgu1 |/|/ / / /(  (_)  Bulte		Arnhem, The Netherlands	    ------------------------------  # Date: Thu, 29 Nov 2001 03:03:37 GMTi- From: "John E. Malmberg" <wb8tyw@qsl.network>r$ Subject: Re: Some Multia Help needed* Message-ID: <3C05AC2E.9040102@qsl.network>  
 jmd wrote:  F > a bit pricey but there are some good products there. also a *latest*H > firmware. i understand this firmware allows for booting VMS too (don't > quote me)m    F The only firmware that allows the booting of OpenVMS on the Multia is E the firmware on the OpenVMS Freeware CD-ROM or downloadable from the e copies of it on the www.  $ Use of other firmware will not work.    E Now as to the other question, AFAIK, the only way to load the OpenVMSm9 capable firmware on a Multia is through the floppy drive.   F Of course if someone has figured out how to do it from MOP, I am sure B that a few people will be interested.  But remember the multia is  totally unsupported.    n   -John  wb8tyw@qsl.network Personal Opinion Onlyd   ------------------------------  % Date: Wed, 28 Nov 2001 18:55:16 +0000s4 From: Andrew Swallow <andrew.swallow@baesystems.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org. Message-ID: <3C053314.FEC0F607@baesystems.com>   JF Mezei wrote:e >  [snip] > M > Again, since the code base for Alpha and IA64 is supposedly going to be the K > same, any existing VAX support on Alpha for clustering will inherently beLN > present on IA64. And if it breaks on IA64, shouldn't it logically also break > on Alpha ? >  Any chance of the IA64 having ae   EMULATE/VAX and EMULATE/APLPHA  3 command as standard?  To replace the run command.  e6 Just recompile may be good but companies are reluctant/ to buy compilers for languages where no future i development is planned.H -- X7 _______________________________________________________h Andrew Swallow   ------------------------------  # Date: Wed, 28 Nov 2001 23:28:09 GMTt* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <dqeN7.78702$uB.12431863@bin3.nnrp.aus1.giganews.com>g  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:%h9N7.2054$RL6.62621@news.cpqcorp.net...p   ...   3 > I will grant that I skip about 70% of these postsr  J Which, as noted below, impairs your ability to comment knowledgeably about them.    ...b  L > So what exactly is it that is being debated?  Bill Todd's position is thatL > the Alpha architecture is being prematurely ended by management who eitherF > are incompetent, or who are conspiring in some way with Intel and/or= > Microsoft to kill the architecture as a competetive threat.   L Half right.  I defy you to find any post of mine where I have suggested someL kind of external conspiracy (as distinct from possible internal Compaq power struggles) was at fault.     His reaction todH > this is to insist that on that basis Compaq should not be trusted, andJ > unless Alpha is resurrected and management sacked, that customers should > abandon OpenVMS.  H Half right.  I believe that under current Compaq leadership (or the sameJ incompetents with HP badges) VMS is toast.  With a real house-cleaning andJ major change in attitude toward VMS, however, it's possible that VMS couldL survive on IPF, just nowhere nearly as readily as it could have survived had< Alpha been continued (and similar attitude changes occured).   >rH > Bill's position is that information comming from Compaq is all "spin". ThatE > any information that has become available was designed to justify a  decision) > already made for more sinister reasons.e  L Essentially correct (both my position and your understanding of it) - exceptI that I'm inclined to attribute the decision as much to incompetence as to @ internal power politics (i.e., I suspect a combination of both).   >pL > It became obvious that my previous attempts to explain why the decision isJ > good long term for OpenVMS are unimportant to those with the loud voices in
 > this forum.o  H No:  you're just not convincing, because you have no new data to provideD (and while you have considerably more personal credibility than yourK corporate management, it's not sufficient for "just trust me - I can't tell:D you more" to fly, in the face of all the data that strongly suggests otherwise).    ...f  L > But since Bill's positions rely on what he believes are the motives of theJ > decision makers, leads one to question the motives of someone who is theE > loudest critic in this forum, but who has little or no stake in it.." > Disgruntled is a word that fits.  D Wrongo.  My positions are based on the radical discrepancies betweenL Compaq-provided information and observed behavior, and while I may speculateI on motives in an attempt to make apparently totally-off-the-wall behavior : more understandable I don't really care *why* it occurred.  C But it's entirely fair to call me 'disgruntled' at seeing arrogant,0K incompetent, and monumentally sleazy Compaq management savage products that:K I feel contribute significantly to the industry and represent the long-term F dedication of many talented people (some of whom are friends of mine).   - bill   ------------------------------  % Date: Wed, 28 Nov 2001 17:02:11 -0500(( From: David Froble <davef@tsoft-inc.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3C055EE3.6080206@tsoft-inc.com>   Alan Greig wrote:O  H > On Wed, 28 Nov 2001 11:53:52 +0000, Nic Clews <sendspamhere@127.0.0.1> > wrote: >  >  >>Alan,i >>I >>Do you recall where Doug talked (briefly) about patent infringement? HeuG >>spoke about the original Digital-Intel fiasco, and did say two of the.B >>patents were his, but he also, sort-of under his breath, mumbled >>something around EV8.  >> > C > Yes I remember he mumbled something about EV8 but wasn't too if I F > misheard. If you heard as well then I guess he said it. Wonder if he3 > was a senior EV8 designer who stayed with Compaq.n  H Well, if we're willing to consider any and all possibilities, how about 	 this one.e  H The subject was patent infringement.  What if some patents dealing with E EV8 were either needed by Intel, or, they had already infringed, and eG wanted to avoid any problems, so pressured Compaq for the patents, and -G that was the beginning of the idea to kill Alpha and give the store to F Intel.  Just wondering.c   Dave   -- -4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 29 Nov 2001 00:48:34 +0100o$ From: "Dr. Dweeb" <Dweeb@nospam.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org1 Message-ID: <wOeN7.172$BD4.13405@news.get2net.dk>c  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:%h9N7.2054$RL6.62621@news.cpqcorp.net...e  > Dr. Dweeb wrote in message ... > >Fred, > >,B > >"Not fair" ?  I do not think this is accurate and would like to
 understandJ > >why you think it is so.  My "argument" as such is that Bill does a muchK > >better job of "arguing" than Jeff, and that Jeff's opt-out is ad hominemfJ > >attack. This is the classic retreat of the intellectually bankrupt whenI > >faced with argument such as Bill for the most part presents.  Jeff hasmF > >continued in the same vein despite my (and others) admonishments. I rejectK > >this form of argument (attack) as invalid per se (see my previous post).  > >a >cL > >"Self importance" ?  Which part of my message indicated that ?  If you doG > >not like my prose, say so, however having a more than a monosyllabiciL > >vocabulary is a sign of many things, none of which is the aforementioned.E > >Also, I am not the only one who has admonished the antagonists for0 abusingsH > >each other.  Otherwise I do not understand from where you derive this > >comment.c > >s >eJ > First, you insert yourself as the arbiter in a debate.  Concentrating on thelG > ability of each individual to mount a defense of each position.  This,K > argument has been raging for months, and has long since past the point ofe > rational dialogue. >l  H I was not intending to arbitrate, and I am in 100% agreement about "longJ since past", which was part of the unstated point of my original post.  MyI response - response might have made this more clear (but then again maybe  not).C  I > Your schoolmaster attitude, and condescension towards someone who has auI > point of view - no matter how well you believe it is articulated - setsA youe0 > up for the accusation of being self-important. >t  A Perhaps, I disagree, though I accept your position on this point.o   >eL > >"Compulsion" ?  I think objectively, the set of compulsive individuals inF > >this thread, exclude myself.  The evidence (number and frequency of posts)I > >is clear and unequivocal.  At least up until now, the antagonists haveQ letwH > >very few comments go unanswered - except Jeff seems to have failed to > answer > >mine. > >- >- > H > That remains to be seen - as we do not know your identity.  However, I willG > grant that I skip about 70% of these posts - especially when half waymL > through the threads the subject becomes a debate of response to terrorism. >   J I think the evidence is substantial.  And I have actually read 100% of theI posts on this thread.  It is like a bad saop., I have become addicted.  I@I realise that this admission reflects poorly on me, but I think the threadwE will die soon, obviating me of the necessity to force withdrawal uponp myself.   I > >"Justified" ?  If I felt the need to justify something which I know onm the G > >basis of the evidence - exactly two posts, available for everyone too read -A > >is clearly untrue, then I would use those 2 posts as evidence.e > >X > >0J > >Please read first major section of my first post as if it was the first > postI > >you read in this thread - clear your mind.  Then read Jeff's response.  YoueG > >find precious little rational or logical response to the commentary,h merelyI > >a rehash of what Jeff has said many times about the "substance" of his.G > >position.  My post was largely (though not completely), specificallyW *not*lG > >about the substance of his or Bills position but about how they (andH	 > others) K > >have been going about it.  There is exactly zero substantive response toe > theaD > >ACTUAL post.  Equally, there has been exactly zero response to my response > >to Jeff's said non-repsonse.o >eJ > I cannot effectively argue with Bill Todd, or you over the merits of theL > decision - both the good and ill - mostly because I am handcuffed by beingJ > an employee of Compaq, and not being in a position to provide non-publicL > information - as well as not being privvy to all the information that went > into the decision. >t  D It was not my intention that you should argue over the merits of theL decision with me.  I was trying to point out (as you have) that we have longH passed rational dispassionate discourse, and that better technique mightL keep it on track and produce greater understanding (a foolish goal I admit).  J Personally, I would not even begin articulate a defense of my own opinion,H as its only basis is a strong gut feeling that things are fishy, and theI obvious duplicity and or deceit by of ComapQ executives in many areas.  IIH can usually recognise sophistry when I see it.  I have an opinion, not aI position which I am able to defend with hard evidence.  Bill believes his K can be defended with public information/evidence, while Jeff defends his on K "soft" grounds - rather like CompaQ I conclude (personal evaluation alert).hK I do not know whether CompaQ is being honest in the matter in question, but0> have sufficient circumstantial/anecdotal evidence to doubt it.  J > On the other hand, neither can Bill, Jeff, or anyone else in this forum.H > What each has, is a smattering of real and imagined "facts" as well as > suppositions.m >s0 > >  In fact, only a later post claiming he willL > >not respond, apparently deriding me for anonymity.  Just call me Pavel ifJ > >you would like a name to hang on me, though I like Dr. Dweeb better.  IH > >postulate his inability/unwillingness to respond as indicative of hisH > >inability and/or unwillingness to indulge in an abstract debate - one aboutfI > >form not substance.  I will be happy to be proved wrong on this point.n > >o >l >tJ > I hate debate in the abstract.  I am a horrible at debate in general.  I > think most people are. >e   Ok, fair enough.  K > >It is blatantly obvious (at least to me, and I believe any dispassionateeL > >observer) that he either did not read, did not understand or chose not toF > >understand (and thus ignore) the substance of my post and my reply. PleaseK > >point to contrary evidence in Jeff's post - I may have missed it.  I setl > himgE > >up, he fell in head first and was drowned - figuratively speaking.g > > B > >Finally, you might note that if I have sided with either of the antagonists L > >analyses in any substantive way, it has been with Jeff on his substantiveJ > >thesis that customers do not care about the underlying CPU (though with > someK > >minor modification of the expected final outcome) and with Bill in termss ofL > >ability to clearly formulate and substantiate his position.  I think BillL > >does a better job of deconstruction of the CompaQ spin than Jeff, becauseH > >Jeff does not try - he believes it to start with.  A dubious point of > >departure for debate. > >f >b > L > So what exactly is it that is being debated?  Bill Todd's position is thatL > the Alpha architecture is being prematurely ended by management who eitherF > are incompetent, or who are conspiring in some way with Intel and/orK > Microsoft to kill the architecture as a competetive threat.  His reaction. toH > this is to insist that on that basis Compaq should not be trusted, andJ > unless Alpha is resurrected and management sacked, that customers should > abandon OpenVMS. > H > Bill's position is that information comming from Compaq is all "spin". ThatE > any information that has become available was designed to justify as decision) > already made for more sinister reasons.h >RL > It became obvious that my previous attempts to explain why the decision isJ > good long term for OpenVMS are unimportant to those with the loud voices inL > this forum.  I personally am not "happy" about Alpha being phased out, butF > it isn't the end of the world.  I can accept that those who made theD > decision had valid business reasons, backed by technical analysis. >m  F I read your posts on this, and IIRC they essentially coincide with theK CompaQ view.  However, as a current CompaQ employee, one must by definition L assume that you have a number of priorities and legal (NDA) issues that rateJ higher than newsgroup activity, like keeping your job, feeding your familyD etc. - I certainly would.  That, plus I have no idea how high up theJ heirachy makes your corroborative comments informative and useful, but notH necessarily factual - though I have absolutely ZERO reason to doubt yourK personal integrity or the veracity of your statements - this is an abstracttK view, not a personal one !!  Just as we need to be equally dispassionate inc@ factoring in Bills ex-DEC status (Jeffs pet peeve) and attitude.  H > >Later posts from Jeff where he again throws disparaging commentary at BillsaH > >"ex-DEC" credential, his inability to distinguish between Digital and > CompaQL > >and the list goes on and on and on are sufficient for me at least to takeE > >the same moral/intellectual high ground, and dismiss his very weakgE > >arguments - even though I might agree with final opinion/analyses.l > >  >t >/L > But since Bill's positions rely on what he believes are the motives of theJ > decision makers, leads one to question the motives of someone who is theE > loudest critic in this forum, but who has little or no stake in it.l" > Disgruntled is a word that fits. >,  J It does.  But just like being paranoid does not mean someone is not out toJ get you, you cannot conclude that becauise he is disgruntled everything he says is invalid.  E > I have a personal, financial, and emotional stake in seeing OpenVMS" continueI > into the future.  I am close enough to the management of OpenVMS to say0 thatH > there are no conspiracies *here* in which we are saying one thing, yetK > planning something else - like the demise of OpenVMS or of EV7 or Marvel.  >t  J I have this interest too.  I have never doubted the VMS management an downE committment.  I severely doubt Curly & Carly and there opos though !!-  H > I have talked to Brannon offline, and understand his position.  I have alsoL > listed to Dave and others explain their positions.  Each has a valid pointJ > of view.  The decision may be right or wrong, but it is made.  I believeJ > that despite having been an Alpha bigot since working on V1.0 of OpenVMSI > Alpha - that the right long term decision was reached.  I have no greatu loveE > for the Itanium ISA, I expect to be swearing nightly about it while- getting-I > us to the initial boot.  But frankly it isn't all that important in thel long > run. >w  L In the long run, I care about my family and there health and well being, allG this other stuff is just an interesting sidebar.  I do however hope VMSz. survives, but I am not sanguine on this point.   ------------------------------  # Date: Thu, 29 Nov 2001 00:47:31 GMTx& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <DAfN7.965$s06.97450@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageo; news:dqeN7.78702$uB.12431863@bin3.nnrp.aus1.giganews.com...m  F > Wrongo.  My positions are based on the radical discrepancies betweenD > Compaq-provided information and observed behavior, and while I may	 speculate_K > on motives in an attempt to make apparently totally-off-the-wall behavior-< > more understandable I don't really care *why* it occurred.  > "observed behavior" .eq. interpretation .eq. opinion .ne. fact   ------------------------------   Date: 29 Nov 2001 05:01:51 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle)rN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <9u4ffv$c7q@gap.cco.caltech.edu>  , In article <3C04FF3B.A293FE59@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:o >dO >And is this issue a subtle hint that VMS on VAX will soon be considered matureiO >and will no longer be tweaked to remain compatible with subsequent versions ofyN >VMS on IA64, and eventually it will not be able to cluster with it, just likeN >too old a VMS version on one node prevents it from participating in a cluster4 >made up of nodes running a younger version of VMS ?  I   I don't think it's subtle at all and it's been going on for years, evenbF when you could buy a new VAX.  No CDE desktop, no ODS-5 for VAX (whichL already limits some cluster flexability), no modern browser (i.e. no MozillaI even though it was listed on the VAX software rollout as Netscape 5 for a L long time), no new C++ compiler, no Fortran 90, etc. etc.  No VAX in an IA64K cluster is just a continuation of current policy.  They want you to buy new-/ machines, damn the support money you give them.,   -- Vance Haemmerle  vance@alumni.caltech.edu   ------------------------------    Date: 28 Nov 2001 22:12:43 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER). Subject: Re: SRM software for alpha server 800( Message-ID: <3c05534b@news.kapsch.co.at>  n In article <001201c1711d$e16c83a0$cb96a8c6@manufact5l8vs8>, "Hank Vander Waal" <hvanderw@novagate.com> writes:+ >Can someone tell me where I can find this? + >or does it not matter which box it is for?t  < http://ftp.digital.com/pub/digital/Alpha/firmware/index.html@ http://ftp.digital.com/pub/Digital/Alpha/firmware/v6.1/alpha800/   should be still valid    -- t< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888h< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Wed, 28 Nov 2001 15:19:52 -0500t2 From: "Sue Skonetski" <susan.skonetski@compaq.com>" Subject: submarine telephone booth3 Message-ID: <CEbN7.2066$RL6.62844@news.cpqcorp.net>   1 This is an interesting message and is not a joke.e   Suee  0 From: (France Telecom) [mailto:(France Telecom)]  ' Sent: Friday, November 23, 2001 5:35 AMs   To: (subsribers)  " Subject: submarine telephone booth       Paris, November 21, 2001  K France Telecom invents first submarine telephone booth, with new underwaterp communications systemp  L France Telecom R&D, in partnership with Amphicom, has invented a system thatI allows telephone communications with a diver working underwater - a worldrJ first! Easy to use, this system ensures a clear connection from a fixed or; wireless phone to a person working underwater at any depth.d  F The system comprises a buoy fitted with a GSM phone relay that handlesK two-way communications with an underwater terminal - almost like a personaloL underwater phone booth! The terminal is connected to the buoy by a wire, andB is equipped with a dial pad (like a telephone keyboard), a special! mouthpiece, a light and a buzzer..  H The buzzer and a flashing light alert the diver of an incoming call. TheI parties are able to talk because of the ability of bones to conduct soundOJ underwater. The sound wave from the surface transits through the system toL the mouthpiece. The diver merely has to bite down on the mouthpiece and pushK a button to "unhook the handset". Sound vibrations propagate to his ear viacJ his skull, which acts as a resonance chamber. He can then clearly hear the6 incoming call and also talk back, in half duplex mode.  L With the dialing pad, the diver can also call anybody on a fixed or wireless phone.  F This innovative system is primarily designed for professionals workingJ underwater, and significantly improves safety. Since the end of last year,J it has been tested by archeologists at the Alexandrine Research Center, inG charge of underwater excavations at the presumed site of the AlexandriaeG Lighthouse, in Egypt. By providing direct, instantaneous communicationsoL between the divers and excavation managers, this system supports interactiveL research, eliminates the need for frequent returns to the service (and risksA of decompression), and the loss of information inherent in diving < (directional problems on the sea floor, forgetfulness, etc.)  K Other possible areas of application, all requiring underwater work, includenH oil platforms, shipyards, scientific research, salvaging ships and civilH security. Divers can quickly signal any sign of discomfort or danger, or$ report to the surface on their work.  L The new underwater communications system should be commercialized by the endG of 2002. France Telecom's research teams are already looking at ways to%L eliminate the wire link between the buoy and the submerged terminal, so thatF divers are totally independent. This also means that members of a teamL diving in the same area can call each other whenever they want. Two possibleH solutions to transmit voices under water are now under study: ultrasound# waves, or weak electrical currents.i   About France Telecom R&D  G France Telecom R&D, the France Telecom group s research and developmenthJ center, drives innovation for all group units in France and worldwide. TheJ center anticipates technological revolutions and paradigm shifts in usage.K The center focuses on innovation that provides customers with best-in-classcJ communications solutions, paving the way for technologies that will becomeH ubiquitous in the future. The performance of France Telecom R&D makes it: Europe' s leading telecom research and development center.      0 France Telecom - Press Office / 33 1 44 44 93 93   Manuel Lesaicherre  $ manuel.lesaicherre@francetelecom.com   Nilou Du Castelr    nilou.ducastel@francetelecom.com  C http://www.francetelecom.com/vanglais/whats_in_the_news/f_news.htmln   ------------------------------  # Date: Thu, 29 Nov 2001 02:23:45 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>9 Subject: Time for the Encompass US Inc CHAD-FREE Election ; Message-ID: <R_gN7.1641$29.1642086@typhoon.ne.mediaone.net>a  J Well, the Encompass BoD ballot is available in PDF format at the following9 URL. Print it out, fill it out, and mail it back in ASAP.a  G You can vote for up to four of the eight candidates on the ballot, or as lesser number if you so choose.u  K Please take the time to download the PDF, cast your vote(s), and return theo4 ballot by fax or snailmail. Deadline is December 12.   Thank you for your support!g  0 http://www.encompassus.org/whatsnew/bodElec.html   cheers,    terry so   -- Terry C. Shannon Consultant and Publisher Shannon Knows Compaq% Director at Large, Encompass US, Inc.q  email: terryshannon@mediaone.net3 Web (info on SKC):  www.acersoft.com, www.tru64.orgh   ------------------------------  % Date: Wed, 28 Nov 2001 10:57:49 -0800f# From: "Tom Linden" <tom@kednos.com>-& Subject: RE: TRIBON (for shipbuilding)9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEGNDKAA.tom@kednos.com>I   Try  Richard.Lundberg@tribon.comc Tom  > -----Original Message-----* > From: mislav [mailto:msalapic@yahoo.com]- > Sent: Wednesday, November 28, 2001 10:48 AMi > To: Info-VAX@Mvb.Saic.Comt$ > Subject: TRIBON (for shipbuilding) >  > H > i need manual of program TRIBON.if someone can help me about that send > me mail:mislav_385@yahoo.com > mislav >    ------------------------------    Date: 28 Nov 2001 12:20:27 -0800! From: msalapic@yahoo.com (mislav)e' Subject: TRIBON,manual for shipbuildingh< Message-ID: <be17736d.0111281220.9b38db1@posting.google.com>  E i am just graduate engineer of naval architecture and i want to learnnC some things about tribon(every thing).has someone manual for tribonf	 thank yous   ------------------------------  # Date: Wed, 28 Nov 2001 22:04:21 GMTi* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))B Message-ID: <FbdN7.137529$qx2.8519246@bin5.nnrp.aus1.giganews.com>  9 "Duane Sand" <duane.sand@mindspring.com> wrote in messagel9 news:r19N7.54018$RG1.29054927@news1.rdc1.sfba.home.com...t   ...t   > The starting question is,uE > Will the merged Unix be big-endian, like PA-RISC and IPF HP-UX are,  > or little-endian, like Tru64?nJ > The IPF hardware can do both, even at same time for different processes,E > but no practical OS will ever be bi-endian in its raw file support.f  L I'm not sure what you mean by the last clause above:  while applications mayH (or may not) elect to embed endian-sensitive data in their files (and ifH they do will certainly have problems sharing that data with other-endianK applications), that's an application-level rather than a file-system issue,dC so it's not clear what application-visible implications file-systemeJ endianness has (assuming of course that at the API appropriate conversions6 are made when dealing with other-endian applications)?   >dI > One camp of users or the other will be losers, in having to fix endian-nH > sensitive nonportable source code before doing the "just a recompile",G > even if both sets of APIs are supported, and in not having the optionlI > for a binary translator for unchanged PA-RISC or Alpha binary programs.o  K While I agree that any migration to an other-endian environment requires atiH a minimum exhaustive testing to ensure that there is no endian-sensitiveJ code in one's applications, I would have thought that the ability to run aC process in either-endian mode on IA64 would make binary translation G possible - and 'just a recompile' migration possible as well if an IA64 I compiler that generates same-endian output code was available.  Assuming,lL again, that the OS was capable of handling either-endian processes (possibly by stub translators).i  L Of course, I may just be drawing a blank on some very obvious problems here.   - bill   ------------------------------  # Date: Wed, 28 Nov 2001 22:59:51 GMTr% From: Milton <mbhewitt@optonline.net>yN Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))8 Message-ID: <5nqa0uga5c7f754pe2r8icufftiiqqbd72@4ax.com>  F On Wed, 28 Nov 2001 22:04:21 GMT, "Bill Todd" <billtodd@metrocast.net> wrote:   >i: >"Duane Sand" <duane.sand@mindspring.com> wrote in message: >news:r19N7.54018$RG1.29054927@news1.rdc1.sfba.home.com... >t >... >e >> The starting question is,F >> Will the merged Unix be big-endian, like PA-RISC and IPF HP-UX are,  >> or little-endian, like Tru64?K >> The IPF hardware can do both, even at same time for different processes,aF >> but no practical OS will ever be bi-endian in its raw file support. > M >I'm not sure what you mean by the last clause above:  while applications mayoI >(or may not) elect to embed endian-sensitive data in their files (and ifuI >they do will certainly have problems sharing that data with other-endian L >applications), that's an application-level rather than a file-system issue,D >so it's not clear what application-visible implications file-systemK >endianness has (assuming of course that at the API appropriate conversionsg7 >are made when dealing with other-endian applications)?a >u >>J >> One camp of users or the other will be losers, in having to fix endian-I >> sensitive nonportable source code before doing the "just a recompile", H >> even if both sets of APIs are supported, and in not having the optionJ >> for a binary translator for unchanged PA-RISC or Alpha binary programs. >oL >While I agree that any migration to an other-endian environment requires atI >a minimum exhaustive testing to ensure that there is no endian-sensitive K >code in one's applications, I would have thought that the ability to run asD >process in either-endian mode on IA64 would make binary translationH >possible - and 'just a recompile' migration possible as well if an IA64@ >compiler that generates same-endian output code was available.   
 *Caution* 	 *Caution*p, Brain numbing technical documentation ahead!    ? Doing a little reading about MIGRATING SOFTWARE APPLICATIONS TOh- ITANIUM-BASED COMPAQ NONSTOP HIMALAYA SERVERS , http://nonstop.compaq.com/view.asp?IOID=5614   I see that:t  E "The Itanium-based versions of CISC-based programs are built with the C same unchanged CISC compilers and Binder as the original CISC-basedoB programs. The same languages are supported: the COBOL, C, C++ (viaD cfront), TAL, and Fortran. These code files can be executed directlyD in the Itanium environment with the CISC Object Code Interpreter forC Itanium (OCI/I). As on MIPS-based NonStop servers, these code fileseC also can run at much faster speeds by augmenting the code file withpE translations of instructions into equivalent Itanium code. AugmentingpB for the Itanium microprocessor is done with a new tool, the Object% Code Translator for Itanium (OCT/I)."y  A So Intel have developed an *Object Code Translator* for Itanium. h   And doing a little reading ato7 http://www.ifi.unizh.ch/groups/richter/people/pilz/oct/e I learned that  : Object code translation,  is sometimes also called *binary
 translation* h  + Over at the Emulation Software R&D WWW Pager http://www.uruk.org/emu/  " I looked up, Alpha-based emulation@ http://www.uruk.org/emu/Binary_Translation_01apr1993DTJ809SC.txt  D It would seem to me that Intel may attempt to follow the same binaryF translation strategy that DEC used back in 92, for running OpenVMS VAXA binary images to OpenVMS AXP images and ULTRIX MIPS images to DEC  OSF/1 AXP images,   4 but instead for OpenVMS AXP, NSK and Tru64 -> IA64.    What do you think? n   Cheers,i Milton   ------------------------------  # Date: Thu, 29 Nov 2001 04:48:48 GMTs. From: "Duane Sand" <duane.sand@mindspring.com>N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))? Message-ID: <Q6jN7.54684$RG1.29896820@news1.rdc1.sfba.home.com>h   > Duane Sand wrote > > The starting question is,iG > > Will the merged Unix be big-endian, like PA-RISC and IPF HP-UX are,o! > > or little-endian, like Tru64? L > > The IPF hardware can do both, even at same time for different processes,G > > but no practical OS will ever be bi-endian in its raw file support.    Bill Todd wrote:J > I'm not sure what you mean by the last clause above:  while applicationsK > may (or may not) elect to embed endian-sensitive data in their files (and M > if they do will certainly have problems sharing that data with other-endian M > applications), that's an application-level rather than a file-system issue,eE > so it's not clear what application-visible implications file-system @ > endianness has (assuming of course that at the API appropriateD > conversions are made when dealing with other-endian applications)?  B Sorry, that phrase "bi-endian in its raw file support" was unclearC and/or wrong.  Of course, the file system's support for byte streamaB files or disk block files doesn't care in any way, how those bytes7 and words are arranged and interpreted by applications.o: A big-endian file server can service little-endian clients and vice versa, no problem.s  < What I should have said, is that any automatic byte-swapping= service supplied by the OS or runtime library, is going to bem9 useless for automatically converting files whose internali; layouts are unknown to the system.  So the system generallyv? can't help a big-endian version of an application work together-; with a little-endian version of that same application.  The < problem is that when items of different sizes are intermixed? in a file or struct, the two-byte numbers must be byte-reversed98 on a two-byte basis, and four-byte numbers must be byte-7 reversed on a four-byte basis, etc.  The system doesn't24 know enough about each application's declarations or3 methods to know how to parse and reverse each part.t  : Some cases of file interchange can work via automatic byte3 swapping.  This includes data bases (whose internalt: structures are self-described somewhere), and simple files6 where all items are the same size (eg text files), and: Fortran binary files (where the read/write statements show9 how to parse each record into bigger and smaller fields).0  9 The cases that don't work, include C programs reading andr9 writing structs with scalar fields of different sizes, orm: worse yet, unions of those. (And that's most every program
 I deal with.)t    K > > One camp of users or the other will be losers, in having to fix endian-wJ > > sensitive nonportable source code before doing the "just a recompile",I > > even if both sets of APIs are supported, and in not having the optionsA > > for a binary translator for unchanged PA-RISC or Alpha binary 
 > > programs.  >hA > While I agree that any migration to an other-endian environment E > requires at a minimum exhaustive testing to ensure that there is no . > endian-sensitive code in one's applications,  E In my experience, nearly every program is endian-sensitive, unless it E has already been ported back and forth between big- and little-endianbG machines already.  And it's some hassle to find declarations or methodst: that need changing, and some hassle to make those changes.    5 >      I would have thought that the ability to run aAE > process in either-endian mode on IA64 would make binary translation I > possible - and 'just a recompile' migration possible as well if an IA64m@ > compiler that generates same-endian output code was available.D > Assuming, again, that the OS was capable of handling either-endian+ > processes (possibly by stub translators).h  B Yes, yes, and yes.  It's possible to create an entirely big-endian> environment on top of a little-endian machine, and vice versa.B It's not even particularly inefficient; just requires inserting an4 XOR operation on addresses, and many of those can be- folded at compile time or moved out of loops.a  > But what sucks, is trying to have anything in that application9 environment talk to opposite-endian software outside thate environment, including the OS.   ------------------------------   Date: 29 Nov 2001 05:06:03 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle) N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)), Message-ID: <9u4fnr$cau@gap.cco.caltech.edu>  ? In article <r19N7.54018$RG1.29054927@news1.rdc1.sfba.home.com>,e- Duane Sand <duane.sand@mindspring.com> wrote:b >i >The starting question is,D >Will the merged Unix be big-endian, like PA-RISC and IPF HP-UX are, >or little-endian, like Tru64?I >The IPF hardware can do both, even at same time for different processes,oD >but no practical OS will ever be bi-endian in its raw file support. >oH >One camp of users or the other will be losers, in having to fix endian-G >sensitive nonportable source code before doing the "just a recompile", F >even if both sets of APIs are supported, and in not having the optionH >for a binary translator for unchanged PA-RISC or Alpha binary programs.  F    Do I have to start this?  Little-endian is "industry standard"! It  must be because PCs are.   -- Vance Haemmerler vance@alumni.caltech.edu   ------------------------------   Date: 29 Nov 2001 05:11:47 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle)-N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)), Message-ID: <9u4g2j$cfk@gap.cco.caltech.edu>  , In article <9u4fnr$cau@gap.cco.caltech.edu>,4 Vance R. Haemmerle <vance@alumni.caltech.edu> wrote: >hG >   Do I have to start this?  Little-endian is "industry standard"! It a >must be because PCs are.f     I forgot this:  ;->    -- Vance Haemmerlea vance@alumni.caltech.edu   ------------------------------  # Date: Thu, 29 Nov 2001 05:26:33 GMTw. From: "Duane Sand" <duane.sand@mindspring.com>N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))? Message-ID: <dGjN7.54809$RG1.29981861@news1.rdc1.sfba.home.com>c   > Bill Todd wrote:N > >While I agree that any migration to an other-endian environment requires atK > >a minimum exhaustive testing to ensure that there is no endian-sensitivedM > >code in one's applications, I would have thought that the ability to run aeF > >process in either-endian mode on IA64 would make binary translationJ > >possible - and 'just a recompile' migration possible as well if an IA64A > >compiler that generates same-endian output code was available.,   Milton wrote> > Doing a little reading about MIGRATING SOFTWARE APPLICATIONS2 > TO ITANIUM-BASED COMPAQ NONSTOP HIMALAYA SERVERS2 >     http://nonstop.compaq.com/view.asp?IOID=5614
 > I see that:sG > "The Itanium-based versions of CISC-based programs are built with thelE > same unchanged CISC compilers and Binder as the original CISC-basedpD > programs. The same languages are supported: the COBOL, C, C++ (viaF > cfront), TAL, and Fortran. These code files can be executed directlyF > in the Itanium environment with the CISC Object Code Interpreter forE > Itanium (OCI/I). As on MIPS-based NonStop servers, these code fileslE > also can run at much faster speeds by augmenting the code file withsG > translations of instructions into equivalent Itanium code. AugmentingyD > for the Itanium microprocessor is done with a new tool, the Object' > Code Translator for Itanium (OCT/I)."i  = Someone in product marketing has renamed our products without  telling us?  Hmmpf.o    B > So Intel have developed an *Object Code Translator* for Itanium.  : No, this particular OCT is Compaq's, being developed by my@ officemate, derived from the version targetting Mips we designed some 12 years ago.  @ HP also has a similar but independently done thing called Aries,@ which translates PA-RISC code to efficient IPF code at run time.  8 And I believe the OVMS group is aiming to supply one for
 Alpha-to-IPF.s  E Intel's own efforts in this area, if any, are not announced.  But thee; technology is well known now.  Transmeta has made an entiree* company and chip product line based on it.     >  ...F > It would seem to me that Intel may attempt to follow the same binaryD > translation strategy that DEC used back in 92, for running OpenVMS9 > VAX binary images to OpenVMS AXP images and ULTRIX MIPSp! > images to DEC OSF/1 AXP images,h5 > but instead for OpenVMS AXP, NSK and Tru64 -> IA64.-  > Yes to all, except that it's all done by Compaq and HP without Intel's involvement.   ------------------------------  # Date: Wed, 28 Nov 2001 22:59:35 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: xdmcp3 Message-ID: <r%dN7.2071$RL6.63042@news.cpqcorp.net>t  h In article <C_7N7.153670$zK1.42148406@typhoon.tampabay.rr.com>, "john nixon" <jnixon@cfl.rr.com> writes:8 :I have not been able to find this on DSN or in the FAQ. :uM :Is XDMCP  (X Display Manager Control Protocol) supported on current versionsd@ :of VMS?  All I found on VMS was an article from 1993 saying NO.  F   XDM is supported on current TCP/IP Services versions.  Specifically,9   on TCP/IP Services V5.1 and later.  (DHCP client, too.)   J   Topic (6723) in the Ask The Wizard area covers this -- a set of updates H   to the handful of other XDM-related topics in the Ask The Wizard area    has been queued.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 29 Nov 2001 00:00:22 GMTo& From: "Ken Farmer" <kfarmer@tru64.org>: Subject: Yahoo - IBM unseated in new supercomputer ranking? Message-ID: <qUeN7.92719$fm5.17025390@typhoon.southeast.rr.com>o  B "...At the top of the new list, created by IDC in cooperation withH supercomputer users, is a 3,024-processor Compaq Computer machine called< Terascale based at the Pittsburgh Supercomputing Center...."  L http://dailynews.yahoo.com/h/cn/20011128/tc/ibm_unseated_in_new_supercompute r_ranking_1.html     -- Ken Farmer, kfarmer@tru64.orga Tru64.org, http://www.tru64.orgn Tru64.org Newsletter:-< http://www2.tru64.org/pages.php?page=Newsletter-Registration   ------------------------------  # Date: Thu, 29 Nov 2001 00:08:12 GMTa& From: "Ken Farmer" <kfarmer@tru64.org>> Subject: Re: Yahoo - IBM unseated in new supercomputer ranking? Message-ID: <M%eN7.92813$fm5.17052851@typhoon.southeast.rr.com>s  D I knew I should have said it...watch the line wrap on the below url.   Kenh  1 "Ken Farmer" <kfarmer@tru64.org> wrote in messagei9 news:qUeN7.92719$fm5.17025390@typhoon.southeast.rr.com...iD > "...At the top of the new list, created by IDC in cooperation withJ > supercomputer users, is a 3,024-processor Compaq Computer machine called> > Terascale based at the Pittsburgh Supercomputing Center...." >  >vL http://dailynews.yahoo.com/h/cn/20011128/tc/ibm_unseated_in_new_supercompute > r_ranking_1.html >  >y > -- > Ken Farmer, kfarmer@tru64.orgg! > Tru64.org, http://www.tru64.orgc > Tru64.org Newsletter:a> > http://www2.tru64.org/pages.php?page=Newsletter-Registration >t >p >a   ------------------------------   Date: 29 Nov 2001 01:36:31 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) > Subject: Re: Yahoo - IBM unseated in new supercomputer ranking+ Message-ID: <9u43ev$fmj$1@info.cs.uofs.edu>   ? In article <qUeN7.92719$fm5.17025390@typhoon.southeast.rr.com>,d)  "Ken Farmer" <kfarmer@tru64.org> writes:hE |> "...At the top of the new list, created by IDC in cooperation withaK |> supercomputer users, is a 3,024-processor Compaq Computer machine callede? |> Terascale based at the Pittsburgh Supercomputing Center...."  |> iO |> http://dailynews.yahoo.com/h/cn/20011128/tc/ibm_unseated_in_new_supercompute  |> r_ranking_1.html  |>   What OS is it running??o   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>   e   ------------------------------  # Date: Thu, 29 Nov 2001 04:38:50 GMT & From: "Ken Farmer" <kfarmer@tru64.org>> Subject: Re: Yahoo - IBM unseated in new supercomputer ranking? Message-ID: <uZiN7.94274$fm5.17372048@typhoon.southeast.rr.com>i   > What OS is it running??y   Tru64 of course. :)s  8 http://www.compaq.com/newsroom/pr/2000/pr2000080301.html   --
 Ken Farmer# OpenVMS.org, http://www.openvms.org  Tru64.org, http://www.tru64.orgT    > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:9u43ev$fmj$1@info.cs.uofs.edu...sA > In article <qUeN7.92719$fm5.17025390@typhoon.southeast.rr.com>,t+ >  "Ken Farmer" <kfarmer@tru64.org> writes:WG > |> "...At the top of the new list, created by IDC in cooperation with F > |> supercomputer users, is a 3,024-processor Compaq Computer machine calledA > |> Terascale based at the Pittsburgh Supercomputing Center...."d > |> > |>L http://dailynews.yahoo.com/h/cn/20011128/tc/ibm_unseated_in_new_supercompute > |> r_ranking_1.html  > |> >n > What OS is it running??e >t > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------   End of INFO-VAX 2001.663 ************************