Xref: utzoo comp.databases:1122 comp.unix.wizards:9631 comp.unix.questions:7809 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ucsd!ucsdhub!hp-sdd!ncr-sd!dasher!jtc From: jtc@dasher.SanDiego.NCR.COM (Jeffrey T. Carter) Newsgroups: comp.databases,comp.unix.wizards,comp.unix.questions Subject: Re: ZIM vs PROGRESS Keywords: Zim, Progress, 4GL, RDBMS Message-ID: <383@dasher.SanDiego.NCR.COM> Date: 27 Jun 88 16:14:09 GMT References: <5136@dasys1.UUCP> Reply-To: jeff.carter@SanDiego.NCR.COM (Jeffrey T. Carter) Organization: NCR Corporation, E&M San Diego Lines: 68 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@dasys1.UUCP> tbetz@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 I have no relation to Progress Corp. other than as a customer.