Conference ulysse::rdb_vms_competition

    I hear it all the time from customers.  In fact, they are getting
    pretty rude about it.  They really want to bang our heads when it comes
    to the lack of any product 4GL from Digital that is available to do
    this.  They usually respond to the 3rd party 4GL argument by saying
    that if they have to buy the tools from the 3rd party, they might as
    well buy the database from them as well.
    
    Any suggestions as to how to fix this?
    
    Rick

    
    
    Hey Guys, lay off !
    
    DECwindows support is in the development plans for VAX RALLY, I don't
    know what the timeframe is but look in BEAGLE::RALLY_COMPETITION.
    
    VAX RALLy you may remember is the 4GL that is tightly coupled to
    Rdb/VMS and support 99% of its features, and yet is open enough to
    allow to pull in 3GL code, and write your own interfaces to other
    databases if you want. Also in the next version is 2PC support and a
    rudimentary ACMS interface.
    
    Simon

�   "...in the development plans..."

    No offense intended, Simon, but this sounds too much like Oracle.

� "open enough to allow to pull in 3GL code"

    This, too, though I think what you probably mean is "flexible."  Not 
    to put words in your mouth, or anything.

�   "in the next version is ...a rudimentary ACMS interface."
    You just answered my next question, but "next version" and "rudimentary" are
    not words my customers want to hear in the same sentence from me.

    I'm trying to stoke the fires and get a feel for what the rest of the world 
    wants from us.

    I don't hesitate to tell people that we spent $1.5 billion on research last
    year.  I just hope, every time I say it, that they don't ask me "How much 
    on software?" or worse yet "How much on 4GLs?"

    
    
    well the next version is 2.2 and will have the bare bones ACMS
    interface, ie we supply a load of 3GL code that will do the ACMS work
    and that the customer can personalise to their hearts copntent
    
    DECwindows is a goal of 3.0 of VAX RALLY
    
    the 'next version' is 2.2 and is nearing the end of field test and is
    due to be submitted to the SSB the first week of November.
    
    Simon

� a load of 3GL code that will do the ACMS work
� and that the customer can personalise to their hearts copntent
    
Hey!  That's good news.  I have a customer now at USC whose RALLY application
is "too slow."  Maybe 2.2 will make it easier for them to like RALLY.  I hope so.
I want to see us have good products and see this as the most important in the
application development space.

Thanks,

