tbetz@dasys1.UUCP (Tom Betz) (06/24/88)
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<!!"fyl@ssc.UUCP (Phil Hughes) (06/26/88)
In article <5136@dasys1.UUCP>, tbetz@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
jtc@dasher.SanDiego.NCR.COM (Jeffrey T. Carter) (06/27/88)
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<!!" 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@SanDiego.NCR.COM (619)485-2643 = ============================================================================= #include <std/disclaimer.h> I have no relation to Progress Corp. other than as a customer.
tankus@hsi.UUCP (Ed Tankus) (06/28/88)
I spoke with the Progress people recently and they claim the do run under
BSD on the VAX, only under Sun. I believe the same was true for Zim. I
will receive the literature from both firms this week and will confirm this
if possible.
Cheers!
-- Ed.
Net : {uunet,noao,yale}!hsi!tankus
Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511
Bell : (203) 562-2101mitch@Stride.COM (Thomas Mitchell) (07/02/88)
>In article <5136@dasys1.UUCP> tbetz@dasys1.UUCP (Tom Betz) writes: >> In evaluating 4GL/RDBMS products available for Xenix 386, with an >> management/production database system, I've come down to a choice >> between ZIM and Progress... and right now I'm leaning toward ZIM, for I just had a 10 min tour of ZIM at one of our product shows. I was impressed with the clarity of the language that the presenter used to describe his sample relational data base. The relations between various records and files were very cleanly presented. Some of this was the presenter to be sure but much was also the underlying product. I wish I had the time to play with both. I expect I would be a better programmer for working in ZIM -- even if another product was selected for production work. > Is ZIM portable to other platforms? The NCR binary ran fine on our Stride. This indicates that the code is rather clean and portable. Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975 MicroSage Computer Systems Inc. Opinions expressed are probably mine. -- Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975 MicroSage Computer Systems Inc. Opinions expressed are probably mine.
allbery@ncoast.UUCP (Brandon S. Allbery) (07/05/88)
As quoted from <383@dasher.SanDiego.NCR.COM> by jtc@dasher.SanDiego.NCR.COM (Jeffrey T. Carter): +--------------- | In article <5136@dasys1.UUCP> tbetz@dasys1.UUCP (Tom Betz) writes: | > 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). +--------------- Could you enlighten me as to how make(1) can determine that a small part of a single file has changed and determine which dependencies have changed? Since Progress stores everything in a single file, there's no way to make a recompile of procedures dependent on changes to the data dictionary except by kluges (i.e. dump the data dictionary to a file after every change made to it) -- and no way whatever to recompile only the procedures dependent on a particular table. No 4GL that I am familiar with handles this automatically, although Accell IDS comes close. (Please note that I say nothing about 4GLs which I am *not* familiar with; I would be pleased to discover a 4GL which tracked that information for me.) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc