Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!amanue!oglvee!jr From: jr@oglvee.UUCP (Jim Rosenberg) Newsgroups: comp.databases Subject: Re: Info wanted on PROGRESS DBMS Keywords: Progress 4GL RDBMS Message-ID: <531@oglvee.UUCP> Date: 19 Mar 90 17:39:45 GMT References: <7266@life.ai.mit.edu> Organization: Oglevee Computer Systems, Connellsville, Pa Lines: 32 ericf@montreux (Eric Feigenson) writes: >Hi! I am looking at various RDBMS and have come across mention of a product >called "Progress" (which is also the name of the company, I believe). [...] >Has anyone had any experience actually *using* this system? Is it any good? >Is it easy to use? How big of an application can it handle? Is the language >sane and/or rational to use (please... no COBOL!)? We've been using Progress for our MIS work and are quite pleased. As far as how "rational and sane" the language is, it's TERRIFIC. It's fully block structured, no goto statement, and all kinds of neat things are scoped to blocks. For instance there's an undo statement to roll back transactions; undo is also a *control flow statement*: you undo a block. It's the best DBMS language I've seen from a standpoint of readability of the code. As to application size, there's a fly in the ointment here. Code is portable among DOS, VMS, most UNIX platforms -- supposedly even AS400! -- but on Intel architecture machines there's a limit of 64K on the size of a compiled procedure. This is a very big pain in a tender place. You can usually figure out a way to break up an application into small enough pieces, but occasionally it causes real problems. I wrote a an automated system that sends database information over UUCP and validates transactions at each end -- almost entirely in Progress. That should tell you something about the power and flexibility of the language. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include