Bruce

    RALLY V2.2 also has some new transaction features to allow you to
    further control how RALLY handles transactions. You can specify that
    only one database attach should be used, amongst other things.
    
    The open data interface (RALLY V2.2) will allow you to write your own
    routines to access any data (in memory, foreign databases, etc), and to
    integrate these routines fairly easily into a RALLY application.
    
    Bruce, are your customers asking for a Motif (Decwindows) based
    development environment, runtime environment, or both? Which is 
    more important?
    
    Richard

    Excellent question, Richard!  
    
    My first impression is to answer that the development environment is 
    more important.  But, with a 4GL, the distinction begins to blur a little, 
    does it not?  I know that it is mostly developers who're asking, and
    they're asking for windows-type database application development tools.  
    
    I think the DECwindows/Motif/X environment is still too expensive (if
    only in peoples' minds?) to be considered for a multi(i.e. many)-user 
    environment, though Athena's beginning to catch on, and there're lots 
    of "PCs" sitting on a lot of desks "out there," waiting to be made into
    PC-DECwindows servers.
    
    I'll ask a few of the "multitudes" who've been bugging me about it and
    see what they say.
    
    Bruce

    
    re: .5
    
    speaking of RALLY applications being "too slow"....
    
    It is an old, rather common and often misplaced song. When comparing 
    RALLY with other 4GL tools I doubt that RALLY is any "slower".
    
    OFTEN I found that performances depend a lot on HOW a RALLY application
    is built and on HOW a database is designed.
    

    re: .6 and .7
    
    Bruce and Richard,
    
    My customers are definitely asking for a Windows-based environment for
    both the developers and the end-users.  They desire these for
    ease-of-use reasons, consistency in the user interface (regardless if
    the user is developer or application end-user),  ease of support
    issues, and desire to use the interface mode of the 90's (or at least
    the early 90's - until the bionic implant is perfected ;-)  ).
    
    I wish the RALLY development team the best of luck in delivering the
    DECwindows interface and hope that the release is soon.  There are more
    and more PC 4GLs delivering the application front end functionality
    that RALLY provides for the VAX.  The PC tools like DataEase, Paradox,
    MicroSoft/SQL, and others are getting better at providing SQL
    interfaces to backend databases.  Whether these products do the job of
    accessing the backend well or not, they definitely are gobbling up
    marketshare.  I hope that we can stem the tide with RALLY to some
    degree, especially since most of the PC 4GLs support other databases
    first (i.e. Oracle, Sybase, or DB2).
    
    Keep those notes coming as to how we can best beat these guys.
    
    Rick

I also believe that we have been extremely slow in providing interfaces like 
these -- at least in a form that is acceptable (or visible?) to our customers. 

4GL style interfaces are unlikely to get built in a timely fashion unless you 
guys out there in the field push back on the appropriate Product Managers saying 
that they are Product Requirements on Rdb, and supplying evidence that the lack
of such tools hurts sales in a significant way. The Rdb/VMS developers have more 
than they can handle with just the requirements on the 'engine' and the SQL
language, so it takes a lot to raise the consciousness in this area.

The issue is also potentially one of packaging.  Would the availability of a 
package that includes Rdb/VMS and Rally help the situation?  Or is Rally more
than most customers really need?  Or what?  Where does DECDecision (etc.) fit 
in?  etc., etc., etc.

Bryan

    Bryan and Richard,
    
    I think the idea in ;-1 of packaging Rally with Rdb/VMS is a good one. 
    Especially from version 2.2 where Rally could be used to create simple
    form per table database maintenance applications for customers who have
    large DECtp ACMS/Rdb applications.
    
    Reducing the price of the development package might also help a little.
    From the checking I've done so far with the third party 4gl tool
    vendors, Rally is slightly more expensive than the rest.
    
    Iain.
    

    Good idea to package Rally with Rdb/VMS.  Given Rally's limited
    functionality and nonsupport of windows, the pricing seems more
    than a bit out of line with competitors' products for VMS.
    
    For example, Ingres now has a product called "Windows 4GL" that runs
    on top of Ingres v 6.3 (both VMS & RISC/ULTRIX operating systems)
    that's really sweet.  Wish it were our own.  We're dreading going
    against them in the government market for RDBMS procurements that
    specify a windows-based interface for users.  It hurts to lose the
    business because our products aren't there now.
    
    Elaine Casey, government DCC

    If you think that Rdb & RALLY should be packaged together, please can
    you tell the relevant product managers (Marie Murphy TLE::MMURPHY in the
    case of RALLY).
    
>For example, Ingres now has a product called "Windows 4GL" that runs
>on top of Ingres v 6.3 (both VMS & RISC/ULTRIX operating systems)
>that's really sweet.  Wish it were our own.  We're dreading going
>against them in the government market for RDBMS procurements that
>specify a windows-based interface for users.  It hurts to lose the
    
    This is a good point. However, as far as I am aware, the 
    INGRES Windows 4GL product only creates applications that will run 
    on workstations, not on character cell terminals. Although customers 
    are giving workstations to end users, the customers that I 
    have worked with and talked to have large installed bases of 
    character cell terminals, and at this stage they do not plan to 
    replace them all with workstations. From this point of view, it 
    is important to have a product that can create applications
    for both character cell terminals and workstations. Also, I seem to
    remember that existing INGRES applications are not compatible with the
    Windows 4GL product (although this may have changed).
    
    I seem to remember that the INGRES Windows 4GL product does not
    actually write any of the database access code for you. You have to
    write it all yourself. This can add quite a sizeable burden to your
    application development when building a complex system. RALLY does not
    require that you write any code for the database access. It is all
    built into RALLY.
    
    Keep the customer requirements coming!
    
    Richard

Is the INGRES windows product part of their TOOLS, or does it work with their
TOOLS product? Just thinking out loud, since INGRES TOOLS works with Rdb...

John.

          <<< CLT::DISK$CLT_LIBRARY3:[NOTES$LIBRARY]RALLY_V2.NOTE;1 >>>
                            -< VAX RALLY Version 2 >-
================================================================================
Note 1845.0               "What's New" slides available               No replies
4GL::TROGERS "Tony Rogers, Supervisor of RALLY, MMS" 15 lines  11-OCT-1990 23:35
--------------------------------------------------------------------------------

    I have copied the slides that John Henning will be using in his December
    1990 DECUS talk "What's New with VAX RALLY" into the RALLY$INFO
    directory:

	CLT::RALLY$INFO:WHATS-NEW-SLIDES.PS

    You are welcome to use these slides in presentations to customers.
    
    This presentation is based on the talk with the same title that I gave
    in Cannes in September.  The primary topic is the enhancements in V2.2,
    with a note about our direction towards NAS integration for the future.

    Tony
    
    

    Remember that INGRES is ported to all Digital operating systems:
    RISC/ULTRIX, VAX/ULTRIX, VAX VMS.  INGRES Tools look and feel similar
    in all 3 environments.  In ULTRIX, the Tools are used with ULTRIX/SQL, 
    which is actually INGRES V6.2.    
    
    The Windows 4GL product is currently available for the VMS platform
    and is for creating windows-based applications against an INGRES V6.3
    database.  Product is currently in beta test for RISC/ULTRIX and should
    be available for that platform on or about 1/1/91.  
    
    INGRES rdbms & INGRES Tools are available in DSPS, but the windows
    product is currently available only from INGRES Corp.
                                                                         

    As someone previusly stated, the Ingres Windows/4GL is incompatiable
    with Ingres Tools.  Therefore, you cannot build one applicaation that
    runs on both character cell terminals and workstations.  I see this
    functionality as a definite requirement.

    
    Packaging Rally with Rdb sounds like a good idea.
    Among the benefits, it would help customers selecting the right 4GL
    tool.

    I don't see much gain from packaging Rally with Rdb/VMS. None of our
    competitors does that (you have to buy half a dozen tools from Oracle
    to get the job done). What I see that is wrong is our licencing policy.
    
    We have software licences according to the number of points in a
    system, where the larger systems have more points. We make the
    assumption, that on larger machines more people will use the tool.
    I don't see why one single Rally developer on a �VAX3100 has to pay
    far less money compared to a single Rally developer on a 6000 class
    machine.
    
    I know we suggest our customers to develop on small machines and run
    the production on larger machines. But that is not alway's feasible.
    More and more a see customers who have critical applications, that run
    on large systems. For that, they have a backup machine with the same
    size who can be used if the first one fails. To exploit the capacity,
    they want top use that machine for development. Unformtunately they
    cannot do that because of the exorbitant high licence fees there, even
    is only a few people use the product.
    
    I think that introducing a user-based licencing system for our
    products, we can leverage sales of both HW and software. This type
    should come as an addition to the existing one, the customer can select
    the one he needs.
    
    Any thoughts?
    Henny

    So we should somehow restrict usage from within the product based upon
    the number of "user-units" the customer purchases?  Hmmm......makes
    sense to me....
    
    If we installed RALLY on a 9000 and it had one user-unit, and user
    number two came in, it would error out with "maximum users exceeded"....
    
    Sounds good to me, but it would be tougher to implement and enforce
    than the current scheme...
    
    Gil
    
    In any case, MY customers sure would buy it!
    

    
    
    re -1
    
    VMS licensing already support this, you can get 4-user VMS licences and
    16-user ALL-IN-1 Licenses already..
    
    I think it would be a great idea too, helps sell memory on top :-)
    
    Simon

    Don't we currently sell licenses for Notes and Datatrieve this way?
    I think the mechanisms all exist, we just need to decide this is
    how we want to do business.  Makes sense to me, for Rally.
    

    
    
    
    
    
    Sorry if this is a bit late, but here is my 2 cents worth.
    
    There are a number of products that have user based licensing, i.e
    TEAMDATA, ALL-IN-1, etc.  The mechanisms are there.
    
    However, the impact on s/w revenue is probably the major reason that
    Digital has not been offering this sort of lecensing scheme for every
    product.
    
    I believe that a windows implementation is crucial if RALLY is going to
    live on in an ever increasingly competitive world.  However, as well as
    MOTIF or DECwindows interface, I believe that MS-WINDOWS should be a
    platform to be ported to as well.
    
    I know of many customers with HUGE investments in PC's who would love
    to be able to develop 4GL applications on the VAX and deploy on the PC
    in a client server model.
    
    We already have the data access mechanism (SQL/Services), now if only
    RALLY run time could be ported to MS-DOS, then we would have a truly
    unbeatable product.
    
    Michael
    (Who has been consulting on, supporting and marketing (in that order)
    RALLY since the early V1 field test days)

    
    
    Well, I did hear the story that when Digital originally bought the
    rights to RALLY years ago, we were offered the PC rights for a piddling
    sum. 'Somebody' decided that we'd beeen burnt too many times with PC's
    and weren't interested in them.... ORACLE bought the rights and what
    you are looking at today is SQL*FORMS.
    
    Receently we were offered the PC rights again, or something happened
    that we are allowed to sell Rally on a PC, so I'm watching the
    development plans eagerly!
    
    Simon

    Simon,
    
    I think that the ORACLE product that is based on ALLY is the SQL report
    writer, not SQL*FORMS.
    
    I'm not sure what the original contract signed for RALLY was, other
    than I think it restricted RALLY to being sold on VAX/VMS only. I think
    that the recent change in this contract was that there is now no
    restriction on what platforms RALLY can be sold on.
    
    Cheers,
    Richard

    
    
    well, hey ! I was close :-)
    
    thats what you get when you listen to third-hand stories....
    
    Simon