Conference 7.286::digital

    Mickey,
    
    I've forwarded the customer the spd via Internet mail.  The TA90 is
    currently supported (see SPD 41.61.04, table 4 of supported h/w) in 
    DEC OSF/1 Operating System V1.3B.
    
    Tim 
    
    BPDA (Business Partner Developer Assistance)

    The CI looks supported to me for mixed OpenVMS clusters according to
    the SPD #4218.
    
    End of story!
    
    Tim

...but .0 was asking for an OpenVMS solution:

> we would like to migrate our complete VAX/VMS system from VAX-BI models to
> ALPHA machines. 

This morning's message from the customer....

From:	US3RMC::"[email protected]" "Herbert Rotscheidt / CERN" 14-FEB-1994 09:31:44.53
To:	<elwood::lane>
CC:	
Subj:	RE: TA90s on Alpha/VMS machines


	hi Mickey,

thanks for all your efforts in trying to find a solution for us !  that's
really much more than i had expected...
to give you a quick answer to an easy question:  unfortunately we don't have
an ALPHA 7000 model, we would intend to connect the TA90s (indeed, without
the CI stuff, HSC etc.) to models 3000-400 and 3000-500 (perhaps later also
to 3000-600 an -800), if possible.

bye for now, -
                 Herbert

re .2
    
>End of story!

End of story, my foot! Don't you think it a bit odd that a European
customer is trying to buy several machines from us via Internet mail
to a US tape engineering guy who's name he got off of some old Usenet
note?

Mickey.

    
>End of story, my foot! Don't you think it a bit odd that a European
>customer is trying to buy several machines from us via Internet mail
>to a US tape engineering guy who's name he got off of some old Usenet
>note?

    Odd? No, not at all. I talked to a friend of mine the other week. He's
    a former Digital salesperson who relayed the stories he's heard from
    some of his old customers (he's no longer in sales BTW). It seems that
    3 customers of his who did an total average of $5m/year have been
    unable to get Digital to return calls for months now. It's always been
    hard to get Digital to sell one something but it seems to be getting
    harder. If I were a Digital employee I'd use every name and resource
    I could to get the information I needed.

    			Alfred

    re: -1
    
    It's not that I don't believe you, but I find it unbelievable that
    accounts that large would be left unattended to.  Surely there must be
    some mistake here.

    re: .8
    >It's not that I don't believe you, but I find it unbelievable that
    >accounts that large would be left unattended to.  Surely there must be
    >some mistake here.
     
    Sadly, the mistake is that it happens a lot. While Digital reps spend
    2/3 of their life trying to get answers for basically simple
    questions, like "is my order booked yet?" or "when will I get that?"
    they cant spend time with customers. Or they spend unbelievable time
    working out booking splits, or fending off the booking vultures that
    want 'their' piece of the action.
    
    Even sadder is the fact that this is not a new problem. I started
    selling for DEC in 1969, and it has been a constant problem. In the old
    days out products were so hot customers put up with this just to get
    what they wanted. Today we havent got a single technology that a
    customer will wait for.
    

Re:   <<< Note 2900.7 by CVG::THOMPSON "An other snowy day in paradise" >>>

>	If I were a Digital employee I'd use every name and resource
>    I could to get the information I needed.

I though you *were* a Digital employee, Alfred...   :-)

-  David

There is a 'Brand X' version of a CI interface for Q-bus... customer I
work at has these in some model 4000's... no idea how/if/when these
would work on OpenVMS AXP...

Lee

    re .-1
    
    Seeing as how there's no Q-bus on ANY Alpha AXP system, I would
    consider the usefulness of the above mentioned adapter as near zero...
    
    tim m.

My knowledge of Alpha-based stuff is ZILCH as you can plainly tell...

Lee

    
>>	If I were a Digital employee I'd use every name and resource
>>    I could to get the information I needed.
>
>I though you *were* a Digital employee, Alfred...   :-)

    Yeah, I meant to say customer. Though of course as an employee I'd
    be in big trouble if I just relied on "official" resources as well. :-)

    			Alfred

RE: .8 ICS::DONNELLAN  "Couldn't be true"

>> I find it unbelievable that accounts that large would be left unattended to.

