Conference ulysse::rdb_vms_competition

    CYTROL, INC.
    
    4620 West 77th St.
    Minneapolis, MN  55435
    
    Phone:  (612)-835-4884  FAX:  (612)-830-0598
    
    Established 1969.  Employees as of Jan 91 = 65
    
    Chairman/CEO/Pres: Keith A. Peterson
    VP Mktg/Sales: David Wiley
    Promotion Dir: Barbara Gurstelle

    CYX is actually produced by HN Corp.
    
    HN Corporation
    5100 Edina Industrial Blvd.
    Edina, MN 55439
    
    Phone:  (612)-893-1848
    
    Pres:  Michael T. Helland
    VP Mktg:  Robert W. Nelson

    CYX Transaction Processing System is billed as both a communications
    monitor and a database manager.
    
    It appears to be configurable for both VAX's and PDP-11's and requires
    256 kilobytes of main memory.  Source code is in MACRO (!).
    
    It's been shipping since 1979 - pre-relational db's - and costs
    somewhere between $30k-$50k.
    
    It claims to support 1,000 terminals max - and both VT and 3270
    terminal protocols.
    
    Performance reports are available on request.
    
    [cf:  Data Sources: Software 1st Edition 1991 - Volume 2, pp. I-67]

    RLEE -- what is your name?
    
    Anyway, thanks for the input.  I've mailed you a message in response
    to your mail message.  Looking for more of the technical stuff. 
    Performance reports would be great.  We here in NCD are embarking on a
    project to move a customer from CYX to Rdb and I'll be involved in the
    database design.  I felt the more I know about this CYX product the
    smoother the conversion will go.
    
    So, any technical info will be great.
    
    Thanks again,
    Miles.

    ah ... right, name .... -bob lee- ... which happens to currently
    coincide with at least 6 other "bob lee"'s in the corporation.
    
    the "bob lee" who survived the bony crash of '86 where the txn seq no
    rolled over into negative numbers... one of 5 memorable 36 hour days in
    my life ...

    Oops ... "performance reports available" ... means that the system
    tracks the elapsed time of transactions performed against their
    transaction manager.
    
    HN Corporation is a 2-person operation and doesn't really have a
    marketing arm to fund publishable benchmarks.

    Spoke to Bob Nelson, VP Mktg at HN Corporation:
    
    Product status:  5-years in maintenance mode since take over of product
                     from CYTROL, Inc.
    
    Product target:  MIS shops that wish to use VAX's or PDP's as
                     inexpensive data-entry transaction processors
                     instead of IBM 30xx mainframes.  Generally,
                     customers have a pre-existing IBM application
                     running on CICS and IMS.  CYX is designed to
                     support CICS and IMS functionalities on VAX's.
                     
    Applications on CYX:  airline reservation service, credit card
                          membership service, subscription service, 
                          stock exchange trading systems, etc.
    
    Current marketing effort is:  $0 per year.
    
    Product feature:
    
    CYX-DC is the data communication transaction manager for the system.
           It supports IBM 3270 bisynch terminal protocol and SDLC - ONLY.
    Asynch terminal support for VT's is not provided.  Support for bisynch
    terminals requires installation of a CIMPACT (?) controller on VAX's.
    The result is a decrease in the number of interrupts required to
    service terminals - allowing higher CPU throughput to support
    applications.  Applications written for CYX-DC must reside on exactly
    one VAX-node in a VAXcluster.  Application Programming Interface calls
    are made by application code that is targetted for management by
    CYX-DC.
    
    CYX-DB is the database manager for the system.
           It supports hierarchical networked database schemas.  Its
    interface is strictly an application programming interface.  It
    supports transaction recovery mechanisms using logfiles, disk
    shadowing, and logging to tape.  It only supports fixed record
    length records.
    
    Quoted performance:  
    
    Single VAX 8650 is supporting 300 tps of complex transactions with .3
    second response time for 90%.  Cited application is an airline reservation
    system.

    Bob,
    
    Thanks for the info and the mail messages.  Sorry I haven't gotten back
    to you sooner.  As things stand right now, I'm not working on that
    account as another piece of business that I have been persuing has come
    in so I am the project lead for that.  That business will take me
    through Oct. 1 (maybe slightly longer depending upon how things go). 
    After that, I may be back to looking at this CYX conversion, though, so
    your info will come in handy then.  If you should come across any more,
    please forward on - I'll definitely appreciate it.
    
    Again, thanks very much for your persuit of this matter that I figured
    no-one would really care much about (or know anything about either).
    
    I don't get into notes every day, so sometimes it may seem like I'm not
    responding.  I try to catch up every now and then.
    
    Thanks again,
    Miles.

    Welcome!
    
    I'm just another megalomaniac TP driver ... I like systems that
    are lean, mean, and fast - as well as software-fault tolerant - and
    responsibly designed for human care and feeding.  
    
    [Having done data-entry myself to support my college years... ]
    
    I positively detest software that can "barf" all over a disk farm... 
    
         -bob lee-
    
    PS:  I have received a saveset of their docset from Bob Nelson.  
         It is for Digital Internal Use only.  Interested?
    
    PPS:  For other readers - it isn't necessary to use CYX-DC with CYX-DB.
    
          There's no reason at all why you couldn't just make SQLPRE or
          RDBPRE supported calls to Rdb/VMS.  Then again, I wouldn't expect
          CYX-DC to implicitly support DECdtm as Rdb/VMS does at this time.

    RE: .9
    
    Bob,
    
    Yes, I'm definitely interested.  But I don't necessarily need it
    immediately.  At your convienence, maybe you could mail me the location
    and I could ftsv it to my machine.
    
    Thanks,
    Miles.

    I'm just catching up on these notes...a word to the wise about CYX
    and Bob Nelson.
    
    Bob Nelson is currently supporting the airline reservation system of
    *our* customer (they are on a Vax 9000 now, btw).  He is doing some
    on-going consulting and we will be replacing the CYX rez system over
    the next year + probably with ACMS/Rdb/DECforms.  Bob is not exactly
    happy over the prospect of loosing his cash cow.  (this is the same
    customer that Miles is talking about)
    
    I have heard that Bob has been saying negative things about Rdb to the
    customer.
    
    The main problem for the customer is the inability to retrieve data
    from there database.  They have to write a program for everything.
    That is why we are helping them convert it to Rdb.  I have completed
    a requirements document for all of their systems.  This week, another
    deccie and I have begun work on a functional spec for the reservations
    system.
    

    [Moderator: permission to remove this reply is granted.]
    
    Let's remember our manners here:
    
    When working with Digital's 3rd-parties - let's not get upset if their
    marketing messages are sometimes as confused as our own.  Always partner 
    them, because they may have things that we may want to own.
    
    There's TP and there's DB.  CYX might have your TP part - now. Saves
    you money.  Now.
    
    TP requires a close match to the client's business organization.
    DB requires a close match to the client's business model.
    
    A good model will provide good answers to good queries.
    A good organization gets the work done satisfactorily - with a profit.
    
       Often the organization won't match the model.  
       Especially when business conditions change.
    
    So - what's to do:  Work with HN Corp - and convince them that they
    have a profitable opportunity building TP systems that support better
    DB-based business models - where the DB is Rdb/VMS.
    
    Anyone who can get a VAX into an IBM-based shop at half the price of
    Big Blue should be thanked for every opportunity that they make
    available to us today.  Because tomorrow - the client will be seeing
    things our way with half of our sales effort.
    
    If we build something that is pure Digital which is too expensive, too
    slow, and too inefficient, then we have failed to serve the client, and
    we will alienate a 3rd-party vendor.  Worse - we have lost the money
    used to support the pre-sales effort while also taking a chance at being
    shut out of the account for a very long time.
    
    If we partner the vendor, we off-load some of the risk, we loose some
    of the profit, but we also gain a technology leg without having spent
    any money on engineering the solution with half the pre-sales effort.
    
    TP sales are notoriously long-term and take forever to land.  Use the
    3rd-party vendor to shorten the landing time - and then sell the vendor
    and the client on our technology in bits and pieces until the only
    thing either sees is Digital - pure and simple.  [I have a feeling that
    HN Corp wants to use some of our technology in future offerings - if
    they only could keep their cash flow going and had a Digital ear to
    tell their needs to.]
    
    If you do it right - you will have opened doors that were closed to us
    whenever we tried to offer pure Digital TP solutions.  You will have 
    made it possible for the corporation to see profit faster and made it
    possible to deliver future products and services to the client under
    your account team - while the client foots the bill.  If you do it
    right, you will be able to do it again, and again:  Success is repeatable
    business.
    
    Be careful out there - but remember - the 3rd-party vendor is also a
    potential client - and is an agent for his own clients.  Bring the
    3rd-party vendor in line - and you will win his clients too.
    
    Hope this advice helps ... /bob lee/

    
	re .12:

	1.  Thanks Bob for mailing me a copy of your reply; it would have 
	been a while before I got back to these notes.

	2.  I reread all the replies, and I'm not sure that I my note
	sounded "upset with his marketing message".  I was just stating
	the coincidental nature of his reference to a client: the *same* 
    	client that Miles described.

	3.  Since you are the person who is talking to Bob Nelson
	it seemed a good idea to let you know the potential conflict
	that could arise.  If you like, we can talk by phone and I
	can fill you in on the history (dtn 442-2026).

	4.  I appreciate your concerns about working with 3rd parties.
	I hadn't really thought about Bob as a potential customer, but
	then I have lots of other things on my mind... like understanding
	the customer's business.  It *has* changed alot since the days
	when Cytrol was the 3rd party who wrote the system.  The Client's
    	IS mgr originally came from Cytrol, so the relationship has been going
	on a long time.  ...long before I dropped in to deliver services...

	5.  Perhaps you should move the information about 3rd parties
	to another note and start up another discussion.

	Sherry Litasi