ZIM vs PROGRESS

[Jeffrey T. Carter]

I have not used (or even heard of) Zim, and therefore cannot comment on how 
it compares to Progress.  However, I have used Progress and a couple of items
mentioned here are not quite correct:

In article <5136 at dasys1.UUCP> tbetz at dasys1.UUCP (Tom Betz) writes:
>     In evaluating 4GL/RDBMS products available for Xenix 386, with an 
> aim of using one of these to develop an order proccessing/inventory 
> management/production database system, I've come down to a choice 
> between Zim and Progress...  and right now I'm leaning toward Zim, for 
> several reasons:  
> 
>     1:  Zim has a richer set of built-in mathematical functions, while 
> retaining all the capabilities of Progress.  

    I can't comment on this, but Progress has a good set of the basic math
    functions.  What in particuliar are you looking for?

> 
>     2: Zim's set- and entity-based approach (including ROLES, a sort 
> of aliasing) appeals to my sense of how a business is actually 
> structured.  I do feel a bit of discomfort at letting go of arrays, 
> since Zim does not employ them, but I also feel that the power offered 
> by set handling will easily offset this.

    I am not exactly sure what is meant by ROLES, but Progress has the 
    ability to "preselect" portions of a table, thereby providing a 
    logical subset of the entire database.

> 
>     3:  Zim's self-documentation features far outstrip Progress's.  
> One example - when one adds or deletes a field from a file, one needs 
> must recompile any compiled procedures using that file.  Zim is kind 
> enough to tell you which procedures need to be recompiled, so you are 
> less likely to miss one.  This could save a lot of grief in an OLTP 
> system!

    We use makefile's to solve this problem.  Please see make(1).

> 
>     4: Progress automatically compiles every procedure before running 
> it, while Zim permits considerable debugging in an interpreter, then 
> lets the user decide when it's time to compile.  Zim even permits 
> compiled procedures to call uncompiled procedures, and vice-versa!  
> Zim's approach, while offering considerable power to the user, also 
> leaves itself open to some hazards (if the interpreted procedure 
> happens to return something the procedure calling it doesn't 
> anticipate) but I think the power it offers is well worth the 
> tradeoff.

    Progress allows this type of mixture of compile and uncompiled 
    programs.


    Is Zim portable to other platforms?  We choose Progress as our
    devevlopment environment because of its ability to run unchanged on
    several different hardware/OS platforms, i.e.  PC(DOS), PC(XENIX),
    as well as SYSV, BSD, and I believe VAX.

>"Opinions? What opinions? These are >facts<!!"
Just helping the facts be a little more accurate.

=============================================================================
=    UUCP: sdcsvax \                          Jeffrey T. Carter             =
=    NCR:  ncrcae   - !ncr-sd!jtc             Plant Network Administrator   =
=    ARPA: nosc    /                          NCR  E&M San Diego  ISS Dept. =
=    or try   jeff.carter at SanDiego.NCR.COM    (619)485-2643                 =
=============================================================================
#include <std/disclaimer.h>
I have no relation to Progress Corp. other than as a customer.