Before you jump to any conclusions, let me set the record straight. 

As you might guess from my node name, Digital has an on-site office at CERN
which includes an Account Team and a dedicated MCS group. We also have the
Digital Joint Project whose goal it is to work on projects that are beneficial
to both DEC and CERN - and the rest of the High Energy Physics community.

CERN is huge; roughly four thousand resident physicists, and about the same
number of collaborators in institutes around the world. Mr. Rotscheidt is one
person, who has the annoying habit of asking every question to as many people
within DEC that he can, and then trying to find discrepancies. 

The local people do have this situation under control -- Herbert just doesn't
like our answers....  (which were exactly as proposed!).

Thanks for your interest.

-John

    Hey John, sure must be an interesting place to work. CERN, the home
    of the World Wide Web.
    
    Jim C.
    

I'm also currently onsite at CERN, and I have to deal with Herbert every day.

In some sense, engineering's newfound fascination with the Internet is making
the problem worse.  Herbert mines newsgroups looking for names, and bombards
them with questions.  Herbert then takes the average of the responses, weighted
by what he would like to hear.

Unfortunately, the replies are often taken out of context (that is, a mail
message from an engineer is often loaded with assumptions that are simply
not shared with the recipient).  For example, Epsilon FT3 is still the
current OpenVMS AXP field test release.  Of course, for the software engineers
this is ancient history, the master pack has been closed for *FT4* for some
time.

In a message to Herbert in mid-November, one VMS engineer commented that
something was "improved in FT4".  This lead Herbert to insist in meetings here
that not only was FT3 unstable, but that FT4 was already available, and that
somehow I was withholding FT4 from him.  That wasn't what the engineer wrote,
but it what the customer read.

I wish that we could put a filter on the gateway to block this guy -- it would
certainly make it simpler to support CERN!

-cw

Why do I feel like I've just been had by Alan Funt?

>I wish that we could put a filter on the gateway to block this guy -- it would
>certainly make it simpler to support CERN!

Maybe this note string will do the trick.

Mickey.

    What would really do the trick would be a simple to use, preferably
    on-line, way for any employee to locate the person responsible for
    a customer or a territory (for potential customers) so that they could
    feed any answers though the proper channels. This would do wonders
    for the local support people in terms of presenting a consistent
    message and in making it look like Digital knows what it's doing.

    Will it happen in Digital's life time?

    			Alfred 

    Re .-1
    
    You can do that for the US
    
    VTX ACCESS_US
    
    Select option 1 ACCOUNT MANAGEMENT
    
    DAVE

Just to get back to the base note..... a TAxx tape drive implies an 
STI tape protocol which requires a controller such as an HSC or one of 
the various other interface cards we made for things like the BI bus 
or the XMI bus. We do not currently have any interface for the Alpha 
3000 systems (Turbochannel or SCSI) which support the STI protocol. 
However, there have been rumors of some 3rd party boards which may 
provide a CI interface, thus allow the use of an HSC.

You might want to look into a TZK60:





TKZ60 -- TA90 and IBM 3480 Format Compatible Compact Tape Drive


Contacts:
Diane Danault, DTN 264-0228, (603) 884-0228, MKO
Richard Bohn,  DTN 264-4333, (603) 884-4333, MKO

CUSTOMER PROBLEM

Customers require TA90 and IBM 3480 data interchange capability on 
workstations and desktop systems.

DIGITAL SOLUTION

The TKZ60 tape drive is price compatible with the cost of workstations and 
desktop systems and provides the necessary SCSI interface so that it can be 
connected to these lower end systems.  The TKZ60 offers transfer rates up to 
1.5 MB/s and is available with a cartridge loader for maximum unattended 
throughput.  It can read 18-track, uncompressed data tapes from TA90, IBM 
3480, and IBM 3480 compatible tape drives.  An upgrade kit is planned for 
volume ship in early 1994 that will allow the TKZ60 to read or write data 
that has been compressed using the IBM IDRC data compression algorithm, thus 
making the TKZ60 18-track tape drive TA91 and IBM 3490 compatible as well.

CUSTOMER BENEFITS

