1 INFO-VAX	Sun, 22 Jun 2003	Volume 2003 : Issue 344       Contents:( Re: Decwindows: Fileview DCL window font% Re: DSSI disks and allocation classes ! DSSI disks and allocation classes % Re: DSSI disks and allocation classes % Re: DSSI disks and allocation classes % Re: DSSI disks and allocation classes % Re: DSSI disks and allocation classes % Re: DSSI disks and allocation classes % Re: DSSI disks and allocation classes # Re: EVA-5000 performance monitoring ! Re: OpenVMS (TM) VAX Version X7G7  OpenVMS (TM) VAX Version X7G7 ! Re: OpenVMS (TM) VAX Version X7G7   F ----------------------------------------------------------------------  % Date: Sun, 22 Jun 2003 12:35:06 +0200 + From: "Hans Vlems" <hvlems.nieuw@zonnet.nl> 1 Subject: Re: Decwindows: Fileview DCL window font 5 Message-ID: <bd40p1$ohh2c$1@ID-143435.news.dfncis.de>   3 "Lyle West" <arf@ourtownusa.org> schreef in bericht ( news:3EF40F1A.668A0BA1@ourtownusa.org... > Bob Marcan wrote:  > >  > > JF Mezei wrote: K > > > Goal: to select a smaller font for the dcl windows opened by fileview  (VAX). > > >  > (snip) > > 8 > > Have the same problem and like to know how to solve.9 > > All this xwindows stuff is so poor documented on VMS.  > >  > > Regards, Bob > > --G > Following is from cov article from Hoff years ago, which I can't find  > right 7 > now, I put it at DECW$USER_DEFAULTS:VUE$MASTER.DAT...  >  > VUE$MASTER*displayWidthInc: 8  > VUE$MASTER*displayWidth: 820  > VUE$MASTER*fontSetSelection: 1 > VUE$MASTER*condensedFont: on > VUE$MASTER*littleFontSetName: > > -dec-terminal-medium-r-normal--14-100-100-100-c-80-iso8859-1 >  > Note the last line wrapped.  >  > --   >  > Lyle W. West > E Thank you very much for this information. Is it documented in the VMS  manuals?   Hans   ------------------------------   Date: 22 Jun 03 11:39:26 +0200) From: p_sture@elias.decus.ch (Paul Sture) . Subject: Re: DSSI disks and allocation classes) Message-ID: <8hg8MrR4RlLw@elias.decus.ch>   w In article <bd3roa$edf$2@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: I > I've successfully installed VMS on a VAX 4000 100A I inherited.  There  I > is an internal RF35 disk called $1$DIA3.  It appears to have about 800  0 > MB.  I used this as the system disk (for now). > C > Apparently, this is a DSSI disk.  I have no experience with these J > beasts.  Show device/full shows that it has allocation class 1.  I want J > to put it in a cluster where there is already a machine with allocation I > class 1, thus I want to change the allocation class on the new machine.  > G > Is the allocation class used for DSSI disks the same as the "normal"  3 > allocation class (NOT the port allocation class)?  > J > The reason I ask is that otherwise there is no allocation class defined;B > the device shows up as $1$DIA3 automatically, even after a freshG > install.  Apparently, this is the default for DSSI disks whereas for  H > SCSI disks there is no default (or rather it is 0 and the NODE$ names  > are used). >   C It's been a long time since I used DSSI disks, but IIRC you have to ? connect to the controller and do it from there. Something like:   J $ mc sysman io conn fya0:/noad/driver=sys$loadable_images:SYS$FYDRIVER.EXE $ set proc/priv=diagnose: $ set host /dup /task=cli /server=mscp$dup controller_name  > Where controller_name can be seen from a SHOW CLUSTER display.   ------------------------------  + Date: Sun, 22 Jun 2003 09:09:30 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)* Subject: DSSI disks and allocation classes$ Message-ID: <bd3roa$edf$2@online.de>  G I've successfully installed VMS on a VAX 4000 100A I inherited.  There  G is an internal RF35 disk called $1$DIA3.  It appears to have about 800  . MB.  I used this as the system disk (for now).  A Apparently, this is a DSSI disk.  I have no experience with these H beasts.  Show device/full shows that it has allocation class 1.  I want H to put it in a cluster where there is already a machine with allocation G class 1, thus I want to change the allocation class on the new machine.   E Is the allocation class used for DSSI disks the same as the "normal"  1 allocation class (NOT the port allocation class)?   H The reason I ask is that otherwise there is no allocation class defined;@ the device shows up as $1$DIA3 automatically, even after a freshE install.  Apparently, this is the default for DSSI disks whereas for  F SCSI disks there is no default (or rather it is 0 and the NODE$ names 
 are used).   ------------------------------  % Date: Sun, 22 Jun 2003 11:47:19 +0200 $ From: Michael Unger <unger@decus.de>. Subject: Re: DSSI disks and allocation classes5 Message-ID: <bd3u3e$p98hm$2@ID-152801.news.dfncis.de>   E On 22-Jun-2003 11:09, Phillip Helbig---remove CLOTHES to reply wrote:   I > I've successfully installed VMS on a VAX 4000 100A I inherited.  There  I > is an internal RF35 disk called $1$DIA3.  It appears to have about 800  0 > MB.  I used this as the system disk (for now). > C > Apparently, this is a DSSI disk.  I have no experience with these J > beasts.  Show device/full shows that it has allocation class 1.  I want J > to put it in a cluster where there is already a machine with allocation I > class 1, thus I want to change the allocation class on the new machine.  > G > Is the allocation class used for DSSI disks the same as the "normal"  3 > allocation class (NOT the port allocation class)?  > J > The reason I ask is that otherwise there is no allocation class defined;B > the device shows up as $1$DIA3 automatically, even after a freshG > install.  Apparently, this is the default for DSSI disks whereas for  H > SCSI disks there is no default (or rather it is 0 and the NODE$ names  > are used). >   ' The DSSI allocation class is set either 3 - via a (plastic) plug pressing some micro-switches % - via jumpers on the controller board , - via NVRAM configuration (controller board)  / To set the allocation class using the NVRAM use  >>> SET HOST/DUP/DSSI ... G (sorry, I don't remember the full command syntax, but most VAXes have a " built-in HELP in the console code)   Michael    --    @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system. = And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)    ------------------------------  + Date: Sun, 22 Jun 2003 09:55:10 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: Re: DSSI disks and allocation classes$ Message-ID: <bd3udt$gqh$1@online.de>  F In article <8hg8MrR4RlLw@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:    I > > Is the allocation class used for DSSI disks the same as the "normal"  5 > > allocation class (NOT the port allocation class)?  > > L > > The reason I ask is that otherwise there is no allocation class defined;D > > the device shows up as $1$DIA3 automatically, even after a freshI > > install.  Apparently, this is the default for DSSI disks whereas for  J > > SCSI disks there is no default (or rather it is 0 and the NODE$ names  > > are used). > E > It's been a long time since I used DSSI disks, but IIRC you have to A > connect to the controller and do it from there. Something like:  > L > $ mc sysman io conn fya0:/noad/driver=sys$loadable_images:SYS$FYDRIVER.EXE > $ set proc/priv=diagnose< > $ set host /dup /task=cli /server=mscp$dup controller_name > @ > Where controller_name can be seen from a SHOW CLUSTER display.  B Interesting.  Even though I just did a fresh install of VMS, SHOW H CLUSTER does output something, including the controller name.  OK, so I   can try your command suggestion.  F Still, what is the relationship between this allocation class and the B regular allocation class, which one would normally change via the A cluster-configuration procedure or via MODPARAMS.DAT and AUTOGEN?    ------------------------------  % Date: Sun, 22 Jun 2003 12:29:18 +0200 + From: "Hans Vlems" <hvlems.nieuw@zonnet.nl> . Subject: Re: DSSI disks and allocation classes5 Message-ID: <bd40fn$ov70l$1@ID-143435.news.dfncis.de>   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bd3roa$edf$2@online.de... H > I've successfully installed VMS on a VAX 4000 100A I inherited.  ThereH > is an internal RF35 disk called $1$DIA3.  It appears to have about 8000 > MB.  I used this as the system disk (for now). > C > Apparently, this is a DSSI disk.  I have no experience with these I > beasts.  Show device/full shows that it has allocation class 1.  I want I > to put it in a cluster where there is already a machine with allocation I > class 1, thus I want to change the allocation class on the new machine.  > F > Is the allocation class used for DSSI disks the same as the "normal"3 > allocation class (NOT the port allocation class)?  > J > The reason I ask is that otherwise there is no allocation class defined;B > the device shows up as $1$DIA3 automatically, even after a freshF > install.  Apparently, this is the default for DSSI disks whereas forG > SCSI disks there is no default (or rather it is 0 and the NODE$ names  > are used). >  Phillip J a DSSI disk behaves like an RA disk with an HSC built in. But a fairly odd HSC.J You can connect to the DSSI disk with the (DCL) SET HOST/DUP command. It'sJ been too long to remember whether you need the FY driver, like you need toI connect to an HSC50. Anyway, you need a utility name that must run on the J DSSI disk. The parameter you're looking for is called ALLCLASS, almost the! same name as the VMS SYSGEN name. C The full command is: $ set host/dup/server=mscp$dup/task=<taskname>  <devicename>K Where <taskname>::=DIRECT and <devicename> is the label between parenthesis K that shows up behind $1$DIA3. That label is similar to an SCSNODE name in a  CI environment. J The DIRECT task runs a directory of available tasks on the DSSI disk. IIRCJ there's one called PARAMS. Use the SET HOST/DUP command with that taskname; and you have access to the parameter settings of that disk. F You can change ALLCLASS and the hostname as well as the device id. TheI plastic plugs that identify the DSSI disk are used by the console. If the K software id is set to 0 then the value of the plug is used in the VMS name; B if it is non zero then that value is used in the DIAn device name.K I hope this is enough to get you started (if this somewhat unordered memory " dump actually makes some sense...)   hans   ------------------------------  + Date: Sun, 22 Jun 2003 10:42:36 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: Re: DSSI disks and allocation classes$ Message-ID: <bd416s$j9c$1@online.de>  B In article <bd40fn$ov70l$1@ID-143435.news.dfncis.de>, "Hans Vlems"! <hvlems.nieuw@zonnet.nl> writes:    L > a DSSI disk behaves like an RA disk with an HSC built in. But a fairly odd > HSC.  8 OK, but I have no experience with RA or HSC either.  :-(  L > You can connect to the DSSI disk with the (DCL) SET HOST/DUP command. It'sL > been too long to remember whether you need the FY driver, like you need toK > connect to an HSC50. Anyway, you need a utility name that must run on the L > DSSI disk. The parameter you're looking for is called ALLCLASS, almost the# > same name as the VMS SYSGEN name. E > The full command is: $ set host/dup/server=mscp$dup/task=<taskname>  > <devicename>M > Where <taskname>::=DIRECT and <devicename> is the label between parenthesis M > that shows up behind $1$DIA3. That label is similar to an SCSNODE name in a  > CI environment. L > The DIRECT task runs a directory of available tasks on the DSSI disk. IIRCL > there's one called PARAMS. Use the SET HOST/DUP command with that taskname= > and you have access to the parameter settings of that disk. H > You can change ALLCLASS and the hostname as well as the device id. TheK > plastic plugs that identify the DSSI disk are used by the console. If the M > software id is set to 0 then the value of the plug is used in the VMS name; D > if it is non zero then that value is used in the DIAn device name.M > I hope this is enough to get you started (if this somewhat unordered memory $ > dump actually makes some sense...)  G Based on this and other responses, I think I can change the DSSI stuff. C What is still unclear is the relationship of this parameter to the  4 normal allocation class parameter used in a cluster.   ------------------------------  % Date: Sun, 22 Jun 2003 14:13:08 +0200 + From: "Hans Vlems" <hvlems.nieuw@zonnet.nl> . Subject: Re: DSSI disks and allocation classes5 Message-ID: <bd46go$ouurp$1@ID-143435.news.dfncis.de>   I > Based on this and other responses, I think I can change the DSSI stuff. D > What is still unclear is the relationship of this parameter to the6 > normal allocation class parameter used in a cluster. > I A DSSI disk is not really a local, directly attached device. The DSSI bus K may be a cousin of SCSI but behaves more like a CI bus. In a CI cluster you L need ALLOCLASS on VMS nodes and HSx nodes because the disk (or tape for thatJ matter) must  (1) have a unique name and (2) in case of dual hosting: must! have the same name on both nodes. L So under VMS you've got SYSGEN to set ALLOCLASS, on the HSC there is SETSHOWH to set ALLOCLASS and on the DSSI devices there is PARAM to set ALLCLASS.J Of course you know all this and think why bother since DSSI is dual hostedD anyway. IIRC there's a way to put three VMS systems in a shared DSSIK configuration. That allows possible conigurations where VMS based ALLOCLASS G wouldn't do. Hence the need for some intelligence on the DSSI tapes and 7 disks. And you ending up with this particular question. ( Or did I miss the point of the question?   Hans   ------------------------------  + Date: Sun, 22 Jun 2003 14:30:57 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) . Subject: Re: DSSI disks and allocation classes( Message-ID: <bd4ej1$lph$1@pcls4.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  D >What is still unclear is the relationship of this parameter to the 5 >normal allocation class parameter used in a cluster.   F It _is_ a normal allocation class.  As others have pointed out it actsK like an HSC with one disk.  A DSSI bus may be very similar to SCSI (SCSI-1) H but acts more like CI.  A few VMS nodes and several DSSI controllers canF be connected to a single DSSI bus and all the VMS nodes can access the DSSI drives directly via SCS.   I Since you are unfamiliar with CI/HSC configurations, think of things this F way, although this is not strictly correct.  Think of the HSC/HSJ/DSSIJ controllers as cluster members which do nothing but serve their disks (andG tapes, if any)  They have an alloclass like true cluster members do, as D well as a nodename (equivalent to SCSNODE).  Since the alloclass andI nodename belong to the DSSI controller and not to the VMS system, a fresh   VMS install doesn't change them. --   -Mike    ------------------------------    Date: 22 Jun 2003 06:11:13 -0700  From: kuff@tessco.com (Hal Kuff), Subject: Re: EVA-5000 performance monitoring= Message-ID: <6838ef26.0306220511.3baec48d@posting.google.com>   F Thanxs for the reply, in most cases you are correct.  Someone (I thinkC it was Ken Bates) once said that you could run a SuperComputer on a ; floppy drive if the I/O queue depth never exceeded '1' ....   C My curiosity was what the EVA is actually doing... apparently there D are no metrics available that show what the throughput is of a givenC unit at the EVA level.... We can measure from the applications side > the effect of all caches and buffers, that is to say that that6 production chain is very very efficient on OpenVMS....  C Unit hotspots measured from the OpenVMS side would be misleading as 0 the effect of the caches would skew the numbers.  E My interest extends to what the requirement would be for bandwidth to D run Continuous Availability on the EVA and looking at that bandwidthC what the demand from a given unit was....  Right now you're kind of E forced to say that the bandwidth between two EVA units in replication ; mode would be, say 80% the throughput of an HSV-110 pair...       f jlsue <jefflsxxxz@sbcglobal.net> wrote in message news:<udc4fv8eefug68lqaauk2au80msupa67kr@4ax.com>...I > On Wed, 18 Jun 2003 07:31:49 -0400, "Hal Kuff" <kuff@tessco.com> wrote:  > I > >    We'll look into that.... I think it does not show I./O at the unit N > >level... ie.e $1$Dga2130: .... I'm told that EMC has something that can get? > >stats from an HP SAN, but HP does not.... how could that be?  > >  > J > Wait a sec.... $1$DGA2130 is a host-level device unit.  If in a cluster,F > you could use a cluster-wide data collection tool that combines eachI > system's stats into a complete picture.  If not a cluster, then monitor : > disk/item=all would give you the I/O stats to that disk. > G > I often wonder what people really need to see on the I/O stats at the L > controller level.  Nobody ever asked for it for disks on DSSI controllers, > or SCSI controllers. > L > Instead, we managed performance by watching I/O queues on the devices and,J > when they were starting to grow on a consistent basis, then we'd addressM > the issue (actually, prior to that we'd be doing capacity planning).  Sure, G > I've run VDTPY on occasion on the HSC/Z/G, but it's never been a real L > integral part of my performance management and capacity planning (and I'veL > done a LOT of that over the years).  With these HS controllers, using SCSIM > technology, there is a relatively small number of spindles involved in each L > LUN, and performance can degrade very quickly - often exponentially - with > the workload.  > L > With EVA, performance will degrade for pretty much every system who's LUNsK > came from the same storage group.  But the upside is that the performance M > degrades much more gradually, and much more linearly with the workload (due ? > to the statistics involved in the larger number of spindles).  > K > If performance begins getting bad, adding 10 (or more) disks to the group L > is fairly simple, and soon you've alleviated all the I/O bottlenecks.  AndL > it's all transparent (operationally speaking) to the host servers that are0 > using the LUNs.  Performance just gets better. > C > That beats the hell out of manually moving files, or partitioning D > databases/tablespaces among lots of different LUNs to balance I/O. > I > I guess if I understood why someone felt the really needed a VTDPY-like J > tool (i.e., what problems do they need to solve with it), it might help.H > But to manage performance I've almost never actually needed that tool.   ------------------------------  # Date: Sun, 22 Jun 2003 07:06:54 GMT * From: "Mark Buda" <buda_NO@SPAM.yahoo.com>* Subject: Re: OpenVMS (TM) VAX Version X7G7= Message-ID: <iAcJa.14702$Jw6.6190527@news1.news.adelphia.net>   G That is an internal build ident that is used in VMS engineering.  It is D incremented each time a new build occurs.  Base 36 number (A-Z, 0-9)   --  
 Sincerely,	 Mark Buda     L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>/ wrote in message news:bd3gu5$640$1@online.de... G > Subject says it all: what is this strange version number?  It appears  > when booting the CD. > J > I borrowed a VAX CD to do a fresh install of VMS 7.3 on an old VAX in my$ > hobbyist cluster.  It IS a 7.3 CD: >  > $ DIR/EXC=*.DIR  > # > Directory DISK$VAXVMS073:[000000]  > J > BACKUP.SYS;1        BADBLK.SYS;1        BADLOG.SYS;1        BITMAP.SYS;1I > CONTIN.SYS;1        CORIMG.SYS;1        DECW073.C;1         DECW073.D;1 I > DECW073.E;1         DECW073.F;1         INDEXF.SYS;1        ISL_SCRIPT.  > ESS;1 H > SECURITY.SYS;1      VMS073.A;1          VMS073.B;1          VMS073.C;1J > VMS073.D;1          VMS073.E;1          VMS073.F;1          VOLSET.SYS;1 >  > Total of 20 files. >    ------------------------------  + Date: Sun, 22 Jun 2003 06:04:54 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)& Subject: OpenVMS (TM) VAX Version X7G7$ Message-ID: <bd3gu5$640$1@online.de>  F Subject says it all: what is this strange version number?  It appears  when booting the CD.  I I borrowed a VAX CD to do a fresh install of VMS 7.3 on an old VAX in my  " hobbyist cluster.  It IS a 7.3 CD:   $ DIR/EXC=*.DIR   ! Directory DISK$VAXVMS073:[000000]   H BACKUP.SYS;1        BADBLK.SYS;1        BADLOG.SYS;1        BITMAP.SYS;1G CONTIN.SYS;1        CORIMG.SYS;1        DECW073.C;1         DECW073.D;1 G DECW073.E;1         DECW073.F;1         INDEXF.SYS;1        ISL_SCRIPT.  ESS;1 F SECURITY.SYS;1      VMS073.A;1          VMS073.B;1          VMS073.C;1H VMS073.D;1          VMS073.E;1          VMS073.F;1          VOLSET.SYS;1   Total of 20 files.   ------------------------------  + Date: Sun, 22 Jun 2003 09:05:45 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)* Subject: Re: OpenVMS (TM) VAX Version X7G7$ Message-ID: <bd3rh9$edf$1@online.de>  C In article <iAcJa.14702$Jw6.6190527@news1.news.adelphia.net>, "Mark ' Buda" <buda_NO@SPAM.yahoo.com> writes:    I > That is an internal build ident that is used in VMS engineering.  It is F > incremented each time a new build occurs.  Base 36 number (A-Z, 0-9)  H So it's perfectly normal to see this version number when booting the CD?I (When booting the system after installation, all appears as normal, i.e.   Version 7.3 shows up.)   ------------------------------   End of INFO-VAX 2003.344 ************************