1 INFO-VAX	Thu, 21 Dec 2000	Volume 2000 : Issue 710       Contents:+ Re: "process crash" vs. "application crash"  Re: ACMS & Codasyl database 9 Re: BACKUP ACLs (was: standalone backup, disk-saveset...)  Re: C-Kermit Re: C-Kermit Dismount of Drives at Shutdown" Re: Dismount of Drives at Shutdown" Re: Dismount of Drives at Shutdown DS10 and maximum VMS version DS10 and maximum VMS version  Re: DS10 and maximum VMS version  Re: DS10 and maximum VMS version  Re: DS10 and maximum VMS version  Re: DS10 and maximum VMS version  Re: DS10 and maximum VMS version# Re: DS20 vs DS20E. Was: Sun Cluster  DSNlink for OpenVMS v3.0 Re: DSNlink for OpenVMS v3.0 Re: Email forwarding Re: Fasttrack for VAX  Re: Fasttrack for VAX $ Re: File conversion (RMS->stream-lf) Flackey fibre channel support ! Re: Flackey fibre channel support ! RE: Flackey fibre channel support ! Re: Flackey fibre channel support ! Re: Flackey fibre channel support < Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?)< Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?)< Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?) Re: NFS on OpenVMS9 NLA0: the null device - can VMS have other default names? = RE: NLA0: the null device - can VMS have other default names? = Re: NLA0: the null device - can VMS have other default names? = Re: NLA0: the null device - can VMS have other default names? = Re: NLA0: the null device - can VMS have other default names? = Re: NLA0: the null device - can VMS have other default names?  OpenVMS SAN Integration   OpenVMS Tech Tour (Greenbelt MD) Re: scaling an indexed file  Re: Sun Cluster  Re: Sun Cluster  Re: Sun Cluster  Re: Sun Cluster % System halts when console is shut off ) Re: System halts when console is shut off ) Re: System halts when console is shut off  Re: VAX emulation & Re: VAX emulation (was: Vax on a chip)& Re: VAX emulation (was: Vax on a chip)& Re: VAX emulation (was: Vax on a chip)& Re: VAX emulation (was: Vax on a chip) Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: Vax on a chip  Re: VMS 7.3 EFT2 Q RE: VMS 7.3 EFT2 Q VMSTAR
 RE: VMSTAR Re: X terminal for MAC ?  Re: XP1000 - which Graphics Card  Re: XP1000 - which Graphics Card  Re: XP1000 - which Graphics Card5 [Q]: Supported 8mm tapes on HSC-95 k.scsi requestors?   F ----------------------------------------------------------------------  % Date: Thu, 21 Dec 2000 01:47:29 -0500   From: John Santos <JOHN@egh.com>4 Subject: Re: "process crash" vs. "application crash"5 Message-ID: <1001221012943.3113A-100000@Ives.egh.com>   4 On Wed, 20 Dec 2000 david_dawkins@my-deja.com wrote: > [...] ; > I have seen this behaviour too, when the detached process ? > relies on process-level logicals.  Alas, this process is well B > established when it is zapped; it typically has been running for> > several days, and has processed many thousands of records ofB > data. We eliminated quotas, additionally it can go into a "deathB > spiral", where it cannot even be restarted for a few hours; each7 > restart lasts a couple of minutes before dying again.  > [...]   < Re: eliminating quotas...  Some quotas also depend on systemA parameters.  FILLM can't exceed SYSGEN's CHANNELCNT, for example. = I think CHANNELCNT should be at least several higher than the = largest FILLM on the system, to allow for things like mapping C shareable images (the debugger?) and accessing to process-permanent E files (SYS$INPUT, SYS$COMMAND, SYS$OUTPUT, SYS$ERROR and files opened C in DCL) if a program runs out of FILLM and the exception handler or B image rundown tries to access these files and they haven't alreadyA been opened in user mode by the image.  I seem to recall that the E standard BACKUP tuning folklore says to set CHANNELCNT to FILLM+15.   D (This is speculation, maybe some internals guru would know the exact reason.)  A Other process quotas may also be affected by SYSGEN parameters or ? other external factors, but I don't think the symptoms would be ? so mysterious.  For example, pagefile usage is limited not only C by PGFLQUO, but also by the actual size of the installed pagefiles.   E I think insufficient or fragmented system pool (PAGEDYN and NPAGEDYN) C could also prevent you from getting i/o buffers you are entitled to C by BYTLM or various IO quotas, but I think you get console messages A if you run out of pool and it can't be extended.  Also, the whole - system should go south if this was happening.    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Wed, 20 Dec 2000 20:27:29 GMT - From: "Dave Pampreen" <davepampreen@home.com> $ Subject: Re: ACMS & Codasyl database> Message-ID: <RC806.159105$hD4.40255640@news1.rdc1.mi.home.com>  J I got an update about 4 months ago with DBMS 7.0.3 RBD, CDD, and they were& nice enough to include Oracle 8 too :)  : We run MANMAN using DBMS, was your questions DBMS or ACMS?   Dave2 "Alan Greig" <agreig@my-deja.com> wrote in message2 news:f1ku3tsos4826e2srrlts4qmfi5qtgntv4@4ax.com...C > On Tue, 19 Dec 2000 06:50:41 GMT, Dirk Munk <munk@home.nl> wrote:  >  > F > >It is still called DBMS, V7.03 is coming up, and it is a Very Large > >Memory database. C > >You can find it on the Rdb CD-Rom set, because Oracle packed all ) > >ex-Digital software on one CD-Rom set.  > F > Maybe this differs by region but our (UK) RDB and DBMS distributions > come in separate boxes >  > -- > Alan Greig   ------------------------------  % Date: Wed, 20 Dec 2000 20:26:25 -0600 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> B Subject: Re: BACKUP ACLs (was: standalone backup, disk-saveset...)- Message-ID: <3A416A51.B8424B9D@earthlink.net>   " "Gotfryd Smolik, VMS lists" wrote: > / > On Sat, 16 Dec 2000, David J. Dachtera wrote:  > [...] K > +The only advantage I've ever seen to backing up to a saveset rather than J > +disk-to-disk /IMAGE is that the latter doesn't preserve ACLs where diskK > +to saveset to disk does preserve ACLs. I always kinda wondered if *THAT*  > +was a bug in BACKUP...  >  >  Hmmmm... ; >  Do you have already make a disk-to-disk BACKUP non-image  > copy with real user data ?@ >  It is hard to belivie, that you all time remember the use of: > /OWNER=ORIGINAL [1] = > to save the UICs of files -;>, have themself check the fact < > (that at least one time the manager must forget the point,= >  unimportant - but only as long you has BYPASS enabled ;>!) % >  at start of my management work -:]  > = >  And with the requirement of "set owner as original" BACKUP 8 > *also* saves ACLs ! The point is not mentioned in HELP9 > but really works. Have check this moment - but eventual $ > version dependence are welcome -:) > 7 >  BACKUP is suposed for many differrent jobs - and the 8 > one without /IMAGE, /INCREMENTAL etc. looks as typical5 > "for normal user" one; then the defualt in the form 5 > must be as default in COPY - to allow a BACKUP from = > b.ex. directory tree, where the directories are read-only !  > 5 >  The second resolution (even after "buggy" restore) 6 > starting with some VMS version is SET SECURITY/LIKE. >  >  Regards - Gotfryd< > [1] please not correct me: I know that /OWNER is obsolete,< >  but IMHO /BY_OWNER as output qualifier is a inconsistency< >  where makes the life harder; the best description of what
 >  I mean is: > > $ SET SECURITY somefilemask/BY_OWNER=old_owner/OWNER=new_one< >  and I can't see *no* reason to use consistently /BY_OWNER8 >  as input (selecion) but /OWNER as output ("settable")
 >  qualifier. : >   The description in HELP (for BACKUP /BY_OWNER) also is9 >  written as "begginer friendly" but little untrue: "you 9 >  must have SYSPRV or the UIC must be you own" (in HELP) ; >  is *not* exactly the same as "you must have owner access 9 >  of the volume or the created files" -:) (supose BYPASS ) >  is also a equivalent of owner access).   C If I understand correctly, then yes, that would be a bug in BACKUP:    $ BACKUP/IMAGE ddcu: ddcu:/INIT   G ...should imply that the target disk will be an accurate replica of the F source disk - no additional qualifiers. In practice, however, the only( way to ensure this is to do it this way:  8 $ BACKUP/IMAGE ddcu: ddcu:<dir>saveset_filespec/SAVE_SET8 $ BACKUP/IMAGE ddcu:<dir>saveset_filespec/SAVE_SET ddcu:   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Wed, 20 Dec 2000 20:30:22 GMT - From: "Dave Pampreen" <davepampreen@home.com>  Subject: Re: C-Kermit > Message-ID: <yF806.159106$hD4.40256168@news1.rdc1.mi.home.com>   > What's on the receiving end?C It's 2 different banks (wachovia and bank one) and a faxing company K (Kleinschmidt)  All are having the same issue.  I've tried to find out what L hardware they have with little success.  I will be talking to a tech support- at bank one tomorrow to help diagnose this...   B Kleinschmidt wrote their own version of kermit on their mainframe.   Dave    = "Frank da Cruz" <fdc@watsun.cc.columbia.edu> wrote in message / news:91ofmu$de6$1@newsmaster.cc.columbia.edu... @ > In article <anA%5.153976$hD4.39353631@news1.rdc1.mi.home.com>,. > Dave Pampreen <davepampreen@home.com> wrote:J > : I just converted from VAX to Alpha which meant c-kermit went from 5.0a to > : the latest version 7.x > : L > : When I am trying to send text files the receiving end is having trouble. > :  > What's on the receiving end? > . > : I can go back to my VAX and it works fine. > : K > : I am sending using a Multitech modem which is connected to a DECServer.  > : J > So you are dialing out from the Alpha via a LAT port that has a modem on it?  > K > : Since both the Alpha and VAX are using the same terminal server/modem I % > : think it's the version of kermit.  > : J > : I did a test from VMS to a PC running reflections and that PC received the & > : file fine.  So now I'm confused... > : J > Newer Kermits have some performance features that older ones don't have.I > Usually they don't cause trouble, but if they do it's easy to deal with  it.  > 9 > : Does anyone have a version 5.x of c-kermit for Alpha?  > : J > The real solution is to configure the current version to work for you inH > the setting in which you are using it.  First try telling C-Kermit to: >  >   set prefixing all  > I > and see if the problem goes away (it should).  If it doesn't, then send  > email to:  >  >   kermit-support@columbia.edu  > 	 > - Frank    ------------------------------   Date: 20 Dec 2000 20:59:10 GMT0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: C-Kermit 5 Message-ID: <91r6iu$5uu$1@newsmaster.cc.columbia.edu>   > In article <yF806.159106$hD4.40256168@news1.rdc1.mi.home.com>,, Dave Pampreen <davepampreen@home.com> wrote:  : > What's on the receiving end?E : It's 2 different banks (wachovia and bank one) and a faxing company M : (Kleinschmidt)  All are having the same issue.  I've tried to find out what N : hardware they have with little success.  I will be talking to a tech support/ : at bank one tomorrow to help diagnose this...  : D : Kleinschmidt wrote their own version of kermit on their mainframe. :  See:  4   http://www.columbia.edu/kermit/ckermit2.html#x4.22   - Frank    ------------------------------  % Date: Wed, 20 Dec 2000 18:52:08 -0600 / From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> ' Subject: Dismount of Drives at Shutdown R Message-ID: <6FACDDDFBD7BD411B38100D0B7B0CDCC40B5F2@ohms.electric.ci.austin.tx.us>  
 Hello all;  I We have a heterogeneous 5 node NI cluster running various versions of the J OS. All the machines are Alphas and some nodes are running V6.2 and othersD are running V7.2-1 (yep they're the newer boxes ;-).  Anyway, in theI sypagswpfiles.com on each node we mount all the MSCP served drives in the K cluster using a mount/cluster command.  This way whenever  a machine enters G the cluster it mounts all the drives it needs.  However, when the nodes L shutdown the dismounts are not done cluster-wide and the drives being servedL by the machine that went down go into mount verification because the host isH unavailable.  How can we get the drives to dismount/cluster on the nodes when the nodes shutdown?    $ Ed Stuart                           ( Manager, Systems and Desktop Services	   Information Technology Services  City of Austin, Austin Energy  Ed.Stuart@austinenergy.com  + "Glittering prizes and endless compromises  . shatter the illusion of integrity" - Neil Pert  B *Please apply a generous amount of all the usual disclaimers here*      ------------------------------  % Date: Wed, 20 Dec 2000 20:39:04 -0600 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> + Subject: Re: Dismount of Drives at Shutdown , Message-ID: <3A416D48.5BEF126@earthlink.net>   "Stuart, Ed" wrote:  >  > Hello all; > K > We have a heterogeneous 5 node NI cluster running various versions of the L > OS. All the machines are Alphas and some nodes are running V6.2 and othersF > are running V7.2-1 (yep they're the newer boxes ;-).  Anyway, in theK > sypagswpfiles.com on each node we mount all the MSCP served drives in the M > cluster using a mount/cluster command.  This way whenever  a machine enters I > the cluster it mounts all the drives it needs.  However, when the nodes N > shutdown the dismounts are not done cluster-wide and the drives being servedN > by the machine that went down go into mount verification because the host isJ > unavailable.  How can we get the drives to dismount/cluster on the nodes > when the nodes shutdown?  E You would probably need to supply some appropriate DCL code to invoke E SYSMAN on the remaining nodes and "DO DISMOUNT ddcu:" for those disks C MOUNTed cluster-wide which are hosted by the local node. Probably a E series of statements similar to the following for each locally-hosted  device:   ; SYSMAN> DO IF F$GETDVI( "ddcu", "MNT" ) THEN DISMOUNT ddcu:   F Of course, if any of those nodes have files open on those devices, the! results will be most interesting.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------    Date: 20 Dec 2000 22:55:59 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) + Subject: Re: Dismount of Drives at Shutdown + Message-ID: <7nZFQnHSR2nw@eisner.decus.org>   f In article <3A416D48.5BEF126@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:  H > Of course, if any of those nodes have files open on those devices, the# > results will be most interesting.   ? I used to put locally-standard command procedures in the MFD to @ shut down any persistent servers known to keep files open on the disk volume in question.   ------------------------------  # Date: Wed, 20 Dec 2000 21:52:43 GMT ! From: Ian Parker <parker@gol.com> % Subject: DS10 and maximum VMS version & Message-ID: <wyxVlDAdoSQ6Ew0Y@gol.com>   Hello   G We purchased a DS10 from Compaq, had some problem installing VMS 7.2 on ! it and turned to Compaq for help.   G To our amazement Compaq have explained that the DS10 supports VMS up to   7.1-2, but does not support 7.2.  ? Is this correct?   It seems ridiculous (and disastrous for us!)    Regards    Ian    ------------------------------  # Date: Wed, 20 Dec 2000 21:59:17 GMT ! From: Ian Parker <parker@gol.com> % Subject: DS10 and maximum VMS version & Message-ID: <3SMU9EAruSQ6Ew3B@gol.com>   Hello   G We purchased a DS10 from Compaq, had some problem installing VMS 7.2 on ! it and turned to Compaq for help.   G To our amazement Compaq have explained that the DS10 supports VMS up top  7.1-2, but does not support 7.2.  ? Is this correct?   It seems ridiculous (and disastrous for us!)e   Regardss   Iane --  
 Ian Parker   ------------------------------  % Date: Wed, 20 Dec 2000 16:25:29 -0600 1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>a) Subject: Re: DS10 and maximum VMS versionS8 Message-ID: <91rbdf$2n5$1@fizban.fizban.pprd.abbott.com>  0 From the QuickSpec for the DS10 dated 10.19.2000  > Minimum OS support: OpenVMS v7.1-2.  <-- please note "Minimum"   Also  H AlphaServer DS10 OpenVMS systems include pre-installed software (V7.2-1)  
 Rest easy.   Dave...o  . "Ian Parker" <parker@gol.com> wrote in message  news:3SMU9EAruSQ6Ew3B@gol.com... > Hello) >lI > We purchased a DS10 from Compaq, had some problem installing VMS 7.2 one# > it and turned to Compaq for help.  >rI > To our amazement Compaq have explained that the DS10 supports VMS up toM" > 7.1-2, but does not support 7.2. >)A > Is this correct?   It seems ridiculous (and disastrous for us!)  > 	 > RegardsM >o > Ian  > -- > Ian Parker   ------------------------------  # Date: Wed, 20 Dec 2000 23:13:51 GMTd! From: Ian Parker <parker@gol.com>d) Subject: Re: DS10 and maximum VMS version & Message-ID: <szyCVDAR0TQ6EwnK@gol.com>  F In article <91rbdf$2n5$1@fizban.fizban.pprd.abbott.com>, Dave Gudewicz" <david.gudewicz@abbott.com> writes1 >From the QuickSpec for the DS10 dated 10.19.2000  > ? >Minimum OS support: OpenVMS v7.1-2.  <-- please note "Minimum"e >t >Alsop >MI >AlphaServer DS10 OpenVMS systems include pre-installed software (V7.2-1)  >  >Rest easy.  >  >Dave... > / >"Ian Parker" <parker@gol.com> wrote in messageu! >news:3SMU9EAruSQ6Ew3B@gol.com...l >> Hello >>J >> We purchased a DS10 from Compaq, had some problem installing VMS 7.2 on$ >> it and turned to Compaq for help. >>J >> To our amazement Compaq have explained that the DS10 supports VMS up to# >> 7.1-2, but does not support 7.2.a >>B >> Is this correct?   It seems ridiculous (and disastrous for us!) >>
 >> Regards >> >> Ian >> --c
 >> Ian Parkern >c >    David   @ Thanks for that quick check.  I'll go back to Compaq clutching a' printout of their QuickSpec in my hand.r  7 And next time I'll try to remember to check for myself!h   Regardsa   Ian  -- 0
 Ian Parker   ------------------------------   Date: 20 Dec 2000 22:59:58 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)) Subject: Re: DS10 and maximum VMS version0, Message-ID: <91rdle$ob0@gap.cco.caltech.edu>  J In article <wyxVlDAdoSQ6Ew0Y@gol.com>, Ian Parker <parker@gol.com> writes: >Hello >3H >We purchased a DS10 from Compaq, had some problem installing VMS 7.2 on" >it and turned to Compaq for help. >bH >To our amazement Compaq have explained that the DS10 supports VMS up to! >7.1-2, but does not support 7.2.  >a@ >Is this correct?   It seems ridiculous (and disastrous for us!)  H Sounds like you ran into a dyslexic support person.  Our DS10 works fineI at 7.2-1 and if I remember correctly that is the minimum VMS version thatn is supported.    David Mathog mathog@seqaxp.bio.caltech.eduo? Manager, sequence analysis facility, biology division, Caltech     ------------------------------    Date: 20 Dec 2000 19:00:00 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)C) Subject: Re: DS10 and maximum VMS versionh+ Message-ID: <$TfezVxgcciq@eisner.decus.org>   a In article <91rdle$ob0@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:SL > In article <wyxVlDAdoSQ6Ew0Y@gol.com>, Ian Parker <parker@gol.com> writes: >>Hello  >>I >>We purchased a DS10 from Compaq, had some problem installing VMS 7.2 on # >>it and turned to Compaq for help.o >>I >>To our amazement Compaq have explained that the DS10 supports VMS up tou" >>7.1-2, but does not support 7.2. >>A >>Is this correct?   It seems ridiculous (and disastrous for us!)  > J > Sounds like you ran into a dyslexic support person.  Our DS10 works fineK > at 7.2-1 and if I remember correctly that is the minimum VMS version thatb > is supported.   4 No, the statement quoted was "does not support 7.2".@ I would prefer "is not supported by 7.2", but let's not quibble.  @ Others have stated it runs on 7.2-1, but that is quite different	 that 7.2.   ? At VMS 7.0 for Alpha we saw the start of a new release strategyBB from VMS.  The latest feature-filled new release did _not_ supportD the new hardware -- the 6.2-something release at the same time _did_C have that support.  Then at VMS 7.1 for Alpha that new hardware wasnB supported along with the new features, but perhaps some even newer hardware was not supported.   C This is an openly discussed planned strategy on their part, so they B can have people working on the big new features without having the( hardware support change underneath them.  C Those who remember when VMS first came to Alpha know that it was aniB attempt to be the equivalent of VAX VMS V5.4, but VAX VMS V5.5 was5 already released.  Alpha counted as new hardware :-).g   =====e  B I have no direct knowledge of whether a DS10 is supported on V7.2,F but if it is not that is quite consistent with their rollout strategy.  E Of course if someone wanted to donate me a DS10, I _would_ be willing  to try :-).    ------------------------------  # Date: Thu, 21 Dec 2000 00:46:12 GMTc+ From: John Santos <john.santos@verizon.net> ) Subject: Re: DS10 and maximum VMS versione> Message-ID: <MPG.14ab1cebfdd53cca9896a3@news.bellatlantic.net>  , In article <$TfezVxgcciq@eisner.decus.org>, ) Kilgallen@eisner.decus.org.nospam says...2c > In article <91rdle$ob0@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:aN > > In article <wyxVlDAdoSQ6Ew0Y@gol.com>, Ian Parker <parker@gol.com> writes:	 > >>HelloG > >>K > >>We purchased a DS10 from Compaq, had some problem installing VMS 7.2 one% > >>it and turned to Compaq for help.e > >>K > >>To our amazement Compaq have explained that the DS10 supports VMS up tot$ > >>7.1-2, but does not support 7.2. > >>C > >>Is this correct?   It seems ridiculous (and disastrous for us!)* > > L > > Sounds like you ran into a dyslexic support person.  Our DS10 works fineM > > at 7.2-1 and if I remember correctly that is the minimum VMS version thatb > > is supported.  > 6 > No, the statement quoted was "does not support 7.2".B > I would prefer "is not supported by 7.2", but let's not quibble. > B > Others have stated it runs on 7.2-1, but that is quite different > that 7.2.o > A > At VMS 7.0 for Alpha we saw the start of a new release strategy D > from VMS.  The latest feature-filled new release did _not_ supportF > the new hardware -- the 6.2-something release at the same time _did_E > have that support.  Then at VMS 7.1 for Alpha that new hardware waseD > supported along with the new features, but perhaps some even newer > hardware was not supported.L > E > This is an openly discussed planned strategy on their part, so theyrD > can have people working on the big new features without having the* > hardware support change underneath them. > E > Those who remember when VMS first came to Alpha know that it was anrD > attempt to be the equivalent of VAX VMS V5.4, but VAX VMS V5.5 was7 > already released.  Alpha counted as new hardware :-).o >  > =====b > D > I have no direct knowledge of whether a DS10 is supported on V7.2,H > but if it is not that is quite consistent with their rollout strategy. > G > Of course if someone wanted to donate me a DS10, I _would_ be willinge
 > to try :-).s    G The DS10 is definitely supported by both V7.1-2 and by V7.2-1.  I don't D know about V7.2, though.  It is possible the DS10 fell into the V7.2" hardware crack as Larry described.  D I am pretty sure that VMS has *not* dropped support for any Alpha's.E Some old VAX processors are no longer supported, but at least some ofaC those still work.  (Compaq can't test them, because they don't have E any test systems, but didn't do anything intentionally to break them,tI AFAIK.)  The unsupported VAXes are MicroVAX-I and derivatives and (maybe) D VAX 11/725, 730 and 750.  The SPD lists supported systems and shouldE be on the OpenVMS web site somewhere.  http://www.openvms.compaq.com/h   --   John Santos    ------------------------------   Date: 20 Dec 2000 19:18:04 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman), Subject: Re: DS20 vs DS20E. Was: Sun Cluster6 Message-ID: <91r0lc$mdh$1@mailint03.im.hou.compaq.com>  N In article <JIjT29taZnFh@flying>, abuse@flying-disk.com (Alan Frisbie) writes:8 :In article <91m598$krl$1@mailint03.im.hou.compaq.com>, 5 :hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  :e] :> In article <3a3e468e$0$29566@senator-bedfellow.mit.edu>, jfc@mit.edu (John F Carr) writes:rN :> :In article <91le3e$h6q$1@mailint03.im.hou.compaq.com>, Hoff Hoffman wrote: :> :J :> :>  Further, the AlphaServer DS20E enclosure also specifically targets  :> :>  the use of faster CPUs. :> :  :> :Does "faster" mean "hotter"? :> nI :>   If by "hotter", you inquire of the potential for increased emission bH :>   levels of quantum particle energy in unspecified wavelength ranges  :<snip>t    6   Hotter, in this case, in the radio frequency band....   Infrared (chip thermal) is less of a factor.    8 :It sounds like Hoff is getting ready to run for office.8 :Either that, or the VMS v7.3 Release Notes are going to* :look like the Congressional Record.   :-) :w :Thanks for the chuckle.  G   As I've already received email from some folks that wondering if I'd,cF   um, left my system unlocked or had been kidnapped and replaced by anI   alien, that message was a riff on the "Senator Bedfellow" hostname. :-)h  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 20 Dec 2000 14:15:08 -0600.1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>i! Subject: DSNlink for OpenVMS v3.0 8 Message-ID: <91r3qp$1nk$1@fizban.fizban.pprd.abbott.com>  G Heard some rumblings about this recently, but couldn't find much on thet subject.  ) Anyone here running/using this stuff yet?r   TIA,   Dave...    ------------------------------  % Date: Wed, 20 Dec 2000 15:55:25 -0500v- From: "Peter Weaver" <peter.weaver@stelco.ca>.% Subject: Re: DSNlink for OpenVMS v3.0r4 Message-ID: <91906.101124$Z2.1198837@nnrp1.uunet.ca>  < "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message2 news:91r3qp$1nk$1@fizban.fizban.pprd.abbott.com...E > Heard some rumblings about this recently, but couldn't find much onn thes
 > subject. > + > Anyone here running/using this stuff yet?i >...  D We had our quarterly conference call with Compaq today to talk aboutD the service calls and we were told that DSNLink 3.0 will be shippingE real soon. Because of the encryption in it they can not distribute it- via the web.  D They also told us that the Canadian office would be phasing out V1.22 in April so I hope V3 is a lot better than V2 was.   --   RULES OF THE AIR   -----------------u<   #1. Every takeoff is optional. Every landing is mandatory.   ------------------------------  % Date: Wed, 20 Dec 2000 20:35:53 +0100e" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Email forwardingf( Message-ID: <91r1jj$39e$1@news.IAEhv.nl>  K Thank you Christoph and Carl, that is indeed the answer. We run Multinet on ; that box as well and the smtp_alias seems to be the answer.nI The DCL procedure looks very much like something I put together some timen0 ago to preserve the VMSmail forwarding database!   Thanks!w  
 Hans Vlems    . Christoph Gartmann heeft geschreven in bericht' <91pqtg$779$1@n.ruf.uni-freiburg.de>...eF >In article <91of14$982$1@news.IAEhv.nl>, "Hans Vlems" <hvlems@iae.nl> writes::L >>Point taken, but I needed a quick answer whether this was possible or not. >[...]I >>The VMS system is secure, runs forever with minimal support (SLS backupoI >>every week) and can connect to all kinds of  mailservers (ours anyway).pL >>There's some pressure to exchange this system with a unix box. The VMSmail? >>function prevents this, next to its track (up-time) record... L >>I'd be sorry to see the system go (VMS won't work in new environments, you >>know). >hK >Multinet is able to do what you want, PMDF as well and I assume the CompaqeF >product, too. Long before TCP/IP we used the following DCL procedure: >-D >$ ! Procedure to forward mail from user SYSTEM to real system users >$ !2 >$ forward_address = "@servstat:system_users.list" >$ ! >$ SET NOVERIFY  >$ SET NOONl >$ != >$ ! Remove old temporary files (just to be on the save side) : >$ IF F$SEARCH("sys$scratch:maildir*.tmp") .NES. "" THEN -7 >     DELETE/NOLOG/NOCONFIRM sys$scratch:maildir*.tmp;*E >$ !, >$ DEFINE sys$output sys$scratch:maildir.tmp >$ MAILe >DIRECTORY newmail >$ DEASSIGN sys$output >$!e >$ inum = 0 . >$ OPEN/READ maildfile sys$scratch:maildir.tmp3 >$ OPEN/WRITE ofile sys$scratch:maildir_extract.tmp-J >$ WRITE ofile "$ DEFINE/USER sys$output NL:"        ! Avoid huge logfiles >$ WRITE ofile "$ MAIL"i >$ WRITE ofile "SELECT newmail"f >$loop1:' >$    READ/END=end_loop1 maildfile line@; >$    number     = F$EXTRACT(  0,   5, line ) ! mail number > >$    source     = F$EXTRACT(  6,  21, line ) ! source address< >$    date       = F$EXTRACT( 27,  13, line ) ! date of mail@ >$    subject    = F$EXTRACT( 40, 100, line ) ! subject complete$ >$    IF F$LOCATE("-", date ) .EQ. 2
 >$       THENo >$       inum = inum + 1 >$       WRITE ofile numberh5 >$       WRITE ofile "FORWARD/SUBJ=""", subject, """"w$ >$       WRITE ofile forward_address >$       WRITE ofile "DELETE"  >$    ENDIFe >$    GOTO loop1 >$end_loop1: >$ CLOSE maildfile >$ WRITE ofile "EXIT"t >$ WRITE ofile "$ EXIT"  >$ CLOSE ofile4 >$ @sys$scratch:maildir_extract.tmp ! now forward...4 >$ DELETE/NOLOG/NOCONFIRM sys$scratch:maildir*.tmp;* >$ !  >$ isvax = F$GETSYI("ARCH_TYPE") >$ IF isvaxw
 >$    THEN7 >$    time = """" + F$CVTIME("+0:45","ABSOLUTE") + """"i0 >$    SUBMIT/NONOTIFY/NOLOG/NOPRINT/AFTER='time' 'F$ENVIRONMENT("PROCEDURE")'4 >$    SUBMIT/NONOTIFY/NOLOG/NOPRINT/QUEUE=mpi6_batch 'F$ENVIRONMENT("PROCEDURE")' >$ ENDIF >$ ! >$ EXITl >n >oL >Of course it has a disadvantage because a reply will go to the account that >forwarded the mail. >c	 >Regards,n >   Christoph Gartmann > I >-- --------------------------------------------------------------------+iI >| Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |rI >| Immunbiologie                                                        | I >| Postfach 1169                 Internet: gartmann@immunbio.mpg.de     | I >| D-79011  Freiburg, FRG                                               |eI >+--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+t   ------------------------------  # Date: Wed, 20 Dec 2000 20:32:09 GMTe- From: "Dave Pampreen" <davepampreen@home.com>i Subject: Re: Fasttrack for VAX> Message-ID: <dH806.159107$hD4.40256722@news1.rdc1.mi.home.com>  J Go for WASD, I ran it on my VAXes up until 2 weeks ago when I converted to Alpha.  $       demo:  http://wasd.vsm.com.au/)   download:  http://wasd.vsm.com.au/wasd/t     Dave    4 "Colin Blake" <colin@theblakes.com> wrote in message' news:3A409414.805690AB@theblakes.com...l > Clif MacDonald wrote:u > L > > I'm trying to find info on Netscape Fasttrack for OpenVMS VAX. The AlphaG > > version comes with 7.2 and up but I can't find the version for VAX.eJ > > Anyone know if  this was ever created ? If so, does it still exist and > > where do I get it ?o > L > FastTrack is Alpha only. There has been, and never will be, a VAX version. >a   ------------------------------  # Date: Wed, 20 Dec 2000 23:08:38 GMTe' From: Colin Blake <colin@theblakes.com>a Subject: Re: Fasttrack for VAX- Message-ID: <3A413B3D.9632C709@theblakes.com>t   Colin Blake wrote:  L > FastTrack is Alpha only. There has been, and never will be, a VAX version.  : Excuse the typo. I meant to say: There NEVER has been.....   ------------------------------  % Date: Wed, 20 Dec 2000 13:41:47 -0500-' From: Jack Patteeuw <jpatteeu@ford.com> - Subject: Re: File conversion (RMS->stream-lf)b( Message-ID: <3A40FD6B.B1EB29E3@ford.com>   Michael Worsley wrote: >rG > One (hopefully final) question: what is the file format of VFC, print,H > control carriage control files? I'm still having a little trouble withB > these - stray characters are appearing at the end of the line... >   @ http://www.openvms.compaq.com:8000/72final/4506/4506pro_005.html   section 2.1.2.3d  6 Some empirical testing may be required.  Use DUMP/BYTE    
 Jack Patteeuwg   ------------------------------  % Date: Thu, 21 Dec 2000 01:41:47 +0000r, From: Dave Brennan <dave@lugano.demon.co.uk>& Subject: Flackey fibre channel support8 Message-ID: <edn24tsv325958kmfhdtq5bue0k5q24cvs@4ax.com>  C I am interested in other peoples experience with using SAN networkse	 with VMS.g  @ We have been doing some testing and seen nodes crash in our test cluster, when doing SAN access.C  D We have also seen a shadow set PARTITION when the fibre link betweenF two machines is severed. That is, near side says this shadow set is okD but far side, is down. Far side say we are ok but near side shoud be> kicked out. Result two shadow sets being updated seperately by different sides of the cluster.a  F Talking to Compaq, I suggested that fibre channel devices were flakey. They said they were imature.  6 Is enybody else getting this SAN stuff to work on VMS?   Dave/ -----------------------------------------------1/ Dave Brennan          <dave@lugano.demon.co.uk>u  $ Universe saving by appointment only!0 ------------------------------------------------   ------------------------------  % Date: Wed, 20 Dec 2000 20:41:16 -0600 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> * Subject: Re: Flackey fibre channel support- Message-ID: <3A416DCC.A42ED94A@earthlink.net>@   Dave Brennan wrote:g > E > I am interested in other peoples experience with using SAN networks0 > with VMS.  > B > We have been doing some testing and seen nodes crash in our test! > cluster, when doing SAN access.q > F > We have also seen a shadow set PARTITION when the fibre link betweenH > two machines is severed. That is, near side says this shadow set is okF > but far side, is down. Far side say we are ok but near side shoud be@ > kicked out. Result two shadow sets being updated seperately by! > different sides of the cluster.e > H > Talking to Compaq, I suggested that fibre channel devices were flakey. > They said they were imature. > 8 > Is enybody else getting this SAN stuff to work on VMS?  F Not doing that (yet), but it sounds like I'd want to be rather careful1 about using shadow-set members hosted on the SAN.$   -- . David J. Dachtera  dba DJE SystemsD http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/m  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.o   ------------------------------  % Date: Wed, 20 Dec 2000 22:48:30 -0600 + From: "Main, Kerry" <Kerry.Main@compaq.com>v* Subject: RE: Flackey fibre channel supportN Message-ID: <910612C07BCAD1119AF40000F86AF0D805284B1A@kaoexc3.kao.cpqcorp.net>   Dave,C  I There are numerous Customers running fine in mission critical enviroments0 today with shadowing.r  1 Are you running the right versions of software ? 1  
 Reference:6 http://www.openvms.compaq.com/openvms/fibre/index.html   Regards,  
 Kerry Main Senior Consultante Compaq Canada Inc. Professional Servicesa Voice: 613-592-4660a Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----3 From: Dave Brennan [mailto:dave@lugano.demon.co.uk]  Sent: December 20, 2000 8:42 PMt To: Info-VAX@Mvb.Saic.Com & Subject: Flackey fibre channel support    C I am interested in other peoples experience with using SAN networks.	 with VMS.t  @ We have been doing some testing and seen nodes crash in our test cluster, when doing SAN access.i  D We have also seen a shadow set PARTITION when the fibre link betweenF two machines is severed. That is, near side says this shadow set is okD but far side, is down. Far side say we are ok but near side shoud be> kicked out. Result two shadow sets being updated seperately by different sides of the cluster.i  F Talking to Compaq, I suggested that fibre channel devices were flakey. They said they were imature.  6 Is enybody else getting this SAN stuff to work on VMS?   Dave/ ----------------------------------------------- / Dave Brennan          <dave@lugano.demon.co.uk>o  $ Universe saving by appointment only!0 ------------------------------------------------   ------------------------------  % Date: Wed, 20 Dec 2000 21:42:31 -0800e! From: Koloth <koloth@tmisnet.com> * Subject: Re: Flackey fibre channel support+ Message-ID: <3A419847.9DA9F861@tmisnet.com>g  J Can you supply your configuration and versions?  Are you using SAN or host based volume shadowing   Thanks Cass Witkowski   Dave Brennan wrote:5  E > I am interested in other peoples experience with using SAN networks  > with VMS.i >tB > We have been doing some testing and seen nodes crash in our test! > cluster, when doing SAN access.r >lF > We have also seen a shadow set PARTITION when the fibre link betweenH > two machines is severed. That is, near side says this shadow set is okF > but far side, is down. Far side say we are ok but near side shoud be@ > kicked out. Result two shadow sets being updated seperately by! > different sides of the cluster.l >iH > Talking to Compaq, I suggested that fibre channel devices were flakey. > They said they were imature. >c8 > Is enybody else getting this SAN stuff to work on VMS? >h > Dave1 > -----------------------------------------------w1 > Dave Brennan          <dave@lugano.demon.co.uk>  >e& > Universe saving by appointment only!2 > ------------------------------------------------   ------------------------------  # Date: Thu, 21 Dec 2000 06:30:19 GMTa From: Dirk Munk <munk@home.nl>* Subject: Re: Flackey fibre channel support' Message-ID: <3A41A37B.E586E415@home.nl>   F There are many patches that have to be applied. The most important areD Fibrechannel-SCSI and Shadow. Did you apply all of them ? Shadow has many new features for SAN.  F And yes, it does take a bit of experimenting to get everything running the way you would like it to.o   Regards,   Dirk/ (who is building a SAN himself at the moment). u   Dave Brennan wrote:v > E > I am interested in other peoples experience with using SAN networks  > with VMS.r > B > We have been doing some testing and seen nodes crash in our test! > cluster, when doing SAN access._ > F > We have also seen a shadow set PARTITION when the fibre link betweenH > two machines is severed. That is, near side says this shadow set is okF > but far side, is down. Far side say we are ok but near side shoud be@ > kicked out. Result two shadow sets being updated seperately by! > different sides of the cluster.t > H > Talking to Compaq, I suggested that fibre channel devices were flakey. > They said they were imature. > 8 > Is enybody else getting this SAN stuff to work on VMS? >  > Dave1 > ----------------------------------------------- 1 > Dave Brennan          <dave@lugano.demon.co.uk>s > & > Universe saving by appointment only!2 > ------------------------------------------------   ------------------------------    Date: 20 Dec 2000 15:07:34 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)uE Subject: Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?)t* Message-ID: <91r3i6$q9n$1@lisa.gemair.com>  8 In article <3a40387c$0$35013$2c3edae7@news.voyager.net>,. Jack Patteeuw  <jjpatteeuw@voyager.net> wrote: >2 >a >Charles Sebold wrote: >> e* >> On 19 Kislev 5761, Jack Patteeuw wrote: >>  , >> > I would DIE for LSE in Un*x land !!!!!! >> r& >> Warning:  I know nothing about LSE. >>  J >> However, ELSE claims to be some sort of implementation of LSE in Emacs. >> s% >> http://members.nbci.com/pmilliken/l >>  G >> Don't know if this would be helpful.  Looks like you'd need to get aeF >> later version of Emacs from gnu.org than Compaq ships with Tru64 (I  >> think he said 20.1 or later). >> eI >> What's so great about LSE, anyway?  I've met a few "fanatics" here and-  >> there, and I'm quite curious. >D' >GNU is not Un*x and Emacs isn't LSE !!a >o  H Emacs can be customized to be a newsreader, a mail program, a shell and,G seeing as it has embedded in it a powerful programming system, I would 9. assume a Language Sensitive Editor work-alike.  L >LSE (Language Sensitive Editor) is a "customizable" that "understands" yourN >"favorite" programming language (Fortran, Pascal, PLI, C, DCL, Datatrieve andN >even some non-DEC assemblers !!!).  I am far from an expert in LSE but it canM >prompt you for language elements, check syntax and even launch the compiler, M >linker and debugger.  Many "serious" programmer have spent considerable timee >adding extensions.  >:N >The "closest" non-Compaq tools to LSE are probably Code Warrior (WinDOZ Only)D >and Visual Slick Edit (WinDOZ and Un*x).  SImilar but not the same. >r >i >Jack Patteeuw   -Jordan Hendersonn jordan@greenapple.comt   ------------------------------  + Date: Wed, 20 Dec 2000 21:06:03 +0000 (   )f3 From: Christopher Smith <chriss@Mufasa.pubserv.com>rE Subject: Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?)oI Message-ID: <Pine.LNX.4.05.10012202104570.2792-100000@Mufasa.pubserv.com>   , On 20 Dec 2000 jordan@lisa.gemair.com wrote:  P > >The "closest" non-Compaq tools to LSE are probably Code Warrior (WinDOZ Only)F > >and Visual Slick Edit (WinDOZ and Un*x).  SImilar but not the same.  J Windoze and Macintosh for Codewarrior.  We use it here, the editor and theF compiler are both quite good (on both platforms).  It is, however, not LSE. :)#   Regards,   Chris   O ===============================================================================v@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmer. Prime Synergy of Champaign, IL.t% -------------------------------------oI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes andaH weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 jO -------------------------------------------------------------------------------n   ------------------------------  % Date: Wed, 20 Dec 2000 23:33:10 -0800s, From: Jack Patteeuw <jjpatteeuw@voyager.net>E Subject: Re: LSE (was: Re: VMS tools for Linux: EDT, TPU, TECO, LAT?)n8 Message-ID: <3a418792$0$35011$2c3edae7@news.voyager.net>   Charles Sebold wrote:d > E > Actually I think CodeWarrior is available on a number of platforms, E > unless you mean that the LSE-like capability is only under Windows.c >e  L According to Metrowerks web page, the only Un*x system supported are Solaris (Java and GNU C/C++) and f Linux.    
 Jack Patteeuw1   ------------------------------  # Date: Wed, 20 Dec 2000 19:49:25 GMTT* From: Doran Werling <rwscsinc@my-deja.com> Subject: Re: NFS on OpenVMSi) Message-ID: <91r2g3$i6t$1@nnrp1.deja.com>-  2 In article <xt5AOrqGZN1iU2MCPSfU3WYRs6t7@4ax.com>,$   David.Beatty.NOSPAM@sas.com wrote: >R= > You need to add an NFS proxy within the TCPIP product.  See ( > TCPIP HELP ADD PROXY.  David R. Beatty >dE > On Wed, 20 Dec 2000 11:03:54 -0500, James Griffin <griffin@vol.com>e > wrote: >  > >Good morning. > >dD > >I've been trying to get the NFS server working on OpenVMS (7.2-1) > >vG > >I've enabled NFS via TCPIP$CONFIG; added proxies via TCPIP, and donep5 > >what is generally called for in the documentation.. > >nD > >However, when I try to mount my OpenVMS directory from a Unix box (SGIH > >running IRIX 6.5, the following appears on a terminal that's been set > >with REPLY/ENABLE:  > > C > >%TCPIP-W-NFS_NOCMAP, cannot find client record in proxy database A > >(TCPIP$PROXY) TCPIP-S-NFS_CLIENT, uid=0 gid=0 host_name = pearr > >(D > >I then watched the packets using a packet-sniffer and found that,8 > >indeed, the uid and gid in the UDP packets were zero. > >rH > >Here's the rub.  You have to be logged in as root on a unix box to doC > >an NFS mount.  The uid/gid of root are 0/0.  But you can't add ah proxywE > >for root on OpenVMS because AUTHORIZE won't let you add an accountT with > >uid=0 and gid=0.  > >r  > >So how do I get this to work? > >  > >TIA > >Jim Griffin > >jpg1@nrc.govs >$ >   E 1) The VMS UIC [] and the UNIX (uid,gid) pair have nothing in common.   B 2) The UCX proxy maps the incoming UNIX client (uid,gid) pair to a2 Openvms account. The vms account can have any UIC.  D To allow root (Superuser) access, the mapping of the default user onE the VMS side must be changed. For the setup details, refer to section C 16.1.5 of the TCP/IP configuration manual (on the compaq web site).E   Regards,
 Doran Werlingh RW/SCS Inc.        Sent via Deja.comc http://www.deja.com/   ------------------------------  % Date: Wed, 20 Dec 2000 15:49:00 -0800f- From: "Scott Stark" <hayden.s.stark@saic.com>"B Subject: NLA0: the null device - can VMS have other default names?' Message-ID: <3a40d512$1@cpns1.saic.com>l  - From: "Scott Stark" <hayden.s.stark#saic.com>T/ Subject: NLA0: null device - by default on VMS? + Date: Wednesday, December 20, 2000 12:59 PMl   Hi, B Does VMS ever assign a value other than NLA0:  as the null device?   Thanks,- Scot t Stark   ------------------------------  % Date: Wed, 20 Dec 2000 15:12:04 -0900 9 From: "Julliard, Alan T." <JulliardAT@ci.anchorage.ak.us> F Subject: RE: NLA0: the null device - can VMS have other default names?> Message-ID: <5EBCB843B341D411B40A000629382DEC01501CBF@DILBERT>   Scott,  J   You could assign unlimited logicals to point to NLA0: if that's what you need.  For example,r   $ ty gibberishE %TYPE-W-SEARCHFAIL, error searching for DKA300:[000000]GIBBERISH.LIS;C -RMS-E-FNF, file not found $ define null1 nla0: $ define null2 nla0: $ define sys$error null1 $ define sys$output null2R $ ty gibberish $F $ deassign sys$error $ deassign sys$outputT $ ty gibberishE %TYPE-W-SEARCHFAIL, error searching for DKA300:[000000]GIBBERISH.LIS;I -RMS-E-FNF, file not found   Alan   > -----Original Message-----2 > From:	Scott Stark [SMTP:HAYDEN.S.STARK@saic.com], > Sent:	Wednesday, December 20, 2000 2:49 PM > To:	Info-VAX@Mvb.Saic.Com-D > Subject:	NLA0: the null device - can VMS have other default names? >  > / > From: "Scott Stark" <hayden.s.stark#saic.com>e1 > Subject: NLA0: null device - by default on VMS? - > Date: Wednesday, December 20, 2000 12:59 PMe >  > Hi,@D > Does VMS ever assign a value other than NLA0:  as the null device? > 	 > Thanks,  > Scot t Stark >  >  >  >    ------------------------------  # Date: Thu, 21 Dec 2000 00:10:29 GMT-( From: Terry Kennedy <terry@gate.tmk.com>F Subject: Re: NLA0: the null device - can VMS have other default names?& Message-ID: <G5w5tH.Mw@spcuna.spc.edu>  - Scott Stark <hayden.s.stark@saic.com> writes: D > Does VMS ever assign a value other than NLA0:  as the null device?  E   I'm not sure what you're asking here, so I'll answer it in 3 parts:/  K   1) NLA0: isn't a template device, so no more units will be created by the       system.  H   2) Nothing would prevent someone from doing a SYSGEN CONNECT / etc. to=      make a new device called NLB0:, NLQ1234:, or even FOO99:e  K   3) Similarly, someone could create a new driver to duplicate the functione
      of NLA0:o  3   On a stock system, NLA0: is the only null device.t  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USA.   ------------------------------  % Date: Wed, 20 Dec 2000 17:56:50 -0800M- From: "Scott Stark" <hayden.s.stark@saic.com>uF Subject: Re: NLA0: the null device - can VMS have other default names?% Message-ID: <3a40f30b@cpns1.saic.com>c  J Understood.   Here's what I'd like to know...can or does VMS (on it's own)H ever define the null device to something other than NLA0 (w/o deliberate user intervention)?eD "Julliard, Alan T." <JulliardAT@ci.anchorage.ak.us> wrote in message8 news:5EBCB843B341D411B40A000629382DEC01501CBF@DILBERT... > Scott, >6L >   You could assign unlimited logicals to point to NLA0: if that's what you > need.  For example,e >r > $ ty gibberishG > %TYPE-W-SEARCHFAIL, error searching for DKA300:[000000]GIBBERISH.LIS;h > -RMS-E-FNF, file not found > $ define null1 nla0: > $ define null2 nla0: > $ define sys$error null1 > $ define sys$output null2. > $ ty gibberish > $d > $ deassign sys$error > $ deassign sys$outputD > $ ty gibberishG > %TYPE-W-SEARCHFAIL, error searching for DKA300:[000000]GIBBERISH.LIS;: > -RMS-E-FNF, file not found >< > Alan >. > > -----Original Message-----4 > > From: Scott Stark [SMTP:HAYDEN.S.STARK@saic.com]. > > Sent: Wednesday, December 20, 2000 2:49 PM > > To: Info-VAX@Mvb.Saic.ComiF > > Subject: NLA0: the null device - can VMS have other default names? > >s > >h1 > > From: "Scott Stark" <hayden.s.stark#saic.com>e3 > > Subject: NLA0: null device - by default on VMS? / > > Date: Wednesday, December 20, 2000 12:59 PMe > >d > > Hi,iF > > Does VMS ever assign a value other than NLA0:  as the null device? > >d > > Thanks,i > > Scot t Stark > >a > >e > >i > >d   ------------------------------  % Date: Wed, 20 Dec 2000 17:58:55 -0800I- From: "Scott Stark" <hayden.s.stark@saic.com>eF Subject: Re: NLA0: the null device - can VMS have other default names?' Message-ID: <3a40f391$1@cpns1.saic.com>-  3 >>On a stock system, NLA0: is the only null device.   + I'm satisfied with that answer.  Thank you. 5 "Terry Kennedy" <terry@gate.tmk.com> wrote in message-  news:G5w5tH.Mw@spcuna.spc.edu.../ > Scott Stark <hayden.s.stark@saic.com> writes: F > > Does VMS ever assign a value other than NLA0:  as the null device? >RG >   I'm not sure what you're asking here, so I'll answer it in 3 parts:k >tI >   1) NLA0: isn't a template device, so no more units will be created byc theh >      system. >0J >   2) Nothing would prevent someone from doing a SYSGEN CONNECT / etc. to? >      make a new device called NLB0:, NLQ1234:, or even FOO99:o >eD >   3) Similarly, someone could create a new driver to duplicate the function >      of NLA0:d >a5 >   On a stock system, NLA0: is the only null device.s > 6 >         Terry Kennedy             http://www.tmk.com7 >         terry@tmk.com             Jersey City, NJ USAn   ------------------------------  % Date: Wed, 20 Dec 2000 20:34:39 -0600h7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>.F Subject: Re: NLA0: the null device - can VMS have other default names?- Message-ID: <3A416C3F.E9B41151@earthlink.net>b   Scott Stark wrote: > L > Understood.   Here's what I'd like to know...can or does VMS (on it's own)J > ever define the null device to something other than NLA0 (w/o deliberate > user intervention)?t   I believe the answer is "no".   C Are you experiencing a perplexing problem? What is the point of the 	 question?p   --   David J. Dachterac dba DJE Systemsf http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/r  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.e   ------------------------------  # Date: Thu, 21 Dec 2000 00:47:10 GMTo" From: fooguy <jweisen@my-deja.com>  Subject: OpenVMS SAN Integration) Message-ID: <91rjuc$1ot$1@nnrp1.deja.com>e  G We have Xiotech Fiberchannel Storage Area Network Solution, to which weCB have attached several Netware, NT, and Solaris systems. We have onE order, to replace our AS800, (2) DS20s (one with a Solid State Disk).O? What we're wondering, is if anyone has had any luck with QLogicnB Fiberchannel HABs under OpenVMS. QLogic seems to make hardware andH drivers for every platform and OS (and DEC seems to use their stuff here and there).e   Thanks,i John   --- *********************************************t( "All I every wanted from life was to see, Larry Wall give Bill Gates a Perl Necklace."     Sent via Deja.comI http://www.deja.com/   ------------------------------   Date: 20 Dec 2000 21:32:33 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: OpenVMS Tech Tour (Greenbelt MD) 6 Message-ID: <91r8hh$nmr$1@mailint03.im.hou.compaq.com>  I   The ESILUG (Enterprise Server Local Users Group) is seeking informationnL   and interest in the contents of an OpenVMS technical event expected to be J   held in March 2001 in the Greenbelt Maryland USA or another nearby site.  
   Details:  (     http://eisner.decus.org/lugs/esilug/     Contents:v  8     http://eisner.decus.org/lugs/esilug/vmstechtour.html  J   The speakers and the contents will be determined based on your feedback.  8   Follow-ups have been set to the comp.os.vms newsgroup.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 20 Dec 2000 23:03:06 GMTo From: Dirk Munk <munk@home.nl>$ Subject: Re: scaling an indexed file' Message-ID: <3A413A7A.2662BC36@home.nl>n   David Mathog wrote:  > K > I know that VMS is scalable but my own experiences are with small serverslK > and 2 or 3 node clusters, so I don't have much of a feel for what happens H > when things really become big.  This had me wondering just how scaling# > might occur in some simple cases.r > M > Here's one hypothetical scenario.  A single small VMS machine is configured M > to run a web server and through that maintain a single indexed file.   ThisrI > file contains a catalog of products for a small company (for instance.)yX > Through the web interface these three actions with respect to that file are supported: > Y >   1.  add data.  A small amount of data (256 bytes, fixed) is added sequentially to thenQ >       indexed file as a single record, and the record number (key) is returned.- >       (2% of activity)M >   2.  retrieve data. The key is supplied by the user, that record is looked:" >       up, and its data returned. >       (98% of activity)4K >   3.  modify data.  The key and a password are supplied by the user.  TherK >       record is looked up with the key, the internal password it containssJ >       checked against that stored in the record, the record is modified,% >       and is rewritten to the file.  >       (<<1% of activity) > H > The data is important, so it must be physically stored on at least twoL > disks.  Once data is accepted through the interface it MUST be safe.  Loss > of any data is unacceptable. > H > This is a pretty simple application. For a small numbers of hits and aJ > small amount of data it would run fine on a DS10 using disk shadowing orH > even just operating on two files in parallel.  However as time goes onM > demand grows, and grows, and grows.  The number of records goes up into the F > hundreds of millions or billions and the number of retrieve requestsK > rockets upwards into millions per day.  All of a sudden the small catalogtN > isn't small anymore and you're running the parts catalog for General Motors! > F > How do you scale it?   I can see that to start with you can add moreF > cluster nodes and leave the data on one machine (or shadow it acrossF > multiple machines.)   Assuming that these are clustered via 100baseTG > what's going to be rate limiting for the 3 processes described above?-J > Record locking?  Packet rates?  What would be the maximum rate you couldF > achieve for each of the 3 processes in an N node cluster (assume allC > DS10s)?   Then demand exceeds those limits.  What do you do next?c > G > I'm guessing that at some point this problem essentially evolves intovM > a cloud of front end systems, which handle the vast majority of simple data M > retrieval requests, and one or more back end systems that handle data entry G > and modification.  But is there a natural point at which this occurs?b > L > Might this same process be accomplished better on a different OS?  If not,* > what is it that gives VMS the edge here?  E If an indexed file is set up correctly, and if it is well maintained, @ then reading data from it is a extremely efficient process. WithE adequate global buffering, every data record retrieved will only costE0 you one disk IO, and almost no processing power.  H Your storage setup is much more important. Let's say you want to be ableD to service 20 million requests per day. A fast disk can do somethingC like 200 IO's/second (in practice) , so you would need 100.000 disktD seconds. Divide this by 24 x 3600, and you end up with 1.15 disks. AH stripeset (raid 0) with 2 disks would be adequate for this amount of IO.  F Now let us assume you want to have a file with 4 billion records. ThatE file would have a size of 1200 GB (1000 GB + 20% overhead). You wouldoB need 33 36GB disks to accomodate this file, or 66 disks if you useH mirroring (raid 1). It is not possible to configure them as one raid 0+1D set (to many disks), so you would have to split up the file. But oneF HSZ80 or HSG80 cabinet with the new modula drives would be sufficient.D And with 66 disks, you can handle a astronomical amount of requests.  E Conclusion: Get yourself a nice raid array controller (HSZ80, or even-E better HSG80 on fibrechannel), configure a raid 0+1 set of disks, andSF you will have no problem handling many millions of requests a day. AndH if you use fibrechannel, a whole cluster of 8 machines with 2 interfaces8 per machine can access this raid set at the same time.  D These are just rough calculations of course, but you can see what is possible ...   Regards,   Dirk   ------------------------------  # Date: Wed, 20 Dec 2000 18:38:20 GMT + From: Jordan Henderson <jordan@my-deja.com>h Subject: Re: Sun Cluster) Message-ID: <91quar$eas$1@nnrp1.deja.com>a  * In article <3A409DAF.9DF314FD@uk.sun.com>,3   andrew harrison <andrew.nospam@uk.sun.com> wrote:i > Jordan Henderson wrote:h > > 
 > > [snip] > > D > > Anyone else find it interesting that we are supposed to believe,B > > all at the same time, that Andrew is not in marketing, none ofE > > his customers use OpenVMS, as he's reported here in the past, andtD > > yet he's able to get a room full of people together, including a4 > > number of OpenVMS administrators and developers? > >  >t= > The customer I work for has purchased another company whicht= > happens to have a large OpenVMS infrastructure. The OpenVMSe: > folks all come from the company that has been bought and( > assimilated if that is the right term. >n= > But really Jordan, nearly every large company has a mixture4> > of systems and the company I am working for is no different. >oA > Their standard server suppliers are IBM and Sun, S390's and AIX B > from IBM and Solaris based systems from Sun. They of course have> > Niles, HP's, OpenVMS and Tru64 based systems as well becauseB > they either needed an app that only runs on one of these systemsE > or because in the case of OpenVMS they have a legacy infrastructurew6 > that they aquired when they aquired another company. >nA > Nor would it be suprising if indeviduals have both say UNIX andO> > OpenVMS skills, its certainly the case with the company I am> > working for since they are migrating from OpenVMS to AIX and
 > Solaris. >.  A I was only basing this on your own statements some time back that,A you never see OpenVMS in your markets anymore.  Seems like eithera* you were lying then, or you are lying now.  @ When it befits your campaign against OpenVMS to say that OpenVMS> has been completely replaced among your customers, that's what> you say.  When you prefer to have a few OpenVMS experts around, to ask questions, then they suddenly appear.  @ I would say something about your credibility, but you've already= established quite clearly that you have none whatsoever.  I'm < still waiting for your examples of how it was I who used the@ term FUD inconsistently.  Funny how you told another poster that' you never dodged questions from Jordan.   > > > By his own statements, it sounds more believable that he'sB > > actually a technical resource, groomed in OpenVMS technologies9 > > to counter any marketing one might see out of Compaq.w > >. >/> > The fact that you find this unbelievable is more a testiment& > to your own bias than anything else. >H@ > > That's certainly what he does here.  I'd wager you'd be hardB > > pressed to find a Sun employee who knows more about Compaq and > > OpenVMS than Andrew. >u@ > I very much doubt that that is true either. I have 2 collegues? > both technical who sit within 10 yards of my desk, one workedhD > for Compaq supporting OpenVMS and one left a few days prior to the2 > Compaq takeover and was also in OpenVMS support.
 > of Digital,e >e  B Somehow, these colleagues of yours aren't so interested in OpenVMS+ as to be frequent posters to this newgroup.c  	 > regardsw > Andrew Harrisont > Enterprise IT Architect. >    -- -Jordan Henderson- jordan@greenapple.comn     Sent via Deja.com- http://www.deja.com/   ------------------------------    Date: 20 Dec 2000 14:25:12 -0500* From: young_r@eisner.decus.org (Rob Young) Subject: Re: Sun Cluster+ Message-ID: <VGGuxk12031K@eisner.decus.org>i  ] In article <3A409E5D.D11D39A3@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:w > "Richard D. Piccard" wrote:n >> rH >> Can you re-check your OZ sources on the reason for failing acceptanceN >> testing?  I heard a rumor it stayed up long enough but just ran too slowly. >> d& >>                                 RDP >>   > I > The rumour that it failed it acceptance tests because of unreliability h, > was speculation (FUD) on Rob Youngs part.  >   : 	No... it failed acceptance testing.  Maybe there is a way= 	to pretty that up but from their own website it showed they	 > 	were re-issuing RFPs and that Sun was allowed to participate.< 	Maybe we can get caught up in semantics or meaning but they= 	had a 4 node UE10000 there that never went production.  Tell  	us what that means.   				Robr   ------------------------------  % Date: Wed, 20 Dec 2000 15:31:59 -0500 0 From: David Beatty <David.Beatty.NOSPAM@sas.com> Subject: Re: Sun Cluster2 Message-ID: <DxdBOvuksfP9EeFdmtjE3ovCSBX+@4ax.com>  7 I found the article and it says the system did not passe, acceptance testing within the required time:  O http://www.australianit.com.au/common/storyPage/0,3811,1387976%255E3662,00.htmls  ' As usual, draw your own conclusions ...m  C On 20 Dec 2000 14:25:12 -0500, young_r@eisner.decus.org (Rob Young)v wrote:  ^ >In article <3A409E5D.D11D39A3@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes: >> "Richard D. Piccard" wrote: >>> I >>> Can you re-check your OZ sources on the reason for failing acceptancemO >>> testing?  I heard a rumor it stayed up long enough but just ran too slowly.l >>> ' >>>                                 RDP  >>>  >> pJ >> The rumour that it failed it acceptance tests because of unreliability - >> was speculation (FUD) on Rob Youngs part. e >> i > ; >	No... it failed acceptance testing.  Maybe there is a wayt> >	to pretty that up but from their own website it showed they	? >	were re-issuing RFPs and that Sun was allowed to participate.n= >	Maybe we can get caught up in semantics or meaning but theya> >	had a 4 node UE10000 there that never went production.  Tell >	us what that means.a >o >				Rob   ------------------------------    Date: 20 Dec 2000 16:27:48 -0500* From: young_r@eisner.decus.org (Rob Young) Subject: Re: Sun Cluster+ Message-ID: <WH5sSadSuLbp@eisner.decus.org>i  e In article <DxdBOvuksfP9EeFdmtjE3ovCSBX+@4ax.com>, David Beatty <David.Beatty.NOSPAM@sas.com> writes:  > 9 > I found the article and it says the system did not passs. > acceptance testing within the required time: > Q > http://www.australianit.com.au/common/storyPage/0,3811,1387976%255E3662,00.htmls > ) > As usual, draw your own conclusions ...e >   < 	The article confirms acceptance testing failure but doesn't= 	say why.  So maybe it isn't reliability as the issue.  Maybe < 	it is just because the UE10000 sucks and that is why Sun is@ 	allowed to rebid.  Maybe one of the rebid criteria is that they8 	can't use UE10000s as the hardware as they are too slow1 	with that cache scrubbing software in place ;-).a   				Robr   ------------------------------  % Date: Wed, 20 Dec 2000 22:35:19 -0500o9 From: "Steven Shamlian" <not dot an at earthling dot net>n. Subject: System halts when console is shut off2 Message-ID: <91rts7$e7s$1@slb2.atl.mindspring.net>  B This post is in regards to a VAXstation 4000 VLC.  The machine ranL wonderfully before my graphics monitor randomly died and I had to hit s3 andI use a terminal as the system console.  To save power on the machine (it's K only a fileserver, so I don't care all that much about what messages scrolloB across its screen), I turn the console on only when necessary (forK [re]booting it and the like).  However, with the terminal-as-console setup,aL the VAX halts itself whenever I shut the terminal off (shutting the graphicsL monitor off before didn't do this, most probably because monitors are outputH devices and so the VAX doesn't give a damn whether it's doing its job orI not).  How do I tell the VAX that it's really OK to keep running when theeI terminal shuts off?  Or is there a setting that needs modification on thet	 terminal?-   Thanks in advance. =+=Steven Shamlian=+=0   ------------------------------  # Date: Thu, 21 Dec 2000 05:06:09 GMTc2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>2 Subject: Re: System halts when console is shut off5 Message-ID: <5dg06.214$LU6.77470@typhoon.aracnet.com>2  8 Steven Shamlian <not dot an at earthling dot net> wrote:D > across its screen), I turn the console on only when necessary (forM > [re]booting it and the like).  However, with the terminal-as-console setup,nN > the VAX halts itself whenever I shut the terminal off (shutting the graphics  F Try setting it up to automatically boot.  I've got a VS3100 whose onlyJ purpose in life is an occasional compile on a V5.5-2 system.  I've noticedE if I have a terminal connected it'll halt, if I turn the terminal offwK (though it can be resumed).  If I boot it without a terminal connected it'se quite happy to run that way.  I So, I run it minus a console and just connect via a VT420 hooked up to myI
 DECserver.   			Zane0   ------------------------------  % Date: Wed, 20 Dec 2000 21:39:53 -0800 ! From: Koloth <koloth@tmisnet.com>12 Subject: Re: System halts when console is shut off+ Message-ID: <3A4197A9.916B213C@tmisnet.com>-  J Turning the terminal off is like sending a break to the console.  Which on# consoles send it into console mode.k* There is usually a switch to disable this.   Regards,   Cass Witkowski Senior Systems Engineer  SAIC   "Zane H. Healy" wrote:  : > Steven Shamlian <not dot an at earthling dot net> wrote:F > > across its screen), I turn the console on only when necessary (forO > > [re]booting it and the like).  However, with the terminal-as-console setup,cP > > the VAX halts itself whenever I shut the terminal off (shutting the graphics > H > Try setting it up to automatically boot.  I've got a VS3100 whose onlyL > purpose in life is an occasional compile on a V5.5-2 system.  I've noticedG > if I have a terminal connected it'll halt, if I turn the terminal off.M > (though it can be resumed).  If I boot it without a terminal connected it'sy > quite happy to run that way. >eK > So, I run it minus a console and just connect via a VT420 hooked up to myY > DECserver. >y >                         Zane   ------------------------------  # Date: Thu, 21 Dec 2000 00:05:26 GMTn( From: Terry Kennedy <terry@gate.tmk.com> Subject: Re: VAX emulation' Message-ID: <G5w5L2.JKK@spcuna.spc.edu>C  ; Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> writes:rB > If, however, one wanted the performance of a VAXstation 4000-96,> > wouldn't one need a host processor running at roughly 4Ghz ?  N   Beats me - I was quoting the SRI info page. At some point it's not practicalG to emulate, but coding heavily-used VAX instruction emulation or commontE parts of the instruction decode in assembler should speed things up).a  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USAh   ------------------------------  % Date: Wed, 20 Dec 2000 11:08:30 -0800n! From: Shane.F.Smith@Healthnet.com / Subject: Re: VAX emulation (was: Vax on a chip) D Message-ID: <OF7554047C.727C6D33-ON882569BB.00691D58@foundation.com>   HA ha ha ha ha bonk.  9 (That's the sound of me, laughing my head off. Good one.)w   Shane           G Christopher Smith <chriss@Mufasa.pubserv.com> on 12/20/2000 11:06:44 AMX   To:   Info-VAX@Mvb.Saic.Com  cc:n  0 Subject:  Re: VAX emulation (was: Vax on a chip)    6 On Wed, 20 Dec 2000 Shane.F.Smith@Healthnet.com wrote:  K > Worse. It might be a 4ghz on the PIII architecture scale, but there won'teE > be any 4ghz PIII's. The P4 is performing badly in benchmarks from atG > work-per-cycle point of view, so it'd have to be an even higher clockEI > speed. They're planning 2ghz late next year, so I'd guess 4ghz sometime/ inI > late 2002 or early 2003. You'd have to be using DDR RAM too, probably a9J > double pumped 150mhz or higher - I have serious doubts about RAMBUS evenG > existing that far out, based on the beating they're taking today. The$G > current PCI bus and disks probably wouldn't be a bottleneck for a VAXjI > emulator, but the kind of machine we're talking about may well be using 0 > souped-up serial ATA and PCI-X by then anyway.  B But, would the hardware be anywhere near as reliable as VAX stuff?   Regards,   Chris-  O ===============================================================================i  H "My two cents"           (http://rootworks.com/twocentsworth.cgi?128562)H Christopher Smith(chriss@pubserv.com)              Prgramer^W Programmer Prime Synergy of Champaign, IL.o% -------------------------------------tI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and-H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes: and weigh only 1.5 tons." -- Popular Mechanics, March 1949O -------------------------------------------------------------------------------s   ------------------------------  + Date: Wed, 20 Dec 2000 19:32:27 +0000 (   ) 3 From: Christopher Smith <chriss@Mufasa.pubserv.com>F/ Subject: Re: VAX emulation (was: Vax on a chip)sI Message-ID: <Pine.LNX.4.05.10012201927350.2792-100000@Mufasa.pubserv.com>s  6 On Wed, 20 Dec 2000 Shane.F.Smith@Healthnet.com wrote:   > HA ha ha ha ha bonk.; > (That's the sound of me, laughing my head off. Good one.)m  I I suppose it is sort of amusing, however, I'm completely serious. :)  I'd C take a MicroVAX II (now, today, with the age of said microvax under B consideration) over a 90Mhz pentium machine running Charon-VAX forC just that reason.  The apple-zealots who say that Intel Inside is a-3 warning lable are completely right in this respect.2   Regards,   Chrise  O =============================================================================== @ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmera Prime Synergy of Champaign, IL.u% -------------------------------------eI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949  O -------------------------------------------------------------------------------r   ------------------------------  # Date: Wed, 20 Dec 2000 23:17:56 GMT  From: Dan <dan@vrx.net>s/ Subject: Re: VAX emulation (was: Vax on a chip)e' Message-ID: <3A4166EC.1DE887B1@vrx.net>m  N Ok, dual CPU AMD Athlon, 1.2ghz each. that's a 2.4gig processing power system.O and not too expensive either. AMD probably have more stable and reliable higher.2 speeds over the next year as well (2ghz at least).       Christopher Smith wrote:  8 > On Wed, 20 Dec 2000 Shane.F.Smith@Healthnet.com wrote:D > But, would the hardware be anywhere near as reliable as VAX stuff? >n
 > Regards, >c   ------------------------------  % Date: Wed, 20 Dec 2000 15:30:00 -0800i! From: Shane.F.Smith@Healthnet.coma/ Subject: Re: VAX emulation (was: Vax on a chip)BD Message-ID: <OFC070D3DC.CAC39BAD-ON882569BB.0080B9F2@foundation.com>  J I have had far more failures on even the best quality x86 stuff than on myJ old MicroVAX II. BTW, you've got the attribution messed up there. I didn't" say that, but I did I laugh at it.   Shaner          + Dan <dan@vrx.net> on 12/20/2000 03:17:56 PM2   To:   Info-VAX@Mvb.Saic.Coma cc:s  0 Subject:  Re: VAX emulation (was: Vax on a chip)    F Ok, dual CPU AMD Athlon, 1.2ghz each. that's a 2.4gig processing power system.uH and not too expensive either. AMD probably have more stable and reliable higher2 speeds over the next year as well (2ghz at least).       Christopher Smith wrote:  8 > On Wed, 20 Dec 2000 Shane.F.Smith@Healthnet.com wrote:D > But, would the hardware be anywhere near as reliable as VAX stuff? >f
 > Regards, >r   ------------------------------  % Date: Wed, 20 Dec 2000 14:24:33 -0500 - From: "Richard D. Piccard" <piccard@ohio.edu>f Subject: Re: Vax on a chip( Message-ID: <3A410766.E7308A62@ohio.edu>  f The hardware solution has been moderately successful for Windows PC cards in Macintosh computers (both( Apple and Orange Micro did such things).  d At the present time, price/performance for Windows on Macintosh favors software instead of hardware:h Virtual PC V3 will install the regular Office 2000 CDs, although it has troubles running some games thate try to get too intimate with the hardware (Roller Coaster Tycoon, for example, counts on replacing orue bypassing the mouse driver while it is running).  There is one VMS-related thing that I regularly use-g through Virtual PC:  WS_FTP can be configured to automatically strip off version numbers and semicolons:U while downloading files, but the native FTP on Mac, Fetch, cannot (so far as I know).F  f One could argue that the VAX-11 compatibility mode and the Apple 680x0 emulator for PowerPC are on the edges of this space, too.e  #                                 RDPp     Hoff Hoffman wrote:   j > In article <OF2B58A019.E9042353-ON882569BA.0071A6B1@foundation.com>, Shane.F.Smith@Healthnet.com writes: > : 8 > :...Interesting idea, an Alpha board in a PC. You keepJ > :your Office stuff, and you have a real computer in the same box for the > :serious stuff..... Hmmm.....w > :oK > :Hey, Q guys - he might have something here. Call it an "enhanced windowsr > :machine"... >nJ >   This is an idea has been around for eons and has not been a particularL >   success in most contexts... I've seen Q-bus PC boards, network-based PCsE >   with remote displays on OpenVMS and UNIX hosts, and various othernI >   permutations of combining two architectures into one box using either  >   software or hardware.l >sL >   Search keywords for similar products include Logicraft, 386ware, SoftPC,K >   SoftWindows, DECmigrate, FX!32.  I'm sure folks here can cite other and M >   older and newer products and vendors.  Various of these vendors and otherfJ >   have tried this and related markets over the years -- and with varying >   degrees of success.  >iM >   Few vendors and few of these approaches have been particularly successfultK >   in this market, save for in some very specific applications and/or veryXK >   specific markets -- the business model, the size of the target customermI >   base and (without the benefits of volume) the relatively high productt2 >   costs can combine to be somewhat of a problem. >nP >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Wed, 20 Dec 2000 20:46:00 +0100e" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Vax on a chip( Message-ID: <91r26f$4hf$1@news.IAEhv.nl>  J The idea is not entirely new. IBM made a card with a S/370 chip on it that	 fitted insI an Intel box, even a laptop. The PC had to run OS/2 of course and allowed  you toD boot any (mix) of S/370 series operating systems. Very neat for demo	 purposes.eI IBM dropped Intel support but still has a similar set up for the RS/6000.o  A It is a lot cheaper to emulate an instruction set, either throughm microprogramming orsG by coding an instruction set emulator. The CHARON-VAX product does justs that.dL The freeware issue is throttled at approx. 2 VUPS. Even when the VAX machine idles,G it takes 98% cpu on my Pentium II 350 MHz processor (under RedHat 6.0).   L Note that Burroughs (now Unisys) did the same for their A series mainframes.H The instruction set was put in software and runs on an Intel /WNT server box.K It's a bit of a shock to hear a fine o/s run that way but I'm sure that thee (rather unique) ; A series architecture would have been long gone without it.e4 The same way it could preserve the VAX architecture.  
 Hans Vlems  C fabio_compaq@ep-bc.petrobras.com.br heeft geschreven in bericht ...o >Peoplen >tK >Forgive me if I am wrong... if is possible to have a CHARON-VAX  emulator,m
 >why not a3 >PCI card with a chip to emulate a VAX / MicroVAX ?h > = >I thing the Amiga people used to have an idea like this ....g >I >Regards >r >FCt >d   ------------------------------  % Date: Wed, 20 Dec 2000 14:28:24 -0500 ' From: Jack Patteeuw <jpatteeu@ford.com>t Subject: Re: Vax on a chip' Message-ID: <3A410858.3A5CA2F@ford.com>t   Hoff Hoffman wrote:  > j > In article <OF2B58A019.E9042353-ON882569BA.0071A6B1@foundation.com>, Shane.F.Smith@Healthnet.com writes: > :t8 > :...Interesting idea, an Alpha board in a PC. You keepJ > :your Office stuff, and you have a real computer in the same box for the > :serious stuff..... Hmmm.....  > : K > :Hey, Q guys - he might have something here. Call it an "enhanced windows- > :machine"... > J >   This is an idea has been around for eons and has not been a particularL >   success in most contexts... I've seen Q-bus PC boards, network-based PCsE >   with remote displays on OpenVMS and UNIX hosts, and various othernI >   permutations of combining two architectures into one box using eitherl >   software or hardware.g  D You have it backwards.  Put the PC on a board (easy enough) and someG fancy drivers to "sahre" access to the video board and talk to a driveru( that can share files on the local drive.  % Sun is selling 1000's of these things.G (http://www.sun.com/desktop/products/sunpci) around here.  According to 8 the local Compaq sales, they "aren't interested" !!!!!!!    
 Jack Patteeuwn   ------------------------------  % Date: Wed, 20 Dec 2000 20:52:30 +0100 " From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Vax on a chip( Message-ID: <91r2im$5c2$1@news.IAEhv.nl>  H I'm not sure that's true. The last generation mVAX chips is surprisingly small.L Two cards would be all that is needed, perhaps with an external link instead of the PCI bus.  I A rather interesting idea would be to shrink the EV5 chip in the new EV67  processiG and see at what speed it would run reliably. Intel just shows that CISC	 implementations0 still have a commercial life.t9 The volume of the Intel chips is of course a winner here.-  
 Hans Vlems  - Terry Kennedy heeft geschreven in bericht ...m, >fabio_compaq@ep-bc.petrobras.com.br writes:B >> Forgive me if I am wrong... if is possible to have a CHARON-VAX	 emulator,< >> why not a5 >> PCI card with a chip to emulate a VAX / MicroVAX ?P >sK >  VAX chips have been out of production for > 5 years (the last VAXen weresK >built with chips made a long time ago, before DEC sold its fabs to Intel).a >.I >  Thus, they don't have the high level of integration that today's chipsr do.uK >You're probably looking at multiple PCI cards, plus a blank slot for heat-e >sink clearance. >yK >  Alpha chips are probably a closer fit, since the smaller Alpha boxes arehL >pretty close to PC architecture, but with an Alpha chip instead of an IntelH >one. However, just because those systems can control a PCI bus, doesn't mean; >that the same parts could operate as a PCI bus peripheral.	 >oI >  I'd expect that a VAX architecture emulator (for, say, the MicroVAX II0I >subset implementation) could exceed the performance of a real MV II whensH >run on a reasonably modern Intel processor, even if coded in a HLL. TheK >Charon-VAX page claims 1 VUP per 100MHz, so a 90MHz original Pentium wouldeI >be faster than a MicroVAX II. So a hardware solution would be at a speed  >disadvantage. >nJ >  The VAX archictecture documents fully specify the architecture, so it's3 >not like reverse-engineering an unknown processor.g >s5 >        Terry Kennedy             http://www.tmk.comw6 >        terry@tmk.com             Jersey City, NJ USA   ------------------------------  % Date: Wed, 20 Dec 2000 12:17:36 -0800h! From: Shane.F.Smith@Healthnet.comr Subject: Re: Vax on a chipD Message-ID: <OF390D9939.91675673-ON882569BB.006EFCE7@foundation.com>  I Oooh, now THAT is an idea. I know I could sell my management on that. The F only reason I'm not using a VMS workstation right now is MS Office andI Lotus being company standards. If I could run those on a PC card, I could K put a real machine on my desk and really get some work done. That way round- it's much more reliable, too.6  1 Now I  /really/ want the Q to notice this thread.e   Shaneu          ; Jack Patteeuw <jpatteeu@ford.com> on 12/20/2000 11:28:24 AM4  4 Please respond to patteeuw@pt9500.pcse.poee.ford.com   To:   Info-VAX@Mvb.Saic.Comr cc:    Subject:  Re: Vax on a chipe     Hoff Hoffman wrote:e >rF > In article <OF2B58A019.E9042353-ON882569BA.0071A6B1@foundation.com>,# Shane.F.Smith@Healthnet.com writes:f > :e8 > :...Interesting idea, an Alpha board in a PC. You keepJ > :your Office stuff, and you have a real computer in the same box for the > :serious stuff..... Hmmm.....o > :5K > :Hey, Q guys - he might have something here. Call it an "enhanced windowsu > :machine"... >wJ >   This is an idea has been around for eons and has not been a particularH >   success in most contexts... I've seen Q-bus PC boards, network-based PCscE >   with remote displays on OpenVMS and UNIX hosts, and various other-I >   permutations of combining two architectures into one box using eithero >   software or hardware.:  D You have it backwards.  Put the PC on a board (easy enough) and someG fancy drivers to "sahre" access to the video board and talk to a driverh( that can share files on the local drive.  % Sun is selling 1000's of these thingscG (http://www.sun.com/desktop/products/sunpci) around here.  According to 8 the local Compaq sales, they "aren't interested" !!!!!!!    
 Jack Patteeuwg   ------------------------------  # Date: Thu, 21 Dec 2000 00:03:08 GMT ( From: Terry Kennedy <terry@gate.tmk.com> Subject: Re: Vax on a chip' Message-ID: <G5w5H8.J9H@spcuna.spc.edu>a  5 Roger Ivie <rivie@server.newlogan.teraglobal> writes: J > Bear in mind that one flavor of the last round of VAX chips was (mostly)G > pin-compatible with the 21064. An NV5, an APECS chipset, and a bit of.G > imagination yields a VAX with PCI. Been there, done that, didn't havee= > enough funding or manpower to write my own SYSLOA module...h  H   Was that the VAX 7000 / DEC 7000 cabinet that could take either VAX orF AXP processors (but not a mix)? I heard that the only other change wasH re-flashing the XMI controllers for the different pagelet/scatter-gather stuff.  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USAe   ------------------------------  # Date: Thu, 21 Dec 2000 00:18:07 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Vax on a chip; Message-ID: <3%b06.3365$gS.2497673@typhoon.ne.mediaone.net>a  . <Shane.F.Smith@Healthnet.com> wrote in message> news:OF390D9939.91675673-ON882569BB.006EFCE7@foundation.com... >oK > Oooh, now THAT is an idea. I know I could sell my management on that. TheiH > only reason I'm not using a VMS workstation right now is MS Office andK > Lotus being company standards. If I could run those on a PC card, I could,G > put a real machine on my desk and really get some work done. That way8 round0 > it's much more reliable, too.. >   I Umm, would MS-Office or Lotus be any more reliable on a Wintel board in a2/ VMS workstation than on Windoze on a Wintel PC?h   ------------------------------  + Date: Thu, 21 Dec 2000 00:47:05 +0000 (   ) 3 From: Christopher Smith <chriss@Mufasa.pubserv.com>b Subject: Re: Vax on a chipI Message-ID: <Pine.LNX.4.05.10012210044010.2792-100000@Mufasa.pubserv.com>o  , On Thu, 21 Dec 2000, Terry C. Shannon wrote:  0 > <Shane.F.Smith@Healthnet.com> wrote in message@ > news:OF390D9939.91675673-ON882569BB.006EFCE7@foundation.com... > >yM > > Oooh, now THAT is an idea. I know I could sell my management on that. TheeJ > > only reason I'm not using a VMS workstation right now is MS Office andM > > Lotus being company standards. If I could run those on a PC card, I couldrI > > put a real machine on my desk and really get some work done. That way5 > roundi! > > it's much more reliable, too.R  K > Umm, would MS-Office or Lotus be any more reliable on a Wintel board in a 1 > VMS workstation than on Windoze on a Wintel PC?   G No, but the discussion was previously about putting a VAX or Alpha on an/ board in a pc system.  So the question becomes:A  D "Would a primarilly Alpha/VAX setup that happens to have a bit of pcC hardware on a card be more reliable than a primarilly PC setup that=1 happens to have some Alpha/VAX  stuff on a card?"=  G I believe the answer is yes. -- at the very least it's more likely thani the reverse.   Regards,   Chrisp  O ===============================================================================-@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmer  Prime Synergy of Champaign, IL.o% -------------------------------------1I "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and-H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 mO -------------------------------------------------------------------------------:   ------------------------------  % Date: Wed, 20 Dec 2000 23:39:59 -0800a, From: Jack Patteeuw <jjpatteeuw@voyager.net> Subject: Re: Vax on a chip8 Message-ID: <3a41892c$0$35014$2c3edae7@news.voyager.net>   Christopher Smith wrote: >   F > "Would a primarilly Alpha/VAX setup that happens to have a bit of pcE > hardware on a card be more reliable than a primarilly PC setup that 3 > happens to have some Alpha/VAX  stuff on a card?"  >   L You can make a case for both options, the problem is Compaq is too stupid toL realize that there is a marketplace out there in the business world for this7 type of "two headed" beast and only Sun has a solution.=   Are you listening Q ?????     
 Jack Patteeuw/   ------------------------------  % Date: Wed, 20 Dec 2000 20:53:16 -0500c, From: "Glenn C. Everhart" <Everhart@GCE.com> Subject: Re: VMS 7.3 EFT2 Q-' Message-ID: <3A411C3B.4FAD0AA4@GCE.com>u  1 It is for sale, same order # as the old one; $40.e   No idea what is in it...     Dave Gudewicz wrote: > H > Saw on the VMS web page today that EFT2 for VMS 7.3 has been released. > M > Went to www.openvms.compaq.com/openvms/sdk.html and found reference to EFT1-N > but no mention of EFT2, except for the SDK scheduled to be available in Oct. > Y2K. >  > Anyone found notes on EFT2?V > I > Also saw vmsnet.sdk.openvms.fieldtest mentioned as a newsgroup for 7.3.  > Nothing in it yet. > 	 > Dave...    ------------------------------  % Date: Wed, 20 Dec 2000 23:08:08 -0600 + From: "Main, Kerry" <Kerry.Main@compaq.com>. Subject: RE: VMS 7.3 EFT2 QsN Message-ID: <910612C07BCAD1119AF40000F86AF0D805284B1D@kaoexc3.kao.cpqcorp.net>   Dave,m  " >>> Anyone found notes on EFT2?<<<  
 Reference:0 <http://www.openvms.compaq.com/openvms/sdk.html>  J Not sure, but I thought that once you were signed up as a FT Customer, you5 had access to the online doc's. Is this not the case?:   Regards,  
 Kerry Main Senior Consultants Compaq Canada Inc. Professional Services0 Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----6 From: Dave Gudewicz [mailto:david.gudewicz@abbott.com] Sent: December 20, 2000 9:36 AM  To: Info-VAX@Mvb.Saic.Com  Subject: VMS 7.3 EFT2 Q     F Saw on the VMS web page today that EFT2 for VMS 7.3 has been released.  K Went to www.openvms.compaq.com/openvms/sdk.html and found reference to EFT1aL but no mention of EFT2, except for the SDK scheduled to be available in Oct. Y2K.   Anyone found notes on EFT2?i  G Also saw vmsnet.sdk.openvms.fieldtest mentioned as a newsgroup for 7.3.i Nothing in it yet.   Dave...d   ------------------------------  % Date: Wed, 20 Dec 2000 12:39:35 -0900 9 From: "Julliard, Alan T." <JulliardAT@ci.anchorage.ak.us>  Subject: VMSTAR-> Message-ID: <5EBCB843B341D411B40A000629382DEC01501CBD@DILBERT>  
 Greetings!  L   I am new to this list (sorry for the previous SUBSCRIBE post - it's been aH while since I subscribed to any list).  I have 2 Alpha's which I want toG backup via NFS to an IBM S/390 with a tape robot running OMVS 2.7.  ThecL Alpha's are running OpenVMS 7.1 with Process Multinet 4.2.  I seem to recallG that Process does not support BACKUP to NFS due to file permissions notlJ translating back on a restore.  Having read suggestions of using VMSTAR toJ accomplish the same task, I have added VMSTAR_AXP.EXE as a foreign commandJ (VMSTAR :== $disk:[directory]VMSTAR-AXP.EXE).  When I attempt to run it, IE receive the following error (doen't matter which Alpha - same error).t   $ vmstar cvf test.tar *.*u; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual: address=000000007B51& 5E48, PC=000000000002014C, PS=0000001B/ %TRACE-F-TRACEBACK, symbolic stack dump followstJ   image    module    routine             line      rel PC           abs PC>  VMSTAR-AXP  VMSTAR  main                7817 000000000000014C 000000000002014C>  VMSTAR-AXP  VMSTAR  __main                 0 0000000000000058 0000000000020058>                                             0 FFFFFFFF82F350D8 FFFFFFFF82F350D8   I found a similiar problem atyG http://www.openvms.compaq.com/wizard/wiz_0880.html but that's it.  Does H anyone out there have a clue as to what's going on or how to fix it?  OrH does anyone have a better idea for backing up Alpha disks to a differentJ system that would allow a full restore (my TZ87 tape drives seem to be theL only Achilles heel of either Alpha system -  I recently rebooted one of themI to change some system parameters and it had been up for 11 months withoutsK any problem!)?  Barring any solution, I will just carry on with the currenta$ tape backups and not worry about it.   Thanks!d  
 Alan Julliardc Municipality of Anchorage, MISDi   ------------------------------  % Date: Wed, 20 Dec 2000 14:46:26 -0900e9 From: "Julliard, Alan T." <JulliardAT@ci.anchorage.ak.us>  Subject: RE: VMSTARt> Message-ID: <5EBCB843B341D411B40A000629382DEC01501CBE@DILBERT>   Chris,  L   I had thought of that when it first happened so changed all permissions toJ RWED for SOGW - no change.  I "own" the image so that's not it but I triedI with the SYSTEM account anyway.  I also own all files I am trying to tar.eL Actually, any use of VMSTAR produces the exact same error except VMSTAR with' no parameters which returns the "help":b   $ vmstar1 usage: tar x|c|t[vbd][f tarfile] [file [file...]]-   Thanks anyway.  
 [Later...]  J Ok, since I had the source files and was trying to find the error there, IH compiled and linked the source code into a new image and it works!!  The' original executable I had obtained from J http://www.openvms.compaq.com/openvms/freeware/freeware.html.  However, beL that as it may, I am still looking for advice from folks who have experienceL with Backup (or whatever) over NFS (I am assuming that this is not a job for$ Samba) or similiar/better solutions.   Alan   > -----Original Message-----: > From:	Christopher Smith [SMTP:chriss@Mufasa.pubserv.com], > Sent:	Wednesday, December 20, 2000 1:15 PM > To:	Julliard, Alan T.  > Subject:	Re: VMSTARt > / > On Wed, 20 Dec 2000, Julliard, Alan T. wrote:s > K > > translating back on a restore.  Having read suggestions of using VMSTARa > toF > > accomplish the same task, I have added VMSTAR_AXP.EXE as a foreign	 > commandRL > > (VMSTAR :== $disk:[directory]VMSTAR-AXP.EXE).  When I attempt to run it, > IrI > > receive the following error (doen't matter which Alpha - same error).d >  > [snip] >  > > $ vmstar cvf test.tar *.*o? > > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtualk >  > [snip] > E > I don't know a lot about the vms version of tar, but I'll make some $ > guesses about what might be wrong: > G > You may be getting the access violation in response to your trying totD > run the tar image.  Is the image owned by some other user, and not > executable/readable by you?r > K > Otherwise you might be trying to backup a file for which you have no read J > access -- or -- you might need to give the process that runs tar, or theD > tar image itself privs for some reason.  Have you read through the( > documentation for something like that? > 
 > Regards, >  > Chrism > L > ========================================================================== > =====e > "My two cents"1 > (http://rootworks.com/twocentsworth.cgi?128562) 4 > Christopher Smith(chriss@pubserv.com)			Prgramer^W > Programmer! > Prime Synergy of Champaign, IL.u' > -------------------------------------oK > "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and J > weighs 30 tons, computers in the future may have only 1,000 vacuum tubes= > and weigh only 1.5 tons." -- Popular Mechanics, March 1949  L > -------------------------------------------------------------------------- > -----  >    ------------------------------  # Date: Thu, 21 Dec 2000 04:53:13 GMT-2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>! Subject: Re: X terminal for MAC ?h5 Message-ID: <Z0g06.213$LU6.77470@typhoon.aracnet.com>   . JF Mezei <jfmezei.spamnot@videotron.ca> wrote:O > Is there an X terminal emulator for macintosh available on the net ? (so that T > I could use the mac as a second screen onto a vaxstation (which has a b/W screen).  D It's anything but free, however, I rather like 'eXodus'.  It has theI advantage of being the only X software for the Mac that I'm aware of thataL admits that VMS exists, and is supposed to be able to do X over DECnet (I've not actually tried doing this).'   			Zanet   ------------------------------  % Date: Wed, 20 Dec 2000 14:21:58 -0500g5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>!) Subject: Re: XP1000 - which Graphics Card-, Message-ID: <91r0u3$90il$1@lead.zk3.dec.com>  A David Mathog wrote in message <91ohf8$bqg@gap.cco.caltech.edu>... ? >In article <91o7u9$7bio$1@lead.zk3.dec.com>, "Fred Kleinsorge"t% <kleinsorge@star.zko.dec.com> writes:i7 >>I doubt that anything I say will make you very happy.s >e >That's a safe bet!e >r >>D >>There isn't some sinister plot to force people to buy expensive 3DF >>controllers.  What you are seeing is the collision between commodityL >>graphics cards, and traditional "workstation" graphics cards.  In terms ofI >>raw performance, there is now little difference between the two.  There  are-4 >>some serious quality and feature problems however. >hL >Going off on a tangent for a second - this "quality" argument keeps raisingK >its head.  Now I'll agree that VMS is a small market without much pull butcJ >Compaq _also_ sells about a bazillion PCs a year.  Ok, the consumer gradeL >ones are really crappy but supposedly the commercial grade ones are better.L >Is there some reason Compaq can't throw its weight around a little bit moreJ >by requiring a certain quality level for the parts it buys?  And couldn'tI >some of that spill over into VMS land, with the standard having been setaL >high enough that the SCSI cards, disks, and Graphics boards which go out onK >the commercial PCs will be stable enough to use on VMS as well?   It seems K >like a win/win proposition for Compaq - they obtain more stable componentseI >for the PCs _and_ lower cost components with acceptable quality for VMS.oL >Heck, it's probably even a win for the vendors because if the standards areE >precisely defined they know exactly what they must produce and who'se/ >responsible if something does or doesn't work.e >     H The problem here is that the PC market is mostly a component integrationH business.  A number of vendors make high-quality options and drivers forK them -- but it really is a matter of what they are targeted at.  3DLabs fornJ instance makes graphics for the "professional" market, and their PC OpenGLK implementations tend to be quite good.  nVidea on the other hand, targets aoL gaming market - and their products do not tend to work good if you are doing! CAD/CAM instead of running Quake.   J A lot of "quality" (as well as performance) in the PC world depends on the/ software the vendor supplies - not just the HW.B  I So when someone puts together a PC configuration, they simply pick from amF palette of available options, cost, functionality, and quality for theL market for their PC.  A PC with an Oxygen VX1 on it will make a fine CAD/CAMF system, an nVidea won't (I just helped a friend though just this exact? situation not long ago).  But it makes a fine system for games.   G But the PC market also does not make use of functionality that might bekD required in a traditional UNIX/VMS CAD/CAM or server.  Sticking withJ graphics, most commodity graphics cards do not offer multiple-simultaniousB pixel formats, and their overlay plane support tends to be limitedF (actually, overlay planes are making a comeback here and there on someH boards).  Moving away from graphics, to say SCSI - VMS and SCSI clustersH push disks in ways that require a strictly correct implementation of theD standard.  A lot of them cheat - but they cheat in ways that are not= material to how PCs use the disks or even how UNIX uses them.n   >>J >>Yes, our strategy is to move to off-the-shelf "industry standard" cards. WeJ >>no longer design our own graphics, and the P300/350 is probably the last OEM, >>card we will buy.  >>K >>There is an internal struggle among the engineers and management who havet toK >>deliver graphics on Alpha (VMS and Tru64).  The struggle is between those H >>who believe that it is only worth doing the fastest graphics (and that takeseF >>time), and those who would trade off performance for time-to-market. > K >Ah very much like the Genome project!  The public guys insisted on a leveliL >of accuracy that was attainable but extremely expensive and slow to obtain.L >Meanwhile Celera came along and quickly cranked out a rough draft which hasG >98% of the utility at a fraction of the cost.  Now the public guys are K >playing catchup and are wondering how they're ever going to get funding togH >move from the 98% good enough that Celera delivered to the 99.999% thatK >they wanted to deliver.  You see, the big questions in genetics can all behH >pretty much answered with the rough draft, so the cost/benefit analysisH >does not favor ever reaching the level of accuracy that the public camp	 >favored.h >eJ >In the case at hand we have the "better nothing than perfect" camp again,J >versus the "better something than nothing."   Right now we've (most of usK >anyway) effectively got nothing, and we want something.  Perfect can wait.   >Perfect may not even be needed. >e    I Well, let's not try to extend personal needs/wants to a generalization ofcL what "most" need/want.  For the most part, the P300/350 satisfies the targetF customer base that are currently using 3D on VMS.  It could be better,L faster, cheaper.  That is always the case.  The wide difference between whatL you can get on a PC in price/performance will shrink when we finally replaceL the P300/350.  2D graphics (which, by-the-way, is what more than 90% of whatB VMS users need/want based on research) will get better performance real-soon-now.  J The compromise we reached internally was to pass up the opportunity to putJ low-end 3D onto the next "2D" card, to allow us to eventually do away withJ the need to have a 2D versus a 3D card, and have a family of cards that doJ both 2D and 3D and span low-end to high-end.  That is, just what you want.6 To do that meant *not* doing 3D on the ELSA follow-on.  
 >>  UnlikeG >>the NT market, we don't just get the software for free from the boardhI >>vendor, nor is there uniform quality in SW or HW on NT - many so-calledaG >>OpenGL implementations are really designed for full-screen simulation0E >>(gaming).  We are looking to leverage work being done for Linux andrG >>xFree86 - but frankly, *high-quality* and *high-performance* Linux 3D H >>drivers are not readily available, and this market is in it's infancy. >oK >This comes back to the argument I was making before.  Why does Compaq have L >to accept the situation that the board vendors get to deliver only a driverK >for one OS but not another?   REQUIRE them to produce the driver in such a L >form that it will "make" to an NT driver, and also "make" under a differentK >OS to VMS or  XFree86 driver.  I know I'm grossly simplifying things here,aH >but what I mean is hardware acceleration of any particular 2D or OpenGLG >function might as well shove the same series of bytes into the card no J >matter what the OS is.  Sort of a universal driver interface.  There's noE >such thing now, and Microsoft would prefer that one never exist, butdI >everybody else would certainly benefit from its existence.  Maybe CompaqoF >has the oomph to make it happen.  Again - this may not be the perfectF >OpenGL driver, but if we can get 90% of it using the standard, that's& >probably good enough for most people. >=    L Actually, some of that is happening.  The problem is that the Linux graphicsJ market is still in it's infancy.  The PC option makers are recognizing theJ need to offer both Windows and Linux software - but to date, there are fewJ vendors out there with *real* Linux OpenGL implementations (especially 3D)H that are anywhere near as good as their NT/Windows implementations.  TheJ system vendors are, or will be, moving to XFree86 to take advantage of theG Linux DDX/Drivers... that is likely to be the case for VMS and Tru64 ---K although I think everyone wants x.org and XFree86 to merge their code bases9G first.  In any case, what we have found, and are finding, is that it isxC taking time for the vendors to catch up to Windows with their Linux  implementations.  I We are looking to leverage the xFree86 code for the next set of boards asbI much as possible (even to the point of porting XAA and FB back to the MITt server from xFree86).    >>L >>Having said all that, we are in the final stages of qual for a replacementL >>for the ELSA card that will phase in as the ELSA inventory is used up.  ItJ >>will also only be 2D, although the card is quite capable of being a fineI >>entry/low-mid 3D card.  Rather than spend the limited 3D budget on this-H >>card, instead we are working on support (in late 2001) for a family of cardsCJ >>that will span low-end to high-end 3D -- and are off-the-shelf commodity >>graphics.A >GK >Now I'm just confused.  The half life of a graphics card seems to be abouttK >9 months, so if these cards exist now this means Compaq will be coming outhJ >with support just as the cards reach their end of life (in the PC market,H >anyway.)   Or has Compaq found a way around that problem, for instance, withJ >drivers which are somehow guaranteed to be compatible with newer variantsK >of the card?  If not this strategy leaves you perpetually behind the curvew+ >(and uncompetitive) in the graphics arena.  >e    L The way to do it is to target initial delivery for the start of, or mid-lifeH of an "architecture".  Even the option makers are having trouble keepingG up - so while a specific card, or chip may have a 9-month lifetime, therJ "architecture" it uses tends to last at least 1-2 years.  The new versionsL are faster, smaller, bug fixed, and with added functionality -- all around aL core that isn't far removed from the previous incarnation.  Look at S3 as anG example.  They took the 864 to the Trio32, the Trio64, the Trio64+, theqG Trio64V+, and the Trio64V2.  All pretty much compatable, but spanning a7J multi-year life.  The same is true for 3DLabs, ATI, and others.  They willD then have periodic "new" architectures to break through bottlenecks.   >>I >>VMS is tied to Tru64 for graphics.  We are not driving it.  We will gete! >>whatever the Tru64 market gets.M >.J >That's really too bad  - graphics there are only (very) marginally better >than under VMS. >TK >It would really be nice to see Compaq work with the graphics card vendors,cH >the Xfree86 folks, and even Sun, Apple and Be to arrive at some sort ofI >"portable graphics card driver".   It benefits nobody but Microsoft that I >the drivers for the cards must now be hand crafted on an OS by OS basis. L >A lot of the graphics card vendors' windows drivers are pretty iffy as theyF >are - but they might as well be iffy on all platforms as on that one! >!    J If you want to really get sick, look at the "UDI" crap being pushed by SCOI to the UNIX world.  The be-all, end-all, Universal Driver Interface.  You L have to be one sick puppy to want to write one of these things, because theyG took nothing for granted in how the system works (heck you can't make a L simple function call, every call contains a callback for completion).  Yuck.  7 What I think you will see emerge over the next year is:g  L 1) WIndows will continue as always.  Option Vendors will supply drivers/GDI.K 2) Option vendors will start to supply Linux implementations using XFree86.iG 3) Non-windows system vendors will start moving to XFree86 (or a merged) x.org and XFree86 "X11R7")E 4) Option vendors will supply the Linux code, and System vendors willr- compile/port it to their non-Windows systems.=  K I'll go further to say that by the end of 2001, I think Gnome and GTK+ will C start to replace Motif and CDE in the mainstream UNIX market.  WithVI Motif/CDE still available for legacy systems and contractual obligations.-  F I think sometime in 2002, you'll see VMS and Tru64 moving that way too (IMHO).   J So.  Bottom line:  We all would love to get to the point where support forL cards on Tru64 and VMS is as cheap and universal as Windows.  Its not likelyL to ever "quite" get there.  But over time, Linux may simplify everyones lifeK by providing a "standard" that the systems which use X11 can take advantage L of.  Nobody here is trying to gouge you on graphics cards - the "high" priceJ for the P300/350 is a remnant of the "old days" where workstation graphicsJ were developed in-house and *were* better than PC graphics.  Things *will*3 get better.  We're getting there as fast as we can.    ------------------------------  % Date: Wed, 20 Dec 2000 12:28:17 -0800.! From: Shane.F.Smith@Healthnet.comi) Subject: Re: XP1000 - which Graphics Card-D Message-ID: <OF252C59DB.1419716F-ON882569BB.006FA8D7@foundation.com>  K nVidia's GeForce gaming series are also sold (with a slight board tweak) asgG their professional Quadro series. There's some hacks on the net to turn I GeForce cards into the more expensive Quadro's with a little soldering. IWE believe the drivers are interchangeable. nVidia have a unified driverdI design, so the same ones work on all the cards they've produced since theeK TNT mk1. I know they get some flack for being a little fuzzy at the highesthA resolutions (although my cards seem fine), but I still think thatxI supporting these cards would be a good idea. One set of drivers coded frokH VMS buys you an awful lot of options from several suppliers ranging from> sub-$100 to $500+, and a head start on forwards compatability.   Shane           G Fred Kleinsorge <kleinsorge@star.zko.dec.com> on 12/20/2000 11:21:58 AMe   To:   Info-VAX@Mvb.Saic.Come cc:t  * Subject:  Re: XP1000 - which Graphics Card      A David Mathog wrote in message <91ohf8$bqg@gap.cco.caltech.edu>...m? >In article <91o7u9$7bio$1@lead.zk3.dec.com>, "Fred Kleinsorge"n% <kleinsorge@star.zko.dec.com> writes:-7 >>I doubt that anything I say will make you very happy.. >] >That's a safe bet!D >m >>D >>There isn't some sinister plot to force people to buy expensive 3DF >>controllers.  What you are seeing is the collision between commodityI >>graphics cards, and traditional "workstation" graphics cards.  In termso ofI >>raw performance, there is now little difference between the two.  There  areA4 >>some serious quality and feature problems however. >oD >Going off on a tangent for a second - this "quality" argument keeps raisingmK >its head.  Now I'll agree that VMS is a small market without much pull butCJ >Compaq _also_ sells about a bazillion PCs a year.  Ok, the consumer gradeD >ones are really crappy but supposedly the commercial grade ones are better. G >Is there some reason Compaq can't throw its weight around a little bits moreJ >by requiring a certain quality level for the parts it buys?  And couldn'tI >some of that spill over into VMS land, with the standard having been settI >high enough that the SCSI cards, disks, and Graphics boards which go outi onK >the commercial PCs will be stable enough to use on VMS as well?   It seemssK >like a win/win proposition for Compaq - they obtain more stable componentsaI >for the PCs _and_ lower cost components with acceptable quality for VMS.=H >Heck, it's probably even a win for the vendors because if the standards areoE >precisely defined they know exactly what they must produce and who'se/ >responsible if something does or doesn't work.g >f    H The problem here is that the PC market is mostly a component integrationH business.  A number of vendors make high-quality options and drivers forK them -- but it really is a matter of what they are targeted at.  3DLabs foryJ instance makes graphics for the "professional" market, and their PC OpenGLK implementations tend to be quite good.  nVidea on the other hand, targets a-F gaming market - and their products do not tend to work good if you are doingy! CAD/CAM instead of running Quake.j  J A lot of "quality" (as well as performance) in the PC world depends on the/ software the vendor supplies - not just the HW.a  I So when someone puts together a PC configuration, they simply pick from atF palette of available options, cost, functionality, and quality for theD market for their PC.  A PC with an Oxygen VX1 on it will make a fine CAD/CAMXF system, an nVidea won't (I just helped a friend though just this exact? situation not long ago).  But it makes a fine system for games.o  G But the PC market also does not make use of functionality that might beZD required in a traditional UNIX/VMS CAD/CAM or server.  Sticking withJ graphics, most commodity graphics cards do not offer multiple-simultaniousB pixel formats, and their overlay plane support tends to be limitedF (actually, overlay planes are making a comeback here and there on someH boards).  Moving away from graphics, to say SCSI - VMS and SCSI clustersH push disks in ways that require a strictly correct implementation of theD standard.  A lot of them cheat - but they cheat in ways that are not= material to how PCs use the disks or even how UNIX uses them.>   >>J >>Yes, our strategy is to move to off-the-shelf "industry standard" cards. WeJ >>no longer design our own graphics, and the P300/350 is probably the last OEMt >>card we will buy.f >>K >>There is an internal struggle among the engineers and management who havem toK >>deliver graphics on Alpha (VMS and Tru64).  The struggle is between thoseeH >>who believe that it is only worth doing the fastest graphics (and that takeslF >>time), and those who would trade off performance for time-to-market. >rK >Ah very much like the Genome project!  The public guys insisted on a levelbD >of accuracy that was attainable but extremely expensive and slow to obtain. H >Meanwhile Celera came along and quickly cranked out a rough draft which hastG >98% of the utility at a fraction of the cost.  Now the public guys areeK >playing catchup and are wondering how they're ever going to get funding to H >move from the 98% good enough that Celera delivered to the 99.999% thatK >they wanted to deliver.  You see, the big questions in genetics can all beoH >pretty much answered with the rough draft, so the cost/benefit analysisH >does not favor ever reaching the level of accuracy that the public camp	 >favored.e >pJ >In the case at hand we have the "better nothing than perfect" camp again,J >versus the "better something than nothing."   Right now we've (most of usK >anyway) effectively got nothing, and we want something.  Perfect can wait.o  >Perfect may not even be needed. >e    I Well, let's not try to extend personal needs/wants to a generalization of E what "most" need/want.  For the most part, the P300/350 satisfies theP targetF customer base that are currently using 3D on VMS.  It could be better,G faster, cheaper.  That is always the case.  The wide difference betweenu whatD you can get on a PC in price/performance will shrink when we finally replaceoG the P300/350.  2D graphics (which, by-the-way, is what more than 90% oft whatB VMS users need/want based on research) will get better performance real-soon-now.  J The compromise we reached internally was to pass up the opportunity to putJ low-end 3D onto the next "2D" card, to allow us to eventually do away withJ the need to have a 2D versus a 3D card, and have a family of cards that doJ both 2D and 3D and span low-end to high-end.  That is, just what you want.6 To do that meant *not* doing 3D on the ELSA follow-on.  
 >>  UnlikeG >>the NT market, we don't just get the software for free from the boardoI >>vendor, nor is there uniform quality in SW or HW on NT - many so-calledtG >>OpenGL implementations are really designed for full-screen simulationyE >>(gaming).  We are looking to leverage work being done for Linux andaG >>xFree86 - but frankly, *high-quality* and *high-performance* Linux 3DsH >>drivers are not readily available, and this market is in it's infancy. >hK >This comes back to the argument I was making before.  Why does Compaq haveiE >to accept the situation that the board vendors get to deliver only at driverK >for one OS but not another?   REQUIRE them to produce the driver in such aaB >form that it will "make" to an NT driver, and also "make" under a	 differentsK >OS to VMS or  XFree86 driver.  I know I'm grossly simplifying things here,iH >but what I mean is hardware acceleration of any particular 2D or OpenGLG >function might as well shove the same series of bytes into the card noaJ >matter what the OS is.  Sort of a universal driver interface.  There's noE >such thing now, and Microsoft would prefer that one never exist, butoI >everybody else would certainly benefit from its existence.  Maybe CompaqoF >has the oomph to make it happen.  Again - this may not be the perfectF >OpenGL driver, but if we can get 90% of it using the standard, that's& >probably good enough for most people. >a    C Actually, some of that is happening.  The problem is that the Linux% graphicsJ market is still in it's infancy.  The PC option makers are recognizing theJ need to offer both Windows and Linux software - but to date, there are fewJ vendors out there with *real* Linux OpenGL implementations (especially 3D)H that are anywhere near as good as their NT/Windows implementations.  TheJ system vendors are, or will be, moving to XFree86 to take advantage of theG Linux DDX/Drivers... that is likely to be the case for VMS and Tru64 --fK although I think everyone wants x.org and XFree86 to merge their code basesyG first.  In any case, what we have found, and are finding, is that it issC taking time for the vendors to catch up to Windows with their Linuxp implementations.  I We are looking to leverage the xFree86 code for the next set of boards asoI much as possible (even to the point of porting XAA and FB back to the MITe server from xFree86).a   >>@ >>Having said all that, we are in the final stages of qual for a replacement H >>for the ELSA card that will phase in as the ELSA inventory is used up. ItJ >>will also only be 2D, although the card is quite capable of being a fineI >>entry/low-mid 3D card.  Rather than spend the limited 3D budget on this-H >>card, instead we are working on support (in late 2001) for a family of cardstJ >>that will span low-end to high-end 3D -- and are off-the-shelf commodity >>graphics.  >-K >Now I'm just confused.  The half life of a graphics card seems to be about3K >9 months, so if these cards exist now this means Compaq will be coming outeJ >with support just as the cards reach their end of life (in the PC market,H >anyway.)   Or has Compaq found a way around that problem, for instance, withJ >drivers which are somehow guaranteed to be compatible with newer variantsK >of the card?  If not this strategy leaves you perpetually behind the curvee+ >(and uncompetitive) in the graphics arena.l >v    C The way to do it is to target initial delivery for the start of, or  mid-lifeH of an "architecture".  Even the option makers are having trouble keepingG up - so while a specific card, or chip may have a 9-month lifetime, theeJ "architecture" it uses tends to last at least 1-2 years.  The new versionsJ are faster, smaller, bug fixed, and with added functionality -- all around aiI core that isn't far removed from the previous incarnation.  Look at S3 asd anG example.  They took the 864 to the Trio32, the Trio64, the Trio64+, thevG Trio64V+, and the Trio64V2.  All pretty much compatable, but spanning arJ multi-year life.  The same is true for 3DLabs, ATI, and others.  They willD then have periodic "new" architectures to break through bottlenecks.   >>I >>VMS is tied to Tru64 for graphics.  We are not driving it.  We will getn! >>whatever the Tru64 market gets.e > J >That's really too bad  - graphics there are only (very) marginally better >than under VMS. > K >It would really be nice to see Compaq work with the graphics card vendors,aH >the Xfree86 folks, and even Sun, Apple and Be to arrive at some sort ofI >"portable graphics card driver".   It benefits nobody but Microsoft that I >the drivers for the cards must now be hand crafted on an OS by OS basis.tG >A lot of the graphics card vendors' windows drivers are pretty iffy ass theyF >are - but they might as well be iffy on all platforms as on that one! >     J If you want to really get sick, look at the "UDI" crap being pushed by SCOI to the UNIX world.  The be-all, end-all, Universal Driver Interface.  YourG have to be one sick puppy to want to write one of these things, becauses theyG took nothing for granted in how the system works (heck you can't make auE simple function call, every call contains a callback for completion).  Yuck.t  7 What I think you will see emerge over the next year is:p  ? 1) WIndows will continue as always.  Option Vendors will supply> drivers/GDI.K 2) Option vendors will start to supply Linux implementations using XFree86.cG 3) Non-windows system vendors will start moving to XFree86 (or a merged  x.org and XFree86 "X11R7")E 4) Option vendors will supply the Linux code, and System vendors willa- compile/port it to their non-Windows systems.   K I'll go further to say that by the end of 2001, I think Gnome and GTK+ willtC start to replace Motif and CDE in the mainstream UNIX market.  With I Motif/CDE still available for legacy systems and contractual obligations.   F I think sometime in 2002, you'll see VMS and Tru64 moving that way too (IMHO).e  J So.  Bottom line:  We all would love to get to the point where support forE cards on Tru64 and VMS is as cheap and universal as Windows.  Its notf likelyG to ever "quite" get there.  But over time, Linux may simplify everyonese lifeK by providing a "standard" that the systems which use X11 can take advantage F of.  Nobody here is trying to gouge you on graphics cards - the "high" priceiJ for the P300/350 is a remnant of the "old days" where workstation graphicsJ were developed in-house and *were* better than PC graphics.  Things *will*3 get better.  We're getting there as fast as we can.r   ------------------------------   Date: 20 Dec 2000 23:13:06 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)) Subject: Re: XP1000 - which Graphics Carda, Message-ID: <91ree2$ob0@gap.cco.caltech.edu>  d In article <91r0u3$90il$1@lead.zk3.dec.com>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > K >The compromise we reached internally was to pass up the opportunity to putfK >low-end 3D onto the next "2D" card, to allow us to eventually do away withdK >the need to have a 2D versus a 3D card, and have a family of cards that doTK >both 2D and 3D and span low-end to high-end.  That is, just what you want.4   Yes, it is!   7 >To do that meant *not* doing 3D on the ELSA follow-on.)   Ok, win some, lose some. e  F Now for the million dollar question - will this line of cards have PCII variants or will we have to junk the existing machines and moving to some $ future Alpha model that offers AGP?      David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------   Date: 20 Dec 2000 16:25:53 PSTT From: Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515)> Subject: [Q]: Supported 8mm tapes on HSC-95 k.scsi requestors?3 Message-ID: <eMbTrh2cFJGk@mccdev.slac.stanford.edu>e  H         We have (one remaining) HSC-95 with a pair of k.scsi requestors,H     among others.  One of the two  is  set  to host disks, and the otherH     tapes.   On the k.scsi/disk, I've got 6 RZ29B and a single RZ28 in aH     BA350 (narrow) shelf.  On the k.scsi/tape, I previously had  a  TZ870     and a TZ88, again in a BA350 (narrow) shelf.  H         I've removed the TZ87 (there were maintenance issues, and I haveH     three other TZ88's besides) and am attempting to replace it with oneH     or another _supported_ 8mm  tape  drive.   This  is where I'm having     trouble.  H         I'm running V8.6 of  the  HSC  software  in  the HSC-95.  I haveH     release  notes for the previous version, V8.5, which state that  theH     TKZ15 8mm tape drive is supported.  I acquired a TKZ15-VA (I _think_H     it was a -VA) and tried it, but the HSC never "saw" it.  My supplierH     talked to his supplier and sent be a newer, TKZ9E as a  replacement.H     He  said the V8.6 release notes list the TKZ9E as a supported drive.H     Well, I received that drive today and  have had no more luck with it'     than I did with the TKZ15.  Sigh...u  H         Now I've gone through all sorts  of hoops with KSUTIL adding andH     deleting  "ports"  for both drives, being sure to use the  "OperatorH     Console" to toggle the state from on to off and back, swapped  slotsH     between  the  TZ88  and the TKZ9E, and even put the TZ87 back in theH     shelf to be sure I understood the SCSI ID assignments, etc.  NothingH     I do makes the TKZ9E visible to the HSC.  In fact, after configuringH     it within KSUTIL, if I  attempt  to run the "exerciser" against thatH     drive,  it tells me the drive is "not ready" when I select its  MSCPH     unit number.  I should note that the TKZ9E runs through  its  power-H     on  self-tests just fine, and will load and unload a tape correctly.H     I've done everything I can to  be  sure  it's securely seated in its	     slot.o  H         Can anyone out there tell me the  most recent 8mm tape drive (inH     an SSB) that is supported by HSC V8.6 software in a k.scsi requestorH     on an HSC-95?  Are there any gotcha's I might have missed?  Is thereH     a  potential  problem  if the TKZ9E had been configured for  a  wideH     shelf, and if so, are there any jumpers or anything else that  might     fix the problem?           Thanks, Kenc -- wM  Kenneth H. Fairfield            |  Internet: Fairfield@SLC.Slac.Stanford.Eduf:  SLAC, 2575 Sand Hill Rd, MS 46  |  Voice:    650-926-2924:  Menlo Park, CA  94025           |  FAX:      650-926-3515N  -----------------------------------------------------------------------------B  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...   ------------------------------   End of INFO-VAX 2000.710 ************************