o  TA90 and IBM 3480 format compatibility
o  Workstation and desktop support via SCSI interface
o  1.5 MB/s transfer rate for maximum throughput
o  200/220 MB (540 ft/600 ft tape) per tape cartridge
o  Compact Size (5.25"H x 8.55"W x 21.25"D)
o  Non-loader and sequential loader versions
o  Tabletop and rackmountable versions
o  optional 5- or 10-cartridge tape magazines
o  Auto-ranging power supply

INTERNAL POSITIONING

Since the retirement of the TA90 and TA91 tape drives in June, 1993, the 
TKZ60 is the only tape drive available from Digital that has both read and 
write compatibility with IBM 3480 tape drives.  Digital does offer the TA92 
36-track IBM 3490E compatible tape drive for data center environments where 
high performance or higher capacity per cartridge is a requirement.  The 
TA92 is backward read compatible with 18-track drives such as the TKZ60, 
TA90, TA90E and TA91.  However, tape cartridges that have been written on 
the TA92 cannot be read on 18-track drives.

CHANNELS STRATEGY

The TKZ60 will be sold by Digital's direct sales force, DECdirect, the 
Electronic Store, VARs and distributors.

PRICING/ORDERING INFORMATION


                            FOR INTERNAL USE ONLY
The following prices are DPP and are orderable now.

Business Partner Discount code:  T

QPB Applies:   Qty  1-4  = 0
               Qty  5-9  = 3%
               Qty 10-24 = 5%
               Qty 25-49 = 7%
               Qty 50+   = 10%

NOTE:  A cleaning cartridge, one blank tape cartridge, user manual, 
       single-ended SCSI terminator, and a 120V AC power cord is included 
       with all model variants.  Countries other than the US and Canada 
       require a country-specific power cord.

Model No. Description                               U.S. List     Std.  BMC

TKZ60-AA  3480 compatible tape drive, rackmountable,  $13,000  $14,920 $160
          field installed.  Order rack mounting kit
          separately.

TKZ60-AC  3480 compatible tape drive, rackmountable,  $14,800  $16,840 $170
          with cartridge loader, field installed.
          Order 5- or 10-cartridge magazines and 
          rack mounting kit separately.

TKZ60-BA  3480 compatible tape drive, tabletop.       $13,000  $14,920 $160

TKZ60-BC  3480 compatible tape drive, tabletop,       $14,800  $16,840 $170
          with cartridge loader.  Order 5- or 
          10-cartridge magazine separately.

TK60R-AA  19" RETMA rackmount kit for TKZ60 drive.       $600      N/A  N/A
TK60K-AB  5-slot cartridge magazine (4-pack).            $400      N/A  N/A
TK60K-BB  10-slot cartridge magazine (4-pack).           $500      N/A  N/A

NOTE:  SCSI cables are not included with the TKZ60 and must be ordered 
       separately.  Tape cartridges can be ordered from DECdirect 
       (1-800-DIGITAL).  Order part #TA90K-30 (30 cartridges).

TECHNICAL DATA

System Support

VMS Systems          ULTRIX RISC Systems    Alpha AXP Systems SCSI Cable
    
MV 3xxx**                                                     BC06P-xx
M3100-x10/10E/20/20E                        DEC 3000-300      BC19J-xx
MV3100-30/40/80/90                          DEC 3000-400      BC19J-xx
VAX 4xxx**                                  DEC 4000          BC06P-xx      
VS 3100              DS 2100                                  BC56H-xx
VS 4000-60/90        DS 5100                DEC 3000-500      BC19J-xx
                     DS 3100                                  BC56H-xx
                     DS 5000                                  BC09D-xx
                     DS 5500 *                                BC06P-xx
                     DS 5900                DEC  7000***      BC09D-xx
                                            DEC 10000***      BC09D-xx
    
HSC cluster support is provided via the HSC9X SCSI Data Channel Card.


                            FOR INTERNAL USE ONLY
*  via direct SCSI port only
**  Requires KZQSA adapter
***  Requires KZMSA adapter

MV = MicroVAX
VS = VAXstation
DS = DECstation

Software Support

OpenVMS V5.5-2 and later
OpenVMS AXP V1.5
ULTRIX V4.2A and later, with CAM (loader support with dump utility only)
DEC OSF/1 AXP V1.3 and later (tape loader is not supported)
HSC High Performance Software V8.3

RESOURCES

o  Sales Support Team 1-800-832-6277 or 603-884-8990 for general information


----------
IBM and IDRC are registered trademarks of International Business Machines.

                            FOR INTERNAL USE ONLY

> However, there have been rumors of some 3rd party boards which may 
> provide a CI interface, thus allow the use of an HSC.

Actually, I would think that any reasonable analysis would show that the
service contract on the HSC/TA90 would very quickly pay for any replacements
with more modern stuff.  [There are a lot of StorageTEK 3480 scsi drives here,
is the TZK60 a buyout of these?]

We're also trying to get DLTs into this lab, but we're having problems because
they want to put the TZ877 onto

	"our VAX 6310 running VMS V5.3, which has a CMD-1010 board, providing a
	 SCSI bus by emulating the KLESI adapter.  i.e. we use the MUDRIVER"

This doesn't quite work, due to some firmware issues with the DLT regarding
forward and backspacing.  (These positioning problems are worked around in
MKDRIVER on VMS.)

I'm sure every digit whose written to a tape-related internet newsgroup has a
mail asking about firmware upgrades for these drives...

-cw

    RE: -.2
    
    The TA92 is NOT an STI device and thus does not need and HSC.  It is a
    true FIPS-60 device and so it connects to a KCM44 or to a TC44.  The
    KCM44 works only on XMI based machines while the TC44 works only with
    an HSC.  But the point of -.2 is correct - the TKZ60 is a SCSI
    interface 3480 drive that now comes with compression.  Given that this
    is CERN and they likely have a need for more than one drive and also a
    need for automation, the TL3 tape robotic unit would be a great fit. 
    
    /Andrew

> Given that this is CERN and they likely have a need for more than one drive
> and also a need for automation, the TL3 tape robotic unit would be a great0

As John said earlier, CERN is quite large.  Picture a *big* state university,
with all the different departments, intra- and inter-departmental politics,
etc. with one big difference -- every department is some computer-science or
other science discipline with a huge appetite for computes and storage.

Herbert isn't CERN, he is a system programmer/manager for one small group
with a limited budget.  He's trying to stretch that budget, and find some
way of keeping those expensive TA90s running to justify their purchase so
many years ago.  At this point, his group has bought one used (seed) Flamingo,
and is looking at ordering a Pelican.

All Herbert asked was "since i've heard only negative or undefined answers
from asking our local DEC-people".  I'm sure that I'm responsible for some
of these "negative or undefined answers"!  Herbert asked me if we had a
TURBOchannel -> TA90 interface, my answer was negative -- we don't!  I gave
an "undefined" answer about 3rd party solutions, I don't know of any.  But I
also gave him a couple of pointers to other people at CERN that I know have
looked at TA90 -> SCSI issues.  I didn't know of any, but I did actively try
to help him find a third party solution.

As to storageworks, just this week we got a large (+150K$) order for DLT and
other stuff.  At this point in time, I think we are waiting for delivery for
over 200 GBytes of storageworks disks, in addition to a couple of hundred
already delivered.  Our storage message is being heard here, and people who
never would have considered DEC disks/tapes in the past are now complaining
that we can't ship fast enough.  (One question we got -- if we can fit an
RS6000 rack mount into an SW500 with 36GB and a TZ stacker, we'll have an
order for 8 sets next month.)

