ZIM vs PROGRESS

[Phil Hughes]

In article <5136 at dasys1.UUCP>, tbetz at dasys1.UUCP (Tom Betz) writes:
> x
>      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:  
>  
>      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!

Progress does this as well even though possibly at the wrong time.
It will not run a procedure when the data dictionary has been updated
since the compile.
I actually use a make file to do the right compiles when I change
include files, a possibly more probable error.

>  
>      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!  

Again, Progress allows this.  All procedures must be compiled to run
but Progress just checks to see if a compiled version exists.  If not,
it compiles the source version.  Compile times are not very long so
this shouldn't be a serious problem at debug time.  The longest compile
I have is probably 10-15 seconds for a few hundred lines on a 286
system.  Expect the 386 system to run about 4 times faster.


I have been using Progress for about 2 years and am happy with it.
I don't know about Zim and am interested to see how it all comes out.


-- 
Phil    uunet!pilchuck!ssc!fyl