1 INFO-VAX	Sat, 17 Dec 2005	Volume 2005 : Issue 701       Contents:C Re: Clustering (was:  Re: HP announces new Integrity Blade Servers) P OT - GETSYI (was:Re: PHONE error - Invalid specification of node or person. Try E Re: PHONE error - Invalid specification of node or person. Try again.   F ----------------------------------------------------------------------  # Date: Sat, 17 Dec 2005 14:44:19 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) L Subject: Re: Clustering (was:  Re: HP announces new Integrity Blade Servers)L Message-ID: <rdeininger-1712050944320001@user-uinj4in.dialup.mindspring.com>  5 In article <43A2DF12.36968A2C@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:    >Bill Gunshannon wrote: K >> if anything, would be the advantage of building a cluster of, let's say, F >> 2 multi-processor Vaxen like I currently have in the department andG >> a dozen or so VS3100's?  Could all the VS3100's run diskless getting A >> all their support from the HSJ served disks on the big boxes?   >  > > >Yes.  And you could have a single SYSUAF etc. satellite nodesF >(workstations) can still have their own batch queues, controlled fromF >the main central queue manager. So you could have user X submit a jobK >that ends up running on some worksattion while its owner is out for lunch.   I In many cases you'll get poor performance unless you provide a local disk G on each system.  You don't need to boot from the local disk, but having H local page (and swap) files greatly reduces network traffic.  Since manyJ vax workstations tend to be a bit short on memory, you can get significant4 paging and you don't want it all out on the network.  I The first VAXstation 4000-60 I worked with started life with only 8 MB of J memory and no local disk.  It was useless until we added some memory and a local disk.   G >These are concepts which were up and running in the 1980s and which HP 3 >is tryng to get running on Windows 20 years later.  >  > G >Also, any user could use any workstation. Each workstation has its own H >root in the boot servers and that root contain the workstation specificG >codes/parameters. But when you login through decwindows, you are given $ >your own personalised environment.  > F >This is stuff Windows can do, but it is quite a mess to manage due toG >the registry being distributed between workstation, central server and I >user, and it isn't clear where an application's keys will be stored when  >you install it. > @ >In terms of lan traffic, it depends on your users. you can haveB >pagefiles local to the workstation, and then it is only the image: >activations that really generate lan-based disk activity.  A When the VAX workstations were new, most networks were 10 Mb/sec, J thickwire (or sometimes thinwire coax), with hubs and repeaters.  Now it'sI cost-effective to put each system on it own network switch port, and some C VAX servers can get their own dedicated 100 Mb/sec switch port.  So G network traffic is less of a problem for "senior citizen" VAX clusters.   C (But you should still have a local disk on each system for paging.)     G >VMS clustering is really *WAY* ahead of windows in terms of supporting H >workgroup workstations. Remember that it supports up to 96 workstations% >in a cluster. Try that with windows.    True.     F >The problem is that the owners of VMS years ago have decided that VMSI >was not to flaunt its capabilities in such setups and nobody has had the L >guts to get the new owners to review those 10 year old decisions by palmer.  A Such things are reviewed fairly often.  The entire problem of VMS B visibility remains a point of contention, but clustering is ALWAYS$ front-and-center in VMS discussions.  H Satellites are less interesting than they were 10 years ago (in every OSC environment), because HW has gotten cheap enough to make standalone G systems affordable.  But the high cost of managing all those standalone H systems is becoming more and more visible.  Unix and Windows seem to endG up with layers of add-on tools (usually at additional cost) to simplify H management of many systems.  VMS has always been behind in add-on tools,F but they are much less necessary because clustering solves most of the management problems.   ------------------------------  % Date: Sat, 17 Dec 2005 09:11:38 -0500 % From: BRAD <bradhamilton@comcast.net> Y Subject: OT - GETSYI (was:Re: PHONE error - Invalid specification of node or person. Try  * Message-ID: <43A41C9A.9020706@comcast.net>   Richard Maher wrote: > Hi Larry,  >  > E >>Someone wondering the name of the local node should call SYS$GETSYI D >>to retrieve the SCSNODE parameter (whose contents will not include >>trailing colons).  >  > L > But, for SCSNODE names of less than 6 bytes, why does sys$getsyi decide toL > pad out the output buffer with nulls? It tells you that it's written say 5* > bytes but it's actually written all six. >  > Regards Richard Maher   D The manual seems to say that you can specify NODENAME, as well (I'm B _not_ a programmer).  Since F$GETSYI returns the following in DCL:  $ RABBIT::BRAD$ a=f$getsyi("nodename")# RABBIT::BRAD$ b=f$getsyi("scsnode")  RABBIT::BRAD$ sho symb a    A = "RABBIT"  RABBIT::BRAD$ sho symb b    B = "RABBIT  "   F is it safe to assume that NODENAME in SYS$GETSYI will return the node  name without padded blanks?  <snip>   ------------------------------  % Date: Sat, 17 Dec 2005 21:22:03 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> N Subject: Re: PHONE error - Invalid specification of node or person. Try again.1 Message-ID: <do13f8$qth$1@news-02.connect.com.au>   	 Hi Larry,   E > Someone wondering the name of the local node should call SYS$GETSYI D > to retrieve the SCSNODE parameter (whose contents will not include > trailing colons).   J But, for SCSNODE names of less than 6 bytes, why does sys$getsyi decide toJ pad out the output buffer with nulls? It tells you that it's written say 5( bytes but it's actually written all six.   Regards Richard Maher   : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:SPLf0sMxgpH3@eisner.encompasserve.org... F > In article <dnv85t$paj$6@online.de>, helbig@astro.multiCLOTHESvax.de2 (Phillip Helbig---remove CLOTHES to reply) writes:L > > In article <1134706222.495175.229830@g14g2000cwa.googlegroups.com>, "Bob% > > Armstrong" <bob@jfcl.com> writes:  > >  > >>   Ah, that's it - > >> > >> $sho log sys$node, > >>    "SYS$NODE" = "::" (LNM$SYSTEM_TABLE) > >>@ > >>   Next question - where is SYS$NODE supposed to be defined? > > I > > I think it is defined during DECnet startup.  When running DECwindows J > > without DECnet, I defined it by hand (in the startup) since DECwindowsL > > starts with "Welcome to <SYS$NODE>".  Of course, it could and should getJ > > the node name via other means; I guess this is a throwback to the daysF > > when EVERY VMS system ALWAYS had DECnet running, so one could just# > > assume the logical was defined.  > B > Without DECnet running, the string MYNODE:: has no significance,, > so the logical name should not be defined. > E > Someone wondering the name of the local node should call SYS$GETSYI D > to retrieve the SCSNODE parameter (whose contents will not include > trailing colons).    ------------------------------   End of INFO-VAX 2005.701 ************************