This whole thing is being blown out of perspective, and is wasting everyone's
time.  The account manager here is getting heat about this topic (and who says
things don't work inside DEC!), but it is all nonsense.  

As John said in .15 - "case closed, please."

-cw

re .21

>  We do not currently have any interface for the Alpha 
>  3000 systems (Turbochannel or SCSI) which support the STI protocol. 
>  However, there have been rumors of some 3rd party boards which may 
>  provide a CI interface, thus allow the use of an HSC.

   3rd party! sheesh! WE make a TurboChannel to CI adapter; it's called CITCA.
   It's essentially a CIMNA(CIXCD) with a TC front end. It was designed to
   work on DS5000 machines, but getting it to work on an Alpha/VMS/TurboChannel
   machine would be a mere matter of programming! :)

   The CIMNA driver would be a good place to start... 

-john_who'd_love_to_see_us_continue_to_milk_the_CI_cash_cow

    re .-1
    
    Yep, the CITCA is a real device. Now just explain why the adapter costs
    as much as his system ($21,000+ list) and doesn't have driver support
    for the system he's got and you should be set ;^)
    
    tim m.

    re .26

    Well, to put it bluntly, it's obviously priced the same way traditional
    CI adapters have been; you know, 7X or 8X markup. Is was developed for
    just this purpose; to allow a customer with a large CI/HSCXX/RAXX/TAXX
    investment to continue to use these devices on an upgraded server. The
    $21K is what the marketeers thought the market would bear. 

    As far as driver support?
    Who would want to put an HSC on a DS3000? Apparently not enough to pay for
    the development cost of the driver... after all, we are in the business
    of making money. 

    My point was not that CITCA is a practical solution, but a technical
    possibility. The amount of development required to make a TA90 work on
    a Flamingo is laughable when you consider what it can be sold for. The
    annual service costs for a TA90 are probably greater than some of the
    other solutions presented in this string.  

    Don't hold your breath on that 3rd party CI adapter; nobody else has
    done one right yet.  
  
