| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 1244.1 |  | NETCAD::STEFANI |  | Thu Jan 16 1997 14:33 | 34 | 
| 1244.2 | How to Escalate? | MSDOA::JDICKERSON |  | Thu Jan 16 1997 17:06 | 11 | 
| 1244.3 |  | NETCAD::FERGUSON |  | Fri Jan 17 1997 09:44 | 9 | 
| 1244.4 |  | NETCAD::STEFANI |  | Mon Jan 20 1997 11:33 | 13 | 
| 1244.5 | NT4 SP2 doesn't see DE435 | UTROP1::utodhcp-198-112-228.uto.dec.com::STOEKENBROEK | Rob Stoekenbroek@UTO | Tue Jan 21 1997 05:50 | 10 | 
| 1244.6 |  | NETCAD::FERGUSON |  | Tue Jan 21 1997 10:31 | 6 | 
| 1244.7 | Old Driver Better? | MSDOA::JDICKERSON |  | Mon Jan 27 1997 13:52 | 18 | 
|  |     Would love to report to Microsoft. The customer's scenario is that the
    Alpha "hangs" every 7-9 days. We now have a Sniffer@ onsite with a Rube
    Goldberg setup for triggering a stop. Basically, a client workstation
    is doing continuous "net view"'s to the Server. When the client can no
    longer detect the server( hopefully, at "hang time"), the client will
    start a ping from himself to another workstation on the lan. At the
    detection of traffic between these two the sniffer will stop capturing.
    Ron Branch at mail.dec.com is available for consulting on these and
    other issues.
    
    We have now run successfully 14 days without a "hang".
    
    We attribute this to a different driver. It is an older driver. It is
    almost half the size of the driver on the Microsoft dist. 4.0 cdrom.
    The driver we are using was installed on Mon. nite Jan. 13. The sniffer
    has not yet triggered and we are cautiously optimistic.
    
    
 | 
| 1244.8 | Call off the dogs | MSDOA::JDICKERSON |  | Fri Jan 31 1997 14:05 | 4 | 
|  |     Thanks for all the suggestions. Haven't gotten info back on them, but
    have found out through NT engineering that this problem has been
    reported on 3 other customer sites and they were looking for a
    work-around. Now they have it.
 | 
| 1244.9 | Only Workaround | SNOFS1::ELEFTHERIOU |  | Mon Feb 03 1997 19:37 | 7 | 
|  |     Is the only workaround to which you refer the use of the previous
    driver?
    
    Many thanks,
    
    Harry E.
    CSC-Sydney.
 | 
| 1244.10 | is there a de435.sys? | VMSNET::DMCFARLAND | still TurboMom[tm]... | Tue Feb 04 1997 13:21 | 7 | 
|  |     In note 1255, there is a discussion about the DE450.SYS driver which
    can replace the dc21x4.sys generic driver on the DE450 PCI card.  Is 
    there a DE435.SYS driver for the DE435 which would work in lieu of
    the dc21x4.sys?
    
    Diane
     
 | 
| 1244.11 | DC21X4.SYS only driver for DE435 | NETCAD::HILLER |  | Tue Feb 04 1997 13:43 | 7 | 
|  |     Sorry,
    
        The only driver available for the DE435 is the DC21X4.SYS driver.
    We have not done our own driver for that adapter.
    
    -Brent
    
 | 
| 1244.12 | 10-4 | VMSNET::DMCFARLAND | still TurboMom[tm]... | Wed Feb 05 1997 15:21 | 6 | 
|  |     Brent,
    
    That's exactly what I needed to know.  Thanx for the info.
    
    di
    
 | 
| 1244.13 | Driver file size | MSDOA::JDICKERSON |  | Thu Feb 06 1997 11:30 | 12 | 
|  |     The file size for the driver that is not hanging is:
    
    dc21x4.sys	44,544
    
    It is available in the de435 "release" area of
    http://ftp.digital.com/pub/DEC/adapters
    
    I understand the "interim" area has newer drivers, but unofficially
    (per an NT support engineer I talked to), the driver in the interim
    area did not fix the customer hangs at another site.
    
    22 days now without a hang. (previous customer record- 9 days)
 | 
