mats@enea.se (Mats Josefsson) (06/04/89)
Hi, I am working in a large DBMS project. It is an on-line transaction system with very large amounts of data, several tens of Gigabytes. The size of the development phase is estimated to be in the order of 50 to 100 man years. We're just starting up and have to make some decisions about the development environment, specifically on which 3GL(s) to use, C or C and COBOL. It has already been decided to use Ingres RDBMS. Most of the applications are going to be developed in OSL, Ingres' 4GL. But my (and others) experience tells me that there will be a need for at least one 3GL as well. I can see two reasons for using a 3GL, 1) some tasks are not at all possible to do in OSL, and 2) some tasks will be too slow in OSL. Since this is a UNIX(tm) environment we think that C (maybe with ESQL) is the language to use for tasks that isn't possible to do in OSL. Examples of the other types of tasks are reports on and batch updating of very large (sets of) tables in the database. I know that it would be possible to do this in C, but other people in the project say that for this type of tasks COBOL is the preferred language. Since I don't know COBOL, I can't argue with this statement. COBOL is said to have support for report writing and other types of data handling. But isn't this equally well handled by well designed C function libraries and/or preprocessors? You may have to develop the libraries yourself, but in a project this size it may be worth the effort (or will it not?). There are other factors to take into account as well. Most of the applications will be developed (programmed) by people not familiar with UNIX and C, but with at least some COBOL experience. If they are going to use C they will have to be educated. And of course there is the additional cost of supporting two 3GL's instead of one (I'm sure COBOL can't replace C for systems programming). I would like to get comments and advice from people who have experience with development in a similar environment. My question really is: "Should we use C for all non-OSL programming, or a combination of C and COBOL?" I don't want to start a (new) C vs. COBOL war. I'm only interested in their relative merits in this specific environment. Thanks in advance, Mats Josefsson, ENEA Data AB, Sweden mats@enea.SE
pscaaf@vms.macc.wisc.edu (Ron Peterson) (06/12/89)
In article <18@helios.se>, mats@enea.se (Mats Josefsson) writes... >I am working in a large DBMS project. It is an on-line transaction >system with very large amounts of data, several tens of Gigabytes. >The size of the development phase is estimated to be in the order >of 50 to 100 man years. We're just starting up and have to make >some decisions about the development environment, specifically >on which 3GL(s) to use, C or C and COBOL. >It has already been decided to use Ingres RDBMS. > "Should we use C for all non-OSL programming, or a > combination of C and COBOL?" I am using Ingres in a vax/vms environment where COBOL is not available, although I am a COBOL programmer. I use C, ReportWriter, QBF, SQL, and QUEL. OSL was avoided to keep applications portable. The C programs are used for batch loading of "heads-down" keyed data to the database. It is not a transaction oriented system. COBOL would be better than C for hard copy reports, but Report- Writer is much faster for simple reports. I would use C for everything else to ensure portability to other systems and efficiency(compiled code). Ingres does not use packed decimal data, which is handled nicely by COBOL. COBOL also uses ISAM files, which are not needed when a relational database is available. A 50 to 100 man year project seems rather large, how many tables and columns are involved?
bg0l+@andrew.cmu.edu (Bruce E. Golightly) (06/12/89)
Carnegie Mellon went through something like this. Some of the answers really aren't clear or clean. I can pass along some of the things we have learned and some of the conclusions we reached. 1) Nearly everybody knows COBOL. Traditionally, this is one of the first languages programmers learn, especially in those schools that place some emphasis on business programming. 2) C, when written after a little thought and planning, can be one of the most portable languages around. We have successfully ported C back and forth from VMS to Unix. This cannot be done with COBOL, 'cause COBOL isn't in the Unix world. 3) COBOL does better output formatting than nearly anything. 4) C is (generally) faster, especially in arithmetic operations. COBOL arithmetic on the wrong platform can be an incredible dog. Conclusions and observations: - We'll plan to do all future development work in C, except for quick portsl of systems from other platforms that are already written in COBOL. - We will continue to provide COBOL support, but only for exissting systems or those mentioned above. - Mixed language systems are probably a mistake. C and COBOL within a single application/system is a really obnoxious mix. - Don't overlook ABF, ReportWriter, RBF and the use of SQL scripts in planning your work. These Ingres tools can be real helps. Hope this stuff helps. --------------- More ramblings from Bruce --------------------
emuleomo@yes.rutgers.edu (Emuleomo) (06/14/89)
From personal experience, I would say you should use OSL and C. Dont even try mixing up COBOL into the situation. Isay this for a number of reasons. a) There will likely be many more installations out there that are using OSL and C (and possibly ESQL/C). b) I suspect that C will be better supported by RTI. c) Most importantly, I am also involved in a project where I am using Ingres with OSL,C and ESQL/C. Thus we can swap war stories/experiences. --Emuleomo O.O. (emuleomo@yes.rutgers.edu) -- ** Research is what I'm doing when I dont know what I'm doing! **