-john.

    I got the s**t beat out of me at NYU just last week because
    of the lack of CITCA support on Alpha.  They were not
    about to buy a 7000 just to connect to their existing
    peripherals.
    
    Given their perception of Digital protecting their investment,
    the current box to buy is now SGI.
    
    The more customer's I meet, the more discouraged I get.
    
    I guess with this level of enthusiasm within the installed base,
    it's no wonder the SLT wants us to go off-base.
    
    Dan

>    Yep, the CITCA is a real device. Now just explain why the adapter costs
>    as much as his system ($21,000+ list) and doesn't have driver support

and is priced 50% more than the supported TKZ60 with stacker....

Thanks for all the help, but I need to get back to work and probably won't
follow this note any more.  Please send me mail if something comes up that
would be worth investigating.  (Also, I'd like to hear from anyone who gets
mail from Herbert, and get an open CC: on any replies to him!)

-cw

ps:  From watching this conference for a few days, I've basically become
disgusted with all of the griping and Digital-bashing that's the fashion
here.  If people would put half that energy into positive thinking and
actions we'd be a lot better off.  Get out of this damned negative feedback
loop!  Moaning about low morale just lowers morale...

Re.29:

>ps:  From watching this conference for a few days, I've basically become
>disgusted with all of the griping and Digital-bashing that's the fashion
>here.  If people would put half that energy into positive thinking and
>actions we'd be a lot better off.  Get out of this damned negative feedback
>loop!  Moaning about low morale just lowers morale...

Most of the people complaining are probaly already at rock bottom, so just 
think of this conference as therapy.

Dave.
P.S. Why is it I like the fact that the author I responded to won't read my 
reply ;-)

re: .25
>> re: .21
>>  We do not currently have any interface for the Alpha 
>>  3000 systems (Turbochannel or SCSI) which support the STI protocol. 
>>  However, there have been rumors of some 3rd party boards which may 
>>  provide a CI interface, thus allow the use of an HSC.
>
>   3rd party! sheesh! WE make a TurboChannel to CI adapter; it's called CITCA.
>   It's essentially a CIMNA(CIXCD) with a TC front end. It was designed to
>   work on DS5000 machines, but getting it to work on an Alpha/VMS/TurboChannel
>   machine would be a mere matter of programming! :)

My .21 reply was coming from a VMS perspective (which was what .0 
asked for).

