Xref: utzoo comp.databases:1110 comp.unix.wizards:9574 comp.unix.questions:7745 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!phri!dasys1!tbetz From: tbetz@dasys1.UUCP (Tom Betz) Newsgroups: comp.databases,comp.unix.wizards,comp.unix.questions Subject: ZIM vs PROGRESS Summary: Zim seems to have an edge on PROGRESS... opinions? Keywords: Zim, Progress, 4GL, RDBMS Message-ID: <5136@dasys1.UUCP> Date: 23 Jun 88 19:24:23 GMT Reply-To: tbetz@dasys1.UUCP (Tom Betz) Organization: The Big Electric Cat Lines: 51 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: 1: Zim has a richer set of built-in mathematical functions, while retaining all the capabilities of Progress. 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. 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! 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. These are just a few of the points I have observed in a couple weeks' part-time exploration of these two packages. I would very much appreciate comments from anyone who has used either or both of these packages regarding points I may have missed or should look out for... also from partisans of other 4GL packages that can offer reasons why I'm missing the boat here. As usual, if sufficient response is generated, I will summarize to the Net. -- Tom Betz ZCNY {bellcore,cmcl2}!cucard!dasys1!tbetz Yonkers, NY, USA 10701-2509 "Opinions? What opinions? These are >facts