Conference azur::mcc

    Wolfgang,
    
    Here's 2 pointers...
    
    You might have a chat with Phillipe DSVB03::TABONE, I believe he's in
    the Valbonne area... he's provided me patches in the past...
    
    You might have a looksee in this area -
    
    TAEC::DISK$USER4:[MCC_PUBLIC.MCC_V130.PATCHES...]
    
    I didn't see an OSI specific subdirectory, but there's lots of patches
    there...  BTW, is there a problem with checking in with the CSC?  I
    believe your *chapter* might be in Basingstoke, UK?
    
    Typically here in the States, we call the CSC and they fire up a patch
    for us on just about any/all OpenVMS based products... 
    
    good luck and report back either way...
    
    /Mic
    

    Hi Wolfgang,
    
    I believe the patch you reference has been updated and is now called
    VAXPHV10_U2055.A.  I have created the patch kit and you can pull it
    from CSC32""::DUMPS:[W_MCGAW].  It is a 972 block file and included the
    release notes.  I hope this is what you are looking for.
    
    Walt McGaw
    Digital Network Services Unit
    CSC/CS
    
    P.S.
    
    The patch kit is also known as CSCPAT_0606

    Thanx a lot to both of the authors of .1 and .2.
    
    But... close but no cigar... (like it happens to me now for several
    days).
    
    re .1: with the move of the MCC stuff from node TOUDON to node TAEC the
    aforehand mentioned patch ( NET$VAXPHV01_U2055.A) wasn't moved. It got
    lost.
    
    re. 2: ECO VAXPHV10_U2055.A does not and never did contain the images
    that made up NET$VAXPHV01_U2055.A, i.e., NET$CSMACD.EXE & NET$FDDI.EXE,
    both dated 10-Aug-1994. These images never made it to be included in
    the official ethernet driver ECO; the ECO is still carrying the old
    faulty images, dated 4-Mar-1994.
    
    What I'm looking for are exactly these images, because they fix the
    SRP memory leak in DECnet/OSI with DECmcc. The only thing I know about
    these images ist, they once were provided by Walter Bysko. I don't know
    how to get a hold of him, nor where to look for the places he used to
    distribute them. 
    
    So any help is very very much appreciated.
    
    Regards Wolfgang

    Sorry I can't help you with locating this guy... you didn't mention if
    you tried the CSC?  They have that kind of information in their
    databases...
    
    I'm not sure why you couldn't go to OpenVMS V6.X, but if you need
    leverage with your client, don't the pool parameters, SRP/LRP/IRPs get
    setup dynamically with V6.X?
    
    Also, not sure if you stated whether you are using
    DECnet-VAX-Extensions or if you've got REAL OSI?  There have been tons
    of enhancements since DVE... 
    
    Finally, you've stated that you didn't want to go to V1.4 of MCC?  This
    doesn't have anything to do with problems incurred with VMS upgrades
    does it?
    
    The reason I ask this last question is that I'm running OpenVMS V7.0,
    with OSI V6.3 and MCC V1.4 (actually, EMS V2.4) and I'm quite happy
    with the system > application stuff going on... I have patches that
    I've received from Valbonne, that fixed any/all problems I had...
    
    Although MCC has been "retired", I urge you to consider using the
    latest stuff to ensure you're working properly...
    
    IMHO,
    
    /Mic
    

Hello Wolfgang,

I find in TIMA tool an article speaking about your problem. The title
of this article is :

{Elev} Crash starting up DECnet/OSI V6.3, NET$FDDI+10880

An abstract is :

\ A solution has been proposed:

\ Walt Bysko has provided the images which solve this problem
\ (net$csmacd.exe and net$fddi.exe).  Closing in engineering.

\ Regards,

\ Steve Woodard, OpenVMS Engineering



\ REFERENCES:

\     CHAMP/CSC Service Request (SRQ) #: C960202-8050
\     Field Service Log #: HPAQ21BAC
\     QARs:


\ CONTRIBUTORS:

\     Technical:
\        John Sobecki (312838) of NSU

\\ FXDRIVER
\\ PROD=ENET_DRVR SPD=28.31 CAT=COMM GRP=DEVDRVR OS=OPENVMS-VAX
\\
\\ NSU 312838
\\ HPAQ21BAC
\\ SRC960202008050
\\ SOURCE=CHAMP_TO_IPMT TYPE=KNOWN_PROBLEM TYPE=ESCALATION
\\ ANSWERED

John Sobecki is still in Digital :
Common Name:   JOHN SOBECKI
Search Surname:  SOBECKI  Search Given Name:  JOHN,  JOHN MANLEY
DTN:  592-4101,  592-4101  Intrnl Mail Addr:  CXO3-2/E4  Location:  CXO
Node:  CSC32  Username:  J_SOBECKI  Org Unit:  AMERICAS FEW PLACE ZONE


Walter Bysko is reachable at :
Common Name:   WALTER BYSKO
Search Surname:  BYSKO  Search Given Name:  WALTER,  WALTER M  DTN:  381-2824
Intrnl Mail Addr:  ZKO3-2/Z24  Location:  ZKO  Node:  STAR  Username:  BYSKO
Org Unit:  OPEN VMS,  VMS Engineering

First point : Mic's advise was good CSC has a lot of interesting informations.

Second point : apparently this problem is not inside MCC, but MCC is only the
revelator ! So, there is no reason these fixes are located in MCC directories !
I don't think we have lost anything !


Hope this help you.

Regards,
Philippe Tabone - DECmcc Maintenance Team -

Another TIMA article for VMS 5.5-2 : {Elev} NETDLLERR EZDRIVER+01839: DECNET/OSI V5.6B with ECO8 on V5.5-2"



\ #############################################

\ ENGINEERING RESPONSE:

\ I received the same blessed kit from the engineer Walter Bysko:
\ Directory DISK$USER0:[DUCHARME]

\ NET$VAXPHV01_U2055.A;1

\ I had already recieved this from a Canadian CSC person who had received
\ this from Walter.  I sent this patch kit to Marilyn already via DSNLINK.

\ I left her a message to see if she received, installed and rebooted with
\ this new kit.



Philippe

    Hi Wolfgang,
    
    I have found a copy of the patch kit you referenced floating around
    here in the Colorado CSC.  I have verified it has the new date for the
    net$fddi and net$csmacd images (10-AUG-1994).  I placed it at the
    following location for you to pull over.
    
    $ Directory CSC32""::DUMPS:[W_MCGAW]NET$VAXPHV01_U2055.A
    
    NET$VAXPHV01_U2055.A;1
                             144
    
    Total of 1 file, 144 blocks.
    
    I hope this helps you.
    
    Walt McGaw
    Digital Network Services Unit
    CSC/CS