I know about the CITCA, but there is no VMS support for it, and from 
what I hear, there is no intention to support it on VMS (I'd sure 
love to hear someone tell me I'm wrong however....). No-one in Alpha 
systems Product Management seems to think there is a need to connect 
anything smaller than a 7000/10000 to a CI (at least in the VMS 
world). What they keep telling us is that MTI is working on an 
interface to do that..... I terribly disagree with that philosophy and 
would love to be able to tell my customers to buy a CITCA, but without 
Operating System support, it's not even an option.


Arlan

 "in Alpha 
systems Product Management seems to think there is a need to connect 
anything smaller than a 7000/10000 to a CI"

Care to send me mail and name names!

APS and OpenVMS, and other groups went around and around to try
and find the $600,000 to re-engineer and test a TC based CI adapter.

No one would fund the project, this was in late 1992 and early 1993.

We needed the money + 6 months time to complete the project, that no one
would fund.

So, it all came down to money, and the money never arrived.

Bill Zaharchuk

DEC 3000 Workstations
Marketing Manager

re: .32
Not to bring this not into a rathole, but ....

>APS and OpenVMS, and other groups went around and around to try
>and find the $600,000 to re-engineer and test a TC based CI adapter.
>
>No one would fund the project, this was in late 1992 and early 1993.

Bill - regardless of the internal politics and funding, the view from 
customers is that Digital would prefer to force customers to buy a big 
expensive box to use a CI instead of allowing them to use lower cost 
(yet high performance) Alpha systems. We (the field) are put in the 
awkward position of having to defend this decision in front of 
customers who only see that we continue to push higher priced systems 
for the CI when lower-priced machine have far more capabilities and 
performance than the systems they currently have in their CI clusters. 
I don't know who made the decision not to fund CI on FB+ and TC, but 
it was a stupid decision.

.33

As somebody who was involved peripherally with the TC CI adapter, I
must respond:

1) The CI is essentially an obsolete interconnect. The corporation
   must drop support for it at some point. The only question is when.

2) The cost of engineering and supporting CI adapters would need to
   be covered in some reasonable way by product sales. A reasonable
   engineering cost is 5%-10% of revenue. To justify a $600K
   expenditure, we would need to see $6 million in revenue. Regardless
   what price you might put on these adapters, you couldn't get this
   much revenue from this piece of gear. (Don't tell me about all the
   other hardware it will leverage. It might be true here and there,
   but it's a dangerous basis for making investment decisions. If you
   go down this slope, the CPU folks will want to take credit for
   leveraging the CI adapter purchase!!)

3) DSSI drives from a CI system can be moved into 4000 boxes. Only the
   tapes are an issue. It simply isn't worth doing this much engineering
   work so that a few customers can move their crusty old tape drives
   onto our new hardware.

4) If we can get a third party adapter to cover this need, go for it!

5) The CI and the big boxes are both relics of the past. We need to put
   our energy into popular new stuff: raid boxes, automated backup systems,
   etc. on SCSI, for our full range of equipment from PC to Laser.

Just my $.02 worth.

--RS
   

Look at the cost of ownership (purchase + maintenance) of something like
50 GB of HSC/RA storage vs. 50 GB of Storageworks SCSI stuff....  I think
we're doing the customers a favor by treating CI as a legacy item for VAX
coexistence.

The main computer center at CERN did such an exercise.  The result was that
they have powered off their VAX9000, 6 HSCs and 50 GB of RA disks.

The replacement?  A VS4000/90 (for legacy apps), a DEC 3000m500 with 10 SCSI
channels and 70 GB of RZ28s as a disk server, and n*DEC 3000m400 as main
timesharing systems.  (N is currently 2, but the 3000m500 is also open to
users)  These are in one FDDI cluster.

The cost of the new cluster is about 18 month's maintenance on the old one.

There's one really big hole in a strategy such as this, however, and that's
the complete lack of FDDI-based storage servers to replace the HSC.  It's
very hard to build an available system without having something to replace
the dual-path capabilities of RA/HSC storage.  ("hard" includes the costs
and management headaches of shadowing the universe)

Too bad we didn't raise the $600,000 and give it to storage engineering to
speed the development of FDDI disk servers (and maybe a little to the
O/S groups to buy into the idea of MSCP over FDDI).

-cw

re .35

>There's one really big hole in a strategy such as this, however, and that's
>the complete lack of FDDI-based storage servers to replace the HSC.  It's
>very hard to build an available system without having something to replace
>the dual-path capabilities of RA/HSC storage. 

Doesn't ASE do this?? My understanding is that they have dual-path capability
to SCSI drives, with automatic transparent failover.

--RS