Conference 7.286::fddi

I think you are overestimating the support of multi-platforms.  Most of the
NDU functions should be system and O/S independent.  Then you write the
system dependent functions for each system (and for Unix systems, they should
overlap quite a bit).

If NDU "supposed" make a profit?  Or is the cost of NDU bundled with the FDDI
devices?

DECndu has cause more frustations within the support organzations. DECndu
is a licensed software product that a customer NEVER buys. When we have a field
person on site and we tell them that their microcode is not to current revs and
you need x.x version to fix it, well we supply them with x.x version of microcode
but the customer doesn't have NDU. Now we tell them that they need to go off and
find a copy of NDU, either VMS or Ultrix, so they now wasted another trip to the 
local office and back to the customer site, costing DEC big bucks and wasted 
time for our field engineers, time our field engineers no longer have to waste.
This waste is much more than the cost of the NDU license, which we usually end up
providing a temporary PAK and getting no revenue for anyway.

Upgrade of FDDI products, at least for bug fixes, should be simular to upgrading
the DEMNA (LANcontroller 400), a diagnostic on the VAX diagnostic pack or better 
yet, a MSDOS based diagnostic that can go on a LAPTOP PC, that all the field
engineers are getting, with a mechnisim to load the firmware via the OBM.

Brad Goodwin
CSC/CS Network Support

> Upgrade of FDDI products, at least for bug fixes, should be simular to
> upgrading the DEMNA (LANcontroller 400), a diagnostic on the VAX diagnostic
> pack, or better yet, a MSDOS based diagnostic that can go on a LAPTOP PC
> (which all the field engineers are getting), with a mechnisim to load the
> firmware via the OBM.
>Brad Goodwin
>CSC/CS Network Support

    I like that feedback, but be more specific.  What OBM interface will
    allow field service PCs to load microcode into host adapters?  If the
    field has developed a strategy to deploy service tools that communicate
    only through OBM, please tell us more.  In engineering, we commonly
    assume that a LAN (using MOP or bootp) is the preferred upgrade medium.

    I shudder at the thought of upgrading adapters using off-line software
    like MDM.  If you have to upgrade 100 desktop machines, you're going to
    want to copy an upgrade script to each system.  When the script is
    executed, it can take the system off the network, do the upgrade, and
    put the system back on the network without ever walking to the machine.
    (Is that level of control possible in MS-DOS?  In every Unix?)

    For the application of loading microcode into stand-alone network
    boxes, plan to use a LAN when possible.  Serial ports are too slow to
    load firmware images into big products like GIGAswitch--but it can be
    upgraded via MOP and bootp/tftp instead of DECndu, as I understand it.
    Is it reasonable for the field engineer to bring an Ethernet interface
    for his PC, and for the box to be upgraded?

>What OBM interface will allow field service PCs to load microcode into host 
>adapters? 

Well, I was making more of a suggestion on trying to find a way to do this, since
the OBM on DEFCN/DEFEB's are going to change over to using SLIP, maybe we can 
find a way of being able to load new microcode via the OBM. The idea has been put 
forward that we put SLIP software on the field service laptops so they will have
access to DEFCN/DEFEB's. I don't know if it is possible, but I was making the
suggestion.

>I shudder at the thought of upgrading adapters using off-line software like MDM.
 
I was thinking of the diag, EVGDB, which can be used either on-line or off-line
to upgrade the DEMNA. I beleive it is possible, from one system, upgrade all 
DEMNA's on a lan at once, but this is a special program written by the developer
and is not generally available. The nice thing about this is you don't have to 
bring the systems down, only the eeroms are updated, not the operational 
firmware in ram. But since it is possible, we should be looking at the 
same thing for our other controllers.


>For the application of loading microcode into stand-alone network
>boxes, plan to use a LAN when possible. 

I agree, the LAN should be really be used. So another possiblity, the laptops 
don't have an ethernet interface, but there is a company (can't remember the 
name), that makes a ethernet interface that plugs into the parallel port of 
a PC, we use that to download the firmware, as you have  stated, using 
MOP/bootp/tftp.

I just beleive the current use of NDU doesn't not work right and takes to much 
time to setup when all the pieces are not there, ie the license, and wastes
a lot of resourses.

I think there could be many good ways to do it, but we need to come up with the
same mechinism across all our product sets, not each individual engineering group
do something different with every controller made, it makes it a support
nightmare, which we are experiancing now.


Did I ramble enough?
Brad

Does NDU really require a license separate from the firmware?  

If so, that's clearly nonsensical.  As far as I remember, it was decided
during NDU product planning that it would come with the firmware upgrades.
It's debatable whether firmware upgrades should be charged for, but it
clearly makes no sense whatsoever that the tool necessary to install an
upgrade is licensed separate from the upgrade.

