Conference 49.910::kav30

    Hi there,
    
    the DSP3210 is not supported with VAXELN....
    
    As you or your customer already figured out, one would need to modify
    the KAV30 SCSI 'port' driver (which, in fact, controls the NCR53C700).
    Thats not an easy task...
    
    In addition - if your customer wants to boot from this disk - the boot
    code needs to be modified as well, and this is not part of the 'port'
    driver and the sources are not given away in any case...
    
    In order to get the sources (or better a 'source kit' since you need
    several files) you have to contact the Product Manager Erwin Kettner at
    EICMFG::KETTNER (DTN 873-4180).
    
    Be aware, that modifying the driver is not an easy task - you (or the
    customer) will need a SCSI analyzer to understand what the problem at
    the SCSI bus is before you can try to 'fix' it. Obviously, this task
    can be done at Digital-PCS, since we have all the knowledge - but the
    customer would have to pay for it... if this is an option, talk to the
    product manager, Erwin Kettner, and ask him for an offer.
    
    best regards,
    
    Thomas
    

    Thanks for the info. (Sorry it took so long to say that).  I have
    followed up with Erwin.
    
    Thanks again,
    Mark

Well, I've got an update to my customer situation.  So far my e-mails
have gone unanswered (vacation?).  Hopefully someone here can point me
in the right direction or say "no way".

Either my customer finds someone at Digital, by 5PM EDT Wednesday, to help
fix the problem , or he must find a different DataShuttle disk drive.
This is not a palatable solution because they already have 150-200 units
deployed to their customers.

I was able to obtain the port driver code and the customer has continued
(along with Seagate engineers) to investigate the problem he is having
with the Seagate 31200N drives.  According to Seagate, this drive has the
same SCSI processor as our RZ25L drive.  Anyway, this is what they have
found:

    Seagate contends that there are cases where the NCR 53C700 chip does
    not work properly.  They know of at least two such instances.  In
    this case, the symptom is a bus timeout.  Their research has
    resulted in this problem description:

    The SCSI bus has two phases: command and data (request/ack).  When
    a data transfer is requested, the initiator tells the target (in
    command phase) the number of bytes to send.  IT IS LEGAL FOR THE
    TRANSFER TO COMPLETE WITH LESS THAN THE REQUESTED NUMBER OF BYTES
    RETURNED.  The data is then sent (in data phase) using a request/
    acknowledge protocol for each byte.  When the transfer completes
    (regardless of the number of bytes returned), the target changes
    the bus back to command phase and sends "request".  Seagate contends
    that the NCR 53C700 can "miss" the transition from data to command
    phase when the transfer ends early.  It then "times out" waiting for
    the transfer to complete.

    Seagate believes that the problem can be solved by modifying the
    "scripts" the NCR chip executes.  They do a lot of business with
    Digital (ex. RZ25L) and would welcome the opportunity to work with
    Digital engineers to do this.  The customer has the source for the
    scripts, but does not have a compiler for the scripts.  He says they
    appear to be in a "Digital specific" macro form that is non-NCR standard.

    Seagate has also found that transferring other than 32-bit quantities
    results in an error.

I now need to find out who in Digital might be willing and able to work
with the Seagate engineers to solve this problem.  Given that we already
work with Seagate, hopefully this will be doable.

Fire away....

Thanks,
Mark

    First, it is not a DEC specific macro, but just plain macro. Secondly
    you need a tool called SDL which is under absolute no condition to be
    given to customers. We have offered you repeatedly to fix the problem
    for you. The answer was the customer wants to do it. I  had doubts at
    the beginning that this would work. Apperantly it is urgent now. The
    customer cannot fix the problem unless we give him the the tools he
    needs, and those are not available - That's as far as I am concerned the
    whole story. 
    
    Now, what you can do is get the sources out of VAXELN eng. what you
    need to compile/link the port driver are the files and the command
    procedure I will pu in the next note.
    However I don't know what the ELN groups policy on source code is these
    days. Your best bet is ask Maureen Johnson.
    
    Or, you can give us money and we'll do it for you and your customer.
    
    	Julian.
    
    

    The files you need are:
    
    scsi_macros.mar
    ascsi_script.sdl
    scsi53c700.c
    scsi53c700.opt
    scsi53c700_script.mar
    krdriver.c
    scsisnif.c
    scsignrc.c
    scsidisk.c
    
    To compile and link
    
    $ lib/cre/mac macro_lib
    $ lib/repl macro_lib scsi_macros
    $ sdl/lang=macro ascsi_script.sdl
    $ lib/repl macro_lib ascsi_script
    $ cc scsi53c700
    $ macro scsi53c700_script+macro_lib/lib
    $ cc krdriver
    $ cc scsisnif
    $ cc scsignrc
    $ cc scsidisk
    $ link/nosyslib/nosysshr krdriver krdriver,scsisnif,scsignrc,scsidisk,-
    scsi53c700,scsi53c700_script,scsi53c700/opt,3kvker.stb/sel
    
    	Julian.