1 INFO-VAX	Mon, 16 Dec 2002	Volume 2002 : Issue 694       Contents:A Re: "OpenVMS and Windows NT Integration for Dummies" book on eBay   %BACKUP-F-CLUSTER on ODS-5 disksG Re: (Very) Affordable VMS on older gear (was: "VMS will be around ...") G Re: (Very) Affordable VMS on older gear (was: "VMS will be around ...")  ADO.NET -> RMS) Re: DEC C and DEC CXX licenses (on a VAX) % Re: DECwindows/Motif sessions over IP % Re: DECwindows/Motif sessions over IP * Re: DS10 - problem using widescreen or ???* Re: DS10 - problem using widescreen or ??? HSG80 cache performance  Re: HSG80 cache performance  RE: HSG80 cache performance  Re: HSG80 cache performance  Re: http_server crashes  Re: MAIL redirection1 Re: misc HW maintenance end of life dates, where?  multinet+ Re: new version of OpenVMS password cracker  OpenVMS software? - Re: OT: Whoa! Is Sun aiming at VMS's jugular?  Re: Porting from Sun to OpenVMS  Re: Porting from Sun to OpenVMS  Re: Porting from Sun to OpenVMS  Re: Porting from Sun to OpenVMS  Re: Porting from Sun to OpenVMS  Problems with Support-Website ? pthread - finding the status of other threads without blocking? C Re: pthread - finding the status of other threads without blocking? < Re: Question on BACKUP/RECORD to reduce size of incrementals2 Scott Stallard: BCS customers are happy with HP... Re: Test Re: VAX 7810's. @ Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?@ Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?P Re: Why does BACKUP/IMAGE need write access to INDEXF.SYS,	BITMAP.SYS?	BITMAP.SYK Re: Your Multi-volume Tape Backups may be bad on all versions of	VMS	VMSVMS K Re: Your Multi-volume Tape Backups may be bad on all versions of	VMS	VMSVMS D Re: Your Multi-volume Tape Backups may be bad on all versions of VMS< Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]< Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]< Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]< Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]  F ----------------------------------------------------------------------  % Date: Mon, 16 Dec 2002 13:13:45 -0500 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> J Subject: Re: "OpenVMS and Windows NT Integration for Dummies" book on eBay$ Message-ID: <3dfe17cc$1@news.si.com>  < >You mean they're like Gremlins ... They breed in the night?  ' Only if you feed them and get them wet.  --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM. @ 3290 Patterson Ave. SE, MS Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------    Date: 16 Dec 2002 06:13:42 -0800' From: ultrajoe@spamcop.net (Joe Sewell) ) Subject: %BACKUP-F-CLUSTER on ODS-5 disks = Message-ID: <a55b951e.0212160613.67e5b62c@posting.google.com>   E I've got a very strange situation here with VMS V7.2-6C2.  I'm trying F to use BACKUP/IMAGE to copy one disk to another; I'm not going throughA a saveset here.  The BACKUP fails with the error mentioned in the  subject.  A The disks are the same size, though perhaps not the same geometry E (which, unless something happened with V7.2, shouldn't matter here).  ; The source disk is not full; all the data should fit on the E destination disk.  The source disk is a 181GB SCSI disk (the SCSI bus ? runs off a Qlogic ISP1020, according to SHOW DEVICE/FULL PKA0), B initialized as an ODS-5 disk with a cluster size of either 3 or 35F (I'm not sure how the original disk was created, and I currently don'tC have access to that specific disk).  The destination disk is also a F 181GB SCSI disk, running off the same or similar controller.  (I'm notB sure, at this point, whether it's actually on the same SCSI bus or; not; hopefully it doesn't matter.)  The destination disk is 6 specifically INITIALIZEd /STRUCTURE=5/CLUSTER_SIZE=35.   The actual commands are:  2 $ INIT/NOHIGH/HEADERS=50000/MAXIMUM_FILES=150000 -2   /STRUCTURE=5/CLUSTER=35 _$1$DKA100: OWS_COE_TSR2 ...  $ MOUNT/FOREIGN _$1$DKA100: 3 $ BACKUP/IMAGE/NOINIT/TRUNC _$1$DKA300: _$1$DKA100: > %BACKUP-I-EXTINDEXF, INDEXF.SYS on device _$1$DKA100: has been% extended to accomodate restored files < %BACKUP-F-CLUSTER, unsuitable cluster factor for _$1$DKA100:  F I do believe the /HEADERS and /MAXIMUM_FILES qualifiers are incorrect,A and should be removed in this situation, but I don't see how that ) would produce the BACKUP-F-CLUSTER error.   > This ran in a batch job, so I don't know if the error occurred immediately or not.    ------------------------------  % Date: Mon, 16 Dec 2002 09:20:17 -0800 % From: Dean Woodward <deanw@rdrop.com> P Subject: Re: (Very) Affordable VMS on older gear (was: "VMS will be around ...")& Message-ID: <3DFE0B51.50701@rdrop.com>   JF Mezei wrote: N > It would be strategic for VMS to use those unused assets (old VAXes) towardsP > assimilating new customers who would then possibly upgrade to current hardwareL > and pay (as long as prices are acceptable).  But I am not sure it would beD > strategic for HP to allow old platforms to be given a second life.  G Why push VAX for new customers when, for example, a used AS1200 can be   had for ~$1000 USD?    ------------------------------  % Date: Mon, 16 Dec 2002 13:24:24 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>P Subject: Re: (Very) Affordable VMS on older gear (was: "VMS will be around ...")/ Message-ID: <3DFE1A56.5298FDE7@vl.videotron.ca>    Dean Woodward wrote:H > Why push VAX for new customers when, for example, a used AS1200 can be > had for ~$1000 USD?   I Because VAX are the moral equivalent to the low cost 8086 today. They are L basically free, just like many have spare 8086 servers in-house which can be used to test new stuff.   N Of course, Alphas are quickly becoming like that because of the Jun 21 murder.  N The problem would be defining some sort of automated way to continually updateJ the list of machines  which qualify for the "free licences".  I guess someL sort of updated LURT which would lower the number of units required for each machine as they grow older.   N Is there a way to distribute updated LURTs, or would those potential customersL be forced to buy the most recent CONDIST that includes a version of VMS that! considers their hardware "free" ?    ------------------------------    Date: 16 Dec 2002 10:09:04 -0800% From: dana20154@yahoo.com (D Schultz)  Subject: ADO.NET -> RMS = Message-ID: <1b0306b5.0212161009.489c6bed@posting.google.com>   < I have implemented an ADO.NET managed data provider for RMS.  F Written specifically for ADO.NET and RMS, it contains some interesting functionality:      o Variable Length Records, 
    o RFAs,A    o The schema data type and that of the XABKEY are independent. E    o Schema USAGE clause allows numeric fields to be passed to client  as date fields.   - Best of all, for a limited time, it's free...   - For a no cost - no risk copy, please contact:   ( dana d0t schultz at schultzassoc d0t com   ------------------------------  % Date: Mon, 16 Dec 2002 13:38:59 -0500 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> 2 Subject: Re: DEC C and DEC CXX licenses (on a VAX)$ Message-ID: <3dfe1db7$1@news.si.com>  G >C and C++ are different products.  You'll need a separate PAK for C++.   L And rightly so, sinc they are different languages.  C is not a proper subset' of C++, as some Unixites seem to think.  --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM. @ 3290 Patterson Ave. SE, MS Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------  % Date: Sun, 15 Dec 2002 16:02:59 -0500 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>. Subject: Re: DECwindows/Motif sessions over IP/ Message-ID: <3DFCEDFB.AD3E1E0A@vl.videotron.ca>    Hans Vlems wrote: ; > The session manager on the target VAX was set as follows:  >  > protocol    node    username > DECnet      *             *  > TCPIP        *             *  > LAT            *             *  N You need to define/SYSTEM (or in the decw table) DECW$INSTALL_TCPIP "TRUE" (or- any value) prior to starting the DECW server.    If you are already started:   ( DEFINE/SYSTEM DECW$INSTALL_TCPIP "TRUE" ! @SYS$MANAGER:DECW$STARTUP RESTART   N After it restarts, if you do a netstat, you will see that "someone" listens onL port 6000. (TCPIP show services doesn't show this, you have to use netstat).  S If you have a router/firewall, you need to figure out how to enable port 6000-6063.    ------------------------------  % Date: Mon, 16 Dec 2002 19:54:12 +0100 " From: "Hans Vlems" <hvlems@iae.nl>. Subject: Re: DECwindows/Motif sessions over IP4 Message-ID: <atl7h5$7vpm$1@ID-143435.news.dfncis.de>  ? "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> schreef in bericht ) news:3DFCEDFB.AD3E1E0A@vl.videotron.ca...  > Hans Vlems wrote: = > > The session manager on the target VAX was set as follows:  > >   > > protocol    node    username > > DECnet      *             *   > > TCPIP        *             *" > > LAT            *             * > L > You need to define/SYSTEM (or in the decw table) DECW$INSTALL_TCPIP "TRUE" (or / > any value) prior to starting the DECW server.  >  > If you are already started:  > ) > DEFINE/SYSTEM DECW$INSTALL_TCPIP "TRUE" # > @SYS$MANAGER:DECW$STARTUP RESTART  > E > After it restarts, if you do a netstat, you will see that "someone" 
 listens onD > port 6000. (TCPIP show services doesn't show this, you have to use	 netstat).  > J > If you have a router/firewall, you need to figure out how to enable port
 6000-6063.  G I have a W2k system with a portscanner, no problem. I'll check this out  immediately!   Thanks,    Hans   ------------------------------  # Date: Sun, 15 Dec 2002 20:24:41 GMT ' From: nickerson@pundit.ds.boeing.com () 3 Subject: Re: DS10 - problem using widescreen or ??? ( Message-ID: <H76Gp5.K1J@news.boeing.com>  ( In article <H74uno.GBL@news.boeing.com>,'  nickerson@mirage.boeing.com () writes:   H |>I have a DS10 6/600 with VX1 card running 7.3-1 with no patches; I getE |>the DECwindows prompt screen but can not login; behavior is that is E |>takes the username and then the Xserver restarts & you never see a  J |>password prompt; this is a "new" machine and has never been successfully0 |>used with any display much less a widescreen;   C great - the monitor thing was a false alarm; actual problem is with A SYSUAF file; somewhere (and remember this is a "new" machine) the J startup is setting logical SYSUAF = SYSUAFALT; so even going to sys$systemK and running $ mcr authorize does not see the sys$common:[sysexe]sysuaf.dat   file sitting right there;     G meanwhile for the wide screen monitor which is 1280x786 pixels; can the G decwindows display fullscreen; I've looked in decw$private_server_setup ) template and don't see anything relevant;      --bn (Bart Nickerson)  nickerson@pundit.ds.boeing.com (206) 662-0183   ------------------------------  % Date: Mon, 16 Dec 2002 18:30:52 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)3 Subject: Re: DS10 - problem using widescreen or ??? ; Message-ID: <3dfe0dcc.524144494f47414741@radiogaga.harz.de>   % nickerson@pundit.ds.boeing.com wrote: I > meanwhile for the wide screen monitor which is 1280x786 pixels; can the I > decwindows display fullscreen; I've looked in decw$private_server_setup + > template and don't see anything relevant;   C You should have a look in the SYS$MANAGER:DECW$DEVICE_CONFIG_Gx.COM C for your graphics device GxA0: (not sure what it is for a VX1), and C then set the appropriate symbols in DECW$PRIVATE_SERVER_SETUP.COM .    cu,    Martin --  F                           | Martin Vorlaender  |  VMS & WNT programmer3  Cetero censeo            | work: mv@pdv-systeme.de F  Redmondem delendam esse. |   http://www.pdv-systeme.de/users/martinv/:                           | home: martin@radiogaga.harz.de   ------------------------------    Date: 16 Dec 2002 01:34:34 -0800) From: martin.ballard@ndr.co.uk (Martin B)   Subject: HSG80 cache performance= Message-ID: <7908c667.0212160134.59ad16d5@posting.google.com>   D When performing a VMS image restore from SDLT to a 3 disk stripe setA on an HSG80 I get a throughput of less than 1MB/sec when there is C 512MB of cache in the HSG80. When i remove 256MB form the HSG80 and B perform the same restore i get 10MB/sec. Does anyone know why this should be ?    ------------------------------  % Date: Mon, 16 Dec 2002 11:33:32 +0100 $ From: "Peter Flunger" <p-i-b@gmx.at>$ Subject: Re: HSG80 cache performance0 Message-ID: <atka5t$r5m$1@newsreader1.netway.at>  + "Martin B" <martin.ballard@ndr.co.uk> wrote F > When performing a VMS image restore from SDLT to a 3 disk stripe setC > on an HSG80 I get a throughput of less than 1MB/sec when there is E > 512MB of cache in the HSG80. When i remove 256MB form the HSG80 and D > perform the same restore i get 10MB/sec. Does anyone know why this
 > should be ?   ) How is the unit configured on the HSG80 ? 8 Try to avoid RAIDx sets with more than one member on the
 same SCSI bus  AND ( even more important ) < enable writeback_cache for that unit and try to increase the' maximum_cached_transfer_size Parameter. < ( writeback_cache'ing is not enabled by default on the units:   behind a HSxxx controller and RAIDx is very slow without   using the writeback_cache )  Regards, Peter   ------------------------------  % Date: Mon, 16 Dec 2002 06:46:04 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> $ Subject: RE: HSG80 cache performanceT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF402660C2C@kaoexc01.americas.cpqcorp.net>   Martin,    What version of the HSG80 code?   D I seem to remember an older version (V8.5??)of the HSG80 code where,H depending on the config, a problem similar to yours was fixed in a newer@ release of the HSG code. V8.7 is the latest version as I recall.  
 Regards=20  
 Kerry Main Senior Consultant  Hewlett-Packard (Canada) Co.! Consulting & Integration Services  Voice: 613-592-4660  Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)      -----Original Message-----3 From: Martin B [mailto:martin.ballard@ndr.co.uk]=20  Sent: December 16, 2002 4:35 AM  To: Info-VAX@Mvb.Saic.Com   Subject: HSG80 cache performance    G When performing a VMS image restore from SDLT to a 3 disk stripe set on G an HSG80 I get a throughput of less than 1MB/sec when there is 512MB of F cache in the HSG80. When i remove 256MB form the HSG80 and perform theB same restore i get 10MB/sec. Does anyone know why this should be ?   ------------------------------  % Date: Mon, 16 Dec 2002 16:15:51 +0100  From: gerhard.staub@rizit.at$ Subject: Re: HSG80 cache performance( Message-ID: <3DFDEE27.D517A3BD@rizit.at>  # Does your HSG80 use Shadowed Cache? & It is an sigificant performance boost!5 btw On our HSG80 writebackcache is enabled by default > Also you can use VTDPY on your HSG80 to detect the bottleneck.   regards  Gerhard    Martin B schrieb:  > F > When performing a VMS image restore from SDLT to a 3 disk stripe setC > on an HSG80 I get a throughput of less than 1MB/sec when there is E > 512MB of cache in the HSG80. When i remove 256MB form the HSG80 and D > perform the same restore i get 10MB/sec. Does anyone know why this
 > should be ?    ------------------------------  % Date: Mon, 16 Dec 2002 13:32:40 -0500 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>   Subject: Re: http_server crashes$ Message-ID: <3dfe1c3b$1@news.si.com>  9 >   our www server crashes regularly a few times per day,  >the reason being unknown. > : >   The HTTP_SERVER_ERR.LOG files produced when the server! >is screwed up all look the same:   : Best asked in the OSU mailing list vms-web-daemon@kjsl.com --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM. @ 3290 Patterson Ave. SE, MS Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------  % Date: Mon, 16 Dec 2002 13:24:24 -0500 - From: "Peter Weaver" <peter.weaver@stelco.ca>  Subject: Re: MAIL redirection 4 Message-ID: <atl5p0$6hfm$1@ID-141708.news.dfncis.de>   Syltrem wrote: >..., > MAIL> SET FORWARD/USER=PERSON_ON_CALL JDOE > then, the next day: 0 > MAIL SET FORWARD/USER=PERSON_ON_CALL JTREMBLAY > etc  > G > I thought about this. How can I switch from one account to another to F > modify the profile of another user in VMSMAIL_PROFILE.DATA ? I couldD > use DLC and hardcode the field position in the record, but I'm notG > hardcode-prone... even if a good bet is that this field position will G > not change in the record, for the next 100 years or so (VMS not being E > like weendoze). This would actually be the best way of doing what I  > want at this point.  >...  H The SET FORWARD/USER= command is built into MAIL as long as the user hasH SYSNAM privilege, you don't need to do any special coding or use any 3rdH party software. The next few lines of code will forward SYSTEM's mail to7 either JDOE or JTREMBLAY depending on what the date is.      $ day=f$cvtime("",,"day")  $ if day / 2 * 2 .eq. day 	 $    then  $       mail set forward/user=system JDOE	 $    else  $       mail! set forward/user=system JTREMBLAY 
 $    endif $!   -- Peter WeaverD Opinions are my own, and do not reflect the opinions of my employer,A nor the company that it sub-contracts to, nor the company that it  sub-contracts to.    ------------------------------  % Date: Mon, 16 Dec 2002 10:23:31 -0800 ( From: Alan Frisbie <Abuse@NelsonUSA.com>: Subject: Re: misc HW maintenance end of life dates, where?, Message-ID: <3DFE1A23.E39ADBD@NelsonUSA.com>   Didier Morandi wrote:   R > Where can I find the official HW maintenance end of life dates for the following
 > equipments:  > 	 > uVAX-II   A Shhhh!   Don't let my microVAX II (actually a VAXstation II) hear @ you.   It it is still earning its keep every day as my UUCP mail? gateway.   It also does all my TK50 and TK70 media conversions.   C It is perfect as an e-mail system.   No viruses or HTML web bugs to C worry about.   The only problem is those people who can't configure * their PC mail software to send plain text.   Alan   ------------------------------  % Date: Mon, 16 Dec 2002 10:32:47 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: multinet 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEBIGEAA.tom@kednos.com>   
 3.3 on 6.2  . Stopped smtp and have many entries of the form  4   Entry  Jobname         Username     Blocks  Status4   -----  -------         --------     ------  ------5      28  SMTP-RETURN     SYSTEM            3  Pending    How do I delete then all?  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.419 / Virus Database: 235 - Release Date: 11/13/2002    ------------------------------  % Date: Mon, 16 Dec 2002 13:18:26 -0500 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> 4 Subject: Re: new version of OpenVMS password cracker$ Message-ID: <3dfe18e5$1@news.si.com>  J I'm trying to run john on a VAX 4600.  It's clocked "3 09:00:09.32" of CPU8 time and shows no signs of stopping.  What's reasonable? --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM. @ 3290 Patterson Ave. SE, MS Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------    Date: 16 Dec 2002 09:01:55 -0800' From: timasmith@hotmail.com (Tim Smith)  Subject: OpenVMS software?= Message-ID: <a7234bb1.0212160901.3215b2ef@posting.google.com>    Hi,   E   I have a digital alpha server 3000 coming and would like to install F VMS 7.x on it.  This is for personal use at home.  What is the current2 best place to order the software for hobbyist use?   thanks   Tim    ------------------------------  % Date: Mon, 16 Dec 2002 14:21:19 +0000 ' From: Andrew Harrison SUNUK Consultancy 6 Subject: Re: OT: Whoa! Is Sun aiming at VMS's jugular?. Message-ID: <3DFDE15F.8030100@nospamn.sun.com>   Mark E. Levy wrote: M > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com> ; > wrote in message news:3DF8A5AD.8090002@nospamn.sun.com...  >  > 6 >>If you couple this with the fact that the throughput5 >>of each OpenVMS node has always been 1/4 of that of ; >>the largest Sun and you end up with a rather unimpressive  >>story. >  > L > And your point is? The major points of OVMS clustering are scalability andM > fault tolerance. I'd rather have 4 OVMS cluster nodes than 1 Sun. If I lose N > a cpu, I still have 3/4 of my system available, with the Sun I'm dead in theM > water. Unix "clustering" is a feeble also-ran compared to OVMS' clustering.  > @ > Unimpressive? Yea, if I were trying to sell Suns. But I'm not. > K > Just what is your point here, Andrew? Do you really think you're going to L > "convert" c.o.v readers like me to Sun? As they say here in the U.S., "fat
 > chance." >   > No, why should I bother ? If a large proportion of the posters= on this group are correct then you will end up on Solaris/AIX 8 or HP-UX unless you are going to go for a career change.  9 But if you want to hasten the demise of OpenVMS then look 9 no further than arming yourself with the kind of argument < that Bob espouses next time you are in a why OpenVMS instead of some other UNIX OS argument.   : Or do you really think that Bobs 80,000 SPARC's claims are; realistic. If you want a laugh and one at OpenVMS's expense  then look no further.    Regards  Andrew Harrison    ------------------------------    Date: 16 Dec 2002 06:46:35 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ( Subject: Re: Porting from Sun to OpenVMS3 Message-ID: <edrUDs+qJrOH@eisner.encompasserve.org>   S In article <uvkqdafc85s30b@corp.supernews.com>, Z  <zarlenga@conan.ids.net> writes:  > ? > Does even the most dyed-in-the-wool VMS supporter here REALLY > > think that VSM will be around in 2106, when the C RTL time() > overflows?  H    All us died in the wool VMS supporters are convinced that VMS will beE    around in 9999 when the VMS time formwatting routines get updated.    ------------------------------    Date: 16 Dec 2002 05:57:30 -0800- From: jodonnell@hrblock.com (Jason O'Donnell) ( Subject: Re: Porting from Sun to OpenVMS= Message-ID: <9059bf6b.0212160557.6427731a@posting.google.com>   X Nic Clews <sendspamhere@127.0.0.1> wrote in message news:<3DF9A5C3.EBFBB25@127.0.0.1>... > Jason O'Donnell wrote: > > A > > Sorry Nic, I think you didn't get your coffee before writing.  > >  > ' > Ever gone in for being a psychic? :-)  > D > Anyway, trust you found the GNV stuff on the CD supplied with your  > 7.3-1, Open Source Tools disc.  E The real question for GNV is whether the original Solaris application B development staff will continue developing it or whether our staffE will take it over.  Of course, we have one relatively new team member B who we hired for his C skills that is a UNIX blasphemer.  He stillD hasn't seen the light.  May have to dress him up like a witch...  ;)  < I think the new portability stuff may be the most important.   ------------------------------    Date: 16 Dec 2002 06:04:28 -0800- From: jodonnell@hrblock.com (Jason O'Donnell) ( Subject: Re: Porting from Sun to OpenVMS= Message-ID: <9059bf6b.0212160604.133c6bc9@posting.google.com>   E > ... and, in some cases, you'll save time and money by ripping out a D > unixism and supplanting with a VMSism.  The real "reality" is thatE > you'll likely do a "first level port to get everything running" and B > never comes the day when you then "re-architect to fit OpenVMS".D > And, borrowing from another thread, your users will dis VMS as the > root of the problem.  C Depending on how we find the code and its performance, we will know B what it will take to sell the re-engineering.  Obviously, the factC that they are considering running it on VMS is a good thing!!!  The A answer is educating management as to the problems and benefits of E running ported code on VMS.  The portability issue to be able to move E off of VMS is a reason to tread carefully on making platform specific F changes.  Selling that we can do a simple port to VMS is important!!! D Selling the benefits to optimize the application for the platform is the next step.   ------------------------------    Date: 16 Dec 2002 06:19:27 -0800- From: jodonnell@hrblock.com (Jason O'Donnell) ( Subject: Re: Porting from Sun to OpenVMS= Message-ID: <9059bf6b.0212160619.108fcaac@posting.google.com>   X Z  <zarlenga@conan.ids.net> wrote in message news:<uvkqdafc85s30b@corp.supernews.com>...$ > Jim Agnew <jpagnew@vcu.edu> wrote:H > : Right... why settle for that when you can have whatever vms end date! > : is??? i forget, 38,000 A.D.??  > = > Because when you move _off_ VMS, all the date/time routines  > need to be rewritten.  > 4 > VMS's routines, formats, etc are industry-uniqiue, > ? > Does even the most dyed-in-the-wool VMS supporter here REALLY > > think that VSM will be around in 2106, when the C RTL time() > overflows?  ( YES!  It will be around in some fashion.  B If you mean as a living growing OS, it depends.  If HP markets the product properly, then yes.    ------------------------------    Date: 16 Dec 2002 08:11:26 -0600+ From: young_r@encompasserve.org (Rob Young) ( Subject: Re: Porting from Sun to OpenVMS3 Message-ID: <30kOZ7hJZBvQ@eisner.encompasserve.org>   m In article <9059bf6b.0212160604.133c6bc9@posting.google.com>, jodonnell@hrblock.com (Jason O'Donnell) writes: F >> ... and, in some cases, you'll save time and money by ripping out aE >> unixism and supplanting with a VMSism.  The real "reality" is that F >> you'll likely do a "first level port to get everything running" andC >> never comes the day when you then "re-architect to fit OpenVMS". E >> And, borrowing from another thread, your users will dis VMS as the  >> root of the problem.  > E > Depending on how we find the code and its performance, we will know D > what it will take to sell the re-engineering.  Obviously, the factE > that they are considering running it on VMS is a good thing!!!  The C > answer is educating management as to the problems and benefits of G > running ported code on VMS.  The portability issue to be able to move G > off of VMS is a reason to tread carefully on making platform specific H > changes.  Selling that we can do a simple port to VMS is important!!! F > Selling the benefits to optimize the application for the platform is > the next step.    B 	Let me pass on my best example of what could possibly go wrong inD 	a port, how I found it and what the obvious fix was.  Beware simpleA 	ports.  Porting can be simple.  Fixing or finding something long B 	broken could be a long term side-effect.  Here is the story . . .  ? 	A number of years ago a vendor of search engine technology had @ 	a VAX API but not Alpha, nor any intention of creating an Alpha; 	port.  We had customer demand, so management swallowed (or C 	bundled to a customer :-) the cost of a "class D port" to Alpha.   ? 	(class D port... meaning:  if this works, good for you, if it  * 	doesn't ... too bad!)  I pushed for it.    A 	Prior to that, our Alpha product shipped VESTed, including their B 	search engine!  Of course, the performance was less than stellar,; 	as we had to statically link and *then* VEST the resulting ; 	binaries.  But it sure was a lot faster than a VAX 11/750.   D 	So the class D port went ahead.  They hired a contractor to perform@ 	the work, in a few weeks we received native Alpha search engineC 	binaries/libraries.  After a bit of testing, I noticed that things ; 	still weren't a whole lot faster on indexing runs, so the  ? 	slowdown pointed to something else.  I ran a re-index in batch @ 	at priority 0, slowed it down further by running a few CPU hogsF 	and then did DIR/SIZE=ALL on the temp files used during the rebuilds.C 	What I noticed was the temp files were growing 8 blocks at a time, D 	a set volume/extend=1024 changed nothing, nor did $ SET RMS_DEFAULT; 	/EXTEND_QUANTITY=1024 change anything.  An extend of 8 was C 	hard-coded in the source somewhere.  I called the fellow doing the A 	class D port and asked him to search all headers and all .c code @ 	for the string "deq=8".  He found it and was very curious as toG 	how I knew it was there.  He would not change the value but agreed to	 G 	take it out.  Subsequent runs of $ SET RMS/EXT=1024 had the reindexing ( 	time go from over an hour to 5 minutes.  > 	I pleaded for them to recompile a VAX library/API for us withA 	"deq=8" removed.  They refused.  Of course, I suppose the upside F 	was many of the "slow" VAX customers converted to Alpha or Unix.  So $ 	we did get to churn hardware sales!  F 	Two things may have been going on.  1) Someone may have misunderstoodC 	and figured if they are doing a 4K IO, they would grow the file 4K E 	when the files needed more room.  Of course, the filesystem overhead B 	was absolutely brutal.  2) Deliberate?  Hard to tell.  Their UnixE 	products sure were a whole lot faster than the VAX product, however.   4 	Additionally, a quick Google Group shows various IO? 	tips and tricks.  Hein commenting on Pin H. Chen's statements:   \ http://groups.google.com/groups?selm=5uqkpl%24vcs%40usenet.pa.dec.com&oe=UTF-8&output=gplain  > In article <01bcb94c$35324030$e9ea689b@w780845>, "Pin H. Chen") <pin_h_chen@mail.northgrum.com> writes...  >Hello,  > 9 >I am currently using $assign and $qio to access files on : >my local disk (for fast block I/O).  I use the $assign to7 >assign an I/O channel to the disk device.  Then, I use 7 >the $qio to request read/write from/to the disk.  This  >works very well.   7 Good for you, but looks may be deceiving. Did you also  5 take care of double buffering, Async write behind and 8 read ahead? If not, some folks have found that plain RMS< record IO performed better (with ROP=WBH,RAH; MBC=64; MBF=8)   ---   , 	Many similar examples to that above in cov.  ? 	All this to say... the battle will be won or lost on the IO if  	IO is involved.  A 	If your potential port involves "IO", I would strongly encourage C 	training and/or great overview for the "Unix" folks doing the port B 	regarding IO choices (QIO vs. RMS, uses, advantages, etc....)  OrA 	get someone that knows VMS to pour over the key portions of code  	that could cause "issues."    	(Another sidebar:  B 	To make IO fly, use IO_PERFORM , see sys$examples:io_peform.c and$ 	of course the seminal fast_io_copy:  \ http://groups.google.com/groups?selm=6ajqur%24nl3%40usenet.pa.dec.com&oe=UTF-8&output=gplain  @ 	Granted -  as you say... "simple port" and the IO_PERFORM stuff3 	probably goes beyond the bounds of "simple"  ;-)      	)    < 	Elsewise, someone may get a bright idea of coding something) 	that could have brutal VMS side-effects.    				Rob     L "UNIX is akin to a religion to some.  If things aren't done like they are inG UNIX, then they must be bad.  Sorry, I don't believe in this religion."   O                                               -- Dave Cutler, NT lead Architect J                                                  UNIXWorld - February 1992   ------------------------------  % Date: Mon, 16 Dec 2002 13:06:55 +0100 2 From: "Ren Schelbaum" <rene.schelbaum@datakom.at>& Subject: Problems with Support-WebsiteG Message-ID: <3dfdc1e7$0$25426$91cee783@newsreader01.highway.telekom.at>    Hi!   J Is it just me, who is unable to reach http://ftp.support.compaq.com or ist, the site down, or has its location changed ?   Ren   ------------------------------   Date: 16 Dec 2002 18:37:28 GMT7 From: yehavi@vms.huji.ac.il (Yehavi Bourvine (58-4279)) H Subject: pthread - finding the status of other threads without blocking?% Message-ID: <2002Dec16.183728@hujicc>    Hello,M   I am writing a program which uses pthread package; there is a "main thread" M which creates other threads and do some housekeeping. How can the main thread M knows when another thread died without callnig the pthread_join()? I need the M main thread to do continous work and from time to time poll the status of the  other threads.  8                                        Thanks! __Yehavi:   ------------------------------  % Date: Mon, 16 Dec 2002 18:03:28 -0000 , From: seibel_r@rich.ociweb.com (Rich Seibel)L Subject: Re: pthread - finding the status of other threads without blocking?5 Message-ID: <slrnavs5bc.865.seibel_r@rich.ociweb.com>   O On 16 Dec 2002 18:37:28 GMT, Yehavi Bourvine (58-4279) <yehavi@vms.huji.ac.il> S wrote: >Hello,EN >  I am writing a program which uses pthread package; there is a "main thread"N >which creates other threads and do some housekeeping. How can the main threadN >knows when another thread died without callnig the pthread_join()? I need theN >main thread to do continous work and from time to time poll the status of the >other threads.  > J I prefer to keep my own global structure and update it from the threads asD they exit.  There is no portable pthread call that works across all G platforms, so I don't try, thus don't know if it would work on OpenVMS.p   Rich  9 >                                       Thanks! __Yehavi:n     --  D --------------------------------------------------------------------D Rich Seibel, Software Engineer                 (314)579-0066 ext 211D Object Computing, Inc.                           seibel_r@ociweb.comD Need ACE training?                      See http://www.theaceorb.comD --------------------------------------------------------------------   ------------------------------  + Date: Mon, 16 Dec 2002 11:50:43 +0100 (MET)l& From: Rudolf Wingert <win@fom.fgan.de>E Subject: Re: Question on BACKUP/RECORD to reduce size of incrementalsa6 Message-ID: <200212161050.LAA09348@sinet1.fom.fgan.de>   Hello,  > you can do the following command to set the DSA101 device to a fully backuped state:s  % 	$BACK/IMAGE/RECORD DSA101: NL:T/SAVE   C After this command the BACKUP/RECORD command will work as you want.    Best regards R. Wingertl  H P.S. Merry Christmas and a Happy New Year to all members of this mailbox   ------------------------------    Date: 16 Dec 2002 11:10:53 -0600B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley); Subject: Scott Stallard: BCS customers are happy with HP...-3 Message-ID: <U+4$7MwdIeGj@eisner.encompasserve.org>0  I Anyone care to comment on the following quote from Scott Stallard, in theR% first issue of Customer First Times ?f  I -------------------------------------------------------------------------h  @ As far as I know, we have not lost one Business Critical SystemsH customer due to the Compaq-HP merger, which is a ringing endorsement for? our roadmaps, the dedication and caliber of our people, and theiB excellence of our products. The extremely positive feedback I have@ received at recent customer events and from the industry analystE community confirms that our strategy, business model and technologies-G are the right ones at the right time. We remain committed to delivering D on our roadmaps, increasing the value we offer you, and offering the$ richest growth path in the industry.   [Cut...]  
 Sincerely, Scott Stallard Senior Vice President6 Business Critical SystemsC  I -------------------------------------------------------------------------    Simon.   --  B Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       & "This is VMS. Viruses are irrelevant."   ------------------------------    Date: 16 Dec 2002 09:48:45 -0800% From: dana20154@yahoo.com (D Schultz)l Subject: Re: Testt= Message-ID: <1b0306b5.0212160948.25f4d64d@posting.google.com>s   Test   ------------------------------  % Date: Mon, 16 Dec 2002 07:54:40 +0000 ( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: VAX 7810's.) Message-ID: <3DFD86C0.D6D5D470@127.0.0.1>a   Leigh Bowden wrote:n > / > Some suggestions would be useful on this one.i > N > Three machines A, B, C are all VAX 7810's fully ECO'd VMS 7.1 and DECnet/OSI > 7.1 ECO 5. 256MB memory etc. ...iN > A and C are in building X and B is in building Y about ten miles away. A andJ > C are connected by one of the FDDI lines with routing provided by Cisco.N > This is dedicated to one application and nothing else. All the ethernets and< > other FDDI are heavily used i.e. they cannot be taken out. > N > The DECnet copies between A and B are awful and can only do 2-3MB/minute. If5 > C is put in place of A this becomes 60-70MB/minute.  > M > If cards are moved from A to C the performance drops back to 2-3MB/minute..   D I'm alerted to the fact you've mentioned CISCO. From a very reliableF source, I understand that there are, or have been performance problemsF with CISCO equipment handling DEC protocols. I have no further detailsA on this, but it isn't clear to me if using C rather than A if thet7 routing is any different over the networking equipment.o  G Do you need to have DECnet on all the circuits? Try disabling it on thejG interfaces not being used (switch off circuit and line) and see if this.@ changes things. This should help identify if it is a software orG hardware issue. Have you tried comparing an IP copy if you have TCPIP? r  @ My interpretation of your problem description is that you've gotC problems when there are two FDDI paths between each of the nodes, IIH wonder if the DECnet is trying to use both, but the routers are blocking down to one path?.  A Some rambling suggestions [BEFORE A COFFEE!] I'd check out a SHOWa1 LAN/COU in SDA and try to understand the numbers.-   -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencese nclews at csc dot comn   ------------------------------  # Date: Mon, 16 Dec 2002 14:22:35 GMT / From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com>iI Subject: Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?,7 Message-ID: <LklL9.9335$f6.233351@twister.maine.rr.com>   B I  don't know about their availability, but I've received some new: IO_ROUTINES* images that correct the SMTP/$BRKTHRU issues.   -Jeffo  ; "Peter LANGSTOEGER" <peter@langstoeger.at> wrote in message - news:ZG8L9.42087$TA6.451003@news.chello.at...uF > In article <ataefm$6ff$1$8300dec7@news.demon.co.uk>, "Chris Sharman"$ <chris.sharman@sorry.nospam> writes: > >sI > >> In article <aspt4c$mdp$1$8302bc10@news.demon.co.uk>, "Chris Sharman"T' > ><chris.sharman@sorry.nospam> writes:qD > >> >I installed the VMS73_SYS05 patch two weeks ago & rebooted. On	 rebootingtF > >> >dce, pathworks & goldfax were all broken (dce fixed with another supportNF > >> >call, no luck yet with the others). Talking to DPD, suppliers of Goldfax,K > >> >they've got a similar problem with another customer, who's identified0 theaF > >> >VMS731_SYS02 patch as causing his problem, which was released at roughly4 > >the8 > >> >same time, and is presumably a very similar patch. > >> >J > >> >Is anyone aware of any problem with this patch ? Is there a fix ? Is
 > >backing > >> >out advisable ?  > >>> > >"Peter LANGSTOEGER" <peter@langstoeger.at> wrote in message/ > >news:04nI9.33974$A9.507750@news.chello.at...hL > >> We read about problems with this (both) patch(es) some days ago here in > >COV.tK > >> That's why I noted these patches as On-Hold (though they are still notl !)! > >> in my very private ECO list.c > >>I > >> I must however admit that I have VMS73_SYS05 already installed on my: PWS H > >> and I so far haven't seen problems on this machine (though my DNEWS NNTPE > >> server still dies every night at ~2am with memory exceeded - buts because H > >> I installed DNEWS some days after VMS73_SYS05 I can't blame the ECO yet).i > > L > >I've still heard nothing 'official' about VMS73_SYS05, although there was a ) > >VMS731_SYS02 problem which I'd missed.a > D > In the meantime a modification to the release notes of VMS73_SYS05 arrived.F > It mentions problems caused by a change im memory allocation (eg. in BRKTHR)"E > and that you better increase CTLPAGES until the next ECO comes out.o >'H > >I've a workaround for the important faxes, so we've waited to reboot. > >1I > >Pathworks, according to the pathworks group in the Netherlands, should> nevercI > >have worked, because it should be configured for 32 users, even though.K > >there's only 1 licence. The fact that it's worked for years like that is H > >apparently some kind of miracle, and the fact that it's now broken is) > >nothing to do with anything, they say.  > > I > >TSC (UK) has advised me to back out VMS73_SYS05, as it's implicated by  the)C > >timing. There also seem to be one or two other anecdotes, here & 
 elsewhere.K > >I've a reboot window for Saturday night, so I'll be backing it out then.S >N* > Maybe try the CTLPAGES approach first... >,; > eg. http://ftp.digital.com.au/pub/ecoinfo/ecoinfo/934.htm  >t > -- > Peter "EPLAN" LANGSTOEGER ' > Network and OpenVMS system specialistf > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Mon, 16 Dec 2002 16:13:56 -0000v2 From: "Chris Sharman" <chris.sharman@sorry.nospam>I Subject: Re: VMS73_SYS05 (& VMS731_SYS02) kills dce, pathworks, goldfax ?"4 Message-ID: <atku47$dhc$1$8300dec7@news.demon.co.uk>   "Chris Sharman" wrote:K > I've still heard nothing 'official' about VMS73_SYS05, although there wase aA( > VMS731_SYS02 problem which I'd missed. > G > I've a workaround for the important faxes, so we've waited to reboot.   F Deinstalled (manually) & rebooted on Saturday night, & all's well with goldfax now.G Didn't try the ctlpages fix, because it wasn't quantified, & I couldn'tr% afford to spend hours messing around.e  H > Pathworks, according to the pathworks group in the Netherlands, should neverDH > have worked, because it should be configured for 32 users, even thoughJ > there's only 1 licence. The fact that it's worked for years like that isG > apparently some kind of miracle, and the fact that it's now broken isw( > nothing to do with anything, they say.  5 Pathworks now pinned down (nothing to do with SYS05):r6 the license_r procedure starts up with a bad default (H pwrk$logs:[wherever.you.start.it.from] ), which our sylogin was tripping over:  $ here := 'f$env("default")'A $ if f$trnlnm("sys$login").eqs."" then $ def/job sys$login 'here'?B $ if f$trn("sys$scratch").eqs."" then $ def/job sys$scratch 'here'/ $ if f$trnlnm("sys$login_device").eqs."" then -m6  $ def/job sys$login_device 'f$parse(here,,,"device")'  K The last line here failed with %DCL-W-INSFPRM, whereupon poor SYLOGIN triedgK to show symbols to a scratch file to mail them to the sysmgr, and of course&( the scratch area wasn't much use either.  J Whether SYLOGIN shouldn't expect a default directory (or sys$login_device,F or whether it's a pathworks or vms problem, is still under discussion.   Chrisr   ------------------------------  # Date: Sun, 15 Dec 2002 14:29:09 GMTi+ From: Jeff Cameron <JCam90502@jcameron.com> Y Subject: Re: Why does BACKUP/IMAGE need write access to INDEXF.SYS,	BITMAP.SYS?	BITMAP.SYm2 Message-ID: <BA21D1B4.246E%JCam90502@jcameron.com>  F On 12/12/02 5:00 PM, in article 12DEC200219593513@gerg.tamu.edu, "Carl$ Perkins" <carl@gerg.tamu.edu> wrote:  1 > John Laird <john@laird-towers.org.uk> writes...dJ > }On 12 Dec 2002 14:09:23 -0800, spamsink2001@yahoo.com (Alan E. Feldman)	 > }wrote:c > } 1 > }>In the documentation for BACKUP/IMAGE it saysa > }> > }>{eJ > }>To use the /IMAGE qualifier, you need write access to the volume indexE > }>file (INDEXF.SYS) and the bit map file (BITMAP.SYS), or the input0? > }>medium must be write-locked. BACKUP opens the index file to.F > }>synchronize with the file system (no update is made). Finally, you; > }>must have read access to all files on the input medium.  > }>}i > }>A > }>Just what does it mean to "synchronize with the file system"?  > } O > }That "the file system" (XQP/RMS etc) is not set up for shared writing ?  I'dhJ > }guess, without checking, that it has a null lock on INDEXF.SYS which itK > }converts up when it needs to write.  If so, and BACKUP/IMAGE takes out a O > }write lock for as long as it needs to build its image of the disk structure,oL > }then file system updates will be blocked and only disk writes to existingF > }allocated data blocks will be allowed.  In other words, no files orC > }directories should appear or disappear.  Which is what you want.c > }  > }  > }    Johnm > E > That is not the case. It is entirely possible (and not uncommon) toeG > run an image backup on an active disk. This does not interfere in anyoJ > way with file or directory creation, extension, or deletion - you can doF > any or all of these things while the image backup is running. It mayH > be possible that it could set things up to be notified if they happen, > but it doesn't seem to.e > H > I don't know what they mean by that phrase, but I expect that they areJ > at the very least flushing the FID cache to disk and probably some other > things along those lines.e > 
 > --- CarlH I believe what John has said is correct. The INDEXF.SYS file is open forJ write access as to prevent any changes to the file system while the backupJ image makes a complete mapping of the file system in it's internal tables.L This is done prior to writing to the output saveset. It is true that you canK still do operations to disk at this time, because the volume is not locked, L only the index file. Thus changes can be made to header cache, in memory, toH be written when Backup releases write access to the index file (which isC done just prior to writing the output saveset). You will find that,hJ depending on the size of your SYSGEN parameter ACP_HDRCACHE, if the numberK of header changes exceeds this amount, then the volume will be locked until ) the backup image releases the index file.r  L The backup image must synchronize with the on disk file system (which is notK necessarily the active XQP file system) and maintain essentially two copies I of the INDEXF.SYS internally. One is the original INDEXF.SYS, so it knowscG where to get all the files and it's fragments from the disk volume wheneJ writing the output saveset, and a second one which is optimized to reflectK the manner in which the files are written in the saveset with all fragments.I and extension headers removed. This second copy is what is written to therD saveset which is ultimately the base form for the INDEXF.SYS that is: restored from the saveset to the new target output volume.  J Once the backup image begins writing to the output saveset, the index fileG is no longer open for write access by the backup image, allowing cached]K changes to be written. Backup then access the index file through the normalHI XQP file system calls. If some of the cached changes that were made whileoJ the index file was locked involve the deletion of files or directories, byL the time the backup image gets to the point of processing the missing files,L you will receive an error indicating the files do not exist. The interestingJ thing here is because the backup image has a complete mapping of where theD files are, if any of the cached header changes are renaming files orG directories to a different location or name, you will not get any errordF messages when the backup image is processing those files to the output saveset.   Jeff Cameron www.jcameron.com/vms/n   ------------------------------  # Date: Mon, 16 Dec 2002 13:24:45 GMT + From: Jeff Cameron <JCam90502@jcameron.com> T Subject: Re: Your Multi-volume Tape Backups may be bad on all versions of	VMS	VMSVMS2 Message-ID: <BA231416.24B5%JCam90502@jcameron.com>  I On 12/15/02 4:10 PM, in article eWN7e0uKT9pL@elias.decus.ch, "Paul Sture"s <p_sture@elias.decus.ch> wrote:k  A > In article <BA21D9DA.2470%JCam90502@jcameron.com>, Jeff Camerone" > <JCam90502@jcameron.com> writes:O >> Attention : Your Multi-volume Tape Backups may be bad on all versions of VMSe >> through VMS 7.3-1.D > G > Never heard of MME. I severely doubt that what you say above is true.s; > Does "all versions of VMS though VMS 7.3-1" include V3.0?E > F > Please give us an official Compaq/hp reference, rather than your own > email address. > C > Sorry if I sound sceptical, but I have successfully restored from B > multi-volume backups on many occasions, all the way from V3.0 toB > V7.3-1. I have never seen the errors you quote, except when they > have been true." >  > References please.I I will be more than happy to provide references. Please let me gather themH information. It would be improper for me to provide the names of the VMSF Backup Engineers that I worked with for about 4 months diagnosing thisL problem. If you are patient for when the patch is releases would the releaseJ notes be sufficient reference for you? Otherwise the only references I canI provide are emails between myself and the VMS engineers involved with the - dumps of tape volume headers as test results.c   Jeff Cameron   ------------------------------  # Date: Mon, 16 Dec 2002 13:31:50 GMTu+ From: Jeff Cameron <JCam90502@jcameron.com> T Subject: Re: Your Multi-volume Tape Backups may be bad on all versions of	VMS	VMSVMS2 Message-ID: <BA2315C5.24B7%JCam90502@jcameron.com>  H On 12/15/02 6:44 PM, in article $qFKUYi5A4PV@tachxxsoftxxconsult, "Wayne9 Sewell" <wayne@tachysoft.xxx.134848.killspam.00ac> wrote:.  A > In article <BA21D9DA.2470%JCam90502@jcameron.com>, Jeff Cameron " > <JCam90502@jcameron.com> writes: >  >  >> aJ >> Known third party software products that use MME are Software Partners'H >> TapeSys, and MTI's TAPEControl. Some of Compaq/HP's integrated backupL >> solutions also use MME. Contact the support for your software product for >> absolute determination. >> r >  > M > Really?  I did not know that tapesys uses mme.  Since I've been the primaryeI > tapesys developer since sometime in 1996 I probably *should* know this.p >  > N > Tapesys uses straight vms backup with its *own* wrappers around it.  It doesM > not use mme.  A search of sp32_master_disk:[sp32_master.tapesys.sources...]0 > for3D > mme gets no hits except for extraneous ones such as "immediately". > M > Volume switching at end of reel, including dynamic allocation of reels from. > the M > tapesys database, is handled by the tapesys processes sysbak and sbpoll, on  > request from vmsbu.o > O > On systems running vms 6.x or ealier, tapesys runs vmsbu.exe as a subroutine, O > using a standard backup command line.  No mme-related qualifiers are used, if 
 > such exist.  >  > M > On 7.x systems, tapesys uses the backup API.  No mme-related parameters ares > passed in the parameter list.s >  >  Wayne,  J I humbly beg your forgiveness, and I retract my statement the Tapesys usesK MME as I am 100% incorrect in this matter. I based my statement on the wordoC of a user of Tapesys who said that Tapesys does provide support for L multi-volume backup replication, and based on that I concluded that it wouldJ use MME just as Compaq/HP's backup services and MTI's TapeControl both do.   Please accept my apologies.l Jeff Cameron   ------------------------------  % Date: Mon, 16 Dec 2002 15:19:56 +0100 E From: Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de>uM Subject: Re: Your Multi-volume Tape Backups may be bad on all versions of VMSw+ Message-ID: <3DFDE10C.B9D91A01@mediasec.de>t  L > %BACKUP-W-NOT1STVOL, <tape-device>:[000000]*.*; is not the start of a save > set1 > orL > %BACKUP-I-WRONGVOL, <tape-device>:[000000].; is not the next volume in the > setu  J The first one is routine when you mount the non-initial tape, knowing thatM what you want to restore is on them; in my experience, this is just a warning2" that doesn't preclude restoration.  K The second is informational, although I don't know what happens then - doesl7 the restore abort because of an informational message?!s   	Jan   ------------------------------  % Date: Sun, 15 Dec 2002 21:19:02 +0100d5 From: "Chris Clifford" <chris.clifford@openvms.co.uk> E Subject: Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]-, Message-ID: <3dfce3cc$1@news.swissonline.ch>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3DFC05AE.D8818B96@fsi.net...1  E > Neither is the quality of the service we pay for, in certain cases.  >0H > We have some local guys here who quite excellent. They are, of course,< > well above average for that reason. "Average" can be quite" > disappointing, indeed, at times.  H I can't remember any time either in the UK or Switzerland that I've come2 across a poor Digital/Compaq/HP hardware engineer.  G However, I was a bit shocked when I flew to the States to work on a new0K cluster installation. We had two DS20's delivered and it should have been auE simple task to install them in the newly purchased Compaq cabinet andw. connect them up with shared SCSI interconnect.  L The engineer that turned up onsite had never worked on AlphaServers before -I seriously. We showed him how to connect the SCSI cables together, advisedhI him what to do with the two SCSI Y cables and terminators that were 'leftfI over' after the installation (and it was very tempting to suggest that heOH stuck them somewhere else!) and also (after digging out the docs myself)J showed him how to set the DIP switches on the shelf personality modules so* that there wasn't any termination mid-bus.  . Not impressive, but I hope that was a one-off.   - Chris.   ------------------------------   Date: 16 Dec 2002 13:03:15 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)E Subject: Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]n6 Message-ID: <atkiuj$14kk9e$1@ID-135708.news.dfncis.de>  ( In article <3DFD44A0.7040904@rdrop.com>,( 	Dean Woodward <deanw@rdrop.com> writes: > Stuart Fuller wrote:  >> norm.raphael@metso.com wrote: >> f >>>Actually, that should read: >>>n8 >>>Q: How does a Field Service Engineer fix a flat tire?D >>>A: He keeps swapping in spares until he gets the four good tires. >>$ >>>The second one is just not funny. > ' >> Actually, neither of them are funny.P > I > You're right, it's not funny.  But I've seen problems solved with that  B > approach, all too frequently.  And note that I didn't specify a E > company- I've seen the same basic methodology applied by FSE's (or i1 > whatever the title) from all the major players.c >   J Bet you never considered that you might be the problem.  Your expectations4 are just way to high.       :-)   well, actually :-(  D You wouldn't believe the looks of surprise a few weeks ago when someB of the faculty and students came into my research lab and found meG sitting over a VS3100 motherboard with a hot soldering iron in my hand. I And we won't even go into the PDP-11/44 with it's power supply all pulledtG apart.  But then, board swapping on most of these boxes isn't really an- option.   G It's yet more fallout from the PC revolution.  Repair is now synonomouse with board-swapping.   bill   -- oJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   c   ------------------------------    Date: 16 Dec 2002 07:13:23 -0600+ From: young_r@encompasserve.org (Rob Young)tE Subject: Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]h3 Message-ID: <K1aVh6kfEika@eisner.encompasserve.org>i  a In article <atkiuj$14kk9e$1@ID-135708.news.dfncis.de>, bill@cs.uofs.edu (Bill Gunshannon) writes:.* > In article <3DFD44A0.7040904@rdrop.com>,* > 	Dean Woodward <deanw@rdrop.com> writes: >> Stuart Fuller wrote:e! >>> norm.raphael@metso.com wrote:  >>>  >>>>Actually, that should read:) >>>>9 >>>>Q: How does a Field Service Engineer fix a flat tire? E >>>>A: He keeps swapping in spares until he gets the four good tires.r >>>o% >>>>The second one is just not funny.  >> c( >>> Actually, neither of them are funny. >>  J >> You're right, it's not funny.  But I've seen problems solved with that C >> approach, all too frequently.  And note that I didn't specify a aF >> company- I've seen the same basic methodology applied by FSE's (or 2 >> whatever the title) from all the major players. >>   > L > Bet you never considered that you might be the problem.  Your expectations6 > are just way to high.       :-)   well, actually :-( > F > You wouldn't believe the looks of surprise a few weeks ago when someD > of the faculty and students came into my research lab and found meI > sitting over a VS3100 motherboard with a hot soldering iron in my hand.hK > And we won't even go into the PDP-11/44 with it's power supply all pullednI > apart.  But then, board swapping on most of these boxes isn't really anS	 > option.n > I > It's yet more fallout from the PC revolution.  Repair is now synonomous  > with board-swapping. >   F 	Funny... very similar conversation came up yesterday.  A fellow about> 	my age (few years older) told me a how he told his sons aboutB 	TV repairmen.  They used to come to your house and fix the TV.  IB 	remember that too.  A giant toolbox with tubes in it , taking theC 	correct one out for the burnt one.  That then became the homeownernF 	finding the burned out one and going to RadioShack and matching it upD 	(of course many still called TV repairmen).  Today there is nothingF 	but a hand full of printed circuit boards.  Thing breaks, get another 	one.    				Rob    ------------------------------  % Date: Mon, 16 Dec 2002 10:52:11 -0800n% From: Dean Woodward <deanw@rdrop.com>aE Subject: Re: [OT] Humor - was [Re: AlphaServer 4100 Power-Up Problem]p& Message-ID: <3DFE20DB.20500@rdrop.com>   Bill Gunshannon wrote:I > It's yet more fallout from the PC revolution.  Repair is now synonomous  > with board-swapping.  C You know, if a FSE showed up (having logged into FIELD to get some sE diagnostic info), swapped a board (or two), and actually _fixed_ the 0= problem on the first go-round, I'd be perfectly OK with that.r  G In a similar vein, I'd be happy if we paid to have an FSE come hook up gF a new piece of equipment, and they actually had a clue about the gear E at hand _in advance_ of showing up to do the work.  Next time I have ,G to show an FSE type how to do something, I swear I'm going to send his w boss an invoice for _my_ time.  = DISCLAIMER: Not all field service people I've dealt with are h? unfamiliar with what they're supposed to be doing or just flat e* incompetent- but the trend is on the rise.   ------------------------------   End of INFO-VAX 2002.694 ************************