1 INFO-VAX	Tue, 03 Jun 2003	Volume 2003 : Issue 306       Contents:: "Strange" values in Monitor in a GS80 Galaxy configuration> Re: "Strange" values in Monitor in a GS80 Galaxy configuration> Re: "Strange" values in Monitor in a GS80 Galaxy configuration> Re: "Strange" values in Monitor in a GS80 Galaxy configuration Re: Alpha / OpenVMS and SANS! Re: Alpha hardware shop in Europe ! Re: Alpha hardware shop in Europe ! Re: Alpha hardware shop in Europe ! Re: Alpha hardware shop in Europe  CA CCC/Harvest and VMS Re: curl library on VMS 7 Re: Download service for VMS and Tru64 layered products  Re: Help with VMS & Re: How to make a shadowed system disk Re: Install Directory  Re: Install Directory / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way / Re: Intel 64 bit Pentium seems to be on its way  Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500# Re: JAVA appears to hang on OpenVMS  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death E Re: Printing to a very old LXY12 line printer via a DecServer  (long) ( Re: Samba + Multinet: The Saga continues@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)@ Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long) Some fiction for you to enjoy  Syncing Directories via FTP  Re: Syncing Directories via FTP  xxJ Re: [DCL] Is the max length of DCL lexical functions argument documented ?  F ----------------------------------------------------------------------  % Date: Tue, 03 Jun 2003 12:55:45 +0100  From: Roy Omond <Roy@Omond.net> C Subject: "Strange" values in Monitor in a GS80 Galaxy configuration 4 Message-ID: <bbi2cs$m7h$1$8300dec7@news.demon.co.uk>  = Gentle colleagues,  one of my clients has posed the following @ Monitor query to me.  This is on VMS 7.3-1, well up-to-date with> patches, on a GS80 in a Galaxy configuration.  Node XE has one= CPU migrated to it (I'm pretty sure it starts off as one CPU, A i.e. it gets a second CPU, though I can't be certain exactly when B the CPU was migrated, but I'm assuming it was during the MonitoredB period), and this seems to, ahem, "confuse" Monitor as seen below.  E Is this expected behaviour (I understand it might be rather difficult 9 to get this right in all circumstances) ?  Any comments ?    Thanks in advance,  	 Roy Omond  Blue Bubble Ltd.   --- cut here ---  F We run a daily monitor job between 14:00 and 15:00 using this command:  . $ MONITOR PROCESS/TOPCPU,SYSTEM/ALL/NODISPLAY-H /INPUT=filename/SUMMARY=filename/BEGINNING=14:00/ENDING=15:00/NODE=noden ame   B We are running a GS80 containing two nodes - XE and XN. If we move; one CPU to XE the above monitor job running on XE gives the  following results:  $              OpenVMS Monitor Utility              SYSTEM STATISTICS:              on node XE         From: 28-MAY-2003 14:00:09:               SUMMARY           To:   28-MAY-2003 15:00:09  9                         CUR        AVE     MIN        MAX 9 Interrupt State       8.90     108.68     3.69    1210.23 9 MP Synchronization    1.12     102.52     0.00    1220.00 9 Kernel Mode          11.76    1041.19     5.23   12368.69 9 Executive Mode        2.15     189.44     0.73    2251.14 9 Supervisor Mode       0.41       9.30     0.19     108.20 9 User Mode            16.96    1579.34     8.47   18745.42 9 Compatibility Mode    0.00       0.00     0.00       0.00 9 Idle Time           158.66   12923.51    77.38  153655.51   G We are especially interested in the Idle Time figures but the ones I've 8 highlighted above are a little strange to say the least.  C Is this a bug? If so, is there a fix? If not, can you explain these  figures to me?   ------------------------------  # Date: Tue, 03 Jun 2003 12:47:24 GMT - From: "labadie" <tonari_no_tottoro@127.0.0.1> G Subject: Re: "Strange" values in Monitor in a GS80 Galaxy configuration 0 Message-ID: <wN0Da.1796$3h.326@news.cpqcorp.net>  , "Roy Omond" <Roy@Omond.net> wrote in message. news:bbi2cs$m7h$1$8300dec7@news.demon.co.uk...? > Gentle colleagues,  one of my clients has posed the following B > Monitor query to me.  This is on VMS 7.3-1, well up-to-date with@ > patches, on a GS80 in a Galaxy configuration.  Node XE has one? > CPU migrated to it (I'm pretty sure it starts off as one CPU, C > i.e. it gets a second CPU, though I can't be certain exactly when D > the CPU was migrated, but I'm assuming it was during the MonitoredD > period), and this seems to, ahem, "confuse" Monitor as seen below. > G > Is this expected behaviour (I understand it might be rather difficult ; > to get this right in all circumstances) ?  Any comments ?     Hello  K I think that Monitor has not been written with the idea of Cpu disappearing  and appearing suddenly.   H I bet that, once the Cpu has been migrated, if monitor is restarted, the display is fine :-)    Regards    Grard   ------------------------------   Date: 3 Jun 2003 07:42 CDT' From: carl@gerg.tamu.edu (Carl Perkins) G Subject: Re: "Strange" values in Monitor in a GS80 Galaxy configuration , Message-ID: <3JUN200307423396@gerg.tamu.edu>  # Roy Omond <Roy@Omond.net> writes... > }Gentle colleagues,  one of my clients has posed the followingA }Monitor query to me.  This is on VMS 7.3-1, well up-to-date with ? }patches, on a GS80 in a Galaxy configuration.  Node XE has one > }CPU migrated to it (I'm pretty sure it starts off as one CPU,B }i.e. it gets a second CPU, though I can't be certain exactly whenC }the CPU was migrated, but I'm assuming it was during the Monitored C }period), and this seems to, ahem, "confuse" Monitor as seen below.  } F }Is this expected behaviour (I understand it might be rather difficult: }to get this right in all circumstances) ?  Any comments ? }  }Thanks in advance,  } 
 }Roy Omond }Blue Bubble Ltd.  }  }--- cut here ---  } G }We run a daily monitor job between 14:00 and 15:00 using this command:  } / }$ MONITOR PROCESS/TOPCPU,SYSTEM/ALL/NODISPLAY- I }/INPUT=filename/SUMMARY=filename/BEGINNING=14:00/ENDING=15:00/NODE=noden  }ame } C }We are running a GS80 containing two nodes - XE and XN. If we move < }one CPU to XE the above monitor job running on XE gives the }following results:  } % }             OpenVMS Monitor Utility  }             SYSTEM STATISTICS ; }             on node XE         From: 28-MAY-2003 14:00:09 ; }              SUMMARY           To:   28-MAY-2003 15:00:09  } : }                        CUR        AVE     MIN        MAX: }Interrupt State       8.90     108.68     3.69    1210.23: }MP Synchronization    1.12     102.52     0.00    1220.00: }Kernel Mode          11.76    1041.19     5.23   12368.69: }Executive Mode        2.15     189.44     0.73    2251.14: }Supervisor Mode       0.41       9.30     0.19     108.20: }User Mode            16.96    1579.34     8.47   18745.42: }Compatibility Mode    0.00       0.00     0.00       0.00: }Idle Time           158.66   12923.51    77.38  153655.51 } H }We are especially interested in the Idle Time figures but the ones I've9 }highlighted above are a little strange to say the least.  } D }Is this a bug? If so, is there a fix? If not, can you explain these }figures to me?   F I would say that when you add a CPU *while* monitor is running that itE may not have some arrays or such set up properly so you pick up junk.   F It is also possible (probably fairly likely even) that it was a singleA bad sample that happened when the processor was added. If so, you C should see that single bad sample in the CUR column at some point - C I would guess that the bad sample will pretty much match the values B in the MAX column as they are all over 100, which shouldn't happen& when the instance is single processor.   My guess of what happens:   B MONITOR is cruising along checking the time in each processor modeG for each CPU and adding them up. This is easy when there is only 1 CPU. F Then a second CPU magically appears. The CPU tick counts stored in theH kernel are absolute counts - if you add them all up and you get the timeH since boot (in "ticks" - with an Alpha each tick in the count appears toD represent 1/1024 of a second, on a VAX they used to be .01 seconds).F So suddently there is this second CPU with a count. To get the time inH each mode in the interval, you take the current value (a 64 bit integer)H and subtract off the value from the previous sample and then multiply itK by the "tick" to "seconds" conversion factor. Except there was no "previous K sample" - it is 0 for each if the memory location it checks for this exists I and was initialized to 0, otherwise it is whatever random junk was in the K location it checks. So you end up with either the total number of CPU ticks L the processor has had in each mode, or that number minus a randomish number,9 instead of the number of ticks since the previous check.    G The system wouldn't happen to have been up for about 2.19 days when the F second CPU was added, would it? If so, then the new processor probablyE had it's initial CPU tick counters set to match the first processor's H (or MONITOR sees it as such) when it was added, or something along thoseD lines. (If you add up the MAX column's times they add up to a littleD over 2 days, 4 hours, 39 minutes). I ask because the numbers may notF just be random junk, they might be junk with some (undesired) meaning.   --- Carl   ------------------------------  % Date: Tue, 03 Jun 2003 08:52:34 -0500 ( From: brandon@dalsemi.com (John Brandon)G Subject: Re: "Strange" values in Monitor in a GS80 Galaxy configuration 1 Message-ID: <03060308523452@dscis6-0.dalsemi.com>   % > Roy Omond <Roy@Omond.net> writes... @ > }Gentle colleagues,  one of my clients has posed the followingC > }Monitor query to me.  This is on VMS 7.3-1, well up-to-date with A > }patches, on a GS80 in a Galaxy configuration.  Node XE has one @ > }CPU migrated to it (I'm pretty sure it starts off as one CPU,D > }i.e. it gets a second CPU, though I can't be certain exactly whenE > }the CPU was migrated, but I'm assuming it was during the Monitored E > }period), and this seems to, ahem, "confuse" Monitor as seen below.   B We have similar problems with a GS160 Galaxy with three instances.  M We typically use MONITOR CLUSTER and find that when a CPU is migrated between " nodes, the MONITOR values go nuts.  O You might want to use Availability Manager to monitor your Galaxy - AM seems to  be Galaxy compliant.   John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------   Date: 3 Jun 2003 04:29:09 -0500 + From: young_r@encompasserve.org (Rob Young) % Subject: Re: Alpha / OpenVMS and SANS 3 Message-ID: <VLs9QfwH1$s+@eisner.encompasserve.org>   l In article <TsPCa.82047$_c6.701874@news.chello.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:I > In article <3EDBB70A.8030201@home.nl>, Dirk Munk <munk@home.nl> writes:  >>Vic Mendham wrote:B >>> I need some information on VAX/ALPHA, OpenVMS and SANS arrays. >>> 2 >>> Has anyone ever worked on VAX/ALPHA and SANS?  >>R >>Yep, ES40's on HSG80. Great combination. However HSG80 is end-of-production. Go # >>for the HP EVA storage cabinets !  >  > Nope.  > Yes, HP wants us to.L > But as a HSG (EMA, ESA) has a serial console and a HSV (EVA) has a PC as aQ > console I doubt that I will soon switch to EVA/HSV (and loose good automation). L > And as I think, I'm not alone with this opinion, I expect that HPQ will be. > forced to extend the lifetime of the HSGs... >   = 	I bet the odds are very slim there.  Probably not unlike the : 	HSJ kits it becomes a matter of parts.  i.e. getting them 	to make new HSG80s.  H 	There are automation tools/tricks for HSV here or in the pipeline, see:  h http://groups.google.com/groups?selm=nc58avgd351e7p9dst0cb02dmonjtbmmiu%404ax.com&oe=UTF-8&output=gplain   	In particular:   c http://groups.google.com/groups?selm=8sFiVkxZxnV8%40eisner.encompasserve.org&oe=UTF-8&output=gplain    > H > Well, EVM is not running on VMS for me yet (I've gotten no pre-releaseH > versions... haven't even been home in order to play with it if I did).B > On Windows systems, the EVM job can run a host-based scripts (to@ > quiesce the app, whatever), and then has automated methods for7 > creating/splitting mirrors or for creating snapshots.  >   F 	i.e. "pre-release" EVM (and that snippet was from July 2002).  Maybe G 	EVM is out for EVA and VMS now?  Anyway, not sure what you are getting 4 	at regarding automation.  Can you be more specific?  K > Another reason is the total virtualization of storage which might be good K > if everything works (eg. much less space waste) but is a nightmare if you I > can't trust the (doubled) controller (and one learned over the years to P > _not_ trust a single controller [pair] and use more safety belts  [like HBVS]) >   = 	And I'm not sure what you are getting at here either.  There : 	are large customers using EVA in production environments.  @ 	HSG80 is trailing edge.  The horsepower and throughput is years 	behind EVA.   > K > Always use the latest and greatest versions of everything (after a couple N > of weeks "leading-edge means bleeding-edge" time ;-) as SANs are not yet old > (and therefore stable) stuff.  >   " 	Always use...?  Absolutely not.    G 	But a datapoint would counter-act that view.  As an exercise, can you  F 	name the month and year that EVA shipped to customers?  (Hint:  That : 	would knock down the whine "leading-edge bleeding edge").   				Rob    ------------------------------  % Date: Tue, 03 Jun 2003 09:32:20 +0100  From: Roy Omond <Roy@Omond.net> * Subject: Re: Alpha hardware shop in Europe4 Message-ID: <bbhmff$1tr$1$830fa7b3@news.demon.co.uk>  
 Woland wrote:  > Hi,  > P > does anybody know about some shop like Islandco, but located somewhere in EU? O > I'd like to buy some older workstation, but I'm a bit afraid of the delivery   > price from US to EU.O > There used to be a similar shop in Austria several years ago, but I lost the    > link and I can't find it now.. > 
 > Any hints ?   2 You might try http://www.mitlimited.com in the UK.  ; Sheila Moore there is *very* knowledgeable about DEC stuff.   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  * Date: Tue, 3 Jun 2003 11:45:32 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb) * Subject: Re: Alpha hardware shop in Europe* Message-ID: <bbi1os$gr$1@aquila.mdx.ac.uk>  V In article <bbhmff$1tr$1$830fa7b3@news.demon.co.uk>, Roy Omond <Roy@Omond.net> writes: >Woland wrote: >> Hi, >>  Q >> does anybody know about some shop like Islandco, but located somewhere in EU?  P >> I'd like to buy some older workstation, but I'm a bit afraid of the delivery  >> price from US to EU. P >> There used to be a similar shop in Austria several years ago, but I lost the ! >> link and I can't find it now..  >>   >> Any hints ? > 3 >You might try http://www.mitlimited.com in the UK.  > < >Sheila Moore there is *very* knowledgeable about DEC stuff. >   H Is there some reason why noone other than Island seems able to advertiseK representitive refurbished/second-hand systems on their sites with prices ?     
 David Webb VMS and Unix team leader CCSS Middlesex University      
 >Roy Omond >Blue Bubble Ltd.  >    ------------------------------   Date: 3 Jun 2003 07:30:17 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) * Subject: Re: Alpha hardware shop in Europe3 Message-ID: <DjZNCF+8kepd@eisner.encompasserve.org>   X In article <bbi1os$gr$1@aquila.mdx.ac.uk>, david20@alpha2.mdx.ac.uk (David Webb) writes:  J > Is there some reason why noone other than Island seems able to advertiseM > representitive refurbished/second-hand systems on their sites with prices ?   G Perhaps it is a European thing.  WWW.ELI.COM in Massachusetts certainly  advertises prices on the web.    ------------------------------  % Date: Tue, 03 Jun 2003 17:53:04 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)* Subject: Re: Alpha hardware shop in Europe; Message-ID: <3edcc460.524144494f47414741@radiogaga.harz.de>   , David Webb (david20@alpha2.mdx.ac.uk) wrote:J > Is there some reason why noone other than Island seems able to advertiseM > representitive refurbished/second-hand systems on their sites with prices ?   G My company does: http://www.pdv-systeme.de/sonderlisten/sonderliste.htm   + The whole site is in german, though. Sorry.    cu,    Martin --  A    OpenVMS @ 25      | Martin Vorlaender  |  VMS & WNT programmer .                      | work: mv@pdv-systeme.deE    Still exceeding   |       http://www.pdv-systeme.de/users/martinv/ 5    expectations      | home: martin@radiogaga.harz.de    ------------------------------   Date: 3 Jun 2003 04:48:30 -0700 1 From: davidm@hollard.co.za (davidm@hollard.co.za)  Subject: CA CCC/Harvest and VMS = Message-ID: <798b4020.0306030348.5c7bdc5c@posting.google.com>   E Has anyone come across any degree of integration of OpenVMS with CA's  CCC/Harvest product?  $ CA themselves are unable to help me.  , Any leads on this would be much appreciated.   Kind Regards  
 Dave McDonald  Johannesburg   ------------------------------  % Date: Tue, 03 Jun 2003 08:04:33 +0200 7 From: Robert Trawinski <robert.trawinski@softax.com.pl>   Subject: Re: curl library on VMS. Message-ID: <bbhdph$oe$1@bozon2.softax.com.pl>   Robert Trawinski wrote: 	 > Hi all,  > 3 > Is  there curl library implementation on OpenVMS?  > 	 > Robert.  >    Many thanks for everybody    Robert   ------------------------------  * Date: Tue, 3 Jun 2003 11:20:35 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb) @ Subject: Re: Download service for VMS and Tru64 layered products* Message-ID: <bbi0a3$d0$1@aquila.mdx.ac.uk>  k In article <f883d5a4.0306021309.45cf31b3@posting.google.com>, seanobanion@attbi.com (Sean O'Banion) writes: D >Unfortunately, it only downloads to Windoze: NTLM authentication is
 >required.E >The site coyly requires "Microsoft Internet Explorer 5.1 or greater, ? >or a similar web browser that allows challenge/response (NTLM)  >authentication."  > B >It fails to point out that NTLM is only available on Windoze: youF >cannot use Mozilla on VMS.  Mozilla beta 1.4 on Windoze lists supportG >for NTLM, but implements it by calling the DLL that IE uses.  NTLM has @ >been reverse engineered for Samba, but is not AFAIK implemented >anywhere else.  > D >Very cynical people ( you all know who you are :-) ) could concludeE >that this was done on purpose.  I suspect that nobody knows for sure G >who did this and why, but it seems clear that the target audience (VMS C >VAX, VMS Alpha, and Tru64) was not clearly in their minds when the  >decision was made.  >   N Oh God they've screwed it up yet again. I've just checked and you are correct  it does require IE and NTLM.  ( I've written a note to the webmaster on    http://www1.aclabs.com     (email:  odlcdrom@hp.com)    to complain.    
 David Webb VMS and Unix team leader CCSS Middlesex University     >  >Sean / ><insert appropriate disclaimers where desired>  > e >"Tom Linden" <tom@kednos.com> wrote in message news:<CIEJLCMNHNNDLLOOGNJIEEBEHFAA.tom@kednos.com>...  >> It's about time.  >>   >> >-----Original Message-----6 >> >From: David Webb [mailto:david20@alpha1.mdx.ac.uk]( >> >Sent: Monday, June 02, 2003 10:08 AM >> >To: Info-VAX@Mvb.Saic.Com @ >> >Subject: Download service for VMS and Tru64 layered products >> > >> > >> >I >> >I've just received my latest set of consolidated software release CDs K >> >June 2003 - suprised me a bit I'm not used to them arriving so quickly.  >> > >> >  A >> >There is an interesting announcement leaflet in the packet :-  >> >8 >> >"Announcing a Web Download for the Software library" >> > >> >D >> >Apparently each quarter they will be sending their Consolidated  >> >distributionD >> >service customers a username and password to access a site from  >> >which they can) >> >download any of the layered products.  >> >F >> >According to the leaflet the username and password will remain in  >> >effect long A >> >enough to provide early access to the next quarter's release.  >> >M >> >Now all they need is to give this access to all the registered hobbyist's B >> >rather than to those who already have the software since they  >> >purchased the  >> >CDs. >> > >> > >> >David Webb >> >VMS and Unix team leader >> >CCSS >> >Middlesex University >> > >> >--- * >> >Incoming mail is certified Virus Free.> >> >Checked by AVG anti-virus system (http://www.grisoft.com).D >> >Version: 6.0.484 / Virus Database: 282 - Release Date: 5/27/2003 >> > >> ---) >> Outgoing mail is certified Virus Free. = >> Checked by AVG anti-virus system (http://www.grisoft.com). C >> Version: 6.0.484 / Virus Database: 282 - Release Date: 5/27/2003    ------------------------------  $ Date: Tue, 3 Jun 2003 18:52:39 +0200+ From: "Hans Vlems" <hvlems.nieuw@zonnet.nl>  Subject: Re: Help with VMS5 Message-ID: <bbijon$a090s$1@ID-143435.news.dfncis.de>   6 "Carl Perkins" <carl@gerg.tamu.edu> schreef in bericht& news:3JUN200300095341@gerg.tamu.edu...D > In article <bbaaui$7e9c5$1@ID-143435.news.dfncis.de>, "Hans Vlems"" <hvlems.nieuw@zonnet.nl> writes... > } 9 > }"Carl Perkins" <carl@gerg.tamu.edu> schreef in bericht * > }news:30MAY200318463566@gerg.tamu.edu...4 > }> "Hans Vlems" <hvlems.nieuw@zonnet.nl> writes...I > }> }The 3100-98 is faster than the 3100-80 so it requires licenses with 	 > }higher  > }> }units for the J > }> }base OS and possibly the layered products. Try $ SHOW LICENSE/CHARGE to& > }> }determine what the system needs. > }>I > }> This relationship is not universal. For example, an XP900 requires a H > }> 12 unit VMS license, but the (much) slower DEC 3000m600 requires 20 units. > }>J > }> It pretty much depends on how the system is classified at the time it> > }> is/was new. They rarely, if ever, change them after that. > }>
 > }> --- Carl  > } K > }That is correct. When LMF was shipped (VMS 5.0 IIRC) there was a more or C > }less relationship between the units needed for an A license (VMS 	 capacity) K > }and the VUPS rating of the system. So a VAX 8550 and a VAX 6410 used the L > }same license. Then the VAX cpu's became a lot faster and the (calculated)I > }number of units went up. DEC therafter classified the systems in three J > }groups, and issued A licenses according to that. AFAIK that resulted inH > }recalculated, lower values for certain systems. It also happened only once I	 > }guess.  > } K > }I'm not familiar with the XP900, but isn't that a workstation? Units for  anG > }A license cannot be compared to D (workstation) licenses (nor server  > }licenses for that matter).  > : > The XP900 is a workstation, but it uses type A licenses: > G > This is a COMPAQ AlphaStation XP900 466 MHz, hardware model type 1879 K > Type: A, Units Required: 12     (VAX/VMS Capacity or OpenVMS Unlimited or  Base) 6 > Type: B, * Not Permitted *      (VAX/VMS F&A Server); > Type: C, * Not Permitted *      (VAX/VMS Concurrent User) 7 > Type: D, * Not Permitted *      (VAX/VMS Workstation) F > Type: E, * Not Permitted *      (VAX/VMS System Integrated Products)8 > Type: F, * Not Permitted *      (VAX Layered Products), > Type: G, * Not Permitted *      (Reserved): > Type: H, Units Required: 1050   (Alpha Layered Products)4 > Type: I, Units Required: 1050   (Layered Products) > G > As you can see, the licensing does not follow as regular a pattern as  > one might have expected. > 
 > --- Carl   Quite irregular indeed!    ------------------------------   Date: 3 Jun 2003 03:12:56 -0700 : From: bes@out-fits.com (=?ISO-8859-1?Q?Bernard_Str=E4hl?=)/ Subject: Re: How to make a shadowed system disk = Message-ID: <eb298964.0306030212.3b9e8efe@posting.google.com>   | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KWFK65K7NAAKVGCS@sysdev.deutsche-boerse.com>...J > > I asked the wrong question.  Let me try again ... in part, you posted: >  > Not me; perhaps I quoted it. >  > >    $ EDT MODPARAMS.DAT > >  > >    ALLOCLASS=101 > >    SHADOWING=2 > >    SHADOW_SYS_DISK=1 > >    SHADOW_SYS_UNIT=0 > >    SHADOW_MAX_COPY=2 > >    SHADOW_SYS_TMO=20 > > E > >    then run autogen and reboot.  The above configuration is for a B > >    shadow set of 2 disks with "DKA0" being the primary member. > G > It doesn't specify 2 disks; SHADOWING=2, IIRC, means that the system  J > disk is shadowed.  (I think this is assumed if you set SHADOW_SYS_UNIT).J > You can have 1, 2 or 3 disks in a shadow set.  (Obviously, there is not I > much point in 1; it's just a starting point.)  It also doesn't specify   > DKA0.  > H > > Which parameter specifies DKA0:?  How do I specify another disk, say > > DKB100:  > > N > > Or perhaps I misunderstand.  Maybe whatever disk boots becomes the Primary > > Member.  > K > None of the parameters specifies DKA0.  The SHADOW_SYS_UNIT=0 means that  H > the shadow set will be called DSA0.  You specify the boot disk as the , > console parameter BOOTDEF_DEV or whatever. > D > I've never done it myself, but I think you can specify a LIST for K > BOOTDEF_DEV.  In that case, one could specify all shadow-set members, so  A > that the system will boot as long as at least one is available.     < Here an example in SRM console prompt (using HSG80 devices):   boot_osflags            a,0  boot_reset              ON bootbios9 bootdef_dev             dga49.1001.0.3.0 dga49.1002.0.3.0  dgb49.1003.0.5.5(                         dgb49.1004.0.5.5( booted_dev              dga49.1001.0.3.0 booted_file  booted_osflags          a,0    to startup the node you type:  >>> bootA and the system will boot on first device if availanble or then it  tries the next listed devices.   bye    ------------------------------   Date: 3 Jun 2003 06:46:32 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Install Directory3 Message-ID: <RCZyaE0yIFww@eisner.encompasserve.org>   [ In article <3EDC0656.88751E12@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > Chris Scheers wrote:	 >> [snip] E >> I thought that the justification for PCSI INSTALL was that all the H >> VMSINSTAL kits that were using DCL to do things no one had thought of >> was a bad thing?  > E > As I understand it, yes and no. I was given (by Hoff, I believe) to F > understand that because VMSINSTAL lacks a consistent way of checkingF > versions installed, prior versions, recording files installed, etc., > PCSI was dreamed up.  * Other features in the base design include:  C 	Changing from a procedural to a resulting-state installation model 8 	Changing from DCL to a compiled language implementation$ 	Tracking inter-product dependencies$ 	Coherent product removal strategies? 	Being able have various "installed" products on various discs,  		including CD-ROM  J Support for the last one has never been completed in the operating system.   ------------------------------  # Date: Tue, 03 Jun 2003 12:53:19 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond)  Subject: Re: Install Directory0 Message-ID: <3T0Da.1799$nl.300@news.cpqcorp.net>  4 In article <3EDBD5F7.E9C4D764@applied-synergy.com>, 1 Chris Scheers <chris@applied-synergy.com> writes:   C >I thought that the justification for PCSI INSTALL was that all the F >VMSINSTAL kits that were using DCL to do things no one had thought of >was a bad thing?   E On the contrary.  The inclusion of DCL "INSTALL" procedures in design C and original version of the POLYCENTER Software Installation (PCSI) F utility makes it clear that the architect knew there would necessarilyD be things that need to be done but are not anticpated in the design.E The more recently added "interactive" capability for these procedures ! continues to recognize this need.   C This is not to say that there are not some kits -- VMSINSTALL, PCSI E utility, and others -- that do what I would regard as foolish things. F A kit writer is always wise to consider carefully any roll-it-yourself  function that appears necessary.  E Others have listed some of the reasons for creating the PCSI utility. B One not mentioned is speed.  Although one can negate this with DCLG procedures, a PRODUCT INSTALL generally operates almost as fast as the  6 underlying disk/CD/DVD devices can transfer the bits.    --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  # Date: Tue, 03 Jun 2003 09:20:03 GMT & From: Woland <weiland@no.spam.post.cz>8 Subject: Re: Intel 64 bit Pentium seems to be on its way0 Message-ID: <CFN377754608024537@news.cup.hp.com>  M On Mon, 2 Jun 2003 18:45:07 -0700 "Jack Peacock" <peacock@simconv.com> wrote:   L > HP no, it's not a printer or a desktop PC.  But why not Intel?  If WindowsM > 64 takes off on the AMD platform Microsoft has no vested interest in seeing M > Intel do well with the Itanic.  If Intel buys the poor orphan stepchild VMS M > from HP they have the ready-made customer base in VMS systems to give IPF a M > boost.  Intel already bought the hardware guys from DEC, why not finish the $ > job and buy the software side too?  O Just because Intel is quite happy to be onboard with Windows. Windows actually  L sells the mass volumes of Intel processors because of the CPU cycles hungry O features, which are added to the system just with the intent to force hardware  M upgrades. I quess there is some kind of agreement between Microsoft an Intel  M (and maybe other hw suppliers of memory modules, disk drives etc.). No other  N OS i know about forces you to upgrade so often like Windows. Why should Intel L kill this business and good relationships with Microsoft by developing it's N own competitive OS, especialy when this OS doesn't promise such a high volume  sells?   J.   ------------------------------   Date: 3 Jun 2003 10:17:04 -0000 4 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>8 Subject: Re: Intel 64 bit Pentium seems to be on its way5 Message-ID: <20030603101704.5023.qmail@gacracker.org>   < On Tue, 03 Jun 2003, Woland <weiland@no.spam.post.cz> wrote:O > On Mon, 2 Jun 2003 18:45:07 -0700 "Jack Peacock" <peacock@simconv.com> wrote:  > N > > HP no, it's not a printer or a desktop PC.  But why not Intel?  If WindowsO > > 64 takes off on the AMD platform Microsoft has no vested interest in seeing O > > Intel do well with the Itanic.  If Intel buys the poor orphan stepchild VMS O > > from HP they have the ready-made customer base in VMS systems to give IPF a O > > boost.  Intel already bought the hardware guys from DEC, why not finish the & > > job and buy the software side too? > G > Just because Intel is quite happy to be onboard with Windows. Windows  > actually  N > sells the mass volumes of Intel processors because of the CPU cycles hungry G > features, which are added to the system just with the intent to force  > hardware  O > upgrades. I quess there is some kind of agreement between Microsoft an Intel  O > (and maybe other hw suppliers of memory modules, disk drives etc.). No other  P > OS i know about forces you to upgrade so often like Windows. Why should Intel N > kill this business and good relationships with Microsoft by developing it's P > own competitive OS, especialy when this OS doesn't promise such a high volume  > sells?    Because it offers a high margin?  L And, if correctly managed, will lead to highly profitable long-term business relationships.       Doc. --  K OpenVMS.  Eight out of ten hackers                   https://vmsbox.cjb.net K           prefer *other* operating systems.        http://althacker.cjb.net    ------------------------------  # Date: Tue, 03 Jun 2003 09:54:42 GMT & From: Woland <weiland@no.spam.post.cz>8 Subject: Re: Intel 64 bit Pentium seems to be on its way0 Message-ID: <CFN377754848603125@news.cup.hp.com>  L On 3 Jun 2003 10:17:04 -0000 Doc.Cypher <Use-Author-Address-Header@[127.1]>  wrote:   > " > Because it offers a high margin? > N > And, if correctly managed, will lead to highly profitable long-term business > relationships. n >   L Well, the Wintel business seems to be long-term enough to me. Intel has its # margin, AMD is the one in troubles.aO Yes, it could be a nice profitable business, but the risk that Microsoft could n get pissed is too high :-)   J.   ------------------------------  % Date: Tue, 03 Jun 2003 10:57:52 +0100sO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> 8 Subject: Re: Intel 64 bit Pentium seems to be on its way0 Message-ID: <bbhrf7$8ca$1@new-usenet.uk.sun.com>   Dirk Munk wrote:  ; Current Itanium sales figures would suggest that the sooneri/ Intel have a competitive 64 bit CPU the better.i  + http://212.100.234.54/content/61/30966.htmln  4 The register recently reported that a grand total of; 1,963 IA-64 based systems were sold in the first quarter ofo this year, down 31% on Q4 2002.i  > At an average of less than 2 CPU's per system thats a whopping8 3800 CPU's not enough to even register in the 64 bit CPU market.S  = These numbers would suggest that the IDC estimate that 25,000C< Itanium based systems would ship this year is very very very optimistic.S   Regards  Andrew Harrisonh  K > The German magazine CT has a editorial called "CPU whispers" (translated e > of course) > I > In the editorial of 19 May the editors give us some very good evidence  6 > that a 64 bit Pentium class Intel CPU is on its way. > J > The succesor of the Pentium 4 has the code name Prescott, and a certain H > mr. Hans de Vries took a very good look at the Die plot pictures that  > were published of this CPU.n > G > He concludes that the cpu has two 32 bit integer kernels that can be  J > combined to one 64 bit kernel. Futhermore he concludes that the CPU has J > a 40 bit memory address bus, just like the 64 bit AMD Athlon / Opteron. F > However internally the CPU is 32 still bit wide, and certain 64 bit  > registers are missing. > J > Their conclusion: we can expect a 64 bit Pentium class Intel CPU is the  > second half on 2004. > H > At the same time I saw a HP powerpoint presentation which states that G > Alpha servers will be will be sold untill >>> at least <<< 2006, and eL > that support for Alpha systems will continue untill >>> at least <<< 2011. > K > No statements were made about when the PA-Risc systems will no longer be eI > sold, or no longer be supported. However the arrow on time line of the t< > sheet ended at the same point as the arrow of the Alpha's. >    ------------------------------  # Date: Tue, 03 Jun 2003 12:21:03 GMT # From: "John Smith" <a@nonymous.com>r8 Subject: Re: Intel 64 bit Pentium seems to be on its wayJ Message-ID: <Po0Da.319450$M81.179276@news02.bloor.is.net.cable.rogers.com>  5 "Jack Peacock" <peacock@simconv.com> wrote in messagey, news:QpScnf9CTMrKY0ajXTWcqQ@mpowercom.net...0 > "John Smith" <a@nonymous.com> wrote in messageE > news:ZRPCa.113771$cK1.41318@news01.bloor.is.net.cable.rogers.com...O > > D > > Do you think HP is going to advertise and market OpenVMS? If so,B > > there's a lovely piece of swampland in Florida and a bridge inA > > Brooklyn that I just happen to have available for sale at the  presenti	 > > time.n > >nD > HP no, it's not a printer or a desktop PC.  But why not Intel?  If Windows F > 64 takes off on the AMD platform Microsoft has no vested interest in seeing? > Intel do well with the Itanic.  If Intel buys the poor orphan9
 stepchild VMS B > from HP they have the ready-made customer base in VMS systems to
 give IPF aB > boost.  Intel already bought the hardware guys from DEC, why not
 finish the$ > job and buy the software side too? >    Jack Peacock1    A Intel has butchered and dropped every piece of software they everuA bought. I can think of about a dozen software companies Intel has E purchased over the past 10 years....I don't think any of the products A those companies offered lasted more than 12-18 months after Intel1 bought them.   ------------------------------  # Date: Tue, 03 Jun 2003 12:24:19 GMTu# From: "John Smith" <a@nonymous.com>r8 Subject: Re: Intel 64 bit Pentium seems to be on its wayJ Message-ID: <Tr0Da.319457$M81.197414@news02.bloor.is.net.cable.rogers.com>  # "Andrew Harrison SUNUK Consultancy"08 <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message* news:bbhrf7$8ca$1@new-usenet.uk.sun.com... > Dirk Munk wrote: >G= > Current Itanium sales figures would suggest that the soonerr1 > Intel have a competitive 64 bit CPU the better.a > - > http://212.100.234.54/content/61/30966.html  >e6 > The register recently reported that a grand total of= > 1,963 IA-64 based systems were sold in the first quarter ofd! > this year, down 31% on Q4 2002.  >a@ > At an average of less than 2 CPU's per system thats a whopping: > 3800 CPU's not enough to even register in the 64 bit CPU	 > market.  >a? > These numbers would suggest that the IDC estimate that 25,000u> > Itanium based systems would ship this year is very very very
 > optimistic.   ? What's that work out to.... 400 wafers total?  About 1/2 day ofa= production based on 365 day operation and 2MM chips per year.r  > I can see Intel will be making this chip for a long time. Not!   ------------------------------   Date: 3 Jun 2003 08:26:18 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)m8 Subject: Re: Intel 64 bit Pentium seems to be on its way3 Message-ID: <DD7kHa6uzi9Z@eisner.encompasserve.org>   _ In article <ec6cnTmL3YRMXkajXTWcoQ@mpowercom.net>, "Jack Peacock" <peacock@simconv.com> writes:n >>M > There is a certain irony that while the Itanium would be the CPU that saved K > VMS, given the low Itanium sales figures over the last three years it nowsJ > appears that VMS may well be the operating system that saves the Itanium > CPU.  C    IA-64 may not be big yet, but vendors are watching it.  Tadpole,nJ    makers of the (retired) $14K(US) Alphabook and $6K(US) SPARCbook, just C    announced a new UltraSPARC laptop at $3K(US).  They are watchingwG    IA-64.  If they can do IA-64 at competitive prices HP and/or Tadpole E    is likely to find there is a market for such a system running VMS.p  E    Especially since Mark Gorham noted the desire for such a system asrF    expressed at a national DECUS (oops, I mean Encompass) over a year     ago in no uncertain manner.        ------------------------------  % Date: Tue, 03 Jun 2003 09:50:35 -04000+ From: Steve Lionel <Steve.Lionel@intel.com>S8 Subject: Re: Intel 64 bit Pentium seems to be on its way8 Message-ID: <2a9pdvcgavnvou6cg3efgg76vhhe5bmdtk@4ax.com>  F On Tue, 03 Jun 2003 12:21:03 GMT, "John Smith" <a@nonymous.com> wrote:  < >.  Intel already bought the hardware guys from DEC, why not >finish thes% >> job and buy the software side too?t >tB >Intel has butchered and dropped every piece of software they everB >bought. I can think of about a dozen software companies Intel hasF >purchased over the past 10 years....I don't think any of the productsB >those companies offered lasted more than 12-18 months after Intel
 >bought them.y  G Intel *DID* buy (some of) the software side too - at least a lot of the K compiler team, including myself.  This was part of the Alpha deal, but most L people fixated on the hardware side at the time. We're working together withN our HP friends to develop industry-leading compilers and tools for Itanium VMSL (and IA-32/Itanium Windows and Linux, with somewhat less involvement of HP.)J This is the traditional DEC compiler team and things are looking good from where I sit.  J Intel has some very good development tool software.  Compilers have been a% weak spot, but we're fixing that. See - http://developer.intel.com/software/products/    Steve Lionel Software Products Developmenti Intel Corporation    ------------------------------  # Date: Tue, 03 Jun 2003 15:37:07 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>i8 Subject: Re: Intel 64 bit Pentium seems to be on its way1 Message-ID: <Dg3Da.1814$zD.1525@news.cpqcorp.net>d  I The figure appears to me to be complete hogswallow, someones random guess  based on a few public sources.  J The IA64 has, and will continue to have *leading* FP performance, and nearL leading integer performance in the 64-bit space.  Vendors from HP to IBM are0 bringing more and bigger IA64 systems to market.  J Most sober analysis shows IA64 and Power as the leading 64-bit chips goingG forward, with a potential for Opteron (there's a whole lotta "ifs" with H AMD - the chip isn't a desktop chip, it's really a 2-4 way server chip -J with no serious server system vendors).  SPARC has no chance of keeping upK with any of these three (unless perhaps SUN has Fujitsu take over all theirt future design work ;-).P  K But it *is* in your interest to try and talk down IA64, because you need tor delay and hope for a miracle.n  K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>"; wrote in message news:bbhrf7$8ca$1@new-usenet.uk.sun.com...e > Dirk Munk wrote: > = > Current Itanium sales figures would suggest that the soonern1 > Intel have a competitive 64 bit CPU the better.n > - > http://212.100.234.54/content/61/30966.htmld > 6 > The register recently reported that a grand total of= > 1,963 IA-64 based systems were sold in the first quarter of,! > this year, down 31% on Q4 2002.n >t@ > At an average of less than 2 CPU's per system thats a whopping: > 3800 CPU's not enough to even register in the 64 bit CPU	 > market.t > ? > These numbers would suggest that the IDC estimate that 25,000t> > Itanium based systems would ship this year is very very very
 > optimistic.d >r	 > Regardsa > Andrew Harrison( >yL > > The German magazine CT has a editorial called "CPU whispers" (translated > > of course) > >bJ > > In the editorial of 19 May the editors give us some very good evidence8 > > that a 64 bit Pentium class Intel CPU is on its way. > >-K > > The succesor of the Pentium 4 has the code name Prescott, and a certainhI > > mr. Hans de Vries took a very good look at the Die plot pictures thatg > > were published of this CPU.3 > >sH > > He concludes that the cpu has two 32 bit integer kernels that can beK > > combined to one 64 bit kernel. Futhermore he concludes that the CPU haseK > > a 40 bit memory address bus, just like the 64 bit AMD Athlon / Opteron.lG > > However internally the CPU is 32 still bit wide, and certain 64 bitu > > registers are missing. > >iK > > Their conclusion: we can expect a 64 bit Pentium class Intel CPU is thew > > second half on 2004. > >tI > > At the same time I saw a HP powerpoint presentation which states thatMH > > Alpha servers will be will be sold untill >>> at least <<< 2006, andH > > that support for Alpha systems will continue untill >>> at least <<< 2011.s > >aL > > No statements were made about when the PA-Risc systems will no longer beJ > > sold, or no longer be supported. However the arrow on time line of the> > > sheet ended at the same point as the arrow of the Alpha's. > >i >.   ------------------------------  % Date: Tue, 03 Jun 2003 18:03:18 +0100eO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>c8 Subject: Re: Intel 64 bit Pentium seems to be on its way0 Message-ID: <bbikcv$gng$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:K > The figure appears to me to be complete hogswallow, someones random guesse  > based on a few public sources. > L > The IA64 has, and will continue to have *leading* FP performance, and nearN > leading integer performance in the 64-bit space.  Vendors from HP to IBM are2 > bringing more and bigger IA64 systems to market. >   5 What does this have to do with the number of Itaniums  being shipped ?b  : You can claim leading performance in every field, but this4 hardly matters since the buying public and the ISV's( seem to have very little interest in it.L > Most sober analysis shows IA64 and Power as the leading 64-bit chips goingI > forward, with a potential for Opteron (there's a whole lotta "ifs" withlJ > AMD - the chip isn't a desktop chip, it's really a 2-4 way server chip -L > with no serious server system vendors).  SPARC has no chance of keeping upM > with any of these three (unless perhaps SUN has Fujitsu take over all theirh > future design work ;-).g >   ) Ohh so thats your idea of sober analysis.b  6 Currently SPARC is the 1000 pound gorilla in the 64bit3 market, our volumes exceed all the other mainstreamV+ processors put together by a decent margin.u  2 Nor is there any indication that SPARC cannot keep up.e  2 Nor is there much indication that IBM are going to3 switch their high end systems focus from Power 4 to 8 Itanium they don't even seem very interested in shipping low end IA-64 based machines.a  M > But it *is* in your interest to try and talk down IA64, because you need tor > delay and hope for a miracle.p >   4 Umm, no sorry Fred I don't need to talk Itanium down1 because it isn't required the facts speak only tou clearly.  6 The only people hoping for a miracle are I would guess5 HP. The Miracle being that Itanium sales somehow picki3 up to a point where Intel don't feel the need to doo3 a low cost 64 bit x86-64 based CPU. Because if they 1 do then IA-64 is toast, all the other OEMS exceptn  HP will drop a quick as a flash.  4 Intel are doing Itanium because it promised to offer1 them higher margins and a big chunk of the 64 bity3 server CPU market. Neither promises look like beings' delivered on within the next 2-3 years.t   Regards0 Andrew Harrison.M > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>l= > wrote in message news:bbhrf7$8ca$1@new-usenet.uk.sun.com...f >  >>Dirk Munk wrote: >>= >>Current Itanium sales figures would suggest that the soonere1 >>Intel have a competitive 64 bit CPU the better.  >>- >>http://212.100.234.54/content/61/30966.htmli >>6 >>The register recently reported that a grand total of= >>1,963 IA-64 based systems were sold in the first quarter ofh! >>this year, down 31% on Q4 2002." >>@ >>At an average of less than 2 CPU's per system thats a whopping: >>3800 CPU's not enough to even register in the 64 bit CPU	 >>market.p >>? >>These numbers would suggest that the IDC estimate that 25,000e> >>Itanium based systems would ship this year is very very very
 >>optimistic.i >>	 >>Regardst >>Andrew Harrisoni >> >>K >>>The German magazine CT has a editorial called "CPU whispers" (translatedy
 >>>of course)m >>>oI >>>In the editorial of 19 May the editors give us some very good evidence 7 >>>that a 64 bit Pentium class Intel CPU is on its way.i >>> J >>>The succesor of the Pentium 4 has the code name Prescott, and a certainH >>>mr. Hans de Vries took a very good look at the Die plot pictures that >>>were published of this CPU. >>> G >>>He concludes that the cpu has two 32 bit integer kernels that can bekJ >>>combined to one 64 bit kernel. Futhermore he concludes that the CPU hasJ >>>a 40 bit memory address bus, just like the 64 bit AMD Athlon / Opteron.F >>>However internally the CPU is 32 still bit wide, and certain 64 bit >>>registers are missing.s >>>hJ >>>Their conclusion: we can expect a 64 bit Pentium class Intel CPU is the >>>second half on 2004.a >>>aH >>>At the same time I saw a HP powerpoint presentation which states thatG >>>Alpha servers will be will be sold untill >>> at least <<< 2006, andaG >>>that support for Alpha systems will continue untill >>> at least <<<i >> > 2011.i > K >>>No statements were made about when the PA-Risc systems will no longer be I >>>sold, or no longer be supported. However the arrow on time line of the = >>>sheet ended at the same point as the arrow of the Alpha's.i >>>i >> >  >    ------------------------------  % Date: Tue, 03 Jun 2003 08:54:18 -0400y* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 5000/ Message-ID: <vdp6t1o2lnt44f@corp.supernews.com>y   BoylesA wrote: > A couple of questions: > J > 1:  I am trying to config the sound card on my Alphastation 500/500 and F > the manual says to run isacfg -all, only problem there is no isacfg @ > command at the >>> prompt.  Current console is 7.2_2 and 4.58. > G > 2:  When I boot the Firmware upgrade CD and list the ARC or SRM I am  D > getting an APU-E message stating that the Manufacturing Header is G > invalid.  This machine I believe came from the factory with NT on it.- >  > Any idea?- >  > Thanks in advance3 >  > Alan > D I found an EISA config utility diskette and was able to go into the H system config and the sound board is is a Microsoft sound board in Slot F 1, IRQ 2(9).  When I change to the SRM console though I see no device.   Alan   ------------------------------  # Date: Tue, 03 Jun 2003 15:21:39 GMTi9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>e' Subject: Re: ISACFG on AlphaStation 500y0 Message-ID: <723Da.1812$1B.232@news.cpqcorp.net>  F If you have an EISA bus (not an ISA bus) then you need to use the EISAI configuration utility to manually configure any *ISA* cards.  The utility I can see EISA cards but not ISA cards (which have cfg files on the floppy,t but have to be manually set).c  E I dunno if the SRM will see the card.  When you get into OpenVMS, use-? ANAL/SYS and CLUE CONFIG to see what devices are on the system.c    7 "BoylesA" <alan.boyles@mindspring.com> wrote in message ) news:vdp6t1o2lnt44f@corp.supernews.com...@ > BoylesA wrote: > > A couple of questions: > >dK > > 1:  I am trying to config the sound card on my Alphastation 500/500 andlG > > the manual says to run isacfg -all, only problem there is no isacfg.B > > command at the >>> prompt.  Current console is 7.2_2 and 4.58. > >-H > > 2:  When I boot the Firmware upgrade CD and list the ARC or SRM I amE > > getting an APU-E message stating that the Manufacturing Header iseI > > invalid.  This machine I believe came from the factory with NT on it.  > >l
 > > Any idea?h > >u > > Thanks in advanceo > >O > > Alan > > E > I found an EISA config utility diskette and was able to go into the-I > system config and the sound board is is a Microsoft sound board in Slot@H > 1, IRQ 2(9).  When I change to the SRM console though I see no device. >6 > Alan >r   ------------------------------  % Date: Tue, 03 Jun 2003 11:28:46 -04000* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 500 / Message-ID: <vdpfunl2e29s2d@corp.supernews.com>T   Fred Kleinsorge wrote:H > If you have an EISA bus (not an ISA bus) then you need to use the EISAK > configuration utility to manually configure any *ISA* cards.  The utilityeK > can see EISA cards but not ISA cards (which have cfg files on the floppy,z > but have to be manually set).S > G > I dunno if the SRM will see the card.  When you get into OpenVMS, use A > ANAL/SYS and CLUE CONFIG to see what devices are on the system.f >  > 9 > "BoylesA" <alan.boyles@mindspring.com> wrote in message + > news:vdp6t1o2lnt44f@corp.supernews.com...  >  >>BoylesA wrote: >> >>>A couple of questions:s >>>tJ >>>1:  I am trying to config the sound card on my Alphastation 500/500 andF >>>the manual says to run isacfg -all, only problem there is no isacfgA >>>command at the >>> prompt.  Current console is 7.2_2 and 4.58.e >>>wG >>>2:  When I boot the Firmware upgrade CD and list the ARC or SRM I amrD >>>getting an APU-E message stating that the Manufacturing Header isH >>>invalid.  This machine I believe came from the factory with NT on it. >>>  >>>Any idea? >>>e >>>Thanks in advance >>>r >>>Alan  >>>S >>E >>I found an EISA config utility diskette and was able to go into thetI >>system config and the sound board is is a Microsoft sound board in SlotoH >>1, IRQ 2(9).  When I change to the SRM console though I see no device. >> >>Alan >> >  >  > m Here is the clue config and the device shows up but DECsound can't see it and neither does MMOV$AUDIODEVICES::   Adapter Configuration: ----------------------w TR Adapter     ADP               Hose Bus   BusArrayEntry     Node CSR            Vec/IRQ Port Slot Device Name / HW-Idd -- ----------- ----------------- ---- ----------------------- ---- ---------------------- ---- ---- ---------------------------t5   1 KA0F05      FFFFFFFF.81448600    0 BUSLESS_SYSTEMw*   2 PCI         FFFFFFFF.81448880    0 PCIo                                              FFFFFFFF.81448C68   30 FFFFFFFF.828B2000  9D0 EWA:    6 NI (Tulip)rr                                              FFFFFFFF.81448CD8   40 FFFFFFFF.828B4000  A00 GYA:    8 ZLX2-E (TGA2)z                                              FFFFFFFF.81448D10   48 FFFFFFFF.828B6000  9C0 PKA:    9 Qlogic ISP1020 SCSI-2l                                              FFFFFFFF.81448D48   50 FFFFFFFF.828B8000    0        10 MERCURY                                              FFFFFFFF.81448D80   58 FFFFFFFF.82AE2000  900 EWB:   11 DC21140 - 100 mbit NI (Tulip)s                                              FFFFFFFF.81448DB8   60 FFFFFFFF.82AE4000  940 FWA:   12 FDDI PDQ (PFI)c+   3 EISA        FFFFFFFF.81449180    0 EISAoq                                              FFFFFFFF.81449418    0 FFFFFFFF.828BA000    0         0 System Boarde                                              FFFFFFFF.81449450    1 FFFFFFFF.828DA000    9         1 00303030.32415349 (ISA2000)+   4 XBUS        FFFFFFFF.814497C0    0 XBUS-v                                              FFFFFFFF.81449A18    0 FFFFFFFF.828BA000    0         0 EISA_SYSTEM_BOARDk                                              FFFFFFFF.81449A50    1 FFFFFFFF.828BA000    6 DVA:    1 Floppy                                               FFFFFFFF.81449A88    2 FFFFFFFF.828BA000    7 LRA:    2 Line Printer (parallel port)ix                                              FFFFFFFF.81449AC0    3 FFFFFFFF.828BA000    3 TTA:    3 NS16450 Serial Portx                                              FFFFFFFF.81449AF8    4 FFFFFFFF.828BA000    4 TTB:    4 NS16450 Serial Port SDA>   ------------------------------  # Date: Tue, 03 Jun 2003 16:00:46 GMTb" From:   VAXman-  @SendSpamHere.ORG' Subject: Re: ISACFG on AlphaStation 500t0 Message-ID: <00A20D50.3D82E5F4@SendSpamHere.ORG>  \ In article <vdpfunl2e29s2d@corp.supernews.com>, BoylesA <alan.boyles@mindspring.com> writes: >Fred Kleinsorge wrote:0I >> If you have an EISA bus (not an ISA bus) then you need to use the EISA L >> configuration utility to manually configure any *ISA* cards.  The utilityL >> can see EISA cards but not ISA cards (which have cfg files on the floppy,  >> but have to be manually set). >> eH >> I dunno if the SRM will see the card.  When you get into OpenVMS, useB >> ANAL/SYS and CLUE CONFIG to see what devices are on the system. >>   >> s: >> "BoylesA" <alan.boyles@mindspring.com> wrote in message, >> news:vdp6t1o2lnt44f@corp.supernews.com... >> f >>>BoylesA wrote:s >>>s >>>>A couple of questions: >>>>K >>>>1:  I am trying to config the sound card on my Alphastation 500/500 andvG >>>>the manual says to run isacfg -all, only problem there is no isacfg B >>>>command at the >>> prompt.  Current console is 7.2_2 and 4.58. >>>>H >>>>2:  When I boot the Firmware upgrade CD and list the ARC or SRM I amE >>>>getting an APU-E message stating that the Manufacturing Header isiI >>>>invalid.  This machine I believe came from the factory with NT on it.  >>>>
 >>>>Any idea?e >>>> >>>>Thanks in advances >>>> >>>>Alan >>>> >>>CF >>>I found an EISA config utility diskette and was able to go into theJ >>>system config and the sound board is is a Microsoft sound board in SlotI >>>1, IRQ 2(9).  When I change to the SRM console though I see no device.e >>>* >>>Alani >>>* >>   >> V >> sn >Here is the clue config and the device shows up but DECsound can't see it and neither does MMOV$AUDIODEVICES: >  >Adapter Configuration:U >----------------------px >TR Adapter     ADP               Hose Bus   BusArrayEntry     Node CSR            Vec/IRQ Port Slot Device Name / HW-Id >-- ----------- ----------------- ---- ----------------------- ---- ---------------------- ---- ---- ---------------------------6 >  1 KA0F05      FFFFFFFF.81448600    0 BUSLESS_SYSTEM+ >  2 PCI         FFFFFFFF.81448880    0 PCI)p >                                             FFFFFFFF.81448C68   30 FFFFFFFF.828B2000  9D0 EWA:    6 NI (Tulip)s >                                             FFFFFFFF.81448CD8   40 FFFFFFFF.828B4000  A00 GYA:    8 ZLX2-E (TGA2)r{ >                                             FFFFFFFF.81448D10   48 FFFFFFFF.828B6000  9C0 PKA:    9 Qlogic ISP1020 SCSI-2 m >                                             FFFFFFFF.81448D48   50 FFFFFFFF.828B8000    0        10 MERCURYS >                                             FFFFFFFF.81448D80   58 FFFFFFFF.82AE2000  900 EWB:   11 DC21140 - 100 mbit NI (Tulip)it >                                             FFFFFFFF.81448DB8   60 FFFFFFFF.82AE4000  940 FWA:   12 FDDI PDQ (PFI), >  3 EISA        FFFFFFFF.81449180    0 EISAr >                                             FFFFFFFF.81449418    0 FFFFFFFF.828BA000    0         0 System Board >                                             FFFFFFFF.81449450    1 FFFFFFFF.828DA000    9         1 00303030.32415349 (ISA2000)                                                                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0 I just pulled AISA2000.CFG off of my ECU floppy:     ;  ;h* ; Microsoft Sound Board configuration file ;I BOARDn
  ID="ISA2000" 4  NAME="Microsoft Sound Board ISA Adapter Definition"  MFR="Microsoft"  CATEGORY="OTH"O  SLOT=ISA16w  LENGTH=150   + IOPORT(1)=0530H SIZE=BYTE  INITVAL=00000000n  % FUNCTION="General MSB port resources"t   TYPE="AUD"/   HELP="\nThese are the default MSB ports.\n\n"tQ   COMMENTS="This board has only 13 ports, 4 for Autosel, 4 for Codec, 5 for MIDI"n     CHOICE="Autosel resources"     LINK.     PORT=0530h-0537h | 604h-60bh | 0E80h-0E87h     LINK     PORT=0388h-038bh   FUNCTION="DMA port resources"d   TYPE="AUD"4   COMMENTS="Need 2 ports to adequately do Audio DMA"   CHOICE="two dma channels"    SUBCHOICE1     FREE
     DMA=0|1|3t
     DMA=1|0|0    FUNCTION="IRQ port resources"o   TYPE="AUD"3   COMMENTS="Need one IRQ for the counter interrupt"i+   CHOICE="Select IRQ for counter interrupt"i   FREE     IRQ=7|9|10|11-    3 It would appear that your sound card is configured.r   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMD            w5   "Well my son, life is like a beanstalk, isn't it?" 7   ------------------------------  # Date: Tue, 03 Jun 2003 16:17:41 GMTh9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>f' Subject: Re: ISACFG on AlphaStation 500 0 Message-ID: <FS3Da.1821$fG.326@news.cpqcorp.net>   Sure you do:  ' 9         1 00303030.32415349 (ISA2000)u  = This is the sound card.  You need to install MMOV Version 2.2   B This "should" result in a record in SYS$SYSTEM:SYS$USER_CONFIG.DAT   That looks something like:   device = "Microsoft Sound Card"e	 name = AUI driver = MMOV$MSBDRIVER  adapter = EISA id = "ISA2000"
 end_device  I If you have configured MMOV 2.2 and this record *is* in there... then tryr adding to to this record:g   flags = ISA_ON_EISAk      7 "BoylesA" <alan.boyles@mindspring.com> wrote in messagee) news:vdpfunl2e29s2d@corp.supernews.com...p > Fred Kleinsorge wrote:J > > If you have an EISA bus (not an ISA bus) then you need to use the EISAE > > configuration utility to manually configure any *ISA* cards.  The0 utility3E > > can see EISA cards but not ISA cards (which have cfg files on theu floppy,:! > > but have to be manually set).0 > >9I > > I dunno if the SRM will see the card.  When you get into OpenVMS, use.C > > ANAL/SYS and CLUE CONFIG to see what devices are on the system.g > >a > > ; > > "BoylesA" <alan.boyles@mindspring.com> wrote in messagek- > > news:vdp6t1o2lnt44f@corp.supernews.com...  > >h > >>BoylesA wrote: > >> > >>>A couple of questions:s > >>>DL > >>>1:  I am trying to config the sound card on my Alphastation 500/500 andH > >>>the manual says to run isacfg -all, only problem there is no isacfgC > >>>command at the >>> prompt.  Current console is 7.2_2 and 4.58.a > >>>eI > >>>2:  When I boot the Firmware upgrade CD and list the ARC or SRM I ameF > >>>getting an APU-E message stating that the Manufacturing Header isJ > >>>invalid.  This machine I believe came from the factory with NT on it. > >>>a > >>>Any idea? > >>>l > >>>Thanks in advance > >>>l	 > >>>Alano > >>>e > >>G > >>I found an EISA config utility diskette and was able to go into thevK > >>system config and the sound board is is a Microsoft sound board in SloteJ > >>1, IRQ 2(9).  When I change to the SRM console though I see no device. > >> > >>Alan > >> > >m > >s > > K > Here is the clue config and the device shows up but DECsound can't see it # and neither does MMOV$AUDIODEVICES:C >a > Adapter Configuration: > ----------------------H > TR Adapter     ADP               Hose Bus   BusArrayEntry     Node CSR% Vec/IRQ Port Slot Device Name / HW-IdeL > -- ----------- ----------------- ---- ----------------------- ---- -------5 --------------- ---- ---- ---------------------------:7 >   1 KA0F05      FFFFFFFF.81448600    0 BUSLESS_SYSTEM-, >   2 PCI         FFFFFFFF.81448880    0 PCIE >                                              FFFFFFFF.81448C68   30o+ FFFFFFFF.828B2000  9D0 EWA:    6 NI (Tulip)tE >                                              FFFFFFFF.81448CD8   40o. FFFFFFFF.828B4000  A00 GYA:    8 ZLX2-E (TGA2)E >                                              FFFFFFFF.81448D10   48l6 FFFFFFFF.828B6000  9C0 PKA:    9 Qlogic ISP1020 SCSI-2E >                                              FFFFFFFF.81448D48   50w( FFFFFFFF.828B8000    0        10 MERCURYE >                                              FFFFFFFF.81448D80   58 > FFFFFFFF.82AE2000  900 EWB:   11 DC21140 - 100 mbit NI (Tulip)E >                                              FFFFFFFF.81448DB8   60 / FFFFFFFF.82AE4000  940 FWA:   12 FDDI PDQ (PFI)t- >   3 EISA        FFFFFFFF.81449180    0 EISAsE >                                              FFFFFFFF.81449418    0h- FFFFFFFF.828BA000    0         0 System Board)E >                                              FFFFFFFF.81449450    1w< FFFFFFFF.828DA000    9         1 00303030.32415349 (ISA2000)- >   4 XBUS        FFFFFFFF.814497C0    0 XBUStE >                                              FFFFFFFF.81449A18    0e2 FFFFFFFF.828BA000    0         0 EISA_SYSTEM_BOARDE >                                              FFFFFFFF.81449A50    1e' FFFFFFFF.828BA000    6 DVA:    1 FloppytE >                                              FFFFFFFF.81449A88    2a= FFFFFFFF.828BA000    7 LRA:    2 Line Printer (parallel port).E >                                              FFFFFFFF.81449AC0    3@4 FFFFFFFF.828BA000    3 TTA:    3 NS16450 Serial PortE >                                              FFFFFFFF.81449AF8    4 4 FFFFFFFF.828BA000    4 TTB:    4 NS16450 Serial Port > SDA> >  >e   ------------------------------  # Date: Tue, 03 Jun 2003 16:22:16 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>y' Subject: Re: ISACFG on AlphaStation 500l1 Message-ID: <YW3Da.1823$xB.1343@news.cpqcorp.net>n   >hK > If you have configured MMOV 2.2 and this record *is* in there... then try  > adding to to this record:o >  > flags = ISA_ON_EISA  >e  I Forgot.  If it is there, and you make this change, either reboot or type:    $ sysman io rebuilde $ sysman io auto $ sho dev AU   ------------------------------  % Date: Tue, 03 Jun 2003 12:26:01 -0400e* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 500,/ Message-ID: <vdpja2d75f2vee@corp.supernews.com>    Fred Kleinsorge wrote:K >>If you have configured MMOV 2.2 and this record *is* in there... then tryh >>adding to to this record:i >> >>flags = ISA_ON_EISA  >> >  > K > Forgot.  If it is there, and you make this change, either reboot or type:f >  > $ sysman io rebuildi > $ sysman io auto > $ sho dev AU >  >  >  There is a device now called AUA0 and it is assigned to MMOV$server, but when I invoke DECsound I get an invalid channel assignment.  )   Is there a config routine for DECsound?    Thanks Fred!   ------------------------------  # Date: Tue, 03 Jun 2003 17:02:13 GMT09 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>u' Subject: Re: ISACFG on AlphaStation 500b0 Message-ID: <pw4Da.1829$sK.407@news.cpqcorp.net>  7 "BoylesA" <alan.boyles@mindspring.com> wrote in messagee) news:vdpja2d75f2vee@corp.supernews.com...  > > J > There is a device now called AUA0 and it is assigned to MMOV$server, but; when I invoke DECsound I get an invalid channel assignment. + >   Is there a config routine for DECsound?o >t  L I would imagine so.  But I don't have the documentation.  Look for something. in sys$manager (or sys$startup) with "MMOV*.*"   ------------------------------  % Date: Tue, 03 Jun 2003 13:35:46 -0400-* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 500U/ Message-ID: <vdpnd3asm9es8c@corp.supernews.com>c   Fred Kleinsorge wrote:9 > "BoylesA" <alan.boyles@mindspring.com> wrote in messagec+ > news:vdpja2d75f2vee@corp.supernews.com...: > J >>There is a device now called AUA0 and it is assigned to MMOV$server, but > = > when I invoke DECsound I get an invalid channel assignment./ > + >>  Is there a config routine for DECsound?t >> >  > N > I would imagine so.  But I don't have the documentation.  Look for something0 > in sys$manager (or sys$startup) with "MMOV*.*" >  >  > Z Interestingly enough I can now run the IVP and it seems to work fine though no sound comesd out.  When I try to do the same exact command at the DCL prompt the MMOV$SERVER process dies and the command fails.  
 Any ideas?   Alan   ------------------------------   Date: 3 Jun 2003 05:00:05 -0700a1 From: joe.lofft@itec.mail.suny.edu (Joseph Lofft)f, Subject: Re: JAVA appears to hang on OpenVMS= Message-ID: <de82e5e4.0306030400.3df6bc74@posting.google.com>t   Thanks for the info.  % I will apply it and see what happens.t   ------------------------------   Date: 3 Jun 2003 05:07:41 -0500 + From: young_r@encompasserve.org (Rob Young)s" Subject: Re: Portents of VMS death3 Message-ID: <9zZgATQ1NRWv@eisner.encompasserve.org>t  [ In article <3EDC0475.38ED89F7@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:P   > B > A mentor of mine once said, "Until you know value, everything is
 > worthless".e >   N "A cynic is a man who knows the price of everything and the value of nothing.""                        -- Wilde      ------------------------------   Date: 3 Jun 2003 04:26:54 -07000 From: bihappy@hotmail.com (jo)" Subject: Re: Portents of VMS death= Message-ID: <f8c93d50.0306030326.71950119@posting.google.com>t  F Still after ten years of hypochrondic talks and discussions OpenVMS is still around and kicking. E Ever since Digital is gone, and even before that, some people want usn4 to believe OpenVMS is dead or going to be very soon.  A As I've seen in advertising campains of HP, none of their OS's ise	 promoted.h> I still believe in OpenVMS, and expect HP to know it's value. D If not, lets talk about it again when we bring OpenVMS to it's grave and not before.i  ? For now, don't talk people in to a OpenVMS depression and enjoy2  OpenVMS for as long as it lasts.     Jo!    ------------------------------  $ Date: Tue, 3 Jun 2003 08:08:55 -0700' From: David Mathog <mathog@caltech.edu>"" Subject: Re: Portents of VMS death8 Message-ID: <20030603080855.4c039167.mathog@caltech.edu>   On 3 Jun 2003 04:26:54 -0700 bihappy@hotmail.com (jo) wrote:   H > Still after ten years of hypochrondic talks and discussions OpenVMS is > still around and kicking.t  ? Kicking?  Kicking the bucket maybe.  Things may be different in ? the corporate data center but good luck finding VMS machines inhA academia these days.  I'm not saying there aren't any, I'm sayingo@ that the remaining machines are those few that have not yet beenF replaced.  (Hands up, who in a university has bought a NEW VMS machineB for work in the last 6 months?)  Why would a lab buy a VMS machineG today anyway? Both the hardware and the software are grossly overpricedeJ (for instance, in performance/$), the vendor is a major PITA to deal with,G and there's now zero native application software in most fields.  MaybenD if it was controlling a particle accelerator or some other hideouslyE expensive megaproject one could justify VMS, but for general use, no.e  A > For now, don't talk people in to a OpenVMS depression and enjoy-" > OpenVMS for as long as it lasts.   lasted.0   Regards,   David Mathog mathog@caltech.edu> Manager, Sequence Analysis Facility, Biology Division, Caltech   ------------------------------  # Date: Tue, 03 Jun 2003 15:30:19 GMTo& From: jlsue <jefflsxxxz@sbcglobal.net>" Subject: Re: Portents of VMS death8 Message-ID: <gafpdvcb0e6e89ls9rl3nv565gtovlvcb3@4ax.com>  F On 2 Jun 2003 22:45:36 -0700, mistdragon@zdnetonebox.com (mist dragon) wrote:     >eB >Conspiracy theory: VMS staff wanted off VMS because they knew itsF >dying ? HP wanted them to move off VMS because they knew it was dyingE >(you knew Tru64 is from HP too?) ? VMS staff was not adequate to its F >task and knew no-one would want VMS in these days so they decided allE >to switch to modern OS ? The staff wanted to retire after seeing toos >much ? What is your theory ?  >   I I think I've stated my question before.  IIRC, the test used a much oldertJ version of VMS and TCP/IP, and compared it to a recent version of UNIX andG TCP/IP.  If many of the issues that caused bottlenecks were resolved intI more recent versions that were available at the time of the test, then itrK wasn't a valid test if it didn't include the more recent version.  Well, to-J be more specific, it is not valid to draw the conclusion that VMS (generic VMS) can not take the load.   K If it was done on older version of VMS & TCP/IP, then it does not show thatgB the VMS platform can not take the load, it only proves that if youH "carefully" choose an old enough version, you can find one that will not perform.  K I guess the real conclusion from the test, as described, is that the older, K possibly out-of-date, operating platform can't handle the load.  But that's  not saying much.   ------------------------------  % Date: Tue, 03 Jun 2003 08:53:25 +02004/ From: richard <yves-laurent.richard@wanadoo.fr> N Subject: Re: Printing to a very old LXY12 line printer via a DecServer  (long)8 Message-ID: <pbhodvcktshf67cnku6od5d6r8gvb70t1m@4ax.com>   >  >  > $ >5.4.3.3 Set Modem Function Modifier)>The set modem function modifier is used in maintenance operations to allow a process to activate and deactivate modem control signals. Both set mode and set characteristics functions can take the set modem function modifier. The following combinations of function code and modifier are provided:  ) >"	IO$_SETMODE!IO$M_SET_MODEM!IO$M_MAINT ,) >"	IO$_SETCHAR!IO$M_SET_MODEM!IO$M_MAINT i >Notet >  >For LAT devices, the set modem field for maintenance operations of the IO$M_SET_MODEM!IO$M_MAINT function modifier is unsupported and may return unpredictable results.  _ >These function code modifier pairs take the following device- or function-dependent argument: nk >P1---The address of a quadword block that specifies which modem control signals to activate or deactivate  , >Figure 5-9 shows the format of this block.  >Figure 5-9 Set Mode P1 Block  >  > s >The modem on and modem off fields, in combination or separately, can specify one or more of the following values: 2' >"	TT$M_DS_RTS---Request to send (RTS)  + >"	TT$M_DS_DTR---Data terminal ready (DTR) o? >"	TT$M_DS_SECTX---Transmitted backward channel data (Sec Txd) s >The $TTDEF macro defines the values for these values. These values can only be specified if the terminal characteristic TT$M_MODEM is not set. Otherwise, an error (SS$_ABORT) will result. m >Notes > } >The set modem function is not supported for remote terminals. The status SS$_DEVREQERR is returned in the I/O status block. e >Because the DMF32 does not provide the secondary transmitted data signal (Sec Txd), the driver sets the secondary request to send the signal. Users should connect a jumper cable between pins 14 and 19 on the DMF32. # >5.4.3.4 Loopback Function Modifiero>The loopback function modifier is used in maintenance operations to place the terminal line in a hardware loopback mode. Data transmitted to a line in this mode is returned as receive data. If the controller does not support loopback mode or the terminal line has the TT$M_MODEM characteristic set, an error status (SS$_ABORT) is returned. Both set mode functions can take the loopback function modifier.  >Noteg > | >The loopback function is not supported for remote terminals. The status SS$_DEVREQERR is returned in the I/O status block. H >The following combinations of function code and modifier are provided: $ >"	IO$_SETMODE!IO$M_LOOP!IO$M_MAINT $ >"	IO$_SETCHAR!IO$M_LOOP!IO$M_MAINT >Data transmitted in the loopback mode should only be written in records less than or equal to the size of the type-ahead buffer (see Section 5.2.1.5). Programs that use the loopback function modifier should incorporate a 1-second delay to allow the controller to enable the loopback mode after the request is posted. Write requests should also include the IO$M_NOFORMAT function modifier to prevent terminal driver from formatting input or output data.  >Notes >  >The serial line interfaces for the VAX 8200 processor implement an internal loopback bus that is common to all four serial lines. The hardware allows all serial lines operating in loopback mode to transmit data to the bus at the same time. If more than one serial line writes data to the bus, all of the transmitted data is combined and made available to the receiving end of those same serial lines. Therefore, the received data may be different from the transmitted data if more than one serial line is operat ing in loopback mode at the same time. To prevent receiving such spurious data, you must not operate multiple serial lines in loopback mode. o >The operating system provides another function modifier to reset a terminal line previously placed in loopback mode. The following combinations of function code and modifier are provided: b& >"	IO$_SETMODE!IO$M_UNLOOP!IO$M_MAINT & >"	IO$_SETCHAR!IO$M_UNLOOP!IO$M_MAINT  >Programs that use the unloop function modifier should incorporate a 1-second delay to allow the controller to reset the loopback mode after the request is posted.  >Note  > > >IO$M_LOOP and IO$M_UNLOOP are not supported for LAT devices. 1 >5.4.3.5 Enable Out-of-Band AST Function Modifier  >The enable out-of-band AST function modifier requests that the terminal driver queue an AST for the requesting process when you enter any one of 32 control characters. The following combinations of function code and modifier are provided: 5 >"	IO$_SETMODE!IO$M_OUTBAND---Enable out-of-band AST i5 >"	IO$_SETCHAR!IO$M_OUTBAND---Enable out-of-band AST c` >These function code modifier pairs take the following device- or function-dependent arguments:  >"	P1---Address of the AST service or 0 if the AST entered on this channel is to be canceled. (The AST parameter will be the out-of-band character.) tr >"	P2---Address of a character mask with the same format as the short form terminator mask (see Section 5.4.1.2). N >"	P3---Access mode to deliver AST (maximized with the caller's access mode). ] >The IO$_SETMODE!IO$M_OUTBAND function can optionally take the following function modifiers: -B >"	IO$M_INCLUDE---Include the character typed in the data stream.  >"	IO$M_TT_ABORT---Allow current read and write operations to be aborted. (The IOSB for aborted operations returns the status SS$_CONTROLC.) i >If an out-of-band AST is in effect, pressing any control character specified in the P2 mask gains the attention of the enabling process. Figure 5-8 shows the relationship of the out-of-band function with some of the control characters. n< >You can have only one out-of-band AST enabled per channel.  >Out-of-band ASTs are repeating ASTs; they continue to be delivered until specifically disabled. Out-of-band AST enables are flushed by the Cancel I/O on Channel ($CANCEL) system service. $ >5.4.3.6 Broadcast Function Modifier >The broadcast function modifier allows you to turn on or turn off selected broadcast requester identifiers (IDs). The following combination of function code and modifier is provided:  >IO$_SETMODE!IO$M_BRDCST t_ >This function code modifier pair takes the following device- or function-dependent arguments: rW >"	P1---A buffer that contains the bits that specify the requester IDs to be broadcast  9 >"	P2---The length of the P1 buffer (default is 8 bytes) a;>The first longword of P1 is reserved for use by Compaq facilities, as shown in Table 5-12. The symbols are defined in the system macro library ($BRKDEF). The second longword is for customer use to specify selected bits. If any bit is set in the P1 buffer, that particular requester ID is turned off for broadcast.  # >Table 5-12 Broadcast Requester IDs  >Bit 	Meaning * >BRK$C_DCL 	Disables broadcasts by Ctrl/T _ >BRK$C_GENERAL 	Disables broadcasts by the DCL command REPLY and the SYS$BRDCST system service  5 >BRK$C_MAIL 	Disables broadcasts by the Mail utility A7 >BRK$C_PHONE 	Disables broadcasts by the Phone utility p? >BRC$C_QUEUE 	Disables broadcasts about batch and print queues a; >BRK$C_SHUTDOWN 	Disables broadcasts about system shutdown hG >BRK$C_URGENT 	Disables broadcasts labeled URGENT by the REPLY command n >BRK$C_USER n 	Disables broadcasts by images associated with the specified value; n can be any decimal integer between 1 and 16 $ >5.4.4 LAT Port Driver QIO Interface >The LAT port driver (LTDRIVER) accommodates I/O requests from application programs for connections to remote devices on one or more terminal servers; for connections to remote services; and for configuring LTDRIVER and retrieving configuration information about LTDRIVER. A remote device, such as a printer, can be shared in a LAT configuration. Before an application program can access a remote device, the system manager must create logical devices and map them to physical devices connected to terminal servers. Creating and mapping these logical devices can be done either with the LAT Control Program (LATCP) utility or with a $QIO request from a program that has OPER privilege. Once mapped, application programs can establish and terminate connections to these remote devices. 0>This section describes the capabilities of the QIO interface to the LAT port driver (LTDRIVER). The QIO interface allows application programs to access and modify information contained in the LTDRIVER data structures and to initiate events and obtain status information. You must use these QIO functions to establish a connection to a remote device or service from an application program. Compaq does not support any other methods of connection. h >The LTDRIVER responds to TEST SERVICE commands issued at terminal servers that support the TEST SERVICE command, such as the DECserver 200 and DECserver 500 servers. t >LAT devices can use all read and write function modifiers listed for the terminal driver function codes except those modifiers that apply to modems (see Sections 5.4.1 and 5.4.2). t~ >The operating system does not support the following set mode or set characteristics function code modifiers for LAT devices: 
 >"	IO$M_LOOP b >"	IO$M_UNLOOP   >"	TT$M_ALTRPAR  >"	TT$M_ALTFRAME v >"	TT$M_MODEM  >"	TT$M_READSYNC i >"	TT2$M_SETSPEED  >With LAT devices, the terminal server, rather than the host, handles flow control to the physical device. A separate flow control mechanism exists between the server and the host. w >5.4.4.1 LAT Port TypeshC >QIO functions can be used to create the following LAT port types: s>"	Application Port. This type of port can be used to connect to a remote device (typically a printer) on a terminal server or to a dedicated port on another LAT service node. This is the default port type. See Section 5.4.4.5 for a description of programming an application port. h>"	Dedicated Port. This type of port specifies that the logical port on your node is dedicated to an application service. When users on a terminal server (or on another node that supports outgoing connections) request a connection to this service name, they are connected to a dedicated port. See Section 5.4.4.6 for a description of programming a dedicated port and application service.  >"	Forward Port. This type of port is used for outgoing LAT connections (to remote services) and is created by assigning a channel to the LAT template device _LTA0: with the $ASSIGN system service. k >QIO functions can also be used to configure and read information about these ports; for more information: sC >o	See Section 5.4.4.3 for a description of configuring a LAT port d_ >o	See Section 5.4.4.4 for a description of reading configuration information about a LAT port bv >o	See Section 5.4.4.7 for a description of programming a forward port in order to make a connection to a LAT service " >5.4.4.2 LAT Port Driver FunctionsY >The operating system provides the following combinations of function code and modifier:   >"	IO$_TTY_PORT!IO$M_LT_CONNECT. Requests that the LAT port driver make a connection to a remote device on a server (or dedicated port on another LAT service node) or to a remote service, depending on whether the port is an application port or a forward port respectively. For dedicated ports, this QIO completes when an incoming connection to the port is established. See Section 5.4.4.5 for a description of programming an application port, Section 5.4.4.6 for a description of programming a dedicated port, anC d Section 5.4.4.7 for a description of programming a forward port. ry>"	IO$_TTY_PORT!IO$M_LT_DISCON. Depending on the port type, requests that the LAT port driver terminate the LAT connection to the remote device, service, or local application service. IO$M_FLUSH_DATA can be specified in the P2 argument to IO$M_LT_DISCON. The flush flag indicates that any data not delivered to the remote device is to be flushed when the disconnect is issued. a >"	IO$_TTY_PORT!IO$M_LT_SETMODE. Requests that the LAT port driver create or configure a LAT entity. See Section 5.4.4.3 for more information. b >"	IO$_TTY_PORT!IO$M_LT_SENSEMODE. Requests that the LAT port driver return configuration information about a LAT entity. See Section 5.4.4.4 for more information. . >5.4.4.3 Creating and Configuring LAT Entities >The LAT SETMODE $QIO function (IO$_TTY_PORT!IO$M_LT_SETMODE) is used to create, delete, and modify LAT nodes, services, ports, and links. rP >Creation, deletion, or modification of any entity requires the OPER privilege.  >The LAT SETMODE $QIO function accepts four arguments: P1, P2, P3, and P4. P1 is the address of an item list; P2 is the length of this item list. s >P3 specifies the type of entity to which the SETMODE operation applies. The entity type can be one of five types: l >"	Node (LAT$C_ENT_NODE). Only the local node name may be specified, with the exception of a SETMODE itemlist containing no item codes other than LAT$_ITM_COUNTERS. n >"	Service (LAT$C_ENT_SERVICE). Only local service names may be specified, with the exception of a SETMODE itemlist containing no item codes other than LAT$_ITM_COUNTERS. rA >"	Link (LAT$C_ENT_LINK). The data link associated with the LAN. m >"	Port (LAT$C_ENT_PORT).  >"	Queue Entry (LAT$C_ENT_QUEUE_ENTRY). Indicates queue entry entities. When this entity is used, the only valid SETMODE operation is delete. j>The value for the entity type occupies the low-order 16 bits (bits 0--15) of the P3 parameter. For all four entity types, bits 16--19 are used as a status field to indicate the expected current status of the entity. These bits are used to decide whether the entity needs to be created before its characteristics are set. The possible values for this field are: t >"	LAT$C_ENTS_OLD---The entity must already exist. An SS$_NOSUCHDEV error is returned if the entity does not exist. o >"	LAT$C_ENTS_NEW---The entity must be created. An SS$_DUPLNAM error is returned if the entity already exists. Mu >"	LAT$C_ENTS_UNK---If the entity does not exist, it is created. If it does exist, its characteristics are modified. u >"	LAT$C_ENTS_DEL---If the entity exists, delete it. Otherwise, an SS$_NOSUCHDEV error is returned and the item list is not used. >P4 may contain the address of an entity name string descriptor. If this parameter is omitted (contains a 0 or the address of a descriptor that points to an empty buffer), a default may be used in some cases. The defaults for each entity type are as follows: 0$ >"	LAT$C_ENT_NODE---The local node. F >"	LAT$C_ENT_SERVICE---No default; you must specify the service name. ) >"	LAT$C_ENT_LINK---The string LAT$LINK. E~ >"	LAT$C_ENT_PORT---The device name associated with the currently assigned channel (the CHAN parameter of the $QIO function). 0 >SETMODE can return the following status codes: @ >"	SS$_NOPRIV---No privilege to complete the desired operation. J >"	SS$_ACCVIO---Part of the argument list or itemlist is not addressable.  >"	SS$_BADPARAM---One of the parameters in the itemlist is in error. If this value is returned, the second longword of the IOSB contains the item code of the parameter in error.  >SETMODE Item Codes t >Each item in the itemlist consists of a one-word (16-bit) item code, followed by a value associated with the item. >Item codes in which the bit named LAT$V_STRING is zero take a longword value. The associated value is contained in the longword immediately following the item code in the itemlist. Item codes in which this bit is 1 take a counted string for their value. The byte immediately following the item code contains a byte count, which describes the length of the string that immediately follows it. F>If you set bit LAT$V_CLEAR in the item code to 1, the current value associated with the item code is cleared or set to its default value. In this case, the actual value specified in the itemlist is ignored, although the byte count field skips to the next item in the itemlist. 5 >Figure 5-10 shows an example of a SETMODE itemlist. F& >Figure 5-10 Example SETMODE Itemlist  >  > >This SETMODE itemlist is the P1 parameter for a $QIO SETMODE function on the local node. P4 is omitted, and P3 is #LAT$C_ENT_NODE!<LAT$C_ENTS_OLD@16>. P2 is the length of the itemlist (52). A $QIO SETMODE function for this itemlist would perform the following operations: I% >1.	Set the state of the node to on.  / >2.	Set the LAT keepalive timer to 40 seconds. e0 >3.	Set the node identification to LTC CLUSTER. 3 >4.	Set the LAT circuit timer to 160 milliseconds. o% >5.	Enable LAT outbound connections. nj >6.	Turn on user groups 2, 8, 10, 11, 12, 16, and 19. LAT$_ITM_USER_GROUPS is represented by a bit field. 5 >7.	Set the outgoing session limit to five sessions. i >For each entity type, only a subset of item codes may be set. Table 5-13 lists the item codes that may be set for the LAT$C_ENT_NODE entity type. >% >Table 5-13 LAT$C_ENT_NODE Item Codese >Item Code 	Meaning X >LAT$_ITM_STATE 	Operating state of the LAT protocol. The following values are allowed:  >LAT$C_OFF 	Turns off LAT protocol processing. No new connections allowed in either direction. Existing connections are terminated immediately. This is the default. 0s >LAT$C_SHUT 	Disallows new LAT connections in either direction. Existing connections are allowed to remain active. r- >LAT$C_ON 	Turns on LAT protocol processing. h >I >LAT$_ITM_CIRCUIT_TIMER 	Circuit timer value in milliseconds. Valid values are 10 to 1000 milliseconds. The default is 80 milliseconds.  >LAT$_ITM_CPU_RATING 	CPU rating. Valid values are 0 to 100. If this value is 0, then the CPU rating value is not used in the rating calculation. Refer to the OpenVMS System Management Utilities Reference Manual for a complete description of this feature.  >LAT$_ITM_DEVICE_SEED 	Overrides the default lower boundary for new LTA devices. Valid values are 0 to 9999; the default is 0. Refer to the OpenVMS System Management Utilities Reference Manual for more information on this feature. d| >LAT$_ITM_KEEPALIVE_TIMER 	Keepalive timer value in seconds. Valid values are 10 to 255 seconds. The default is 20 seconds. | >LAT$_ITM_MULTICAST_TIMER 	Multicast timer value in seconds. Valid values are 10 to 180 seconds. The default is 60 seconds.  >LAT$_ITM_NODE_LIMIT 	Maximum number of nodes in LAT database. The default is 0, where the maximum is determined by system resources.  >LAT$_ITM_RETRANSMIT_LIMIT 	LAT retransmit limit. Valid values are 4 to 120 retransmissions. The default is 8 retransmissions. F >LAT$_ITM_SERVER_MODE 	Controls whether the node allows the use of the MASTER side of the LAT protocol for outbound connections. Valid values are: (= >LAT$C_DISABLED 	Server mode disabled (this is the default). 8% >LAT$C_ENABLED 	Server mode enabled. : > Q>LAT$_ITM_SERVICE_RESPONDER 	Indicates whether the node is to respond to service inquiries originating from a remote system. These inquiries are not necessarily directed at services being offered by the node. Refer to the OpenVMS System Management Utilities Reference Manual for a complete description of this feature. Valid values are: 0C >LAT$C_DISABLED 	Service responder disabled (this is the default). F+ >LAT$C_ENABLED 	Service responder enabled.   >  >LAT$_ITM_OUTGOING_SES_LIMIT 	Maximum number of outgoing LAT sessions. A value of 0, which is the default, indicates that the limit is determined by system resources. . >LAT$_ITM_INCOMING_SES_LIMIT 	Maximum number of interactive LAT sessions. A value of 0, which is the default, indicates that the limit is determined by system resources. _ >LAT$_ITM_CONNECTIONS 	Controls whether inbound connections can be accepted. Valid values are: r/ >LAT$C_DISABLED 	Inbound connections disabled.  C >LAT$C_ENABLED 	Inbound connections enabled (this is the default). " >C >LAT$_ITM_NODE_NAME 	Causes the LAT node name to be set to the given name. This item code may be specified only if the entity status field of the P3 parameter is LAT$C_ENTS_NEW; otherwise, a LAT$_ENTNOTFOU error results. sf >LAT$_ITM_IDENTIFICATION 	Node identification string. The default is the translation of SYS$ANNOUNCE.  >LAT$_ITM_SERVICE_GROUPS 	Specifies a default service group code bit mask. This mask is then used when creating new local services. The default is group code 0 enabled and all others disabled when the LAT software is initialized. N>Note that the use of the LAT$V_CLEAR bit is an exception for this parameter code. If you clear bit LAT$V_CLEAR, group codes corresponding to the group code mask, as specified in the itemlist, are set. Alternatively, if you set LAT$V_CLEAR, group codes corresponding to the group code mask, as specified in the itemlist, are cleared.  >LAT$_ITM_USER_GROUPS 	LAT group codes to be used when attempting outbound connections using the MASTER side of the LAT protocol. The default is all group codes disabled when the LAT software is initialized. N>Note that the use of the LAT$V_CLEAR bit is an exception for this parameter code. If you clear bit LAT$V_CLEAR, group codes corresponding to the group code mask, as specified in the itemlist, are set. Alternatively, if you set LAT$V_CLEAR, group codes corresponding to the group code mask, as specified in the itemlist, are cleared. *>LAT$_ITM_COUNTERS 	Node counters block. Allows for zeroing of all node counters. This item code may be specified only if the entity status field of the P3 parameter is LAT$C_ENTS_OLD and the LAT$V_CLEAR bit is set. Violating either of these two rules results in a returned status of SS$_BADPARAM.  >LAT$_ITM_MAXIMUM_UNITS 	Maximum unit number. Sets the highest value for a LTA unit number. Must be between 1 and 9999; defaults to 9999.  >++ LAT$_ITM_HI_CIRCUITS 	Indicates the highest number the resource attained since the host was initialized for LAT connections to node. cR >++ LAT$_ITM_CUR_CIRCUITS 	Indicates current count of active connections to node. O >++ LAT$_ITM_MAX_CIRCUITS 	Indicates maximum allowed virtual circuits to node. Sz >++ LAT$_ITM_HI_SESSIONS 	Indicates highest number the resource attained since the host was initialized for LAT sessions. H >++ LAT$_ITM_CUR_SESSIONS 	Indicates current number of active sessions. @ >++ LAT$_ITM_MAX_SESSIONS 	Indicates maximum possible sessions.  >++ LAT$_ITM_HI_OUT_QUEUE 	Indicates highest number the resource attained since the host was initialized of outgoing queued connect requests. Y >++ LAT$_ITM_CUR_OUT_QUEUE 	Indicates current count of outgoing queued connect requests. tg >++ LAT$_ITM_MAX_OUT_QUEUE 	Indicates maximum number of simultaneous outgoing queued connect requests. n >++ LAT$_TIM_HI_IN_QUEUE 	Indicates highest number the resource attained since the host was initialized of incoming queued requests. T^ >++ LAT$_ITM_CUR_IN_QUEUE 	Indicates current number of entries in the incoming connect queue. f >++ LAT$_ITM_MAX_IN_QUEUE 	Indicates maximum number of entries allowed on the incoming connect queue.  >++ LAT$_ITM_HI_SAMS_QUEUED 	Indicates highest number the resource attained since the host was initialized of outstanding, unprocessed service announcement messages by LATACP.  >++ LAT$_ITM_CUR_SAMS_QUEUED 	Indicates current number of outstanding, unprocessed service announcement messages on LATACP's queue.  >++ LAT$_ITM_MAX_SAMS_QUEUED 	Indicates maximum number of outstanding, unprocessed service announcement messages allowed on LATACP's queue. If this limit is ever reached, subsequent service announcement messages are not delivered or processed by LATACP.  >++ LAT$_ITM_HI_SOL_QUEUED 	Indicates highest number the resource attained since the host was initialized of outstanding, unprocessed solicit information messages by LATACP.  >++ LAT$_ITM_CUR_SOL_QUEUED 	Indicates current number of outstanding, unprocessed solicit information messages on LATACP's queue.  >++ LAT$_ITM_MAX_SOL_QUEUED 	Indicates maximum number of outstanding, unprocessed solicit information messages allowed on LATACP's queue. If this limit is ever reached, subsequent solicit information messages are not delivered or processed by LATACP.   >++ LAT$_ITM_HI_AVAIL_SVCS 	Indicates highest number the resource attained since the host was initialized of number of available services in LATACP database. e >++ LAT$_ITM_CUR_AVAIL_SVCS 	Indicates count of currently available LAT services in LATACP database.  i >++ LAT$_ITM_MAX_AVAIL_SVCS 	Indicates maximum number of available services possible in LATACP database.   >++ LAT$_ITM_HI_REACH_NODES 	Indicates highest number the resource attained since the host was initialized of reachable nodes in LATACP database. ^ >++ LAT$_ITM_CUR_REACH_NODES 	Indicates current number of reachable nodes in LATACP database. \ >++ LAT$_ITM_MAX_REACH_NODES 	Indicates maximum number of nodes allowed in LATACP database.  >++ LAT$_ITM_HI_LCL_SVCS 	Indicates highest number the resource attained since the host was initialized of locally offered services.  O >++ LAT$_ITM_CUR_LCL_SVCS 	Indicates current count of locally offered service. 0Q >++ LAT$_ITM_MAX_LCL_SVCS 	Indicates maximum number of locally offered services.  [ >++ LAT$_ITM_DISCARDED_NODES 	Indicates number of discarded service announcement messages.  >++ LAT$_ITM_SERVICE_CLASSES 	Indicates returned service class bit mask for supported service classes on node. It is returned for both local and remote nodes. If service class 1 is enabled, then bit <1> is set in this mask. When bit setting equals 1, this indicates the corresponding service class for that bit is enabled. That is, when bit <3> equal 1, then service class 3 is enabled. f~ >LAT$_ITM_LARGE_BUFFERS 	Indicates in Boolean logic whether or not the LAT software is using large packet support by default.  >LAT$_ITM_ANNOUNCEMENTS 	Indicates in Boolean logic whether or not the LAT software is transmitting LAT service advertisement messages.  >    >  >  >- >- >     0 On Mon, 02 Jun 2003 20:39:03 -0400, Ken Robinson! <kenrbnsn@kis-hosting.com> wrote:c  I >I am doing some on-again/off-again consulting for a state agency in NJ. sG >They have been printing on a very old LXY12 printer attached to a VAX hG >3100-30 (VMS 7.1) via a MUX. They are now trying to print to the same >K >printer from a VAX 3100-85 (VMS 7.3) via a DecServer 700. The output from sG >the new machine looks like there is a buffer overflow happening. i.e. i" >garbaged lines, lost output, etc. >rK >Here is the output of a show terminal command from the machine that works:nD >Terminal: _TXA0:      Device_Type: LQP02         Owner: SYMBIONT_43@ >                                               Username: SYSTEM >-D >    Input:    9600     LFfill:  0      Width: 132      Parity: None2 >    Output:   9600     CRfill:  0      Page:   66 >F >Terminal Characteristics:G >    Interactive        Echo               No Typeahead       No EscapenA >    No Hostsync        TTsync             Lowercase          TabcI >    No Wrap            Hardcopy           No Remote          No EightbitVE >    No Broadcast       No Readsync        Form               FullduptG >    No Modem           No Local_echo      No Autobaud        No HangupoG >    No Brdcstmbx       No DMA             No Altypeahd       Set_speedrI >    No Commsync        No Line Editing    Overstrike editing No Fallback H >    No Dialup          No Secure server   No Disconnect      No PasthruM >    No Syspassword     No SIXEL Graphics  No Soft Characters No Printer PortsK >    Numeric Keypad     No ANSI_CRT        No Regis           No Block_mode.I >    No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2>K >    No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No Ansi_Color  >    VMS Style Input >I >Device spooled to _DKA200:n >t7 >Here is the show terminal output from the new machine:  >  >$ sho ter lta1000D >Terminal: _LTA1000:   Device_Type: LQP02         Owner: SYMBIONT_64@ >                                               Username: SYSTEM > D >    Input:    9600     LFfill:  0      Width: 132      Parity: None2 >    Output:   9600     CRfill:  0      Page:   66 >t >Terminal Characteristics:G >    Interactive        Echo               Type_ahead         No Escape-A >    No Hostsync        TTsync             Lowercase          TaboI >    No Wrap            Hardcopy           No Remote          No EightbitnE >    No Broadcast       No Readsync        Form               FulldupcG >    No Modem           No Local_echo      No Autobaud        No Hangup G >    No Brdcstmbx       No DMA             No Altypeahd       Set_speed I >    No Commsync        No Line Editing    Overstrike editing No Fallback H >    No Dialup          No Secure server   No Disconnect      No PasthruM >    No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port K >    Numeric Keypad     No ANSI_CRT        No Regis           No Block_modelI >    No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2aK >    No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No Ansi_Color- >    VMS Style Input >0 >Device spooled to _DKA300:a >@ >$ mc latcp sho port lta1000 >rL >Local Port Name:   _LTA1000:         Local Port Type:  Application (Queued) >Local Port State:  Inactive >Connected Link: > ; >  Target Port Name:     LQP02            Actual Port Name:s; >  Target Node Name:     BACK_OFFICE      Actual Node Name:u> >  Target Service Name:                   Actual Service Name: > 9 >And the DecServer Port Definition: (port 3, name: LQP02) ; >Port  3:                               Server: BACK_OFFICE  >sG >Character Size:            7           Input Speed:               9600gG >Flow Control:            XON           Output Speed:              9600eG >Parity:                 None           Modem Control:         Disabled- >Stop Bits:                 1u >3G >Access:               Remote           Local Switch:              NonecG >Backwards Switch:       None           Name:                     LQP02@G >Break:                 Local           Session Limit:                4oG >Forwards Switch:        None           Type:                      Hardn >Default Protocol:        ANYi >t >Preferred Service: None >k >Authorized Groups:   0d >(Current)  Groups:   0t >a >Enabled Characteristics:d3 >Input Flow Control,  Output Flow Control,  Queuinga >g >eL >We have already put a VT terminal in place of the printer which works fine J >in both cases, so that seems to rule out the DecServer or the cable from + >the Decserver to the printer as a problem.W >wG >Has anyone seen a problem like this? Or has anyone printed to a LXY12 t >printer via a DecServer?e >f >Thanks in advance.r >c
 >Ken Robinsonr >  >a  $ IT Services Engineering & Consulting   Adnutum technologies   yves-laurent.richard@wanadoo.frf   ------------------------------   Date: 03 Jun 2003 06:38:31 GMT) From: rankin@pactechdata.com (Pat Rankin),1 Subject: Re: Samba + Multinet: The Saga continues . Message-ID: <2JUN200323371957@pactechdata.com>  - In article <3JUN200300223084@gerg.tamu.edu>,\e,  carl@gerg.tamu.edu (Carl Perkins) writes... [...]SC > My SMBD service definition is the same as it has been for years, -B > predating the V2 line of Samba, so it is not clear if some of it' > is not needed. That said, I have the :% >       Socket Options = SO_KEEPALIVEf > set, and also have this: >       Flags = UCX_SERVERK > in my SMBD service defintion. I also have a Max Servers setting, but thatC) > should not be needed to get it working.b  H      We're not running Samba any more, but our old service configurationI has SO_KEEPALIVE too.  And if UCX_SERVER is omitted, MultiNet will ignoreq$ the `username = "anything"' setting.  2                 Pat Rankin, rankin@pactechdata.com   ------------------------------  * Date: Tue, 3 Jun 2003 15:58:58 +0000 (UTC)+ From: david20@alpha2.mdx.ac.uk (David Webb)yI Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)P+ Message-ID: <bbigk2$23d$1@aquila.mdx.ac.uk>N  j In article <Yv3Da.1816$UE.8@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes:= >"Mark Daniel" <Mark.Daniel@wasd.vsm.com.au> wrote in messaget) >news:3EDBE387.7000106@wasd.vsm.com.au...r >> >WL >XDM was provided by the TCPIP group completely independent of the X11/MotifL >project.  In fact, I was pleasantly suprised to find it when I went lookingK >for it about a year ago.  You can argue where it really belongs...  In anydK >case, no capabilities existed for years for *either* XDM or Magic-Cookie -aL >VMS had a DECnet focus.  TCPIP provided XDMCP and XDM.  Now Motif has addedL >Magic-Cookie.  I would anticipate that TCPIP will add the capability to XDMJ >at some point.  AFAIK there was never a "XDM project" - somebody in TCPIPL >decided that if they were doing XDMCP, it only made sense to have XDM - andC >ported it - there was no change made to DECwindows that I know of.  >e  J Well I for one was asking for XDM for years and years before "somebody in N TCPIP" decided to provide it. Whenever I tried to get someone at DEC in eitherL the TCPIP or DECWINDOWS groups to look at it they would profess ignorance ofL what it was and then that they would ask the other group to see whether theyL could implement it in the future since it was really a TCPIP/Xwindows (which# ever was the other group) facility.e  < XDM has always seemed to fall down the crack between groups.H So it isn't really that much of a suprise that updates which should have affected it have been missed.p    
 David Webb VMS and Unix team leader CCSS Middlesex University      L >> > The OpenVMS priority right now is focused on the delivery of OpenVMS onH >> > Itanium.  With the underlying Magic-Cookie support now available, I >imagineL >> > at some point XDM Magic-Cookie support will follow, your request to theL >> > TPCIP group should help make sure that it is on their future work list. >>K >> Would the provision of the XDM be more appropriately positioned with the K >> DECwindows group?  This is where the XFS resides, which is also a TCP/IPt >> based server. >> >SG >Who knows.  Possibly.  But not without some amount of pain - since therB >"DECwindows" group is actually outsourced support to a 3rd party. >e >>L >> Of course, this is preaching to the converted.  I am not wishing to dwellK >> on the bleeding obvious here (or unduly to sound like much of the banter  >insH >> this forum).  I just wish to emphasize that the much-needed update ofB >> DECwindows without any corresponding functionality changes in a >fundamentalI >> component of that X environment is a significant anomaly that would ben >bestq? >> receiving immediate attention (project management boundariese >notwithstanding). >> >FH >And we will take the input, and I'll do a check to see where things areK >heading.  The "DECwindows" folks are currently porting to IPF and planninglM >the port of XM to Version 2.1.  The TCPIP folks are among many other things,t >porting to IPF. >d >  >    ------------------------------  # Date: Tue, 03 Jun 2003 15:53:28 GMTt9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>oI Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)o. Message-ID: <Yv3Da.1816$UE.8@news.cpqcorp.net>  < "Mark Daniel" <Mark.Daniel@wasd.vsm.com.au> wrote in message( news:3EDBE387.7000106@wasd.vsm.com.au... > L > > The XDM implementation is not provided as part of Motif or the base OS -I > > instead it is a component of the TCPIP product.  So it is not that itl wasy7 > > "overlooked" - it wasn't part of the Motif project.t >tI > This beggars belief Fred.  It's a little like saying the TCP/IP producttL > included an XDM but it can't be used with DECwindows (yet) because the XDMJ > project did not include the provision of hooks into the Session Manager. >i  K XDM was provided by the TCPIP group completely independent of the X11/MotifaK project.  In fact, I was pleasantly suprised to find it when I went looking J for it about a year ago.  You can argue where it really belongs...  In anyJ case, no capabilities existed for years for *either* XDM or Magic-Cookie -K VMS had a DECnet focus.  TCPIP provided XDMCP and XDM.  Now Motif has addedlK Magic-Cookie.  I would anticipate that TCPIP will add the capability to XDMaI at some point.  AFAIK there was never a "XDM project" - somebody in TCPIPcK decided that if they were doing XDMCP, it only made sense to have XDM - and B ported it - there was no change made to DECwindows that I know of.  K > > The OpenVMS priority right now is focused on the delivery of OpenVMS onaG > > Itanium.  With the underlying Magic-Cookie support now available, Ie imaginemK > > at some point XDM Magic-Cookie support will follow, your request to theuK > > TPCIP group should help make sure that it is on their future work list.N > J > Would the provision of the XDM be more appropriately positioned with theJ > DECwindows group?  This is where the XFS resides, which is also a TCP/IP > based server.  >e  F Who knows.  Possibly.  But not without some amount of pain - since theA "DECwindows" group is actually outsourced support to a 3rd party.u   >nK > Of course, this is preaching to the converted.  I am not wishing to dwelleJ > on the bleeding obvious here (or unduly to sound like much of the banter inG > this forum).  I just wish to emphasize that the much-needed update ofdA > DECwindows without any corresponding functionality changes in aa fundamentalIH > component of that X environment is a significant anomaly that would be best> > receiving immediate attention (project management boundaries notwithstanding).s >f  G And we will take the input, and I'll do a check to see where things are J heading.  The "DECwindows" folks are currently porting to IPF and planningL the port of XM to Version 2.1.  The TCPIP folks are among many other things, porting to IPF.    ------------------------------  # Date: Tue, 03 Jun 2003 16:28:27 GMTm9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>lI Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)h0 Message-ID: <L04Da.1825$KB.804@news.cpqcorp.net>  I Yeah.  A historical accident.  The "XTerminal" group was actually part ofrF the *Terminals* group.  So all of the stuff to do non-VMS, non-DECnet,I X-Terminal-like things weren't done by the graphics/Motif folks - but wasiD done by people mostly doing *LAT* work!  So the font server, the LATK transport, etc *did* fall through the cracks for the most part - because itu1 wasn't originally part of the "DECwindows" group.n  G XDM falls through the same crack.  It wasn't in the original DECwindowsnG source, which is outsourced for maintenance.  The TCPIP folks were nicecI enough to do the work to port it when they did XDMCP.  And now that a newoE capability is available, it wasn't added because the group adding theoE capability is A) mostly unaware of it, and B) aren't being paid to doa anything to it.c    8 "David Webb" <david20@alpha2.mdx.ac.uk> wrote in message% news:bbigk2$23d$1@aquila.mdx.ac.uk...hB > In article <Yv3Da.1816$UE.8@news.cpqcorp.net>, "Fred Kleinsorge") <my-last-name@stardotzko.dec.com> writes:e? > >"Mark Daniel" <Mark.Daniel@wasd.vsm.com.au> wrote in messagef+ > >news:3EDBE387.7000106@wasd.vsm.com.au...r > >> > >rD > >XDM was provided by the TCPIP group completely independent of the	 X11/MotifiF > >project.  In fact, I was pleasantly suprised to find it when I went lookingeI > >for it about a year ago.  You can argue where it really belongs...  Inl anyq> > >case, no capabilities existed for years for *either* XDM or Magic-Cookie -H > >VMS had a DECnet focus.  TCPIP provided XDMCP and XDM.  Now Motif has addedlJ > >Magic-Cookie.  I would anticipate that TCPIP will add the capability to XDMCL > >at some point.  AFAIK there was never a "XDM project" - somebody in TCPIPJ > >decided that if they were doing XDMCP, it only made sense to have XDM - andrE > >ported it - there was no change made to DECwindows that I know of.n > >B >CK > Well I for one was asking for XDM for years and years before "somebody inEI > TCPIP" decided to provide it. Whenever I tried to get someone at DEC ina eitherK > the TCPIP or DECWINDOWS groups to look at it they would profess ignorancee ofI > what it was and then that they would ask the other group to see whether  theyG > could implement it in the future since it was really a TCPIP/Xwindowso (which% > ever was the other group) facility.I > > > XDM has always seemed to fall down the crack between groups.J > So it isn't really that much of a suprise that updates which should have > affected it have been missed.  >o >d > David Webb > VMS and Unix team leader > CCSS > Middlesex University >l >v >sK > >> > The OpenVMS priority right now is focused on the delivery of OpenVMSc onJ > >> > Itanium.  With the underlying Magic-Cookie support now available, I
 > >imagineJ > >> > at some point XDM Magic-Cookie support will follow, your request to the H > >> > TPCIP group should help make sure that it is on their future work list.  > >>I > >> Would the provision of the XDM be more appropriately positioned withr theaF > >> DECwindows group?  This is where the XFS resides, which is also a TCP/IP > >> based server. > >> > >iI > >Who knows.  Possibly.  But not without some amount of pain - since thesD > >"DECwindows" group is actually outsourced support to a 3rd party. > >n > >>H > >> Of course, this is preaching to the converted.  I am not wishing to dwellpF > >> on the bleeding obvious here (or unduly to sound like much of the banter > >incJ > >> this forum).  I just wish to emphasize that the much-needed update ofD > >> DECwindows without any corresponding functionality changes in a > >fundamentalK > >> component of that X environment is a significant anomaly that would be4 > >bestTA > >> receiving immediate attention (project management boundariesc > >notwithstanding). > >> > >fJ > >And we will take the input, and I'll do a check to see where things areD > >heading.  The "DECwindows" folks are currently porting to IPF and planningG > >the port of XM to Version 2.1.  The TCPIP folks are among many othern things,h > >porting to IPF. > >r > >l > >n   ------------------------------   Date: 3 Jun 2003 04:52:36 -0700T. From: mistdragon@zdnetonebox.com (mist dragon)& Subject: Some fiction for you to enjoy= Message-ID: <7500353b.0306030352.5459c8a0@posting.google.com>r  % A bit of history and fiction to you :e  E Itanium was created as a joint co-operation between HP and Intel with @ the intention of moving PA-RISC to mainstream. Therefore all theB customers they can get onto it, the better it is. At the beginningD there were many who jumped to train when they heard of this strategyD and markets seemed to merge this new common strategy. But porting toA Itanium was and is expensive as it is using more PA-RISC orientedr solutions than Intel-oriented.  F So one by one the new partners jumped off the train and only ones thatF remained were Linux64 and Windows64. From these two Linux is ported toD any platform just for the fun of it (including AMD64) and Windows isD ported for the money (I wonder what was the price of AMD64 port, butC cant be that much because IBM claimed it ported DB2 to it in 2 daysiF whatever that includes :). Hardware vendors for Itanium AFAIK are IBM,D HP, SGI (special 64-way server) and Intel itself (making OEM boxes).  E Then Compaq failed to complete its Digital aquisition and VMS port too@ Itanium was hastily put together because development people wereD afraid Compaq would dump Alpha and all its software in order to saveE money for its core business, PC's. At the time it seemed a sound plansC as others were also at the train and it would cheaper to support itTD than support the development of new CPU's and fabrication factories.C After this decision, EOL was planned and all relevant manufacturingAD facilities sold. What the people in Compaq did not realize that withE this decision went also the confidence to Compaq. It was Compaqs timer to fall.  E Itanium VMS and Tru64 plans ended to HP, the new owner and originatorSF of Itanium architecture. HP honed this plan, not because it liked VMS,B but because it could afford it and it thought it could convert newC users to its Itanium platform in order to gain more marketshare. ItE did not have to buy major manufacturing of Alpha, only few developersaA that were left to labs and porting. Patents of Alpha were sold tov" Intel so the investment was cheap.  E Toms Hardware is comparing Xeon with Opteron (AMD's 64 bit processor)S; : http://www6.tomshardware.com/cpu/20030422/opteron-01.htmlt  A The conclusion is roughly that Optoron (AMD64) production servers"F perform comparable or better to 32 bit Xeon (IA32). The rumour is thatF Intel is preparing Yamhill, a competitor to AMD64, that will be placed3 on market if AMD64 sales exceed 32 bit Intel sales.L  C Now, just for arguments sake, lets think what happends if this will F become reality and jump to future where AMD64 and new non-itanium IA64 compete.  E Intel rides with two horses: x86-IA64 and Itanium. The masses turn toeF x86-64 and since to most of common people one 64 bit is the same to asA the other, the 64 bit card is no better with Itanium and the onlyP@ thing that is left is the performance with its version of 64 bitB applications. AMD will take care of pushing the performance beyond Itanium.  F Relying on its size is the mistake Intel has done before: 386 was veryF poor at beginning to support 286. i860 never made it. Itanium emulatesF 32 bit poorly. Intel improved 386, abandoned i860 and now it is on theB edge of deciding of what to do with Itanium. Make no mistake - theE design is high-performance and it scales far beyond of _any_ RISC outnF there. The problem is that all the software need not only be ported to7 it, but also tuned according its low-level programming.   F In the face of competition, HP and Intel drop Itanium. Intel will copyA and improve the footage gained by AMD in order to stay on market.u  F With Itanium siking, VMS will sink because I doubt very much they willE do re-port to x86-IA64 because market is no longer the same. With its6) hw-platform gone it will end to junkyard.   B Of course this is just a fiction and not to be taken seriously. InC reality everyone will move to Itanium asap and VMS will be the only D viable choice to everyone in the world, people will throw out Linux, Windows and everything else.   Mist   ------------------------------   Date: 3 Jun 2003 08:24:14 -0700 " From: horn@shsu.edu (James T Horn)$ Subject: Syncing Directories via FTP= Message-ID: <843706dc.0306030724.18d0e280@posting.google.com>e  E We have a need to sync two directories on two servers. I've looked at C FTP_MIRROR but that only sync's the local with remote. I've found aa? Mirror utility written in Perl, but it is geared more for Unix.i  B Does anyone have something or modified something that will sync upC both directions and keep both remote and local with the same files?r   ------------------------------  $ Date: Tue, 3 Jun 2003 19:09:42 +0200+ From: "Hans Vlems" <hvlems.nieuw@zonnet.nl>a( Subject: Re: Syncing Directories via FTP5 Message-ID: <bbikom$96nt3$1@ID-143435.news.dfncis.de>N  1 "James T Horn" <horn@shsu.edu> schreef in berichta7 news:843706dc.0306030724.18d0e280@posting.google.com...NG > We have a need to sync two directories on two servers. I've looked atdE > FTP_MIRROR but that only sync's the local with remote. I've found anA > Mirror utility written in Perl, but it is geared more for Unix.N >ID > Does anyone have something or modified something that will sync upE > both directions and keep both remote and local with the same files?A  H Two cheap identical disks and volume shadowing? OK, you'd need a cluster license too.   ------------------------------   Date: 3 Jun 2003 05:28:18 -0700e. From: mistdragon@zdnetonebox.com (mist dragon) Subject: xxi= Message-ID: <7500353b.0306030428.5e8b884c@posting.google.com>i   xx   ------------------------------  * Date: Tue, 3 Jun 2003 06:01:15 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)S Subject: Re: [DCL] Is the max length of DCL lexical functions argument documented ?s$ Message-ID: <bbhdjb$8b5$1@online.de>  H In article <s_PCa.83132$_c6.706880@news.chello.at>, peter@langstoeger.at$ (Peter 'EPLAN' LANGSTOEGER) writes:   M > I just made a litte test and found that the max lengths of DCL entities area  J > Sadly the lexical functions do not include explainations of the possibleL > length, only the documentation of WRITE backs my assumptions for F$LENGTH. >  > Can anyone enlighten me ?m  ? IIRC, some DCL limits were extended in a recent version of VMS.l   ------------------------------   End of INFO-VAX 2003.306 ************************