| 1244.14 | one or both? | JUGHED::JOHN |  | Fri Feb 14 1997 08:26 | 5 | 
|  |     Is this just a 435 on Alpha problem?
    or is it also a problem on Intel with the 435?
    
    Thanks
    ted john
 | 
| 1244.15 | Final Solution | MSDOA::JDICKERSON |  | Wed Mar 26 1997 12:39 | 19 | 
|  |     Final Update from Engineering (C.A.P.E. #71WB12497)
    
    1. The problem only happens on Alphaserver 1000a
    
    2. Digital engineering will not fix it- Not cost effective
    
    3. Cost effective solution from engineering- A1000a's will now
       ship with DE500 and not DE435. Swap field problems with DE500.
    
    4. Digital engineering has notified Microsoft that our fix will be to
       ship DE500's instead of DE435's in the future. So, Microsoft has
       agreed to stop looking for a solution.
    
    ******Whatever it Takes ;)**** 
    
    
    This is final resolution. No more noting will I answer.
    
    Joel Dickerson
 | 
| 1244.16 | Formal Path for Elevating to Microsoft | CSC32::BINGHAM | Scott Bingham �� Windows NT / BackOffice Team, USCSC | Thu Apr 17 1997 17:17 | 60 | 
|  |                 Hello Joel et al,
                This is water under the bridge, but maybe I can
        help for next time, or maybe it will help for somebody
        else.
                Each country or region has a designated number of
        people who are authorized to make elevations to Microsoft,
        under our ASC (Authorized Service Center) agreement with
        Microsoft -- part of the AEC Alliance.  For USA-based
        field people, your formal elevation path is via the USCSC. 
        In the USA, You have two ways to access this path:
                  1.  You can call us directly as Mary Jo
                  suggested.
                  2.  You can log an elevation against
                  Windows NT software in IPMT or CLD or
                  CAPE, which will come to me and my
                  team.
                (People outside of the USA who wish to elevate to
        Microsoft should do so through their Country Support. 
        Please do NOT use a Digital elevation process as it will
        come to me instead of going to your local Country Support
        people.)
                In this particular technical issue, the problem
        was brought to my attention by the customer Cerner in St
        Louis.  We did some testing and elevated the issue to NPB
        on 5 Dec 1996, via IPMT case CFS.47233.  I did *not*
        elevate it to Microsoft because the newest drivers from
        Digital, available from NPB via our website, also
        exhibited the same problem. 
                In general -- if a person from the field refers a
        problem to me -- will I elevate it to Microsoft?  Of
        course -- as long as you have a cohesive, credible, and
        complete problem statement.  It is my job to make that
        assessment -- I would be called on the carpet if I failed
        to do so.  In the IPMT system, we play the role of
        engineering; if you have elevated a problem to us via the
        formal support mechanism, and it gets ignored, I assure
        you that I will have high-level people on my tail.  :-)
                Please do not let whatever bad history you've had
        with the CSC prevent you from using us for elevations to
        Microsoft.  We're overworked, like you, but we're your
        formal path, and we do care about Digital's future, and
        we've staked our careers on Windows NT.
                Thanks,
                _Scott
        For cross reference, these IPMT cases were associated with 
        this issue:
                CFS.47233
                CFS.50008
    
 | 
| 1244.17 |  | CSC32::BINGHAM | Scott Bingham �� Windows NT / BackOffice Team, USCSC | Thu Apr 17 1997 17:22 | 7 | 
|  |     PS:  I assume, but have not seen in print, that this `solution' also
    means that NPB engineering will take back `failing' DE435a and DE450s
    under warranty when they're replaced with DE500s on this particular
    platform.  ;-)
    
    Thanks again,
    _Scott
 | 
| 1244.18 | Maybe make a separate one time kit, even? | ALFSS2::CHURCHE_J | Nothing endures but change | Fri Apr 18 1997 14:48 | 12 | 
|  |     
    re .3
    
      I think that this notes discussion may show that there is now a need
    to put the NT drivers back into the de435 kit...could you put them
    back?
    
    Thanks,
    
    jeanette
    NT Support/CSC
    
 |