/ INFO-VAX	Sun, 02 Jan 2005	Volume 2005 : Issue 3       Contents:9 Re: (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster 9 Re: (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster  Re: Battersea Power Station = Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images = Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images = Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images 6 DEC Windows / Powerstorm 300 / DS10L Freeze on startup: Re: DEC Windows / Powerstorm 300 / DS10L Freeze on startup Re: DS20 Internal SCSI question  Re: Migration from SCSI to EMC Re: Migration from SCSI to EMC Re: Migration from SCSI to EMC Re: Migration from SCSI to EMCB Re: need help in decoding VAXstation 4000/60 console error message* Re: Older StorageWorks Parts Not Available Re: VMS and digital cameras  Re: VMS and digital cameras  Re: VMS and digital cameras   F ----------------------------------------------------------------------  % Date: Sat, 01 Jan 2005 14:11:43 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>B Subject: Re: (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster+ Message-ID: <41D703FF.DEBBE94A@comcast.net>   / Phillip Helbig---remove CLOTHES to reply wrote:  > F > I gather that /POLICY=MINICOPY allows for a faster shadow copy (justI > writing blocks which have changed, rather than the whole disk) when one F > dismounts one member of a shadow set then remounts it.  This happensD > from time to time in my cluster when I reboot a node which has oneB > member of a shadow set on it and another member on another node. > I > I asked some questions about this topic a while back, but never got the G > feeling I understood under which circumstances I can make use of this 
 > feature. > D > I have a mixed VAX-ALPHA cluster.  ALPHA is 7.3-1, VAX is 7.3, allI > patches applied.  Except for system-disk and swap/page shadow sets, all F > logical disks consist of a shadow set of two physical disks with theH > members hosted by different nodes.  All physical disks are MSCP servedJ > to all nodes and all shadow sets are mounted by all nodes.  All physical9 > disks have a direct (SCSI) connection to only one node.  > F > Thus, either both members are on ALPHA, both are on VAX or one is onH > ALPHA and one is on VAX:  3 possibilities.  I can issue the (DIS)MOUNT@ > command from an ALPHA or a VAX: 2 possibilities.  That makes 6F > combinations.  (I'm assuming that it doesn't matter if the node fromG > which I issue the command hosts 0, 1 or 2 members of the shadow set.)  > I > Which of these 6 combinations will allow me to make use of the MINICOPY 
 > feature? > J > I have never used this qualifier.  In order to make use of it, do I haveI > to start out by MOUNTING a shadow set with /POLICY=MINICOPY (and if so, J > is it OK if it is already mounted, or do I have to dismount it first) orH > can I just dismount a member and benefit from the fast copy when I add > it back into the shadow set? > I > In some cases, there will be open files on the shadow set.  Presumably, I > I can get one physical member dismounted despite the open files, right? H > (In the case of a reboot, presumably I won't have to worry about this,; > at least if the shadow set was initially MOUNTed with the % > /POLICY=MINICOPY qualifier, right?)  > G > Is it currect that MINIMERGE, as opposed to MINICOPY, is not in 7.3-1 ( > but is in 7.3-2 (or a patch to 7.3-2)?  A Based on past posts, first guess time is that the presence of the H VAX(es) in the cluster will preclude the use of minicopy (no support forF the necessary write bitmaps in OpenVMS-VAX), unless the member devicesF are MSCP-served by the Alpha(s), and even then, it still may not work,; since the virtual devices are still present on the VAX(es).    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    ------------------------------   Date: 1 Jan 2005 23:51:56 -0500 / From: brooks@cuebid.zko.dec.nospam (Rob Brooks) B Subject: Re: (DIS)MOUNT/POLICY=MINICOPY in mixed VAX-ALPHA cluster- Message-ID: <OVHF4MJZfTdA@cuebid.zko.dec.com>   R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > H > Is it currect that MINIMERGE, as opposed to MINICOPY, is not in 7.3-1 ( > but is in 7.3-2 (or a patch to 7.3-2)?  I Host-Based Minimerge (HBMM) is available for V7.3-2 via the latest UPDATE  kit.   --    M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com    ------------------------------  $ Date: Sat, 1 Jan 2005 15:51:40 -0500# From: "John Smith" <a@nonymous.com> $ Subject: Re: Battersea Power Station, Message-ID: <TeydnTAZ_JrEkErcRVn-sQ@igs.net>   Dr. Dweeb wrote: > Hi,  > D > Sometime ago someone responding on this newsgroup had a pointer toD > their photography site - name and site lost in the mists.  Anyway,A > there was a great picture (b/w) of the Battersea Power Station.  > @ > If you spot this you might leave me the address.  I am perhaps0 > interested in acquiring a print (a large one).  L http://groups.google.ca/groups?q=Battersea&hl=en&lr=&newwindow=1&group=comp.L os.vms&safe=off&selm=1102412203.365740.35030%40f14g2000cwb.googlegroups.com& rnum=1     http://www.ajphoto.info/   ------------------------------  $ Date: Sat, 1 Jan 2005 14:00:15 -0500) From: "Neil Rieck" <n.rieck@sympatico.ca> F Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large Images; Message-ID: <lrCBd.69994$Tn1.2222960@news20.bellglobal.com>   A "Craig A. Berry" <craigberry@mac.com.spamfooler> wrote in message > news:craigberry-E2F14A.10162801012005@news.isp.giganews.com...D > In article <1104525457.285867.10110@c13g2000cwb.googlegroups.com>,, > "Rich Faust" <faustrj@fastspot.net> wrote: > D >> Anyone else using CSWS V2.0 with MultiNet V5.0 on OpenVMS V7.3-2? >>/ >> If so, any problems displaying large images?  > H > Are the files in stream format?  Be sure to read the know problems andB > restrictions section of the release notes, currently located at: > K > http://h71000.www7.hp.com/openvms/products/ips/apache/csws_relnotes_20.ht 
 > ml#known >  > (unwrap that if necessary)  F A few months back, I encountered a file-size problem with CSWS-2.0 andK TCPware (which is a sister product to MultiNet since they are both produced L by Process Software Corp.). I reported the problem to PSC and they respondedL with patch "DRIVERS_V562P051". So my advice to you is to make sure you have M the most recent MultiNet patches installed then report the problem to PSC if   this doesn't help.  ? Referring them to the TCPware patch I just referenced may help.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.htmlH http://www3.sympatico.ca/n.rieck/docs/csws_tips.html#sws20 CSWS-2.0 tips   ------------------------------   Date: 1 Jan 2005 16:34:05 -0800 ) From: "Rich Faust" <faustrj@fastspot.net> F Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large ImagesC Message-ID: <1104626045.060255.211490@z14g2000cwz.googlegroups.com>   C I wondered about that, so before I posted my original note I took a G closer look at APACHE$COMMON:[000000]APACHE$CONVERT_STREAMLF.COM.  This G tool is called by APACHE$MENU to convert a directory tree to Stream_LF. 9 The convert procedure references the following data file:    # APACHE$CVT_TYPES.DAT # ( #       File types that get converted by APACHE$CONVERT_STREAMLF.COM  #   < .HTM*           #All HTML files (.HTM, .HTML, .HTML.FR, etc)% .SHTML          #Server-side includes  .TXT            #All TXT files  F I take the contents of this file to mean that .JPG files should not beD converted to Stream_LF, so I don't believe the format of the file is the problem.  
 Rich Faust OpenVMS Hobbyist Richmond, TX   ------------------------------   Date: 1 Jan 2005 16:39:21 -0800 ) From: "Rich Faust" <faustrj@fastspot.net> F Subject: Re: CSWS 2.0 + MultiNet 5.0 - Problem Displaying Large ImagesC Message-ID: <1104626361.819363.289070@c13g2000cwb.googlegroups.com>   E I double-checked the Process web site before posting my original note G and confirmed that all current/available patches for MultiNet V5.0 have F been applied to my system.  I've also cross-posted my original note toE the MultiNet news group.  I'm not sure how similar the code bases are C for TCPware and MultiNet, but will keep an eye on the MultiNet news - group to see if anyone from Process responds. 
 Rich Faust OpenVMS Hobbyist Richmond, TX   ------------------------------   Date: 1 Jan 2005 13:04:07 -0800 2 From: dugald_peacock@yahoo.com.au (Dugald Peacock)? Subject: DEC Windows / Powerstorm 300 / DS10L Freeze on startup = Message-ID: <fcdcb36b.0501011304.7abf01c3@posting.google.com>   T > At what point does your monitor freeze ? What is displayed on it when it freezes ?  F It is only DEC windows that freezes.  I get the full logon screen withC HP logo. I have tried both the CDE and classic interfaces and I get  the same problem.   , The system works perfectly from the Vt510.    D I can logon via the vt510 from which I use the DCL reboot command toF reboot the system so that the DEC windows logon and DEC windows system works perfectly.  F If after powerup boot I try @sys$startup:decw$startup reboot and enter yes to the prompted question4 DEC windows restarts, but the logon is still frozen.  F I will try the changing the window_system value in SYSGEN and see if I learn anything from there.   Thanks   Dugald   ------------------------------  $ Date: Sat, 1 Jan 2005 20:45:03 -0500% From: "DAVID TURNER" <DAVID@HPAQ.NET> C Subject: Re: DEC Windows / Powerstorm 300 / DS10L Freeze on startup 0 Message-ID: <10tek318m9i05cb@news.supernews.com>   dug   4 these are known problems with vms and the powerstormC My bet is you have an old firmware version (that can't be upgraded) K I had a customer with an old rev card about 18 months ago that had the same  problem J It turned out to be that card (you need rev F08 or higher rev on the boardA (firmware on altera chip should be D909) for it to work correctly    dt   --   Island Computers US Corp 2700 Gregory St Suite 180  Savannah GA 31404  Tel: 912 4476622 Fax: 912 201 0402  Email: dbturner@icusc.com     ? "Dugald Peacock" <dugald_peacock@yahoo.com.au> wrote in message 6 news:fcdcb36b.0412311948.8bd2cd4@posting.google.com... > Hi Group,  > H > I have a strange issue with a DS10L Alpha server with a Powerstorm 300- > video card installed running OpenVMS 7.3.2.  > C > When I boot the server from power up DEC windows on my monitor is B > frozen. Then if I reboot the server via a vt510 connected on the+ > console port DEC windows works perfectly.  > C > I have installed VMS taking all the defaults but initializing the E > disk.  I have installed no layered products or patches.  I have not ; > modified any startup files or configured DECnet or TCPIP.  > F > I have installed the hobbyist base VMS licence and dw-motif licence. > G > I have added MIN_GBLSECTIONS=1000 to modparams.dat and run autogen to A > remove the message about global sections on the booting of VMS.  > F > I have compared the DEC windows server error logs to see if there isA > any differences between the one created on power up and the one H > created after the software reboot.  There are no apparent differences. > H > This occurs each time I boot my alpha server from power up.  But works > perfectly after the reboot.  > ( > Does anyone know what is causing this? > C > What information would be useful to track down the source of this 
 > problem? >  > Wow - google has changed?????  >  > Dugald   ------------------------------  $ Date: Sat, 1 Jan 2005 18:05:31 -0500% From: "DAVID TURNER" <DAVID@HPAQ.NET> ( Subject: Re: DS20 Internal SCSI question0 Message-ID: <10teano8uqu9lb4@news.supernews.com>  L if it's serving internal disks it's a uscsi wide single ended card and not a fwd card  . you'll need a kzpba-cb for the tape controller   dt   --   Island Computers US Corp 2700 Gregory St Suite 180  Savannah GA 31404  Tel: 912 4476622 Fax: 912 201 0402  Email: dbturner@icusc.com     5 "John Brandon" <brandon@dalsemi.com> wrote in message + news:05010112071160@dscis6-0.dalsemi.com... H > I have a DS20 with a PCI SCSI servicing 2 internal disks drives (dka0, dka100). > % > I believe the device is a FWD card.  > K > I want to attach a TL89-2 to this card - thus I set the TL89-2 library to  SCSI! > bus ID 4, DLT0 to 5, DLT1 to 6.  > G > When I attach the TL89-2 and do an MCR SYSMAN IO AUTO the system disk  (dka0,' > dka100) goes into a MNT VERIFY state.  > 2 > Detach the TL89-2 and the disk goes back online. >  > What am I missing? >  >  > John "REBOOT" Brandon  > VMS Systems Administrator , > firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Sat, 01 Jan 2005 14:00:08 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: Re: Migration from SCSI to EMC + Message-ID: <41D70148.E99B5230@comcast.net>    Rob Brooks wrote:  > [snip]/ > Contact your SAN vendor for more information.   % Read: "OpenVMS does not support EMC".   F The burden of support falls to EMC, since EMC qualifies VMS with their9 gear, but VMS does not qualify third-party gear with VMS.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    ------------------------------  * Date: Sun, 2 Jan 2005 01:23:22 +0000 (UTC)% From: Dan Foster <usenet@evilphb.org> ' Subject: Re: Migration from SCSI to EMC 6 Message-ID: <slrnctejcf.gd7.usenet@gaia.roc2.gblx.net>  _ In article <41D70148.E99B5230@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  > Rob Brooks wrote: 	 >> [snip] 0 >> Contact your SAN vendor for more information. > ' > Read: "OpenVMS does not support EMC".  > H > The burden of support falls to EMC, since EMC qualifies VMS with their; > gear, but VMS does not qualify third-party gear with VMS.   B Yes, that's true. But please note a key comment that Mr. Mah made:  E : Interesting enough, the cluster's 4 local single-member SCSI system H : shadow disks have been spewing out the same messages since the clusterC : was updated to VMS 7.3-2 in Oct-2004, before the migration of the  : production shadows..  H In particular, he said this was an issue after installation of 7.3-2 and5 _prior_ to migration to the EMC, on local SCSI disks.   B Mr. Mah, I would suggest trying to reproduce the issue on a systemG without EMC disks, then call it in to VMS support. (And are you current   on all the relevant 7.3-2 ECOs?)  H And for the systems with the EMC disks going in MVTIMEOUT, you will want> to escalate that through EMC support, as others has suggested.   -Dan   ------------------------------  % Date: Sat, 01 Jan 2005 19:34:13 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: Re: Migration from SCSI to EMC + Message-ID: <41D74F95.2982C2B3@comcast.net>    Dan Foster wrote:  > a > In article <41D70148.E99B5230@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  > > Rob Brooks wrote:  > >> [snip] 2 > >> Contact your SAN vendor for more information. > > ) > > Read: "OpenVMS does not support EMC".  > > J > > The burden of support falls to EMC, since EMC qualifies VMS with their= > > gear, but VMS does not qualify third-party gear with VMS.  > D > Yes, that's true. But please note a key comment that Mr. Mah made: > G > : Interesting enough, the cluster's 4 local single-member SCSI system J > : shadow disks have been spewing out the same messages since the clusterE > : was updated to VMS 7.3-2 in Oct-2004, before the migration of the  > : production shadows.. > J > In particular, he said this was an issue after installation of 7.3-2 and7 > _prior_ to migration to the EMC, on local SCSI disks.  > D > Mr. Mah, I would suggest trying to reproduce the issue on a systemI > without EMC disks, then call it in to VMS support. (And are you current " > on all the relevant 7.3-2 ECOs?) > J > And for the systems with the EMC disks going in MVTIMEOUT, you will want@ > to escalate that through EMC support, as others has suggested.   ...and I'll second that.  C However, I will also caution that any site needing critical support = (i.e., VMS's primary market niche) should avoid EMC and other H third-party storage not explicity supported by OpenVMS Engineering. That@ is, if you can afford downtime, go for it. If not, play it safe.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    ------------------------------  # Date: Sun, 02 Jan 2005 05:44:50 GMT " From: Lee <lytmah@telusplanet.net>' Subject: Re: Migration from SCSI to EMC , Message-ID: <mTLBd.43498$KO5.33857@clgrps13>  < I know all about the support and qualification relationships; between EMC and VMS.  I've been dealing with this issue for  the last several years.   A Note that HP is the vendor of the four local single-member system < shadow disks sending out the same messages as the EMC disks.8 All disks in discussion are in a 5-node ES45 VMScluster.: HP has previously been called for assistance on the system9 shadow disk issue.  A patch will be applied this month to ; see if the problem for the 4 system disks and the EMC disks  can be resolved.  ? As for trying to reproduce the problem on non-EMC disks, that's & not feasible.  We have only SAN disks.     Dan Foster wrote: a > In article <41D70148.E99B5230@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> wrote:  >  >>Rob Brooks wrote:  >>	 >>>[snip] 0 >>>Contact your SAN vendor for more information. >>' >>Read: "OpenVMS does not support EMC".  >>H >>The burden of support falls to EMC, since EMC qualifies VMS with their; >>gear, but VMS does not qualify third-party gear with VMS.  >  > D > Yes, that's true. But please note a key comment that Mr. Mah made: > G > : Interesting enough, the cluster's 4 local single-member SCSI system J > : shadow disks have been spewing out the same messages since the clusterE > : was updated to VMS 7.3-2 in Oct-2004, before the migration of the  > : production shadows.. > J > In particular, he said this was an issue after installation of 7.3-2 and7 > _prior_ to migration to the EMC, on local SCSI disks.  > D > Mr. Mah, I would suggest trying to reproduce the issue on a systemI > without EMC disks, then call it in to VMS support. (And are you current " > on all the relevant 7.3-2 ECOs?) > J > And for the systems with the EMC disks going in MVTIMEOUT, you will want@ > to escalate that through EMC support, as others has suggested. >  > -Dan   --   Lee    lytmah@telusplanet.net   ------------------------------  * Date: Sun, 2 Jan 2005 04:19:46 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)K Subject: Re: need help in decoding VAXstation 4000/60 console error message $ Message-ID: <cr7sp2$u4t$1@online.de>  ; In article <9jFBd.353998$b5.17411840@news3.tin.it>, "-----"  <-----@-----.--> writes:    I > > Subject says it all; who can tell me what this means?  In particular,  > > " > > ??  130  10        SCSI   0034 >  > ??: failure is FATAL > 130: SCSI ID 3 > 10: SCSI controller ID > SCSI: mnemonic for SCSI :)" > 0034: Non-DMA inquiry has failed > + > it seems that (at least) disk 3 is broken   F Thanks.  After a few power cycles (always leaving the power off for a A couple of minutes), the VAXstation booted (which it is set to do  G automatically if it can) and the disk is now mounted on all 3 nodes in    the cluster and is working fine.   ------------------------------  % Date: Sat, 01 Jan 2005 13:54:45 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>3 Subject: Re: Older StorageWorks Parts Not Available + Message-ID: <41D70005.8CAB905F@comcast.net>    "Main, Kerry" wrote: >  > > -----Original Message-----= > > From: David J Dachtera [mailto:djesys.nospam@comcast.net] # > > Sent: December 30, 2004 6:24 PM  > > To: Info-VAX@Mvb.Saic.Com 7 > > Subject: Re: Older StorageWorks Parts Not Available  > >  >  > [snip] > H > > Centers which are within the same metropolitan area have no businessD > > using anything other than HP field service to deliver parts. ForJ > > example: (break out your maps) Delivery from Chicago to Oak Park (lessG > > than 8 miles from the lakefront to Oak Park's western-most border), G > > easily walkable within a day, drivable within two hours even in the D > > worst weather conditions) still takes five days via UPS standard > > (surface) service. > >  > F > Are you saying that it took 5 days to receive a part that was in the1 > same city??? I have a hard time believing that.   C In keeping with my newsgroup policy of "prove me wrong", try it for F yourself. Ship ANYthing from your office to your home via UPS standardH surface delivery (pka "brown label") - a box of staples, and old, broken> stapler, a roll of tape, whatever - and see how long it takes.  G ...take pictures - all sides - of the package leaving your facility and 1 when it arrives at its destination, then compare.   H In our case, the hardware ticket was opened on a Monday. The FSE broughtH a part on site that day (DOA), parts were (re-)ordered on a Tuesday, andH arrived the following Saturday evening. In the meantime, the FSE broughtG two more DOAs at 36-hour (approx.) intervals, for a total of five DOAs.   I > By the way - most Field Service companies these value their technicians F > time much more than a delivery van guy i.e. it is better to have theH > tech work on problem, talk to Customer, whatever.. As opposed to wasteE > tech time doing low level task like driving across town, picking up J > part, finding parking, signing back in again etc etc. Heck, even Digital/ > was doing this back when I was in CS Support.   D Really? For as long as I can remember, the FSEs have been siging outF parts before leaving for the customer site and bringing the parts withD them, if the FRU was known at that time, and once on site it *NEVER*F took more than 18 hours to get a part delivered (except for a "recent"F event with a GS160 part replacement which took over 26 hours - FSE was@ on-site the entire time), less for life-critical systems (as are  typically found in heatlthcare).  J > > > As to the DOA's, that obviously needs to be looked into to determineI > > > what happened. Typically what gets looked into are such things as : # > > > - Was it bad from the center?  > > 
 > > Good bet.  > >  > > > - Was it packed  > >  > > Yes. > > > and handled correctly? > > B > > Cannot be gauranteed. UPS is infamous for "package volleyball"* > > tournaments within their truck depots. > > < > > > - Was the installation of the part done by a qualified > > Field Engineer?  > >  > > Not a factor.  > > < > > > (need to consider things like static issues, quiescent > > buses properly= > > > before replacement, proper commands to be executed from  > > disk controllers > > > like HSx etc. )  > > B > > Must be done during uptime. "Quiescing", etc. is not possible. > 5 > Who did the parts replacement - CS or the Customer?  > J > If the disks were replaced by someone who did not follow the recommendedC > replacement procedures - which on some controllers do require bus J > quiescing (can be done on line at less busy time of day as I recall). OnJ > HSx controllers, you do also not simply swap bad drives with good drivesH > - there are specific HSx processes to move drives in and out of failed > sets etc.   @ Here again, and as noted earlier, all documented procedures wereC followed by qualified personnel. The parts were DOA. Period, end of 
 statement.   > > 7 > > > - Was the revision of the part an issue? Some new  > > equivalent parts mightH > > > have HW/SW compatibility issues with older systems that need to be6 > > > addressed before they can be installed properly. > > ; > > Should have been addressed before the part was shipped.  > H > So, tell me how the logistics person is supposed to know what firmwareE > you are running or what OS version / patch level you have in place.   H Thank you for underscoring my point so well. A "logistics person" has noD business being involved at that level (or any other, really, in this
 scenario).   > SomeH > new parts have incompatibility issues with older OS versions, firmwareH > etc. CS folks know these things and that is one of the reasons why forI > mission critical environments, one should have qualified CS folks doing  > the replacement.  ? ...and selection of parts to be shipped, not a trained UPS ape.   I > Now, perhaps CS did the replacements in your case, but I have seen more E > than a few cases where Customers think they can simply swap out the > > brick drives without understanding that there is more to it.   See the above.   > > = > > > - Has this part a history of problems or was it only at  > > this one site? > > + > > Multiple targets - question irrelevant.  > > ? > > > - What failure symptoms were seen i.e. were they the same  > > for each DOA > > > or were they different?  > > A > > All mostly different. Some never spin up, others spin up then 
 > > die, some   > > start to work then fail, ... > > * > > > - other issues looked at as well ... > > C > > ...and all covered in great detail. The parts were DOA. Period.  > >  > F > I am not saying they weren't, but getting that many bad DOA's of the& > same part seems awful strange to me.  ? To me, as well. Suggests a new height in the field of technical 
 incompetence.   H > As a former CS support resource, while one can obviousl;y not rule outG > some bad parts until you investigate it further, I would initially be F > looking for some common threads besides just immediately blaming theJ > Logistics center or those delivery guys who "are known for having volley" > ball tournaments with packages".  F Care to elaborate on that? Disk drives are designed to survive certainC G-force (impact) levels. What part of "package volleyball" suggests & proper handling of fragile components?  ? (By the way, "package volleyball" within UPS terminals has been H documented by the media, and has even been admitted by UPS itself. So, I7 will discount any claims of "anecdotal" on that score.)   @ > Improper eco levels (disk or controller), improper replacementC > procedures, not allowing disks to thermally stabilize after being J > outside in truck for awhile, not being aware of latest known issues withB > that particular disk and/or controller etc would all be areas to > investigate.   See the above.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    ------------------------------  % Date: Sat, 01 Jan 2005 12:50:25 -0600 . From: Alphaman <alphaman-nix-spam@alphant.com>$ Subject: Re: VMS and digital cameras5 Message-ID: <ThCBd.613$4G1.266@fe40.usenetserver.com>   F I went through this process several years ago and have settled on the F Sony Mavica series as my solution, initially using an FD80, and now a I CD400.  I am *very* happy with my camera, and have shot several thousand  G photos with it.  Skip the USB -- my Mavica CD400 writes directly to CD  $ in a VMS compatible ISO 9660 format.  I Just as a proof of concept, I just mounted a CD that came from my camera  A on my AlphaServer 400 (far from the state of the art) as follows:   $ YODA mou dka400 /media=cdrom /ov=id* %MOUNT-I-WRITELOCK, volume is write lockedE %MOUNT-I-CDROM_ISO, MV_20040320: (1 of 1) , mounted on  _YODA$DKA400:   YODA dir dka400:[dcim.100msdcf]    Directory DKA400:[DCIM.100MSDCF]  D DSC02300.JPG;1    DSC02301.JPG;1    DSC02302.JPG;1    DSC02303.JPG;1D DSC02304.JPG;1    DSC02305.JPG;1    DSC02306.JPG;1    DSC02307.JPG;1 :  : 2 DSC02460.JPG;1    DSC02461.JPG;1    DSC02462.JPG;1   Total of 159 files. - YODA xv DKA400:[DCIM.100MSDCF]DSC02462.JPG;1   F (and yes, xv properly displayed the image.)  I'm currently working on H rewriting my photo gallery software, porting it from my Alpha NT system F to OpenVMS.  I'll probably publish it on http://dcl.openvms.org/ when < it's done.  In the meanwhile, I'm using SPGM, PHP code from > http://spgm.sourceforge.net/, although it's pretty slow on my E AlphaServer 400.  (Drop me an email directly if you'd like to see my  G SPGM photo gallery -- I don't want to publish its address via NNTP for   obvious reasons.)   I The Mavica also records video in MPEG2 format, which is also viewable on   VMS.  F My early choice was based on my need for support on both Alpha NT and C OpenVMS.  This camera provided a complete solution with no special  B drivers required.  The only restriction I've found so far is that G OpenVMS does not support multi-session CD's, so if you want to shoot a  H few pics, finalize, publish, unfinalize, and shoot some more on one CD, I you won't be able to see subsequent sessions.  But if you are happy with  I shooting in large batches and finalizing the CD once, you won't have any  H problems.  And with the 8cm CDs costing way under $0.50 (US) in bulk, I B don't have a problem with even shooting a few pics and finalizing.  I The camera is large and bulky (after all, you've got a CD burner in it),  C but still very manageable.  I especially like the idea of having a  E "permanent" archive on CD the second I shoot an image.  I can easily  D carry about a dozen blank CDs in my camera bag -- that's over 2 gig  (~2,000 photos) for under $6.   D Oh, it does support USB, too, just in case you want to plug it into G someone else's computer.  Check them out at www.sonystyle.com; current  5 models go up to 5MP and have some very nice features.    Aaron       / Phillip Helbig---remove CLOTHES to reply wrote:   I > I'm considering moving from conventional 35mm film to a digital camera.  > I > However, I won't do so if it means that I have to use a computer of any D > sort other than one running VMS in order to get the files from theF > camera to a VMS machine.  Once they are there, I can view .JPG filesG > with a web browser, upload them to a photo-printing service if I want C > hard copies (probably cheaper than buying a printer of equivalent J > quality) and probably even burn them onto a CD (also useful for bringingF > in to a print shop and selecting which ones I want as hard copies).  > G > I don't know much about digital cameras yet.  Am I right in assuming  J > that USB is the de-facto standard?  Will USB be standard on all Itanium K > machines running VMS?  (Yes, this means I would have to wait for a cheap  ? > enough Itanium before I switch to the digital camera.)  When  G > transferring files from camera to disk, how dependent is one on some  F > software running on the target computer?  Presumably, such software K > won't be available for VMS.  How easy would it be to write one's own (in  @ > other words, is there a common, public, stable specification)? >    ------------------------------  * Date: Sat, 1 Jan 2005 19:40:09 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)$ Subject: Re: VMS and digital cameras# Message-ID: <cr6uap$f5$1@online.de>   > In article <ThCBd.613$4G1.266@fe40.usenetserver.com>, Alphaman( <alphaman-nix-spam@alphant.com> writes:   ? > And with the 8cm CDs costing way under $0.50 (US) in bulk, I  D > don't have a problem with even shooting a few pics and finalizing.  D Is the 8-cm CD a common format, likely to be around for a while?  (ID don't have a ruler handy, but I gather this is smaller than a normal CD.)    K > The camera is large and bulky (after all, you've got a CD burner in it),     Wow!  E > but still very manageable.  I especially like the idea of having a  G > "permanent" archive on CD the second I shoot an image.  I can easily  F > carry about a dozen blank CDs in my camera bag -- that's over 2 gig  > (~2,000 photos) for under $6.    Wow!  F > Oh, it does support USB, too, just in case you want to plug it into I > someone else's computer.  Check them out at www.sonystyle.com; current e7 > models go up to 5MP and have some very nice features.i  F Thanks for the info.  So, with this camera, I could take photographs, G have them all on CD automatically and immediately, and view this CD on  ( VMS, with no need for a PC at any stage.   What does this camera cost?i   ------------------------------  % Date: Sun, 02 Jan 2005 00:25:04 -0500t- From: JF Mezei <jfmezei.spamnot@teksavvy.com>e$ Subject: Re: VMS and digital camerasB Message-ID: <1104642925.71e08b13503a155e3e10aedd24d01d4f@teranews>   Alphaman wrote:oH > photos with it.  Skip the USB -- my Mavica CD400 writes directly to CD& > in a VMS compatible ISO 9660 format.  M Neat. But the fact remains that the "industry standard" is for gizmos such aseE cameras (and I suspect stuff like Ipods) to present themselves as FAT-3 structure disks. VMS would do well to support this.-   ------------------------------   End of INFO-VAX 2005.003 ************************