1 INFO-VAX	Wed, 04 Jun 2003	Volume 2003 : Issue 307       Contents: Re: accessing device registers Re: accessing device registers! Re: Alpha hardware shop in Europe ! Re: Alpha hardware shop in Europe , bad websites, and how to complain about them Re: CA CCC/Harvest and VMS CHANNELCNT=65532 ?= CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird! A Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird! A Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird! A Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird! P Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS  Clusters  SurvP Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS Clusters  SurveP Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS Clusters  Surve DCL_CHECK issues: Do you suppose any of these people ever heard of VMS? Nah.7 Re: Download service for VMS and Tru64 layered products 7 Re: Download service for VMS and Tru64 layered products % Foro Yahoo VMS de usuarios argentinos ) Re: Foro Yahoo VMS de usuarios argentinos ) Re: Foro Yahoo VMS de usuarios argentinos ) Re: Foro Yahoo VMS de usuarios argentinos % GKS manuals avail in Richmond Area...  Re: Install Directory  Re: Install Directory / Re: Intel 64 bit Pentium seems to be on its way " IO - VAXes, Alphas, XFC and V7.3-1& Re: IO - VAXes, Alphas, XFC and V7.3-1& Re: IO - VAXes, Alphas, XFC and V7.3-1. Re: IO - VAXes, Alphas, XFC and V7.3-1 (THUD!) Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500 Re: ISACFG on AlphaStation 500> New Alpha hobbyist DECC V6.5 IVF failure: "complex.h" missing. Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death ? Re: Printer recommendation, hobbyist/decwindows/mozilla and VMS ( 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) SNA-RJE  Re: SNA-RJE  Re: Syncing Directories via FTP  Re: Syncing Directories via FTP , Re: SYS$QIOW - Wtih more Details - Final Try, Re: SYS$QIOW - Wtih more Details - Final Try  Re: [OT] best HTML code cleaner?  Re: [OT] best HTML code cleaner?  F ----------------------------------------------------------------------   Date: 3 Jun 2003 13:11:17 -0500 B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)' Subject: Re: accessing device registers 3 Message-ID: <ffuU8Db+AXvn@eisner.encompasserve.org>   D In article <3edbf022.1431137@news.liii.com>, hoblit@liii.com writes:A > Thanks to Fred and Simon for your replies. I've been working on ? > a driver for a PCI card developed for data acquisition at the < > lab where I work. The card uses the PLX 9080 PCI interfaceB > chip, which is documented quite well and so far it actually does= > what manual describes. I started from the example driver in < > driver book and in sys$examples (lrdriver.c) and went from> > there. The card DMAs it's data to the alpha, and it's fast -, > in my DS10 (V7.2-2) I get roughly 115MB/s. >   G Yes, that's fast. In my driver, I was only capturing about 64,000 8-bit E samples every 40ms, but the application program had to do quite a bit F of signal processing on those samples. A 166MHz Alpha just about keeps up with the data stream.  F >> Depending on what you are wanting to do, myself and others may have >> other hints for you.  > D > Thanks to a VMS-expert friend, I now have a working driver. But ifL > you have hints I'd like to hear them, or if you have a piece of PCI driverI > code lying around it would be nice to see if I've overlooked something. , > Any/all comments, recommendations welcome. >   K As you are as far along as you are, I have no specific advice to offer you. J I thought that you may still be working your way through the driver manualG and LRDRIVER, and may like suggestions about choices made by others who G had actually written a driver, especially as not everything that I used F was documented in the driver manual, but only in the headers. Also VMSL Engineering don't give you an DMA driver in SYS$EXAMPLES, but only LRDRIVER.  G BTW, my code would need a serious tidying up before I would release it; G it works just fine, but was something of a testbed while I was learning I to write a VMS driver. This tidying up is not something which is going to   happen in the forseeable future.  E If you are interested, have a look in the Google comp.os.vms archives F with a search of "Simon Clubley device driver" (without the quotes) to- see some of the basic questions I was asking.   $ > thanks again for clearing this up, >    You are welcome.   Simon.   --  B Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       L VMS advocate: One who makes a Mac advocate look like a beginner at advocacy.   ------------------------------  # Date: Wed, 04 Jun 2003 01:26:43 GMT  From: hoblit@liii.com ' Subject: Re: accessing device registers , Message-ID: <3edd4808.2768300@news.liii.com>  ? >> there. The card DMAs it's data to the alpha, and it's fast - - >> in my DS10 (V7.2-2) I get roughly 115MB/s.  >>   > H >Yes, that's fast. In my driver, I was only capturing about 64,000 8-bitF >samples every 40ms, but the application program had to do quite a bitG >of signal processing on those samples. A 166MHz Alpha just about keeps  >up with the data stream.   D This was a test just slamming the driver with $qio's to see how fastG it could DMA it's data into the alpha.  When I intregate this card into H the daq I'll have to do some processing and send the data off somewhere,I like disk or ethernet. If it's a SCSI disk, that will involve most likely E use the PCI bus again, so throughput would go down. But our real data K rates won't go this high; this was just a test to see what the card can do.   L >As you are as far along as you are, I have no specific advice to offer you.K >I thought that you may still be working your way through the driver manual H >and LRDRIVER, and may like suggestions about choices made by others whoH >had actually written a driver, especially as not everything that I usedG >was documented in the driver manual, but only in the headers. Also VMS M >Engineering don't give you an DMA driver in SYS$EXAMPLES, but only LRDRIVER.   D Yeah, at least one example driver using DMA would be nice. LRDRIVER,P nice as it is, is not the best starting point for a DMA driver. It also uses theD CRAM method of device i/o, which prompted my question. I also reliedD on rooting through the header files to figure out what was going on.  H >BTW, my code would need a serious tidying up before I would release it;H >it works just fine, but was something of a testbed while I was learningJ >to write a VMS driver. This tidying up is not something which is going to! >happen in the forseeable future.   L My driver is not pretty either, but at the moment it works. I'll clean it upJ a bit when I get closer to using it in production. I'll take a look in the, archives for the questions from your driver.   thanks, 
 Sam Hoblit hoblit@liii.com    ------------------------------  % Date: Tue, 03 Jun 2003 20:21:22 +0200 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>* Subject: Re: Alpha hardware shop in Europe) Message-ID: <3EDCE722.2030900@vajhoej.dk>   
 Woland wrote: 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.   It is not that bad.   9 And they may be cheaper than even with delivery included.    Arne   ------------------------------   Date: 3 Jun 03 23:31:07 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) * Subject: Re: Alpha hardware shop in Europe) Message-ID: <eIqNnhZk1nRl@elias.decus.ch>   m In article <20030602211051.17871.qmail@gacracker.org>, Doc.Cypher <Use-Author-Address-Header@[127.1]> writes:    <snip>  K > Quite.  I got used to ordering CDs from the US.  Never picked up for VAT, P > customs, or duty - even when getting 20 CDs at a time.  That was in .uk.  HereN > in .be, you order one CD and you get an invitation to pay import duty at theL > post office before they'll let you have your CD.  The very thought of whatO > they might ask you to pay to release something like an AlphaServer would give  > you nightmares.  >    Just arrived by email today:  D "It used to be only death and taxes were inevitable. Now, of course,$ there's shipping and handling, too."   --  
 Paul Sture   ------------------------------   Date: 3 Jun 03 23:44:53 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) 5 Subject: bad websites, and how to complain about them ) Message-ID: <YE32e7dTS9S7@elias.decus.ch>   ) Bad websites, that we all complain about:   G I today happened on a website which says all I have wanted to say about E rotten websites. This person also encourages you to copy it, and even F change the links, because the ISP is not trusted to remain in business  @ Please try http://members.optusnet.com.au/~night.owl/morons.html   please enjoy...    --  
 Paul Sture   ------------------------------  * Date: Tue, 3 Jun 2003 14:51:19 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: Re: CA CCC/Harvest and VMS ? Message-ID: <20030603215119.9852.qmail@web20202.mail.yahoo.com>   . I worked with CCC/Harvest but not with OVMS ! 1 The repository was an Oracle Database under HP-UX . and the programs developed (PowerBuilder) and , versioned were banking automation binaries !3 It worked fine - CA have some good products to help 3 in production when well deployed - I liked CA PPC ! - But I think CA changed the product name from  ; CCC/Harvest to another thing. Check  at the site www.ca.com      Regards    FC8 --- "davidm@hollard.co.za" <davidm@hollard.co.za> wrote:G > 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     =====  ========================== Fbio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.br ==========================  " __________________________________ Do you Yahoo!?@ Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com    ------------------------------   Date: 03 Jun 2003 21:08:49 GMT( From: ka2doug@cs.commoc.sc (DL Phillips) Subject: CHANNELCNT=65532 ? > Message-ID: <20030603170849.01703.00000900@mb-m05.news.cs.com>  '    AlphaServer DS10/466, OpenVMS V7.1-2 !    PATHWORKS V6.1 Advanced Server    SYSMAN> param show channelcnt ( Node XXXXXX:   Parameters in use: ACTIVED Parameter Name   Current   Default   Minimum   Maximum Unit  DynamicD --------------   -------   -------   -------   ------- ----  -------D CHANNELCNT         65532       256        31     65535 Channels      !!!     Well, that's strange. !!!  SYSMAN> param use current  SYSMAN> param show channelcnt ) Node XXXXXX:   Parameters in use: CURRENT D Parameter Name   Current   Default   Minimum   Maximum Unit  DynamicD --------------   -------   -------   -------   ------- ----  -------D CHANNELCNT          1368       256        31     65535 Channels       & $write sys$output f$getsyi("boottime") 29-MAY-2003 19:39:01.00    $set def sys$system 5 $dir/date/before=29-MAY-2003:19:39 *params.dat/vers=1   , MODPARAMS.DAT;29     23-MAR-2003 23:22:23.24, PARAMS.DAT;19        28-MAY-2003 16:39:46.29, SETPARAMS.DAT;20     28-MAY-2003 16:39:55.49  B $search modparams.dat;29,params.dat;19,setparams.dat;20 channelcnt ******************************$ SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT;29  G MIN_CHANNELCNT = 1368   ! PATHWORKS V6 for OpenVMS 23-MAR-2003 23:22:23    ******************************! SYS$SYSROOT:[SYSEXE]PARAMS.DAT;19   E MIN_CHANNELCNT = 1368 ! PATHWORKS V6 FOR OPENVMS 23-MAR-2003 23:22:23    ******************************$ SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;20   set CHANNELCNT 1368  $  !!! '     Okay, so why is ACTIVE at Max when: #       1) CHANNELCNT is NOT dynamic. 2       2) CHANNELCNT was set to 1368 by the AUTOGEN  	   just prior to the last boot.7       3) CHANNELCNT should have an ACTIVE value of 1368   >     Further investigation uncovered a possible reason for the :     65532 value's existence, but not for it's persistence. !!! . $search *params.dat;* channelcnt,65532/mat=and   ******************************# SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT;7   G MIN_CHANNELCNT = 65532  ! PATHWORKS V5 for OpenVMS 18-APR-2000 10:13:35    ******************************! SYS$SYSROOT:[SYSEXE]PARAMS.DAT;15   F MIN_CHANNELCNT = 65532 ! PATHWORKS V5 FOR OPENVMS 18-APR-2000 10:13:35   ******************************$ SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;15   set CHANNELCNT 65532 $  !!! 6     So, way back when, PATHWORKS set MIN_~ to 65532. I9     don't know and I don't really care now why it did so. 6     It is possible that the ACTIVE value has been such<     since then even though it has gone though many autogens 9     and reboots with smaller, more normal values. I just       haven't notice it before.   9     But why doesn't the SET command in SETPARAMS actually      set the requested value?  <     Searching on-line OpenVMS documentation at HP yields the     typical response. !         (*) openvms documentation          search: CHANNELCNT.         No results were found for your search.  9     Searching the Wizard and Googling c.o.v. yields quite =     a lot of discussion about the relationship of channelcnt  =     to various products but nothing I could find relevant to  <     this condition. The doc's I have in-hand just define the>     parameter (misleadingly) and mention its consideration in ?     tuning a backup account. These things I already understand.   8     There should Possibly be something in a release note8     and/or an ECO about this CHANNELCNT phenomenon but I8     can't find it. Anyone have any insight they wish to 
     share?  6     I'm hoping that a MODPARAMS MAX_CHANNELCNT = 1368,7     autogen and reboot will work, but I can't try that       until the weekend.  /     FWIW, This is a very lightly loaded system:  !!!  $show users 7       OpenVMS User Processes at  3-JUN-2003 10:17:23.53 9     Total number of users = 20,  number of processes = 21      ...    $ show mem/phys/slots   F Physical Memory Usage (pages):  Total     Free      In Use    ModifiedF   Main Memory (384.00Mb)        49152    33391       13614        2147  F Slot Usage (slots):             Total     Free    Resident     SwappedF   Process Entry Slots             200      150          50           0F   Balance Set Slots               198      150          48           0  E Of the physical pages in use, 4763 pages are permanently allocated...  $  !!!         DL Phillips   7     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 8     There's a fuzzy line between interesting and weird. 7     I find that interesting, but maybe it's just weird. 7     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!    ------------------------------  % Date: Tue, 03 Jun 2003 13:54:55 -0500 ( From: brandon@dalsemi.com (John Brandon)F Subject: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird!1 Message-ID: <03060313545537@dscis6-0.dalsemi.com>   . I have a command file that does the following:   $ loop:  $ define sys$output john.out $ MANMAN   SY U 199 E  $ deassign sys$output  $! $ open rdfl john.out /read $ read rdfl data $ close rdfl $!) $ open updfl john.dat /read /write /share  $ write updfl data
 $ close updfl  $ wait 00:02:00  $ goto loop      $ dirs john.out;  4 JOHN.OUT;1         3/18       3-JUN-2003 11:30:00.09  L Here is the weird part.  The first pass, the output file john.out is createdJ according to the CLUSTER_SIZE of 18 blocks.  However subsequent passes theM output file john.out is created according to one of the values set in the FDL  used to create john.dat $         ALLOCATION              1000$         EXTENSION               1000$         ALLOCATION              1000$         EXTENSION               1000   $ dirs john.dat;  4 JOHN.DAT;       1008/1008     3-JUN-2003 10:04:09.07   $ dirs john.out 4 JOHN.OUT;          3/18       3-JUN-2003 11:30:00.094 JOHN.OUT;          3/1008     3-JUN-2003 11:32:00.794 JOHN.OUT;          3/1008     3-JUN-2003 11:34:00.314 JOHN.OUT;          3/1008     3-JUN-2003 11:36:00.894 JOHN.OUT;          3/1008     3-JUN-2003 11:38:00.144 JOHN.OUT;          3/1008     3-JUN-2003 11:40:00.094 JOHN.OUT;          3/1008     3-JUN-2003 11:42:00.564 JOHN.OUT;          3/1008     3-JUN-2003 11:44:00.754 JOHN.OUT;          3/1008     3-JUN-2003 11:46:00.45    O Am I missing something here?  It is like the buffer for file creation as set by K CLUSTER_SIZE has been overridden by the values in the FDL of the OPEN/CLOSE  file.    Help?        John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Tue, 03 Jun 2003 22:21:37 +0200 " From: labadie <labadie_g@decus.fr>J Subject: Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird!3 Message-ID: <bbj07g$ei3$1@news-reader12.wanadoo.fr>    John Brandon wrote: 0 > I have a command file that does the following: > 	 > $ loop:  > $ define sys$output john.out
 > $ MANMAN > 
 > SY U 199 > E  > $ deassign sys$output  > $! > $ open rdfl john.out /read > $ read rdfl data > $ close rdfl > $!+ > $ open updfl john.dat /read /write /share  > $ write updfl data > $ close updfl  > $ wait 00:02:00 
 > $ goto loop  >  >  > $ dirs john.out; > 6 > JOHN.OUT;1         3/18       3-JUN-2003 11:30:00.09 > N > Here is the weird part.  The first pass, the output file john.out is createdL > according to the CLUSTER_SIZE of 18 blocks.  However subsequent passes theO > output file john.out is created according to one of the values set in the FDL  > used to create john.dat & >         ALLOCATION              1000& >         EXTENSION               1000& >         ALLOCATION              1000& >         EXTENSION               1000 >  Hello   > May be you are with Vms 7.3 and you do not have the Dcl Patch.  ) The release notes say, among other things ) PROBLEMS ADDRESSED IN VMS73_DCL-V0300 KIT       @       o  A file created by DCL will erroneously inherit the fileE          extension quantity value from a previously opened file.  For           example:               $ DIR/FULL LOGIN.COM                       .                      .                        .;            File attributes:    Allocation: 18, Extend: 5000   6            ** Note that LOGIN.COM has DEQ  set to 5000  +            $ OPEN/READ/SHARE FILE LOGIN.COM             $ CLOSE FILE             $            $ @tt/out=out.txt#            _$ put something in file 5            %DCL-W-IVVERB, unrecognized command verb - ,            check validity and spelling \PUT\            _$  Exit             $            $ DIR/FULL OUT.TXT   #            Directory $2$DKB0:[TEST]   =            OUT.TXT;1                     File ID:  (8282,1,0) ;            Size:            1/5004       Owner:    [SYSTEM] .            Created:    21-AUG-2002 10:35:50.402            Revised:    21-AUG-2002 10:35:57.94 (1)>            File attributes:    Allocation: 5004, Extend: 5000,5                                Global buffer count: 0 #            Client attributes:  None *            Total of 1 file, 1/5004 blocks.    *            Images Affected:[SYSEXE]DCL.EXE   Regards    Grard   ------------------------------  % Date: Tue, 03 Jun 2003 16:31:01 -0500 ( From: brandon@dalsemi.com (John Brandon)J Subject: Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird!1 Message-ID: <03060316310134@dscis6-0.dalsemi.com>    Thanks lababie_g for the info!   The VMS V7.3 ECO kit:   @       o  A file created by DCL will erroneously inherit the fileE          extension quantity value from a previously opened file.  For           example:   K Is not found in the V7.2-1 ECO kit.  However the problem description of the N V7.3 fits the problem I am having on V7.2-1.  So... I guess I need to have theA updated VMS721_DCL-V0400 kit - which does not exists.  Oh bother!        John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Tue, 03 Jun 2003 16:06:39 -0500 ( From: brandon@dalsemi.com (John Brandon)J Subject: Re: CLUSTER_SIZE being overriden by OPEN/CLOSE statement - weird!1 Message-ID: <03060316063919@dscis6-0.dalsemi.com>   + > The release notes say, among other things + > PROBLEMS ADDRESSED IN VMS73_DCL-V0300 KIT    I am running V7.2-1   - I have that patch kit installed on my server:   P VMS721_DCL-V0300.RELEASE_NOTES;1              26/36      20-FEB-2002 10:31:13.31    ' And yes the systems have been rebooted.        John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  # Date: Wed, 04 Jun 2003 02:03:49 GMT 2 From: "Kenneth Farmer" <kfarmer@NOSPAMopenvms.org>Y Subject: Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS  Clusters  Surv = Message-ID: <9scDa.21594$nr.1807651@twister.southeast.rr.com>   G Done.  I just put in the description and a link to the file on your web G site.  Nice and simple...as long as you keep the web server up that is.    -- Kenneth Farmer <>< http://www.OpenVMS.org http://dcl.OpenVMS.org      < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3EDD5499.2905E0BD@fsi.net...  > Kenneth Farmer wrote:  > > I > > I'm working on that and it's taking time...frustrating.  I've tried a  coupleI > > times so far without success.  Will keep trying sporadically and will  > > announce when done.  > > L > > Will have to do it manually for now.  Just fill out description and sendC > > .zip to me directly (kfarmer@openvms.u_know ), I will drop in a 	 directory G > > and put url at end of description of procedure.  They can then just  click onF > > .zip file.  I have to approve the submissions anyway so I can just attach > > then. [snip] > J > It's currently available at http://www.djesys.com/freeware/vms/ Look for > hbyspl010.zip  >  > --   > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 03 Jun 2003 21:08:25 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> Y Subject: Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS Clusters  Surve ' Message-ID: <3EDD5499.2905E0BD@fsi.net>    Kenneth Farmer wrote:  > N > I'm working on that and it's taking time...frustrating.  I've tried a coupleG > times so far without success.  Will keep trying sporadically and will  > announce when done.  > J > Will have to do it manually for now.  Just fill out description and sendK > .zip to me directly (kfarmer@openvms.u_know ), I will drop in a directory N > and put url at end of description of procedure.  They can then just click onK > .zip file.  I have to approve the submissions anyway so I can just attach  > then. [snip]  H It's currently available at http://www.djesys.com/freeware/vms/ Look for
 hbyspl010.zip    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 03 Jun 2003 21:31:03 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> Y Subject: Re: dcl.openvms.org (was Re: OpenVMS.org: Mixed Architecture VMS Clusters  Surve ' Message-ID: <3EDD59E7.512E5C80@fsi.net>    Kenneth Farmer wrote:  > I > Done.  I just put in the description and a link to the file on your web I > site.  Nice and simple...as long as you keep the web server up that is.    Hosted by http://www.dls.net/    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 03 Jun 2003 18:22:51 -0400 * From: "Stanley F. Quayle" <stan@stanq.com> Subject: DCL_CHECK issues . Message-ID: <3EDCE77B.27488.F6F133E@localhost>  A I couldn't find Charlie Hammond's email address, so hopefully he   reads these posts...   ----  B This is the most useful tool.  I've found dozens of errors in the  scripts I use.  Thanks!   C I have noticed three problems in V2.1 of DCL_CHECK.  An input file   of:    	$ TYPE SYS$INPUT: 	       test! 	$ RUN/DETACH/ERR=XYZ.TMP XYZ.EXE 0 	$ IF F$SEARCH ("XYZ.TXT", 1) .EQS. "" THEN EXIT   Gives the following errors:   (     2  LND  line does not start with "$"%     3  LNF  label "XYZ.TMP" not found .     4  WCT  wrong constant type for comparison  E I've seen the "TYPE SYS$INPUT:" contruct in a lot of scripts, and it  E copies the following text to SYS$OUTPUT.  Each line of text gives an   error in DCL_CHECK.   B The RUN command's /ERROR switch expects a file name, not a label, 6 which is different from virtually every other command.  @ The stream ID parameter isn't used much with F$SEARCH, but it's " absolutely essential sometimes....  6 Any chance of getting these fixed in a future version?  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------  # Date: Tue, 03 Jun 2003 20:08:25 GMT # From: "John Smith" <a@nonymous.com> C Subject: Do you suppose any of these people ever heard of VMS? Nah. I Message-ID: <Ze7Da.122929$cK1.71085@news01.bloor.is.net.cable.rogers.com>   F http://story.news.yahoo.com/news?tmpl=story&ncid=1208&e=1&u=/nf/200306 03/tc_nf/21652&sid=95573658   5 Superhero Server Takes War on Hackers to Mythic Level  Mike Martin, sci.NewsFactor.com   B Hackers who dare penetrate the virus-immune and hacker-proof HydraE could find themselves up against a many-headed beast with a bodacious = attitude. Hydra is a server unlike any other, says its maker.   C It is "the first hack proof Web-services appliance which can defend C against such an attack and will never crash," Bodacion Technologies A chief software architect Eric Uner told NewsFactor. "The server's @ combination of complex mathematics and embedded systems makes it impervious."     Wizards of OS?F Audacious as the company's claims are, "it's possible what they say isC correct," commented Steve Chapin, associate professor of electrical 8 engineering and computer science at Syracuse University.  @ The Hydra operating system (OS) is composed of a small real-timeE nano-kernel, TCP/IP networking stack, Web server, FTP server and file > system designed by former Motorola (NYSE: MOT - news) software engineers Uner and Eric Hauk.   F Hydra's kernel is loaded from flash memory rather than disk, accordingF to company specifications. Each time Hydra loads the kernel, it checksD for viruses, then constantly scans the kernel in RAM for any viruses or unauthorized changes.  : "Hydra's embedded kernel is one aspect that makes Hydra soB revolutionary," Bodacion's documentation claims. "Hydra constantly> checks its small kernel for corruption, making Hydra immune to	 viruses."   C Designed from scratch, the Hydra OS is not based on a Linux (news - " web sites), BSD or Windows kernel.  C "These days, it's almost blasphemous to say anything negative about ? Linux," Uner said. "While we at Bodacion Technologies are Linux C advocates, it is clear that Linux has too weak a security model and E too high of a maintenance requirement to trust critical Internet data F and services to. The same can be said of Windows, BSD [and] commercial versions of Unix."     From ChaOS to OSF Bodacion's Hydra server uses biomorphic mathematics -- a derivative ofC Chaos Theory used to model the random growth of living things -- to D generate series of pattern-less numbers that cannot be deciphered byB hackers, even if they possess the basic mathematical formula, UnerE told NewsFactor. No two Hydra users ever receive the same session ID, D customer ID, order ID, or any other digital identification. Nor willD any hacker be able to discern a pattern and predict the next number, Uner added.   B Last year, more than 200,000 hackers tried to crash and invade theB Hydra super-server during the "Bodacion Challenge," but no one wasE able to collect the US$100,000 prize offered for a successful attack.   E Exploitation challenges, however, "prove nothing," said Steve Chapin, F who also directs the Syracuse University Center for Systems Assurance.E "Such challenges are only useful for PR. The best (most evil) hackers D aren't going to give away their tricks for a prize; they're going to' save them for making real money later."      Hesitant To Embrace Hydra E Also ignoring the PR push in favor of hard data -- security-conscious 
 Uncle Sam.  D "Several U.S. government entities -- including NASA, the FAA and theD National Security Agency -- have put Hydra through preliminary testsD and are considering it for adoption," wrote Accenture's Denise Fillo2 in a February 2003 TechWatch analysis of Bodacion.  C Clearly, for Bodacion's claims to hold up, the company will have to A produce "much further evidence," Chapin told NewsFactor. "I'm not > saying Hydra isn't what she claims to be; I'm saying that as a+ scientist -- for me, the jury's still out."    -----------------------   , One of the sidebar links at the URL above is/ http://www.newsfactor.com/perl/story/21212.html . "Inside the World of Secure Operating Systems"  E Of course the vast PR machine is inaction once again. (no typo there)   B A sane person might think that publicizing an o/s that, relativelyB speaking, has been unhackable for a quarter century might be worthF spending the time and effort to let every press hack know about. AfterF all, at a minimum it only takes a few sheets of paper, and envelope, a  stamp, and a mailing list to do.  @ So what does that make people who don't publicize that operating system? Or their bosses?  B Perhaps they're all just trapped in a maze of twisty passages, all alike, and can't get out?   7 What other plausible explanations can you come up with?   C I notice in the article above that the NSA is explicitly mentioned. B Surely one can't mention a public Agency in an article or that theD named Agency is looking at a specific product that has a name from aD specific vendor....As a result of this I'm positive that somebody is> going to be put up against a wall and shot, or at least have a hangnail - one or the other.   ------------------------------  % Date: Tue, 03 Jun 2003 22:36:04 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>@ Subject: Re: Download service for VMS and Tru64 layered products) Message-ID: <3EDD5B0E.429B98D6@istop.com>    Sean O'Banion wrote: > E > Unfortunately, it only downloads to Windoze: NTLM authentication is  > required.   L What is NTLM ? Did Microsoft mess with the FTP protocol ? I can't understandM why HP would use non-compliant proprietarty microsoft protocols for anything. C But I am not surprised. HP is a subsidiary of Microsoft, after all.    ------------------------------  % Date: Wed, 04 Jun 2003 00:25:03 -0500 ( From: Michael Rice <marice@whiteice.com>@ Subject: Re: Download service for VMS and Tru64 layered products/ Message-ID: <vdr0m0n0n9fj2c@corp.supernews.com>   $ On 6/3/2003 9:36 PM, JF Mezei wrote: > Sean O'Banion wrote: > E >>Unfortunately, it only downloads to Windoze: NTLM authentication is  >>required.  >  > N > What is NTLM ? Did Microsoft mess with the FTP protocol ? I can't understandO > why HP would use non-compliant proprietarty microsoft protocols for anything. E > But I am not surprised. HP is a subsidiary of Microsoft, after all.   = NTLM (NT LanMan) is a challenge/response algorithm for doing  H connection/user authentication.  The Microsoft IIS Web server (which is E probably what the afformentioned download server is running) can use  ' this method for validating user logins.   H In a nutshell it works like this, the server side generates a token for G the client to hash, the client hashes it using the user's password and nH sends back the hashed data, and the server compares that to it's hashed G data (using what it thinks is the user's password).  If the two match,   the user is authenticated.  E Unfortunately, I think the hashing requires the Microsoft Crypto API aF libraries.  Which probably means you can only connect to the download B server using a Windows client.  Obviously the preferred, and more  common, approach is to use SSL.I   ------------------------------   Date: 3 Jun 2003 11:25:40 -0700E( From: userdecar@yahoo.com.ar (UserDECAr). Subject: Foro Yahoo VMS de usuarios argentinos< Message-ID: <60063a4.0306031025.1037ee3c@posting.google.com>  ; Se encuentra activo el forio de usuarios argentinos de DEC. < Para acceder al mismo, hagalo a travez del siguiente enlace:    + http://ar.groups.yahoo.com/group/userdecar/o     Hasta la vista!!!!!!!    ------------------------------  % Date: Tue, 03 Jun 2003 21:16:38 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o2 Subject: Re: Foro Yahoo VMS de usuarios argentinos' Message-ID: <3EDD5686.159C857E@fsi.net>e   UserDECAr wrote: > = > Se encuentra activo el forio de usuarios argentinos de DEC.K> > Para acceder al mismo, hagalo a travez del siguiente enlace: > - > http://ar.groups.yahoo.com/group/userdecar/s >  > Hasta la vista!!!!!!!s  E Are we now going to see DIVX data posted to this newsgroup as well as-/ the other VMS newsgroups (especially vmsnet.*)?l   -- F David J. Dachtera) dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  # Date: Wed, 04 Jun 2003 02:19:34 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")2 Subject: Re: Foro Yahoo VMS de usuarios argentinos6 Message-ID: <00A20D8D.879D3340@SSRL.SLAC.STANFORD.EDU>  [ In article <3EDD5686.159C857E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:e >UserDECAr wrote:a >>  > >> Se encuentra activo el forio de usuarios argentinos de DEC.? >> Para acceder al mismo, hagalo a travez del siguiente enlace:P >> D. >> http://ar.groups.yahoo.com/group/userdecar/ >>   >> Hasta la vista!!!!!!! >:F >Are we now going to see DIVX data posted to this newsgroup as well as0 >the other VMS newsgroups (especially vmsnet.*)?  J Dude, just cause it's in Spanish doesn't mean it's off-topic.  The guy has9 set up a yahoo group for Argentine users of DEC products.L  =  Lista de discusion para usuarios Digital (DEC) de Argentina.-  Alpha, VAX, PDP11, etc.   -- Alan-   -- -O ===============================================================================c0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025sO ===============================================================================c   ------------------------------  $ Date: Tue, 3 Jun 2003 23:06:13 -05002 From: "Stuart Johnson" <ssj152 AT charter DOT net>2 Subject: Re: Foro Yahoo VMS de usuarios argentinos/ Message-ID: <vdqs2mfih20g06@corp.supernews.com>r  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>A wrote in message news:00A20D8D.879D3340@SSRL.SLAC.STANFORD.EDU... = > In article <3EDD5686.159C857E@fsi.net>, "David J. Dachtera"n <djesys.nospam@fsi.net> writes:a > >UserDECAr wrote:a > >>@ > >> Se encuentra activo el forio de usuarios argentinos de DEC.A > >> Para acceder al mismo, hagalo a travez del siguiente enlace:s > >>0 > >> http://ar.groups.yahoo.com/group/userdecar/ > >> > >> Hasta la vista!!!!!!! > > H > >Are we now going to see DIVX data posted to this newsgroup as well as2 > >the other VMS newsgroups (especially vmsnet.*)? >kL > Dude, just cause it's in Spanish doesn't mean it's off-topic.  The guy has; > set up a yahoo group for Argentine users of DEC products.  >m? >  Lista de discusion para usuarios Digital (DEC) de Argentina.y >  Alpha, VAX, PDP11, etc. >c	 > -- Alany >  > -- u >   K Not off-topic? Last time I looked this was an English-speaking newsgroup. I G have nothing against speaking another language or a different language,w# especially where it IS appropriate.e  K I don't think it would have been a burden for the original poster of such aeL self-serving (follow me to OUR newsgroup...) and off-topic (unless you speakF Spanish) post to have made the header in the language of the newsgroupJ (English), perhaps explaining what he was doing - for the benefit of those, readers not speaking his language (Spanish).  K DIVX - Oh I HOPE NOT!!! I truly despise what happened to VMSNET. I wish the 6 groups had been removed before being abused like that.   Stuart Johnson   ------------------------------  % Date: Tue, 03 Jun 2003 14:52:53 -0400 ! From: Jim Agnew <jpagnew@vcu.edu>s. Subject: GKS manuals avail in Richmond Area...' Message-ID: <3EDCEE85.2681C041@vcu.edu>   F Subject says it all. I have GKS manuals going to the dump in Richmond, Virginia area...  	 Jim Agnewo  D full set, Fortran, C, bindings, i forget what version..  if you care% ask, and i'll trouble myself to look.    jim    -- lF "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------  % Date: Tue, 03 Jun 2003 22:03:42 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Install Directory) Message-ID: <3EDD537B.7AF2DAAC@istop.com>u   Hoff Hoffman wrote:sH >   The usual installation target for layered product startup proceduresK >   is in SYS$STARTUP:, and when operating with your own tools in a clusterdG >   environment, you will usually want to specify this directory as theeJ >   cluster-common directory SYS$COMMON:[SYS$STARTUP].  For management andF >   related tasks and for startups on older products, use SYS$MANAGER:  K Who am I to disagree woith the all-mighty Hoff ?  But I do disagree on thislM one.  While I have no problem with VMS using the above nomemclature, and some K of the system integrated products using it,  I take issue with this being a ( blanket statement for all applications.   7 Have you seen what TCPIP Services does to sys$manager ?a  G Also, there is a big advantage for 3rd party applications to have theirmM startup procedure in tyheir own directory. When it is invoked, that procedurerN can find its own directory and then define the logicals pointing to it. If youF have a startup file in sys$startup, it has no way of knowing where its software is located.   ------------------------------  % Date: Tue, 03 Jun 2003 22:46:46 -0400o* From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Install Directory( Message-ID: <3EDD5D8F.656AA7B@istop.com>   "David J. Dachtera" wrote:E > As I understand it, yes and no. I was given (by Hoff, I believe) torF > understand that because VMSINSTAL lacks a consistent way of checkingF > versions installed, prior versions, recording files installed, etc., > PCSI was dreamed up.  L Why not modify VMSinstall to support the product database so that vmsinstallG can check what has and hasn't been installed, and have VMS install also = generate the list of files to be deleted during an uninstall.c  H Product Install, when I looked at it, did have nice features compared toK VMSinstal. But the showstopper for me was the lack of ability to prompt the-K user for questions (config, location etc) as well as lack of flexibility ofSM target directory.  It seems to have been designed for VMS integrated productsi that all go to the system disk.0   ------------------------------   Date: 3 Jun 2003 13:33:37 -0700s From: k9jdk@arrl.net (Dave)d8 Subject: Re: Intel 64 bit Pentium seems to be on its way= Message-ID: <bafb6477.0306031233.6fcc1af3@posting.google.com>E  F Good to hear from you Steve.  Hope things keep lookin' good from where you're sitting.    Dave...-  k Steve Lionel <Steve.Lionel@intel.com> wrote in message news:<2a9pdvcgavnvou6cg3efgg76vhhe5bmdtk@4ax.com>...cH > 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 thet' > >> job and buy the software side too?s > > D > >Intel has butchered and dropped every piece of software they everD > >bought. I can think of about a dozen software companies Intel hasH > >purchased over the past 10 years....I don't think any of the productsD > >those companies offered lasted more than 12-18 months after Intel > >bought them.y > I > Intel *DID* buy (some of) the software side too - at least a lot of theaM > compiler team, including myself.  This was part of the Alpha deal, but mostIN > people fixated on the hardware side at the time. We're working together withP > our HP friends to develop industry-leading compilers and tools for Itanium VMSN > (and IA-32/Itanium Windows and Linux, with somewhat less involvement of HP.)L > This is the traditional DEC compiler team and things are looking good from > where I sit. > L > 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/t >  > Steve Lionel > Software Products DevelopmentS > Intel Corporatione   ------------------------------   Date: 3 Jun 2003 15:12:55 -0500o+ From: young_r@encompasserve.org (Rob Young)a+ Subject: IO - VAXes, Alphas, XFC and V7.3-1 3 Message-ID: <28JH0nLZRZ5D@eisner.encompasserve.org>i  G         Part of the business case for going to Alpha was IO saturation. E         For a presentation, I showed the current VAXes were laboring,oA         pointing out the per-CPU IO capability for a high-end VAXrA         was somewhere around 300-400 IOPS, dredging up other infor8         showing the Alpha CPUs would do 7000 IOPS or so.  =         So shorly after upgrading the Alphas, a blurb showingh@         what we were seeing was in order (nice to know what yourI         money bought).  Part of the summary included before and after IO .L         statistics.  I don't claim any of the below to be exhaustive, but I B         do claim there is a very good case here for my conclusion.  B         First a snippet of VAX performance, what is seen below was         typical.  -                                  on node VAXN 4                              26-SEP-2000 09:37:01.23  P I/O Operation Rate                         CUR        AVE        MIN        MAX   M DSAa00:                SITE_VO1           4.23      91.0        0.00   251.33=L DSAb00:                SITE_VO2           5.33     131.0        0.00   256.0L DSAc00:                SITE_VO3           2.75      63.6        0.00   200.0L DSAd00:                SITE_VO4          95.37     167.4        0.00   526.0 (1)o    G         To show immediate improvements, running over similar timeframes.G         after coming over to newer storage and Alphas at VMS 7.2-1, the.A         following being typical.  Keep in mind, this snapshot wasnE         during the day and short.  That is why the averages are high.e  .                                  on node ALPH14                              17-OCT-2001 11:40:41.47  O I/O Operation Rate                         CUR        AVE        MIN        MAX   O DSAa00:                SITE_VO1          23.00      24.29       0.00    1016.33wO DSAb00:                SITE_VO2         361.66     327.33       0.00    4526.99tO DSAc00:                SITE_VO3          36.66     181.70       0.00    3788.33 O DSAd00:                SITE_VO4           3.66      25.64       0.00    1835.00     C         Immediate and obvious is we were able to pump some nice MAX0P         IO numbers.  Those are controller cache hit peaks as the shadows may be L         hitting 4 or 6 disks.  Obviously impossible to get 4500 IOPS out of          6 disks.  D         A recent upgrade to OpenVMS 7.3-1 with XFC turned on reveals.         these numbers, using the same storage:  .                                  on node ALPH13                              3-JUN-2003 06:24:09.12   P I/O Operation Rate                         CUR        AVE        MIN        MAX   O DSAa00:                SITE_VO1           0.00      12.69       0.00   24402.33VO DSAb00:                SITE_VO2           5.33      20.87       0.00   18156.66EO DSAc00:                SITE_VO3           0.00      31.55       0.00   10544.33aO DSAd00:                SITE_VO4          35.66      49.89       0.00   21399.006    L         My conclusion?  XFC is good stuff.  VMS 7.3-1 is good stuff.  There O         is/are investigation to be performed.  When are those peaks occuring?  oN         The much lower average IO numbers are there as this is over 24 hours. .         Isn't it neat to see 24000 for a peak?  B         What I would like to see is a nice tool to take XFC outputE         and gather up some stats.  Meaning, look at XFC IO rates over3D         a timeframe and summarizing for a spreadsheet.  I suppose itD         could be done in DCL, but would be nice to have a C program.  #                                 Rob*  ; (1)  Combing two volumes , database was across two volumes.    ------------------------------  % Date: Tue, 03 Jun 2003 22:26:10 +0200 " From: labadie <labadie_g@decus.fr>/ Subject: Re: IO - VAXes, Alphas, XFC and V7.3-1v3 Message-ID: <bbj0g2$ei3$2@news-reader12.wanadoo.fr>    Rob Young wrote:I >         Part of the business case for going to Alpha was IO saturation.eG >         For a presentation, I showed the current VAXes were laboring,SC >         pointing out the per-CPU IO capability for a high-end VAXnC >         was somewhere around 300-400 IOPS, dredging up other info*: >         showing the Alpha CPUs would do 7000 IOPS or so. > ? >         So shorly after upgrading the Alphas, a blurb showingaB >         what we were seeing was in order (nice to know what yourK >         money bought).  Part of the summary included before and after IO dN >         statistics.  I don't claim any of the below to be exhaustive, but I D >         do claim there is a very good case here for my conclusion. > D >         First a snippet of VAX performance, what is seen below was >         typical. > / >                                  on node VAXNC6 >                              26-SEP-2000 09:37:01.23 > R > I/O Operation Rate                         CUR        AVE        MIN        MAX  > O > DSAa00:                SITE_VO1           4.23      91.0        0.00   251.33eN > DSAb00:                SITE_VO2           5.33     131.0        0.00   256.0N > DSAc00:                SITE_VO3           2.75      63.6        0.00   200.0N > DSAd00:                SITE_VO4          95.37     167.4        0.00   526.0 > (1)m >  > I >         To show immediate improvements, running over similar timeframes)I >         after coming over to newer storage and Alphas at VMS 7.2-1, the C >         following being typical.  Keep in mind, this snapshot was G >         during the day and short.  That is why the averages are high.  > 0 >                                  on node ALPH16 >                              17-OCT-2001 11:40:41.47 > Q > I/O Operation Rate                         CUR        AVE        MIN        MAX! > Q > DSAa00:                SITE_VO1          23.00      24.29       0.00    1016.33 Q > DSAb00:                SITE_VO2         361.66     327.33       0.00    4526.99!Q > DSAc00:                SITE_VO3          36.66     181.70       0.00    3788.33 Q > DSAd00:                SITE_VO4           3.66      25.64       0.00    1835.00i >  > E >         Immediate and obvious is we were able to pump some nice MAXeR >         IO numbers.  Those are controller cache hit peaks as the shadows may be N >         hitting 4 or 6 disks.  Obviously impossible to get 4500 IOPS out of  >         6 disks. > F >         A recent upgrade to OpenVMS 7.3-1 with XFC turned on reveals0 >         these numbers, using the same storage: > 0 >                                  on node ALPH15 >                              3-JUN-2003 06:24:09.12  > R > I/O Operation Rate                         CUR        AVE        MIN        MAX  > Q > DSAa00:                SITE_VO1           0.00      12.69       0.00   24402.33eQ > DSAb00:                SITE_VO2           5.33      20.87       0.00   18156.66 Q > DSAc00:                SITE_VO3           0.00      31.55       0.00   10544.33IQ > DSAd00:                SITE_VO4          35.66      49.89       0.00   21399.00O >  > N >         My conclusion?  XFC is good stuff.  VMS 7.3-1 is good stuff.  There Q >         is/are investigation to be performed.  When are those peaks occuring?  2P >         The much lower average IO numbers are there as this is over 24 hours. 0 >         Isn't it neat to see 24000 for a peak? > D >         What I would like to see is a nice tool to take XFC outputG >         and gather up some stats.  Meaning, look at XFC IO rates overOF >         a timeframe and summarizing for a spreadsheet.  I suppose itF >         could be done in DCL, but would be nice to have a C program.   Helloe  * You have many stats with the SDA extension	 $ ana/syse xfcr   Regardsh   Grard   ------------------------------   Date: 3 Jun 2003 15:52:44 -0500M+ From: young_r@encompasserve.org (Rob Young)r/ Subject: Re: IO - VAXes, Alphas, XFC and V7.3-1-3 Message-ID: <topjtmW5hx8W@eisner.encompasserve.org>2  X In article <bbj0g2$ei3$2@news-reader12.wanadoo.fr>, labadie <labadie_g@decus.fr> writes:   >> EE >>         What I would like to see is a nice tool to take XFC outputaH >>         and gather up some stats.  Meaning, look at XFC IO rates overG >>         a timeframe and summarizing for a spreadsheet.  I suppose it G >>         could be done in DCL, but would be nice to have a C program./ >  > Hellod > , > You have many stats with the SDA extension > $ ana/sys  > xfc/ >   9 	I know.  Now I want them summarized nicely and ready for ? 	import into Excel.  A tool that is configurable would be best!    				Rob    ------------------------------  % Date: Tue, 03 Jun 2003 16:18:32 -0500t( From: brandon@dalsemi.com (John Brandon)7 Subject: Re: IO - VAXes, Alphas, XFC and V7.3-1 (THUD!)n1 Message-ID: <03060316183221@dscis6-0.dalsemi.com>o  5 (THUD) was the sound of my jaw dropping to the floor.a  
 I can't wait!    John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  # Date: Tue, 03 Jun 2003 18:04:36 GMTa" From:   VAXman-  @SendSpamHere.ORG' Subject: Re: ISACFG on AlphaStation 500a0 Message-ID: <00A20D61.8AA4F76C@SendSpamHere.ORG>  \ In article <vdpnd3asm9es8c@corp.supernews.com>, BoylesA <alan.boyles@mindspring.com> writes: >Fred Kleinsorge wrote:r: >> "BoylesA" <alan.boyles@mindspring.com> wrote in message, >> news:vdpja2d75f2vee@corp.supernews.com... >>  K >>>There is a device now called AUA0 and it is assigned to MMOV$server, butt >>  > >> when I invoke DECsound I get an invalid channel assignment. >> a, >>>  Is there a config routine for DECsound? >>>F >> O >> OO >> I would imagine so.  But I don't have the documentation.  Look for something 1 >> in sys$manager (or sys$startup) with "MMOV*.*"E >> n >> n >> c[ >Interestingly enough I can now run the IVP and it seems to work fine though no sound comes e >out.  When I try to do the same exact command at the DCL prompt the MMOV$SERVER process dies and the  >command fails.l >D >Any ideas?  >  >Alan  >z   What "same exact command"? --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             25   "Well my son, life is like a beanstalk, isn't it?" t   ------------------------------  % Date: Tue, 03 Jun 2003 15:08:44 -0400t* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 500./ Message-ID: <vdpsr6m7lek4ea@corp.supernews.com>    VAXman- wrote:^ > In article <vdpnd3asm9es8c@corp.supernews.com>, BoylesA <alan.boyles@mindspring.com> writes: >  >>Fred Kleinsorge wrote: >>: >>>"BoylesA" <alan.boyles@mindspring.com> wrote in message, >>>news:vdpja2d75f2vee@corp.supernews.com... >>>i >>> L >>>>There is a device now called AUA0 and it is assigned to MMOV$server, but >>>a> >>>when I invoke DECsound I get an invalid channel assignment. >>>t >>>a, >>>> Is there a config routine for DECsound? >>>> >>>e >>> O >>>I would imagine so.  But I don't have the documentation.  Look for something31 >>>in sys$manager (or sys$startup) with "MMOV*.*"u >>>  >>>t >>>e >>\ >>Interestingly enough I can now run the IVP and it seems to work fine though no sound comesf >>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 >> >  >  > What "same exact command"? > --Q > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMe
 >            07 >   "Well my son, life is like a beanstalk, isn't it?" a > r I just did a type of the sys$test:mmov$ivp com file and choose the first audioplay command and entered it by hand.u In another screen I do a show ssys and the mmov$server process seems to work fine, however, when I issue an audioplay l (or any other mmov command ) the mmov$server process dies, but there are no messages in the mmov error logs.   Alan   ------------------------------  % Date: Tue, 03 Jun 2003 15:23:16 -04000* From: BoylesA <alan.boyles@mindspring.com>' Subject: Re: ISACFG on AlphaStation 500:/ Message-ID: <vdptmd703scm01@corp.supernews.com>A   Fred Kleinsorge wrote:9 > "BoylesA" <alan.boyles@mindspring.com> wrote in messages+ > news:vdpja2d75f2vee@corp.supernews.com...p > 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?D >> >  > N > I would imagine so.  But I don't have the documentation.  Look for something0 > in sys$manager (or sys$startup) with "MMOV*.*" >  > 9 > I have found the log file and am getting the following:e  ; %CMA-F-EXCCOP, exception raised; VMS condition code followslP -SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000& 0004, PC=000000007BCF9F18, PS=0000001B  Q The help/message states that this is an exception from the POSIX Threads library.   5 EXCCOP,  exception raised; VMS condition code followsa  >    Facility:     CMA, Compaq POSIX Threads Library for OpenVMS  L    Explanation:  An exception has been raised by the EXC_HANDLING.H package,K                  which provides portable exceptions for the C language. The J                  accompanying OpenVMS condition code identifies the error.  L    User Action:  See the documentation for the software that your program isL                  calling to determine the reason for this exception. Correct#                  the problem or useo  K It's been a while but isn't the reason mask a read error?  Any suggestions?e   Thanks,l   Alan   ------------------------------  # Date: Tue, 03 Jun 2003 20:32:08 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>i' Subject: Re: ISACFG on AlphaStation 500w1 Message-ID: <cB7Da.1844$G_.1677@news.cpqcorp.net>w  * Check for logical names, or perhaps privs?  7 "BoylesA" <alan.boyles@mindspring.com> wrote in messagee) news:vdptmd703scm01@corp.supernews.com...u > Fred Kleinsorge wrote:; > > "BoylesA" <alan.boyles@mindspring.com> wrote in message - > > news:vdpja2d75f2vee@corp.supernews.com...a > > L > >>There is a device now called AUA0 and it is assigned to MMOV$server, but > >t? > > when I invoke DECsound I get an invalid channel assignment.s > >.- > >>  Is there a config routine for DECsound?m > >> > >w > >eF > > I would imagine so.  But I don't have the documentation.  Look for	 somethingo2 > > in sys$manager (or sys$startup) with "MMOV*.*" > >  > >2; > > I have found the log file and am getting the following:n > = > %CMA-F-EXCCOP, exception raised; VMS condition code followsi= > -SYSTEM-F-ACCVIO, access violation, reason mask=00, virtuali address=000000000000( > 0004, PC=000000007BCF9F18, PS=0000001B >sJ > The help/message states that this is an exception from the POSIX Threads library. >e7 > EXCCOP,  exception raised; VMS condition code followss >t@ >    Facility:     CMA, Compaq POSIX Threads Library for OpenVMS >oE >    Explanation:  An exception has been raised by the EXC_HANDLING.Hm package,I >                  which provides portable exceptions for the C language.  The L >                  accompanying OpenVMS condition code identifies the error. >DK >    User Action:  See the documentation for the software that your programr isF >                  calling to determine the reason for this exception. Correct % >                  the problem or usec >t@ > It's been a while but isn't the reason mask a read error?  Any suggestions? > 	 > Thanks,  >  > Alan >$   ------------------------------  * Date: Tue, 3 Jun 2003 17:59:05 -0500 (CDT) From: sms@antinode.orgG Subject: New Alpha hobbyist DECC V6.5 IVF failure: "complex.h" missing.h) Message-ID: <03060317590506@antinode.org>   D    I was just doing a general update to the new hobbyist level on myB AlpSta 200 4/233, when I got an IVF failure after installing the C= compiler V6.5.  Apparently, a test compile failed because thenG "complex.h" header file was not found.  (The transcript is lost now.  Ia* did not ask to preserve the old compiler.)  &    All the "reference" header files in: SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] were still oldG (12-FEB-2002), and while SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB had today'seB date, the files in it were all old (11-JAN-2002), and there was no "COMPLEX" module.   >    I moved the old the old DECC$RTLDEF.TLB out of the way, andG re-installed the compiler.  The IVP passed.  Now the "reference" headerh@ files are new, and there's a "COMPLEX" module in the (new) .TLB.  @    However, the dates on the .TLB modules are 11-JAN-2002, whichE pre-date the "old" ones ("12-FEB-2002").  Could a previous patch havee5 confused the installation procedure as to what's old?a  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode.orgM    Saint Paul  MN  55105-2547a   ------------------------------  * Date: Tue, 3 Jun 2003 20:16:31 +0000 (UTC)= From: jlw@psulias.psu.edu (j.lance wilkinson, (814) 865-1818)u" Subject: Re: Portents of VMS death. Message-ID: <bbivmv$10d4$1@f04n12.cac.psu.edu>  b In article <20030603080855.4c039167.mathog@caltech.edu>, David Mathog <mathog@caltech.edu> writes:   	...  G >replaced.  (Hands up, who in a university has bought a NEW VMS machineoC >for work in the last 6 months?)  Why would a lab buy a VMS machinev   	...  C 	Not in the last 6 months, but would my GS160 in the last 12 monthslD 	count?  Tru64 (v5.1, soon to be "clustered" w/ a GS140 and a GS120)G 	AND VMS (on installation, clustered w/ an infoserver and an 8440, but tC 	those have been finally retired) in the same box.  Don't like the eE 	console, but it's what we need for a 3rd-party Application (Dymaxion D 	Medianet) as well as our Email support (Process PMDF).  Lots of new< 	Apache-based applications on it now, since CSWS came along.  P +----"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+B | J.Lance Wilkinson ("Lance")		InterNet:  Lance.Wilkinson@psu.edu < | Systems Design Specialist - Lead	AT&T:      (814) 865-18189 | Digital Library Technologies		FAX:       (814) 863-3560o2 | 3 Paterno Library				"I'd rather be dancing..." B | Penn State University		    A host is a host from coast to coast,K | University Park, PA 16802	    And no one will talk to a host that's closeiC | <postmaster@psulias.psu.edu>	    Unless the host that isn't close : | EMail Professional since 1978	    Is busy, hung or dead.P +---------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+9                 [apologies to DeForest Kelley, 1920-1999] 3 <A Href="http://perdita.lcs.psu.edu">home page</a> tJ <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a> --	/"\ 	\ /	ASCII RIBBON CAMPAIGN 	 X	AGAINST HTML MAILs 	/ \   ------------------------------   Date: 3 JUN 2003 21:16:42 GMTo4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)" Subject: Re: Portents of VMS death5 Message-ID: <3JUN03.21164299@thuria.waisman.wisc.edu>s  ? In a previous article, David Mathog <mathog@caltech.edu> wrote:y  A ->Kicking?  Kicking the bucket maybe.  Things may be different inoA ->the corporate data center but good luck finding VMS machines in C ->academia these days.  I'm not saying there aren't any, I'm sayingyB ->that the remaining machines are those few that have not yet beenH ->replaced.  (Hands up, who in a university has bought a NEW VMS machine# ->for work in the last 6 months?)  a  H I've just put in an order for an ES47 running VMS. It's going to replaceC an Alphaserver 1200 and be clustered with an ES40 we purchased lasto year.m  A I do feel as though I'm the only up to date VMS site left on this E campus. I have recently learned of several local businesses that alsoyC run VMS which I plan on using to counter the "VMS is antiquated andT5 dying" comments that I've heard recently around here.   G We also have just installed an EVA due to the fact that we have VMS. Ift? VMS wasn't in the picture, our heterogeneous SAN solution wouldyF definitely NOT have come from HP. I involved HP in the SAN discussions only because we have VMS.'   --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madisonf8 --                 karcher.nomorespam@waisman.wisc.edu     ------------------------------  % Date: Tue, 03 Jun 2003 20:56:10 -0500g1 From: "David J. Dachtera" <djesys.nospam@fsi.net> " Subject: Re: Portents of VMS death' Message-ID: <3EDD51BA.A1F614DC@fsi.net>    Rob Young wrote: > ] > In article <3EDC0475.38ED89F7@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:f >  > >pD > > A mentor of mine once said, "Until you know value, everything is > > worthless".e > >  > P > "A cynic is a man who knows the price of everything and the value of nothing."! >                        -- Wildei  ; I would counter that there is a profound difference betweenaF understanding value and cynicism. Understanding that difference is key+ to survival in business as well as in life.s   -- . David J. Dachteraa dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Tue, 03 Jun 2003 21:34:41 -0400e* From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: Portents of VMS death) Message-ID: <3EDD4CB0.D43DC5B0@istop.com>n   jlsue wrote:B > And it's not that is "isn't what VMS is for", it's that it is anM > unsupported configuration (potentially).  I still say that putting Dev/testIK > in a cluster (security domain) with production would get you hit big-timeaD > with the auditors I've known.  Especially in the financial sector.  I If you tell the bank "here is the scoop. You want disaster tolerance, youpL don't want to buy addictional vaxes because the bank is against vms, and youJ need to keep the test and production environments. Here is how it *can* beL done, with the following caveats (list of caveats). Banks agrees anmd things	 run fine.   K I was able to tweak with the test system enviroinment to use group logicalshL instead of system logicals and users with "test" privileges had no access toK the production data or environment.  Test and prod could not be on the same-J node. From the production point of view, the test node was simply a mirror$ image of its drives, and vice versa.  L The test environment had different application accounts and the only "login"H to Swifts that were available were the logins to the test environment atN swift. So if they tried to send a funds transfer order for a million bucks, itG could only go to the test environment (swift's equivalent to alt.test).s  B Please note that in that instance, the "test" environment wasn't aL "development" environment, it was a test environment. Install new version ofM software do tests for a few days, and on the scheduled day, install it on thel production environment.   J Crashing the system designated as test (0 cluster votes) had no sigificantM impact on production, other than reduced performance during shadow merge once  the test system rebooted.u   ------------------------------  % Date: Tue, 03 Jun 2003 21:41:56 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: Portents of VMS death) Message-ID: <3EDD4E62.F3E9AB9D@istop.com>    jlsue wrote:M > Wrong again.  It was a test of a very old version of vms against a new UNIXh > offering.   L Lets say you have an old VAX at 5.5-2 and you are told it is time to buy newE machines because this "old museum piece" just doesn't cut it anymore.o  N So you call <whoever is owner of VMS this week> and they propose to loan you aI brand new zippy Unix system pre-loaded with the application you want, and-K they've never heard of VMS and tell you Unix is the way to go and that they); don't have "loaners" for VMS anyways. (or whatever excuse).   L So, as a loyalist to VMS, you still want to push a VMS solution, but all youN have at your disposal is that old vax at 5.5-2 which you can't upgrade because% of the old application that is on it.h   What do you do ? r  L Now, folks who know about the ambassadors programme may call Sue and arrangeK to have some zippy VMS demo showing all its modern stuff.  But ir you don'toD know about Sue or the ambassador programme, who can you turn to when3 Digital/Compaq/HP is unresponsive to VMS requests ?e   ------------------------------  # Date: Wed, 04 Jun 2003 02:17:02 GMTrL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")" Subject: Re: Portents of VMS death6 Message-ID: <00A20D8D.2CF1C1DA@SSRL.SLAC.STANFORD.EDU>  V In article <3EDD4E62.F3E9AB9D@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:
 >jlsue wrote:cN >> Wrong again.  It was a test of a very old version of vms against a new UNIX
 >> offering. t >/M >Lets say you have an old VAX at 5.5-2 and you are told it is time to buy newuF >machines because this "old museum piece" just doesn't cut it anymore. > O >So you call <whoever is owner of VMS this week> and they propose to loan you agJ >brand new zippy Unix system pre-loaded with the application you want, andL >they've never heard of VMS and tell you Unix is the way to go and that they< >don't have "loaners" for VMS anyways. (or whatever excuse). >eM >So, as a loyalist to VMS, you still want to push a VMS solution, but all youPO >have at your disposal is that old vax at 5.5-2 which you can't upgrade because!& >of the old application that is on it. >a >What do you do ?  >uM >Now, folks who know about the ambassadors programme may call Sue and arrangeuL >to have some zippy VMS demo showing all its modern stuff.  But ir you don'tE >know about Sue or the ambassador programme, who can you turn to whenu4 >Digital/Compaq/HP is unresponsive to VMS requests ?  M I was going to say that you don't have to know a secret handshake to find out=F about the VMS Ambassadors; there's a link from the openvms.compaq.com K home age to a nice page describing the Ambassadors program, which makes it 9N clear that if you want to bring in someone who'll say how swell and modern VMS& is, an Ambassador is the one you want.  K That page just doesn't seem to have a description of how to get hold of an - Ambassador.    -- Alan2   -- 0O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056nM  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025.O ===============================================================================    ------------------------------  % Date: Tue, 03 Jun 2003 22:08:18 -0400n* From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: Portents of VMS death) Message-ID: <3EDD548E.829F2620@istop.com>>   David Froble wrote:.O > problems.  I'm proof of this!  My own opinion is that development and testing Q > should be on seperate systems/clusters/whatever, not to protect operations, buto> > to protect the developers from their sooner or later "oops!"  H Testing != development. (consider testing as validation, not debugging).  H In many cases, they will want to test a new version of application on anF environment that is exactlt like that of production.  And this matchesJ perfectly the "backup node" of the production system which is an identical< mirror in config, also running in a cluster config etc etc.)  M If you have a single system used for testing/validation, then its environmentn5 isn't exactly the same because it isn't in a cluster.f   ------------------------------  % Date: Tue, 03 Jun 2003 23:09:44 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: Portents of VMS death) Message-ID: <3EDD62F0.A5D54739@istop.com>a  	 jo wrote:  > H > Still after ten years of hypochrondic talks and discussions OpenVMS is > still around and kicking.s  F We don't know if it is still "kicking".  I don't see HP bragging aboutK increased VMS sales. And when a company doesn't brag about the success of aaG product, the logical conclusion is that the product is not doing well.    L If HP wanted to tell the world that VMS was a success, HP would have all the% means to do so. HP has chosen not to.   C > As I've seen in advertising campains of HP, none of their OS's ise > promoted.t  K There have been plenty of examples written about here where sopecific OS isuL mentioned. Furthermore, "advertising" also include those fancy presentationsC made bt Carly and Company where they mention every OS *except* VMS.-  M My rule: If they mention Tandem but omit VMS, then it must be because VMS waso intentionally omitted.  M If they mention only Windows, then the presentation was targetted at the masswM market. I can tolerate HP making presenttaiosn on Unix. But I do not toleratesG a strategy presentation where all OS except VMS are mentioned. And thissM happened throughout th emerger pregnancy where Carly and company specifically K avoided mentioning VMS. It was mentioned on MAy 7th, but thereafter, in the . big fancy presenattions, it was again omitted.    F > If not, lets talk about it again when we bring OpenVMS to it's grave > and not before.t  K The goal is to get customers/loyalists to rise up BEFORE it is too late ands8 hopefully prevent HP from making the unpopular decision.  I Imagine if we had known about intentions to kill Alpha, how we could haveuJ destroyed their plans.  There were amny who doubted Compaq's commitment toJ alpha, but they were always pointed to "commitment documents" showing some" long term commitment to Alpha etc.  M Well now, it is the same with VMS. There are serious concerns about HP's trueg9 intentions with regards to VMS. But either there are somenL conspiracy-therorists, or there are some people with their heads in the sandI who believe that HP's so called "plan of record" is much more than just am2 promise to continue to support existing customers.   ------------------------------   Date: 3 Jun 2003 21:41:55 -0700 . From: mistdragon@zdnetonebox.com (mist dragon)" Subject: Re: Portents of VMS death= Message-ID: <7500353b.0306032041.16b9abe9@posting.google.com>s  K > I think I've stated my question before.  IIRC, the test used a much oldereL > version of VMS and TCP/IP, and compared it to a recent version of UNIX and > TCP/IP.  a  F And where did I say that ? If you read my posts, everyone of them saysF it was the newest TCP/IP on both platforms and even after it was foundC VMS TCP/IP could not take it, it was knifed to create a new versioni that no customer had.p: It was I think JF Mezei who said it was old TCP/IP, not I.  M > I guess the real conclusion from the test, as described, is that the older,oM > possibly out-of-date, operating platform can't handle the load.  But that'so > not saying much.  ( Did you read the previous post at all ?    Mist   ------------------------------   Date: 3 Jun 2003 22:02:31 -0700 . From: mistdragon@zdnetonebox.com (mist dragon)" Subject: Re: Portents of VMS death= Message-ID: <7500353b.0306032102.269689ae@posting.google.com>p   [Clip]B > At one time, one of my responsibilities was a 3-node cluster ... [Clip]  C So only one old fashioned system with old software. This gives me a. perspective of your opinions...2  L > Absolutely incorrect.  Tandem can not provide the business continuity that > VMScluster provides.    F And to where is this 'fact' based on ? Have you ever used NSK ? Do youC know the ups and downs of it by experience in order to state that ?r! (No, I dont work for NSK either).    Mist :)a   ------------------------------   Date: 3 Jun 2003 13:29:37 -0700t& From: jordan@ccs4vms.com (Rich Jordan)H Subject: Re: Printer recommendation, hobbyist/decwindows/mozilla and VMS= Message-ID: <cc5619f2.0306031229.4144d447@posting.google.com>a  X VAXman-  @SendSpamHere.ORG wrote in message news:<00A20C93.B694FEE5@SendSpamHere.ORG>...h > In article <cc5619f2.0306020759.4387df69@posting.google.com>, jordan@ccs4vms.com (Rich Jordan) writes:
 > {...snip..}y' > >Brian, I can't afford what you have!V > , > What?  My kids or the color laser printer?    C Either of them, actually.   Need a cheap printer, and dogs are moret cost effective than kids.g   Rich   ------------------------------  % Date: Tue, 03 Jun 2003 21:01:37 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n1 Subject: Re: Samba + Multinet: The Saga continues/' Message-ID: <3EDD5301.1A7E23CE@fsi.net>e   Pat Rankin wrote:S > / > In article <3JUN200300223084@gerg.tamu.edu>,\-. >  carl@gerg.tamu.edu (Carl Perkins) writes... > [...]oD > > My SMBD service definition is the same as it has been for years,D > > 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_KEEPALIVEn > > set, and also have this: > >       Flags = UCX_SERVERM > > in my SMBD service defintion. I also have a Max Servers setting, but thatr+ > > should not be needed to get it working.r > J >      We're not running Samba any more, but our old service configurationK > has SO_KEEPALIVE too.  And if UCX_SERVER is omitted, MultiNet will ignore & > the `username = "anything"' setting.  H When you say "MultiNet will ignore the `username = "anything"' setting",F what exactly is the result, if you recall? What UIC/user does the SMBD run as?o   -- t David J. Dachtera  dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 03 Jun 2003 22:29:23 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long) ) Message-ID: <3EDD597E.1F9262F0@istop.com>    Fred Kleinsorge wrote:J > The XDM implementation is not provided as part of Motif or the base OS -1 > instead it is a component of the TCPIP product.     K I wasted many hours trying to fiddle with the TCPIP 5.3 XDM only to come to1D the conclusion that it didn't supportthe MIT magic cookie. The TCPIP] documentation didn't make any mention that it didn't support that established authentication.t  M Since XDM is was introduced fairly recently in the TCPIP Services software, IaN fail to understand why they would have conveniently forgotten about it. At theP very least, they should have documented that it didn't support MIT magic cookie.   My workaround has become:t  6 $set display/transport=tcpip/node=eclair.chocolate.com $mc decw$startlogin0  = and that bring up the real login screen on te target display.   K Also note that the XDM login display (it will work "once" if you define the M terminal in one of the config files) doesn't support logain failure alarms or0 intrusion detection/evasion.   ------------------------------  % Date: Tue, 03 Jun 2003 23:24:05 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)k) Message-ID: <3EDD664B.C67188AB@istop.com>    Fred Kleinsorge wrote:L > heading.  The "DECwindows" folks are currently porting to IPF and planningN > the port of XM to Version 2.1.  The TCPIP folks are among many other things, > porting to IPF.     N What about Alpha and VAX ? HP's "plan of record" mentions continued support ofE at least Alpha. And making VMS behave properly with (old) establishedVI standards is a must. If you get only the "required" features on that IA64 M thing, it will be useless to VMS customers who won't see IA64 stuff for a few3  more years, if they ever see it.   ------------------------------  % Date: Wed, 04 Jun 2003 13:23:25 +09305/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>3I Subject: Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)g. Message-ID: <3EDD6D35.9060504@wasd.vsm.com.au>  J Yes David.  It was on our wish-list fairly early in the piece too (in the # latter part of DEC's halcyon days).u  H IIRC; after a requirement to move from a cluster of desktop VAXstations I (approximately 70 of them at one stage) to more economical and easier to FL manage X-terminal technology was brought up with our DEC account management H (or such like) we received the (perhaps implied) advice that X-terminal K development and support was not a DEC priority, would eat into workstation  K sales, and not to expect such an idea to become corporate strategy (that's oE the way I remember interpreting it anyway - certainly it's continued  1 neglect wouldn't disqualify this interpretation).s  D Of course that advice changed *our* strategy completely ;^)  Having E identified this as a major issue for us we found someone who *would* tB support it on VMS (however tenuously towards the end).  We made a I significant investment in NCD equipment.  It included a VMS-based XDM, a  H vital component for the support of X used in this way.  This was a good H move for us.  These NCD units gave us many years of generally excellent L service.  When the TCP/IP Services XDM finally became available we moved to ! that (loyal - wherever possible).   L Perhaps in the light of it being considered not "strategic" it is easier to J understand the current references to XDM as an effective afterthought and L not to expect too much of it because it's there gratis, nobody's paying any L "real" money for it, and nobody's getting paid any "real" money to maintain L it.  Thanks to whomever in TCP/IP did decide to include it, perhaps because K they personally saw it as an monumental deficiency, but couldn't raise the  K interest anywhere else for some "real" resources to invest in it.  Anybody  K who has seen the login banner, dialog, logo (NOT), etc., can't dismiss the OI impression that some kind soul did it in their own spare time.  It's not SL difficult to imagine why our academic brethren didn't often end up with the H DECwindows Motif SM, or more recently DCE, hosting their session on the " office or computer lab X-terminal.  F Apologies, I've slipped into sarcasm.  Guess this issue has caused my L long-time and simmering astonishment at the neglect of this vital component - of the X environment to get the better of me.    Thanks for listening some more.i   Fred Kleinsorge wrote:K > Yeah.  A historical accident.  The "XTerminal" group was actually part of H > the *Terminals* group.  So all of the stuff to do non-VMS, non-DECnet,K > X-Terminal-like things weren't done by the graphics/Motif folks - but was F > done by people mostly doing *LAT* work!  So the font server, the LATM > transport, etc *did* fall through the cracks for the most part - because it 3 > wasn't originally part of the "DECwindows" group.  > I > XDM falls through the same crack.  It wasn't in the original DECwindows0I > source, which is outsourced for maintenance.  The TCPIP folks were nice K > enough to do the work to port it when they did XDMCP.  And now that a new G > capability is available, it wasn't added because the group adding the G > capability is A) mostly unaware of it, and B) aren't being paid to dos > anything to it.t >  > : > "David Webb" <david20@alpha2.mdx.ac.uk> wrote in message' > news:bbigk2$23d$1@aquila.mdx.ac.uk...v > B >>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 message + >>>news:3EDBE387.7000106@wasd.vsm.com.au...M >>> D >>>XDM was provided by the TCPIP group completely independent of the >  > X11/Motif2 > F >>>project.  In fact, I was pleasantly suprised to find it when I went > 	 > looking  > I >>>for it about a year ago.  You can argue where it really belongs...  In4 >  > anyd > > >>>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 >  > addede > J >>>Magic-Cookie.  I would anticipate that TCPIP will add the capability to >  > XDMr > L >>>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 - >  > and  > E >>>ported it - there was no change made to DECwindows that I know of.t >>>e >>K >>Well I for one was asking for XDM for years and years before "somebody in I >>TCPIP" decided to provide it. Whenever I tried to get someone at DEC in  >  > either > K >>the TCPIP or DECWINDOWS groups to look at it they would profess ignorance- >  > of > I >>what it was and then that they would ask the other group to see whetherr >  > they > G >>could implement it in the future since it was really a TCPIP/Xwindows8 >  > (which > % >>ever was the other group) facility.n >>> >>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.t >> >> >>David Webb >>VMS and Unix team leader >>CCSS >>Middlesex University >> >> >> >>I >>>>>The OpenVMS priority right now is focused on the delivery of OpenVMSa >  > on > H >>>>>Itanium.  With the underlying Magic-Cookie support now available, I >>> 
 >>>imagine >>>oH >>>>>at some point XDM Magic-Cookie support will follow, your request to >  > thet > F >>>>>TPCIP group should help make sure that it is on their future work >  > list.u > H >>>>Would the provision of the XDM be more appropriately positioned with >  > the  > E >>>>DECwindows group?  This is where the XFS resides, which is also a6 >  > TCP/IP >  >>>>based server.u >>>> >>>wI >>>Who knows.  Possibly.  But not without some amount of pain - since theiD >>>"DECwindows" group is actually outsourced support to a 3rd party. >>>  >>>-G >>>>Of course, this is preaching to the converted.  I am not wishing to  >  > dwelle > E >>>>on the bleeding obvious here (or unduly to sound like much of the0 >  > banter >  >>>in. >>> I >>>>this forum).  I just wish to emphasize that the much-needed update ofsC >>>>DECwindows without any corresponding functionality changes in ae >>>d >>>fundamental >>>mJ >>>>component of that X environment is a significant anomaly that would be >>>n >>>best  >>>a@ >>>>receiving immediate attention (project management boundaries >>>  >>>notwithstanding). >>>sJ >>>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 > 
 > planning > G >>>the port of XM to Version 2.1.  The TCPIP folks are among many others > 	 > things,  >  >>>porting to IPF. >>>e >>>  >>>f >  >  >    ------------------------------  # Date: Tue, 03 Jun 2003 18:25:22 GMT # From: "John N." <JNixon@cfl.rr.com>n Subject: SNA-RJE= Message-ID: <mK5Da.60018$Gg7.1935741@twister.tampabay.rr.com>m  8 Does anyone know if SNA-RJE is available for VMS ;7.3-1?  - The  SPD only mentions VMS up to version ;7.3   ? I could not find SNA-RJE mentioned in the VMS software catalog.-!  http://h71000.www7.hp.com/swcat/    ------------------------------  % Date: Tue, 03 Jun 2003 21:15:28 -0500c1 From: "David J. Dachtera" <djesys.nospam@fsi.net>p Subject: Re: SNA-RJE' Message-ID: <3EDD5640.E4E67AD3@fsi.net>e   "John N." wrote: > : > Does anyone know if SNA-RJE is available for VMS ;7.3-1? > / > The  SPD only mentions VMS up to version ;7.3b > A > I could not find SNA-RJE mentioned in the VMS software catalog.e# >  http://h71000.www7.hp.com/swcat/s  @ Have you checked to see if the SPD is updated in the most recent quarterly SPL?  @ I would expect if it's o.k. on V7.3 it should be o.k. on V7.3-1.   -- r David J. Dachteraf dba DJE Systems> http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 3 Jun 2003 15:04:48 -0400>& From: fdc@columbia.edu (Frank da Cruz)( Subject: Re: Syncing Directories via FTP1 Message-ID: <bbirgg$c6k$1@watsol.cc.columbia.edu>o  5 In article <bbikom$96nt3$1@ID-143435.news.dfncis.de>,t* Hans Vlems <hvlems.nieuw@zonnet.nl> wrote: : 3 : "James T Horn" <horn@shsu.edu> schreef in bericht 9 : news:843706dc.0306030724.18d0e280@posting.google.com...aI : > We have a need to sync two directories on two servers. I've looked atsG : > FTP_MIRROR but that only sync's the local with remote. I've found alC : > Mirror utility written in Perl, but it is geared more for Unix.a : >rF : > Does anyone have something or modified something that will sync upG : > both directions and keep both remote and local with the same files?o : J : Two cheap identical disks and volume shadowing? OK, you'd need a cluster : license too. :  Port C-Kermit's FTP client:0  /   http://www.columbia.edu/kermit/ftpclient.htmll  
 to VMS :-)   - Frankc   ------------------------------   Date: 3 Jun 2003 21:34:55 GMTp4 From: Chip Coldwell <coldwell@frank.harvard.invalid>( Subject: Re: Syncing Directories via FTP/ Message-ID: <bbj49v$3ud$1@news.fas.harvard.edu>.  # James T Horn <horn@shsu.edu> wrote:A > D > Does anyone have something or modified something that will sync upE > both directions and keep both remote and local with the same files?   B There's some evidence that John Malmberg was porting rsync to VMS.  > http://lists.samba.org/pipermail/rsync/2001-August/004664.html   Chip   -- V Charles  M. "Chip" Coldwellt "Turn on, log in, tune out"e   ------------------------------  % Date: Tue, 03 Jun 2003 21:53:39 -0400l* From: JF Mezei <jfmezei.spamnot@istop.com>5 Subject: Re: SYS$QIOW - Wtih more Details - Final Try0) Message-ID: <3EDD5120.B7003D5A@istop.com>s   Ryan Moore wrote: H > If you don't use the IO$M_NOW qualifier, the write QIOW won't complete > until that message is read.   M Are you sure about that ? I was under the impression that QIOW would completeAM immediatly if there is enough remaining buffer space in the mailbox, but williM "hang" is the mailbox buffer is full and will then have to wait until someonemJ reads some enough data from mailbox to free sufficient buffer to allow the% write to complete. (hence the RWMBX )t  F > It sounds like you're using one mailbox.  Let's assume the child andH > parent are both writing to the same mailbox with QIOW and no one has aK > read queued to the mailbox.  Then that is a deadlock.  Neither write will H > complete until a read is issued.  And no read will be issued until the > write completes.  H Since the mailbox driver doesn't have a "timer" as does terminal driver,L wouldn't this deadlock last forever ? In the case of the chap, it seems like. something completes after quite a few minutes.  J Seems to me that the person with the problem should investigate what couldN happen to "unfreeze" the  processes. Perhaps some other process issuing a read< or write to/from the mailbox to unjam the othe 2 processes ?  L And as far as 2 processes using one mailbox, it can be done, as long as each6 behaves perfectly in a very strict transactional mode:     server issues read) client issues a write to send transaction % client issues a read to read results l& server issues a write to send results.    S The client "read" will wait for the server to have done its write with the results.   3 If you get out of sync, then  it gets really messy.e    K On the othert hand, with 2 mailboxes, you need to synchronize the responses N with the requests to ensure that the response the client reads is the response: for the current transaction, not the previous or next one.   ------------------------------  # Date: Wed, 04 Jun 2003 05:21:51 GMTr+ From: Ryan Moore <rmoore@rmoore.dyndns.org>i5 Subject: Re: SYS$QIOW - Wtih more Details - Final TryP6 Message-ID: <Pine.LNX.4.53.0306032212340.10663@jaipur>  # On Tue, 3 Jun 2003, JF Mezei wrote:C > Ryan Moore wrote:,J > > If you don't use the IO$M_NOW qualifier, the write QIOW won't complete > > until that message is read.a >nO > Are you sure about that ? I was under the impression that QIOW would completecO > immediatly if there is enough remaining buffer space in the mailbox, but will O > "hang" is the mailbox buffer is full and will then have to wait until someonemL > reads some enough data from mailbox to free sufficient buffer to allow the' > write to complete. (hence the RWMBX )n  D Sorry, that isn't the behavior.  From the I/O User's Manual, section 4.3.2 (Mailbox write):  E IO$M_NOW: Completes the I/O operation immediately without waiting for.F another process to read the mailbox message. $QIO WRITE, without IO$M_G NOW specified, does not complete until the data is read. $QIO WRITE NOW3C completes when the data is in the mailbox. If both IO$M_READERCHECKpJ and IO$M_NOW are specified and no read channel is assigned to the mailbox,F a status of SS$_NOREADER is returned and the data is not placed in theE mailbox. If a read channel is assigned, the IO$M_READERCHECK modifierE is ignored.N    H > > It sounds like you're using one mailbox.  Let's assume the child andJ > > parent are both writing to the same mailbox with QIOW and no one has aM > > read queued to the mailbox.  Then that is a deadlock.  Neither write willFJ > > complete until a read is issued.  And no read will be issued until the > > write completes. >iJ > Since the mailbox driver doesn't have a "timer" as does terminal driver,N > wouldn't this deadlock last forever ? In the case of the chap, it seems like0 > something completes after quite a few minutes.  C Nope, no way to recover.  Writers with no readers means deadlock if- IO$M_NOW is not used.-  L > Seems to me that the person with the problem should investigate what couldP > happen to "unfreeze" the  processes. Perhaps some other process issuing a read> > or write to/from the mailbox to unjam the othe 2 processes ? >2N > And as far as 2 processes using one mailbox, it can be done, as long as each8 > behaves perfectly in a very strict transactional mode: >i >$ > server issues read+ > client issues a write to send transactiona& > client issues a read to read results( > server issues a write to send results.  E Under most cases, this can work.  But if the server and/or client are F doing something other than paying attention to the mailbox, then it isE possible for their reads and write to get out-of-sync.  And when thatuG happens you either have the cilent reading his own message or deadlock.S Not a stable situation.r  D With two mailboxes you can still get out of sync.  But you won't get write/write deadlocks.  M > On the othert hand, with 2 mailboxes, you need to synchronize the responsesoP > with the requests to ensure that the response the client reads is the response< > for the current transaction, not the previous or next one.  ) Synchronization is needed no matter what.n   -Ryanl   ------------------------------  % Date: Tue, 03 Jun 2003 22:14:46 -0400o* From: JF Mezei <jfmezei.spamnot@istop.com>) Subject: Re: [OT] best HTML code cleaner?r) Message-ID: <3EDD5611.81C52FC6@istop.com>o   Michael Rice wrote:	H > However, the HTML returned by the server is not required to have *any*8 > "\r" or "\n" characters (it could all be on one line).  L I am not 100% sure of this. I recall reading an RFC that stipulated that theP HTML content was expected not to exceed a certain number of characters per line.   ------------------------------  % Date: Tue, 03 Jun 2003 23:58:28 -0500 ( From: Michael Rice <marice@whiteice.com>) Subject: Re: [OT] best HTML code cleaner?=/ Message-ID: <vdqv44eojbec71@corp.supernews.com>H  $ On 6/3/2003 9:14 PM, JF Mezei wrote: > Michael Rice wrote:i > H >>However, the HTML returned by the server is not required to have *any*8 >>"\r" or "\n" characters (it could all be on one line). >  > N > I am not 100% sure of this. I recall reading an RFC that stipulated that theR > HTML content was expected not to exceed a certain number of characters per line.  F I'm very curious to know if there is a limit - I've never hit it, but G maybe I've just been lucky.  Do you happen to remember if it was in an uC HTML, SGML, or HTTP spec?  Probably not HTTP, since the content is   treated simply as payload.  I I know there is a line length limitation for MIME encoded HTML, but that  5 is really a MIME limit and not an HTTP or HTML limit.a   ------------------------------   End of INFO-VAX 2003.307 ************************ ES47 running VMS. It's going to replaceC an Alphaserver 1200 and be clustered with an ES40 we purchased lasto year.m  A I do feel as t                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                Y                                                                                                                                                                                                                                                                                                L>        2     d0   A]Aq=?)\    Aq=    )\Aq=)\    Aq=    ?)\xAQ@      xAQ8@Q8QxAQ      xAQ8Q8QxAQ      xAQ8Q8@QxAQ    @  xAQ8@Q8@Q333@      3338@Q8Q333      3338Q8Q333      3338Q8@Q333    @  3338@Q8@Qe?
    e    
e
    e    ?
pף@      q=@      q=      pף      pף      q=      q=    @  pף    @  p                                             	   	   
   
                  
                                             
                                    
   
                           	   	                                                                                             A] xAQ@      xAQ      xAQ      xAQ    @  333@      333      333      333    @  e?
    e    
e
    e    ?
pף@      q=@      q=      pף      pף      q=      q=    @  pף    @                                                   	   
   
               	                              	      
               	   
   
                        
                               Aq= Aq=        q=               CD SORYU                                  D3]?YD3   +    0+    +                                                                                                                                                                                                                                                                                                                                                               S                        F ~      FLIGHT025.G                    '  m  &[FLIGHT.DATA.WORLDS]FLT$MIDWAY.WORLD;2WORLD;1                                                                                  k
                            e @     Q                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   2>>D3   +    в+                                                                            