🚀 go-pugleaf

In article <D0H115.61J@world.std.com>, mew@world.std.com (Michael E Willett) writes...
>What's the substance of that blistering Computer Reseller News
>attack on the Storage Works RAID that CRN had in for its product
>review, as described in last week's issue?  Has DEC suspended shipments 
>of its RAIDs, and, if so, what is going on?  What's the timeframe for
>ECOs to correct the problems?  Is there going to be a press release
>on this to explain what is going on?  If not, why not?  What's Palmer's
>position on this?

I am not in a position to provide a formal reply just now but have 
asked folks that are in such position for help replying here,
notably to come up with a contact point.

From what I gather it is a recently found (at Comdex :-( before eyes of CRN
reporter ?!), rare, problem around raid-5 rebuilds (those themselfs already
being rare one hopes).  A Read-me-first has been created for new to be 
shipped sub-systems and an ECO & communications package is activly worked on.

Hope this helps a little,	+--------------------------------------+
Hein van den Heuvel, Digital.	| All opinions expressed are mine, and |
  "Makers of VMS and other	| may not reflect those of my employer |
   fine Operating Systems."	+--------------------------------------+

In article <D0H115.61J@world.std.com>, mew@world.std.com (Michael E Willett) writes:
|>What's the substance of that blistering Computer Reseller News
|>attack on the Storage Works RAID that CRN had in for its product
|>review, as described in last week's issue?  Has DEC suspended shipments 
|>of its RAIDs, and, if so, what is going on?  What's the timeframe for
|>ECOs to correct the problems?  Is there going to be a press release
|>on this to explain what is going on?  If not, why not?  What's Palmer's
|>position on this?
|>
|>Mike Willett
|>Storage Computer Corp.
|>11 Riverside Street
|>Nashua, NH 03062
|>Tel. 603-880-3005
|>Fax  603-889-7232

Mike, don't you ever give up?  If you WANT Palmer's opinion, ask HIM.  Last
time I checked, he doesn't follow this newsgroup.  Sheesh...
+---------------------------------------------------------------------------+
| Larry Stefani                               stefani@yesway.lkg.dec.com    |
| Networks Engineering                        Digital Equipment Corporation |
|                       Comments are mine, of course...                     |
+---------------------------------------------------------------------------+

In article <D0H115.61J@world.std.com>, mew@world.std.com (Michael E Willett) writes...
> [FUD?]
> 
>Mike Willett
>Storage Computer Corp.
>11 Riverside Street
>Nashua, NH 03062
>Tel. 603-880-3005
>Fax  603-889-7232


This wouldn't be by any chance the same company that 'John O'Brien' works for??



Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer 
Homewood Computing Facilities - Johns Hopkins University, Balto. Md. 21218 
Arrr, there's a worthy vessel! Surely this is the yarest craft I've ever set
eyes on... Arrr, I don't know what I'm talking about... - the 'captain'

In article <D0H115.61J@world.std.com>, mew@world.std.com (Michael E Willett) writes:
>
>What's the substance of that blistering Computer Reseller News
>attack on the Storage Works RAID that CRN had in for its product
>review, as described in last week's issue?

Which RAID was it?  We have:

HSZ10 - SCSI/SCSI (RAID 0, 1, 0+1, 3 and 5)
SWXCR - EISA/SCSI (RAID 0, 1, 0+1, 5)
HSZ40 - SCSI/SCSI (RAID 0 and 5)
HSD30 - DSSI/SCSI (RAID 0 and 5)
HSJ30 - CI/SCSI (RAID 0 and 5)

StroageWorks RAID Software (host based Striping and RAID-5 for VMS)
Polycenter Striping (RAID 0 for VMS)
ULTRIX Shadowing (RAID 1)
ULTRIX Striping (RAID 0)
OSF Shadowing (RAID 1)
Logical Storage Manager (RAID 0, 1 and 0+1)

From what's I heard it was a problem with the SWXCR used in the
DEC 2100 systems.  All the others should be alright.

>
>Mike Willett
>Storage Computer Corp.
>11 Riverside Street
>Nashua, NH 03062
>Tel. 603-880-3005
>Fax  603-889-7232
>
>         Demoing I/O-accelerated, lightning-fast storage at DECUS
>                         Typically 10 GB-1000+ GB
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

In article <3c7nkl$jbv@nntpd2.cxo.dec.com>, alan@nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.) writes:

In response to Mike Willett's question about one of RAID products, I
asked which product and listed many of the products.  I had intended
for the list to be fairly complete for UNIX and VMS, but I missed a
few:

Phase I shadowing on VMS and the HSC disk controllers.
Phase II Shadowing on VMS.
File Striping using the Advanced File System on OSF/1.
File Striping for VMS available as an ASSET.
Volume Striping for Alpha/VMS systems; an ASSET.

In article <D0H115.61J@world.std.com>, mew@world.std.com (Michael E Willett) writes:
|>What's the substance of that blistering Computer Reseller News
|>attack on the Storage Works RAID that CRN had in for its product
|>review, as described in last week's issue?  Has DEC suspended shipments 
|>of its RAIDs, and, if so, what is going on?  What's the timeframe for
|>ECOs to correct the problems?  Is there going to be a press release
|>on this to explain what is going on?  If not, why not?  What's Palmer's
|>position on this?
|>
|>Mike Willett
|>Storage Computer Corp.
|>11 Riverside Street
|>Nashua, NH 03062
|>Tel. 603-880-3005
|>Fax  603-889-7232
|>
|>         Demoing I/O-accelerated, lightning-fast storage at DECUS
|>                         Typically 10 GB-1000+ GB
|>


    I'm one of the technical support consultants with Digital's Storage 
    Business Unit.  I'll try to explain the problem you're referring to.

    First, it's important to know that the problem only occurs in the RAID
    Array 210 subsystem environment.  No other StorageWorks subsystems are
    affected.  The RAID Array 210 has a feature few RAID systems
    have, which is unprompted rebuild-after-replacement. In other words,
    the user/operator can stick in a replacement drive and just walk away
    without hitting any buttons or keys.  What we've found is that there
    was a design margins problem where a chain of events and interactions
    could lead up to a very small percentage of RAID Array 210 storage
    subsystems not automatically rebuilding.  The pieces involved in the
    chain of circumstances are the controller module fault management
    circuit, the SCSI backplane connector and the disk drive carrier flex
    circuit.  When the problem occurs and the automatic rebuild does not
    take place, then the user/operator has to do the rebuild  manually.
    This has always been possible and is explained in the user manual. But
    now, we recommend that users always check for automatic rebuild after
    a disk failure/replacement, and use the manual procedure if necessary. 

    It took a week or two after Comdex to figure out what was going on with
    the product, but now that we understand the chain of circumstances
    we've been able to break the links, so to speak.  Components are being
    screened to eliminate the tiny percentage that could allow the problem
    to happen.  The screening is being done to shipments from Digital and
    to units at resellers.    We've also published a procedure for
    users/operators so they don't unknowingly operate a RAID Array 210 in a
    non-redundant mode.  We're continuing the analysis to see if other
    precautions are needed. 

    Hope this clarifies what's going on.  If you have some of this product
    or if you support someone who does, get in touch with a Digital
    Customer Services account representative if you need any help.

    Chet