If that is indeed how it's currently done, requirement #1 must be to fix
this mistake.  

	paul

    These responses are off the track from the original request, but is 
    important feedback. Since thsi is the first I've heard of things not
    working, let me ask a couple of questions:
    
    	. Firmware is available vis QB kits. The QB kits contain all the
          licenses and media for the firmware and DECndu in one package.
          Why aren't these QB kits being ordered for the customers or 
          DEC offices for these updates? Is there something wrong re:
          the QB strategy? The rationale for the QB kits was to exactly
    	  avoid the problems you've all been identifying? What's the better
          way?
    
    	. Corporate Licensing and Corporate Business Practices requires
    	  that the firmware and DECndu be licensed to protect intellectual
          property. We've disagreed with this requirement, but have no
    	  choice but to comply. 
    
    	. There is no one updating strategy in this corporation. Several
          products groups do use or are looking at DECndu as thier updating
          mechanism. This is a problem that won't be solved easily. DECndu 
          works well for some products, and is available for anyone's use.
    
    Back to the original point, Digital will be developing FDDI adapters
    for pc platforms. The  problems expressed here tellme that the QB 
    strategy isn't working (please clarify the problems) but also that the 
    strategy of having individual pieces orderable will have problems also.
    My original proposal was to have, in essence, a different tool to
    locally update pc fddi adapters than the WCs and bridges.
    
    Any comments?
    
    Thanks, Mike 
     

Yes you do have to have a license. The original concept was that the customer
would get NDU when they ordered the firware upgrades, but since the firmware 
had bug fixes in them along with the upgrades, the CSC's and support 
organizations would give out the latest microcode from engineering without NDU.
The people who designed the concept of NDU forgot about bug fixes.

From the installation script of NDU V2.0

* Do you want to purge files replaced by this installation [YES]?


        Product:      DECNDU-V
        Producer:     DEC
        Version:      2.0
        Release Date:


* Does this product have an authorization key registered and loaded?

and this is what happens when you execute the DOWNLOAD verb without the license

$ download sho version
%LICENSE-F-NOAUTH, DEC DECNDU-V use is not authorized on this node
-LICENSE-F-NOLICENSE, no license is active for this software product
-LICENSE-I-SYSMGR, please see your system manager

btw, here is a typical senario of a call we get:

FE-. We are having problem with SNMP on our Bridge, but we can Ping to it.

CSC-. We have new firmware that fixes that problem. We can download it to your
      system if you like. Do you have NDU on your system?

FE-.  NDU? What's that. Where can I get it?

CSC-. (explain what NDU is) Do you have CD-ROM?

FE-.  No

CSC-. I send a copy over the easynet to your local system and you can go and get
      it. (here are delays) Oh, by the way, does you customer have a 
      license for NDU?

FE-.  No, how do get one.

CSC-. Well, I can give you a temporary, but it will expire or I can send you off
      to the people who handle licensing (we got more delays, customer is 
      starting to get MAD, because he needs a license up to get bug fixes).

I think you might be able to vision the rest of the senario, and in the mean time
we are wasting bucks trying to get a simple situation resolved.

re .6

Mike, I usually find that when SSB releases CD rom's they are behind on the 
current rev of microcode. Yes, this stategy would work, if there were no bugs 
in the microcode. When we have a problem, we usually get the code long before
it has been kitted for SSB release. It is given to us by engineering as just
the raw .sys file, no kit. If the customer has a fairly new build of the device,
it will have the lastest microcode that SSB has had. So no NDU has ever been 
shipped to the customer because there has been no orderable upgrades, hence 
no license. Telling the customer to wait to order the latest when it becomes 
available thru SSB doesn't cut it when they are having problems.

It sounds like the licensing strategy is broken and needs to be repaired.
Perhaps the field people that are seeing the pain from it could push for
this; customer satisfaction problems should be a good reason to bring some
sanity to this area.

Re .6: licensing to protect intellectual property is all well and good, but
that doesn't justify licensing NDU separate from the firmware.

	paul

Licensing seems to be a real sore spot as is obvious from discussions so far.
However, I believe enforcement of the license, rather than the licensing itself,
causes the service problem. There will not be a "licensing" problem on MS-DOS, 
as there is no enforcement. 

However, if LMF was not used to enforce NDU licenses on our own systems, the 
service problem (with licensing) would disappear, and the intellectual 
property would still be protected.

Another (even better) solution would avoid the distribution mess as well. NDU
could be included (and licensed) in the operating system release. I believe that 
this was the original intention, and the separate NDU distribution was a temporary
strategy.
 
Coordination of releases with the OS release seems to have been the largest 
obstacle to this strategy, but NDU v2.0's decoupling from device kits should
make this a very small problem. With this strategy, only the image saveset would 
need to be distributed to perform updates from our own platforms. 

George

When I was visiting Microsoft (who are very interested in our FDDI products)
this summer, they asked about our update strategy.  When I told them about 
DECndu, the network manager almost fell over when it was explained to him 
that he would have to walk over to each of his 1,000 pc (spread over the 
campus) and run NDU individually on each PC.  He was adamant about that not
being an acceptable solution.  I can see many other large customers having
similiar feelings.

