Re: Developer 2000 - Strengths & Weaknesses

(Copy goes to Aaron Neal (UGVD44A_at_prodigy.com))

Since I cannot obtain the original request to reply on I'm adding my thoughts here.

For that amount of transactions (60'000) I recommend to consider the use of a C/S TP monitor for reasons such as performance, scalability and  availability. Your applications would move to an N-tier architecture.

Developer/2000 can be easily integrated on behalf of interfaces to such a C/S TPM which are available at least for NCR's TOP END (see http://www.ncr.com/product/topend for further informations or simply contact me). In such a configuration Developer/2000 executes the Frontend and Business logics as far as useful, logical servers on the middle tier include the (rest of the) Business logic and the database accesses, and of course the third layer would be the oracle itself. You could still directly access oracle if appropriate (mixed 2- and N-tier). You also could integrate your existing MVS applications and data if needed. Integration of Internet/Intranet and other frontends, other DBMS's or other platforms would be easier as well.

Good luck

Rainer Leicht, NCR (Switzerland)
Email: rainer.leicht_at_switzerland.NCR.com  

Jo Pitt wrote:
>
> I would say stick with Designer and Developer 2000, for lots of reasons.
>
> 1) On a large project such as yours it is wise to generate as much code
> as you can, and forget about 'artistry' and personal flair. This will
> kill you in the long term, believe me, and create a maintenance
> nightmare. At least your forms. etc. will have a standard look and
> feel, and that's more important to users than cuteness. Anyway, you
> can get a pretty good looking forms template going, through Designer
> 2000, and it's worth spending some time over this before you start.
>
> Obviously, for some tricky transactions, you will have to adjust the
> generated form and add extra triggers etc. Try to isolate these forms
> as much as possible.
>
> 2) These tools really work and the documentation is good.
> Witness the lack of questions about them in the new groups.
>
> 3) You need to keep a tight integration between the repository, the
> physical database and the production modules, as one can with
> Designer/Developer 2000. This will help you later with impact
> analysis etc. It's easy to let things get out of hand post-
> implementation otherwise, especially with staff changes etc.
>
> 4) Portability is important in a project your size.
>
> 5) The potential to generating for the Web platform with Version 2
> should
> not be underestimated.
>
> 6) I don't work for Oracle - I am using it and have used heaps of
> other tools over the last 18 years in different environments, and
> one of the most important things is maintaining control over the
> software, especially in a large system.
>
> Getting a bunch of programmers to cut some Delphi code might seem
> a neat idea now, but you'll regret it later on.
>
> > Aaron Neal <UGVD44A_at_prodigy.com> wrote in article
> > <5gecvg$en8_at_newssvr02-int.news.prodigy.com>...
> > > My company is currently searching for an Application Development tool for
 

> > > our enterprise wide development. We have about 15 developers 50 systems
> > > and 60,000 transactions / day on our mainframe computer. The goal is to
> > > eliminate our Mainframe by year 2000. We have already decided that
> > > Oracle will be our DBMS, Designer 2000 will be our Data Modeling tool and
 

> > > the next logical leap would be Developer 2000 for our ADT.
> > >
> > > My question. What are the strengths and weaknesses of Developer 2000.
> > > I'm interested in what the people who use it think, not what the vendor
> > > tells you. Any suggestions of other tools that might be comparable?
> > >
> > > Any and all comments will be appreciated
> > >
  Received on Fri Mar 21 1997 - 00:00:00 CET