I realize that technically it is more difficult to remotely upgrade adapters
(an NDU daemon must run on each machine, a protocol must be selected, security
must be implemented, etc), but I think it deserves more attention.  What does
the competiion offer for upgrade capabilities of adapters and other products?

doug

    Before asking some more dumb questions, I'd like to refocus on the
    original point of this note. Does anyone have any comment on the
    pc-DECndu proposal?  
    
    Many of the DECndu complaints raised here are the result of bypassing the
    "system". We've tried to set up the "system" to avoid the issues being
    raised. If bypassing that structure, you own some extra steps (like
    supplying the temp PAK and insuring DEcndu is there). Can this be
    proceduralized at the CSC?
    
    BTW, an MS-DOS version will be available by year end. A license letter
    is the licensing vehicle.  Will this help?
    
    CD-ROM is behind SSB releases. But, SSB QB kit releases are up to date.
    They are for bug fixes, as well as updates. Any change to the firmware
    is in the latest SSB release. Your latest CD-ROM may indeed be behind.
    
    A QB kit costs $265, the cost of media and processing. It is an
    expensive structure for DEC to implement, and it sounds like it
    doesn't work. We tried to make it easy for the customers to get
    upgrades/bug fixes. Has anybody had success with the QB mechanism?  
    
    We wanted to avoid the situation where DECndu HAD to be ordered
    seperately from the firmware. We thought that would drive people crazy.
    Is the feedback that seperate part ordering is a better way?  
    
    As much as I think the licensing situation is overkill, I can see the 
    reason for it. DECndu runs on a different "computer". It is a seperate
    product. In fact, the Digital Services organization told us that DECndu
    would not be supported unless it was licensed. Who needs to help me
    revisit this with PAC, Corporate Licensing and Corporate Business
    Practices? 
     
    Thanks, Mike

Mike, sorry to be a hardass, but these previous responses ARE addressing your
question.  You wanted to know product requirements for NDU; clearly one of
the critical requirements is to correct the defective licensing strategy.

George, absence of enforcement is not a fix.  For that matter, licensing
without enforcement doesn't necessarily protect property rights; consider
what has happened in similar cases involving trademarks.

	paul

Currently the firmware images that are to loaded into the target are stored in
a format called "RSX Task Image Format".  One might wonder why we are using such
a cryptic format when a simple format like Intex Hex or S-Records would do 
nicely.  Also, the RSX format is not plain text and makes debugging much more
difficult and requires a special tool to build the special format of the images
(which currently works only for VMS).

I think things would be simpler for everybody if we went to a standard format.
[does anyone know why we chose this format to begin with?]

doug

    It's one of the native formats that VAX hosts and MOM$LOAD could deal
    with.  Before NDU came about as a special-purpose loading tool, people
    would use the standard NCP "LOAD" command available on any VAX.
    I'm still in the habit of using NCP rather than NDU to load!
    Also, this file format has special fields that show up in the parameter
    load w/xfer address etc available in records set up in the first
    block, as far as I can remmeber.
    
    Anil

Both VMS and Ultrix understand RSX task images.  I don't believe either knows
about Motorola format.  Actually, if you want to switch to something else,
the more obvious choice may be IEEE 695 format (whatever that is) since that's
what the 68k tools around here seem to like best and produce by default.

In any case, it would seem a good idea to stick to formats that available MOP
loaders understand.

	paul

    Re: .14-
    Set Flame on:
    
>Mike, sorry to be a hardass, but these previous responses ARE addressing your
>question.  You wanted to know product requirements for NDU; clearly one of
>the critical requirements is to correct the defective licensing strategy.
    	
    	Paul, you and Brad went to bat for us (the Field) and apparently
    have struck out.
    
    	Nearly a year later it's status quo. I need to update f/w at a site
    as part of a consulting agreement. The first step was to request a
    "loan of product" PAK so we can register the NDU license. I'm now
    depending upon a VTX "virtual system" with the blind faith that the
    magic piece of paper will arrive via U.S. mail at the customer's site
    in a timely fashion. The only alternative is to use an internal PAK
    which could cost me my job according to the "rules".
    
    	There's enough trauma around doing an update (scheduling,
    remembering to set the Update Switch true, making sure you have the
    truely latest images (there are no CSCPAT kits, Brad is graciously
    working to fix this), probing notes files and trying to remember how
    to do an update without all the BS around installing the tool. It's
    like mining iron ore with the goal of making steel.
    
    	I'll put my soapbox away now, but stand on tiptoes: I despise working
    on FDDI due to this problem and the sparse amount of test equipment
    and experience available in the field. It's costly, few need it
    regularly and the evolution of management stations/SNMP has made
    getting the needed diagnostic information overly complicated IMHO.
    
    Phil