I need a new compiler...
in [Cobol]
|
Prev: COBOL/CICS/DB2 - COBOL for MVS and compile option DYNAM -solution from 2006
Next: Still one more Overlapping operands test
From: Richard on 12 Dec 2008 22:53 On Dec 13, 2:42 pm, docdw...(a)panix.com () wrote: > In article <ghufmm41...(a)news1.newsguy.com>, > Michael Wojcik <mwoj...(a)newsguy.com> wrote: > > >docdw...(a)panix.com wrote: > > >> the first resonates; as I recall it Ritchie designed C at Bell Labs (back > >> when it was Bell Labs, early 1970s) as a replacement for Assembley > >> mnemonics. > > >Compiled languages in general were designed as a replacement for > >assembly programming. That doesn't make them "like assembly". > > It was not my intention to give that impression, Mr Wojcik, and I > apologise for my clumsiness in having done so. > > > > >> It is a compiled language, true, but still provides low-level > >> system/memory/device access in an Assembley-like manner. > > >No, it doesn't. Some C implementations may extend the language to > >provide direct access to memory and devices (whatever that may mean on > >the platform), but that's not part of the C language. > > If C, in fact, does *not* 'provide low-level access to memory' Define 'low level access'. > and is does > *not* have a 'primary use is for "system programming", including > implementing operating systems and embedded system applications, How have you established what its 'primary use' would be ? C was first used for applications and utilities (such as editing and word processing) well before it was used for operating systems. So if 'primary' has its usual meaning of 'first' or 'initial' then that is not it. If you meant 'major' then I doubt that operating systems represent the majority of lines of code in C. > due to a > combination of desirable characteristics such as code portability and > efficiency, Much the same as many, such as FORTRAN. > ability to access specific hardware addresses, Whether it can or not depends on several factors including the implementation and the memory model of the system. > ability to > "pun" types to match externally imposed data access requirements' As with many languages C often, but not always, uses the machine's types. > then it > would seem that I am incorrect. > > (quoted material above taken fromhttp://en.wikipedia.org/wiki/C_(programming_language) ... me, I'se jes' a > COBOL-codin' fool) > > DD
From: Anonymous on 13 Dec 2008 05:04 In article <97b437eb-3a62-4fb0-b8f0-a356b0fc4e5c(a)i24g2000prf.googlegroups.com>, Richard <riplin(a)Azonic.co.nz> wrote: >On Dec 13, 2:42�pm, docdw...(a)panix.com () wrote: >> In article <ghufmm41...(a)news1.newsguy.com>, >> Michael Wojcik �<mwoj...(a)newsguy.com> wrote: >> >> >docdw...(a)panix.com wrote: >> >> >> the first resonates; as I recall it Ritchie designed C at Bell Labs (back >> >> when it was Bell Labs, early 1970s) as a replacement for Assembley >> >> mnemonics. >> >> >Compiled languages in general were designed as a replacement for >> >assembly programming. That doesn't make them "like assembly". >> >> It was not my intention to give that impression, Mr Wojcik, and I >> apologise for my clumsiness in having done so. >> >> >> >> >> �It is a compiled language, true, but still provides low-level >> >> system/memory/device access in an Assembley-like manner. >> >> >No, it doesn't. Some C implementations may extend the language to >> >provide direct access to memory and devices (whatever that may mean on >> >the platform), but that's not part of the C language. >> >> If C, in fact, does *not* 'provide low-level access to memory' > >Define 'low level access'. > > >> and is does >> *not* have a 'primary use is for "system programming", including >> implementing operating systems and embedded system applications, > >How have you established what its 'primary use' would be ? > >C was first used for applications and utilities (such as editing and >word processing) well before it was used for operating systems. So if >'primary' has its usual meaning of 'first' or 'initial' then that is >not it. > >If you meant 'major' then I doubt that operating systems represent the >majority of lines of code in C. > > >> due to a >> combination of desirable characteristics such as code portability and >> efficiency, > >Much the same as many, such as FORTRAN. > >> ability to access specific hardware addresses, > >Whether it can or not depends on several factors including the >implementation and the memory model of the system. > >> ability to >> "pun" types to match externally imposed data access requirements' > >As with many languages C often, but not always, uses the machine's >types. > >> then it >> would seem that I am incorrect. >> >> (quoted material above taken >fromhttp://en.wikipedia.org/wiki/C_(programming_language) ... me, I'se >jes' a >> COBOL-codin' fool) >> >> DD >
From: btiffin on 13 Dec 2008 15:08 On Dec 11, 3:33 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Dec 12, 5:04 am, "Paul H" <NoSpamphobergNoS...(a)att.net> wrote: > > > Thanks Pete, > > But your alternatives mostly intimidate me. > > You should note that while OpenCobol, Cobol-IT, tinyCobol are mostly > ANS85 they may not have features that you think of a 'normal'. > MicroFocus has many extensions, such as X/Open and ADIS. These are not > standard ANS85 Cobol and may not exist in other compilers. > > For example in Microfocus you can ACCEPT and DISPLAY AT position (or > variations such as LINE COLUMN) to produce screen interactive > programs. > > In Microfocus (and other commercial products) you can have shared > files with record locking. > > These are not standard ANS85 and may not be available in other > compilers, or may not work the same as MF or other commercial products > (RM, Acu, etc). > > > Isn't using C or Java like > > coding in assembly language? > > No. Using GOTO or not using scope terminators in Cobol is "like using > assembly language". > > > If I stay with COBOL, none of the alternatives > > offer the debugging environment like MF's. Animating, breakpoints, value > > monitoring, etc. These make me productive. > > What do you think about > > Clarion? I did buy a copy a few years ago, but gave up trying to learn to > > use it. Maybe I'll give it another look. > > Paul > > Recent OpenCOBOL 1.1 pre-release versions have a fair handle on SCREEN SECTION and DISPLAY var LINE nn COLUMN nn WITH ERASE EOS etc... As far as I know, the only parts of the NIST test suite not passed now are REPORT SECTION and COMMUNICATION SECTION. With Berkeley DB, most of the sophisticated record and key management options are supported and there are efforts afoot for a native VBISAM layer to make the BDB dependency optional. We now have layers for embedding JavaScript core (SpiderMonkey), Lua, Perl, Tcl/Tk, libCURL, Regina REXX, SQLite (both API and a shell clone), libDBI for MySQL and other databases. Bindings to a full fledged GUI through GTK+ are in progress and even in its early version, support for windows, buttons, text entry, file dialogs etcetera allow for simple but useful GUI applications. Due to OpenCOBOL's model of C generation there are already linkage options for gnat Ada, gfortran and the plethora of other languages that generate object files. Routines for access to gnuplot have been written, along with shell scripts and other external tools. A very complete ncurses layer has existed for quite sometime in the cobcurses package. Documentation is being written and grows daily including instructions for using the gdb debugger. Oh, and it's a very comprehensive COBOL compiler as is, and development is so active at the moment that it is hard to keep up. ;) I recommend that anyone and everyone give it a go. http://opencobol.org A repository of pre-built binaries exist for AIX, HPUX, WIN32 and I've been running it actively on Debian GNU/Linux since I first bumped into it a few scant months ago. Information about the repository can be found in the opencobol.org forums. Cheers, Brian
From: William M. Klein on 13 Dec 2008 15:52 Brian, As far as '85 Standard compliance goes, do you know if Roger (or anyone) has finished all the nested program "stuff"? Las I heard, I didn't think so. Also, I do not think that ANSI intrinsic functions have been implemented yet - but again, I could be mistaken. (The Intrinsic Functions Amendment/module was "optional" for ANSI compliance but was required for FIPS compliance - by 1993). Having said that, it is a VERY complete compiler including both '85 Standard features and many common extensions. -- Bill Klein wmklein <at> ix.netcom.com <btiffin(a)canada.com> wrote in message news:30997c16-9a6c-48c3-825e-291ac7d9aa22(a)e22g2000vbe.googlegroups.com... On Dec 11, 3:33 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Dec 12, 5:04 am, "Paul H" <NoSpamphobergNoS...(a)att.net> wrote: > > > Thanks Pete, > > But your alternatives mostly intimidate me. > > You should note that while OpenCobol, Cobol-IT, tinyCobol are mostly > ANS85 they may not have features that you think of a 'normal'. > MicroFocus has many extensions, such as X/Open and ADIS. These are not > standard ANS85 Cobol and may not exist in other compilers. > > For example in Microfocus you can ACCEPT and DISPLAY AT position (or > variations such as LINE COLUMN) to produce screen interactive > programs. > > In Microfocus (and other commercial products) you can have shared > files with record locking. > > These are not standard ANS85 and may not be available in other > compilers, or may not work the same as MF or other commercial products > (RM, Acu, etc). > > > Isn't using C or Java like > > coding in assembly language? > > No. Using GOTO or not using scope terminators in Cobol is "like using > assembly language". > > > If I stay with COBOL, none of the alternatives > > offer the debugging environment like MF's. Animating, breakpoints, value > > monitoring, etc. These make me productive. > > What do you think about > > Clarion? I did buy a copy a few years ago, but gave up trying to learn to > > use it. Maybe I'll give it another look. > > Paul > > Recent OpenCOBOL 1.1 pre-release versions have a fair handle on SCREEN SECTION and DISPLAY var LINE nn COLUMN nn WITH ERASE EOS etc... As far as I know, the only parts of the NIST test suite not passed now are REPORT SECTION and COMMUNICATION SECTION. With Berkeley DB, most of the sophisticated record and key management options are supported and there are efforts afoot for a native VBISAM layer to make the BDB dependency optional. We now have layers for embedding JavaScript core (SpiderMonkey), Lua, Perl, Tcl/Tk, libCURL, Regina REXX, SQLite (both API and a shell clone), libDBI for MySQL and other databases. Bindings to a full fledged GUI through GTK+ are in progress and even in its early version, support for windows, buttons, text entry, file dialogs etcetera allow for simple but useful GUI applications. Due to OpenCOBOL's model of C generation there are already linkage options for gnat Ada, gfortran and the plethora of other languages that generate object files. Routines for access to gnuplot have been written, along with shell scripts and other external tools. A very complete ncurses layer has existed for quite sometime in the cobcurses package. Documentation is being written and grows daily including instructions for using the gdb debugger. Oh, and it's a very comprehensive COBOL compiler as is, and development is so active at the moment that it is hard to keep up. ;) I recommend that anyone and everyone give it a go. http://opencobol.org A repository of pre-built binaries exist for AIX, HPUX, WIN32 and I've been running it actively on Debian GNU/Linux since I first bumped into it a few scant months ago. Information about the repository can be found in the opencobol.org forums. Cheers, Brian
From: btiffin on 14 Dec 2008 19:49
On Dec 13, 3:52 pm, "William M. Klein" <wmkl...(a)nospam.ix.netcom.com> wrote: > Brian, > As far as '85 Standard compliance goes, do you know if Roger (or anyone) has > finished all the nested program "stuff"? Las I heard, I didn't think so. > > Also, I do not think that ANSI intrinsic functions have been implemented yet - > but again, I could be mistaken. (The Intrinsic Functions Amendment/module was > "optional" for ANSI compliance but was required for FIPS compliance - by 1993). > > Having said that, it is a VERY complete compiler including both '85 Standard > features and many common extensions. > > -- > Bill Klein > wmklein <at> ix.netcom.com<btif...(a)canada.com> wrote in message > > news:30997c16-9a6c-48c3-825e-291ac7d9aa22(a)e22g2000vbe.googlegroups.com... > On Dec 11, 3:33 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > > On Dec 12, 5:04 am, "Paul H" <NoSpamphobergNoS...(a)att.net> wrote: > > > > Thanks Pete, > > > But your alternatives mostly intimidate me. > > > You should note that while OpenCobol, Cobol-IT, tinyCobol are mostly > > ANS85 they may not have features that you think of a 'normal'. > > MicroFocus has many extensions, such as X/Open and ADIS. These are not > > standard ANS85 Cobol and may not exist in other compilers. > > > For example in Microfocus you can ACCEPT and DISPLAY AT position (or > > variations such as LINE COLUMN) to produce screen interactive > > programs. > > > In Microfocus (and other commercial products) you can have shared > > files with record locking. > > > These are not standard ANS85 and may not be available in other > > compilers, or may not work the same as MF or other commercial products > > (RM, Acu, etc). > > > > Isn't using C or Java like > > > coding in assembly language? > > > No. Using GOTO or not using scope terminators in Cobol is "like using > > assembly language". > > > > If I stay with COBOL, none of the alternatives > > > offer the debugging environment like MF's. Animating, breakpoints, value > > > monitoring, etc. These make me productive. > > > What do you think about > > > Clarion? I did buy a copy a few years ago, but gave up trying to learn to > > > use it. Maybe I'll give it another look. > > > Paul > > Recent OpenCOBOL 1.1 pre-release versions have a fair handle on SCREEN > SECTION and DISPLAY var LINE nn COLUMN nn WITH ERASE EOS etc... > > As far as I know, the only parts of the NIST test suite not passed now > are REPORT SECTION and COMMUNICATION SECTION. > > With Berkeley DB, most of the sophisticated record and key management > options are supported and there are efforts afoot for a native VBISAM > layer to make the BDB dependency optional. > > We now have layers for embedding JavaScript core (SpiderMonkey), Lua, > Perl, Tcl/Tk, libCURL, Regina REXX, SQLite (both API and a shell > clone), libDBI for MySQL and other databases. Bindings to a full > fledged GUI through GTK+ are in progress and even in its early > version, support for windows, buttons, text entry, file dialogs > etcetera allow for simple but useful GUI applications. Due to > OpenCOBOL's model of C generation there are already linkage options > for gnat Ada, gfortran and the plethora of other languages that > generate object files. Routines for access to gnuplot have been > written, along with shell scripts and other external tools. > > A very complete ncurses layer has existed for quite sometime in the > cobcurses package. > > Documentation is being written and grows daily including instructions > for using the gdb debugger. > > Oh, and it's a very comprehensive COBOL compiler as is, and > development is so active at the moment that it is hard to keep up. ;) > > I recommend that anyone and everyone give it a go. http://opencobol.org > > A repository of pre-built binaries exist for AIX, HPUX, WIN32 and I've > been running it actively on Debian GNU/Linux since I first bumped into > it a few scant months ago. Information about the repository can be > found in the opencobol.org forums. > > Cheers, > Brian Re: Intrinsic FUNCTION. Unless I'm mistaken, all the functions are in 1.1 http://opencobol.add1tocobol.com/#q-does-opencobol-implement-any-intrinsic-functions Re: Nested programs. Again, as far as I know, yes. Nested programs are fully supported (I could be wrong, as there may be little bits missing, but I don't think so). Recent addition of GLOBAL support added the last piece of the puzzle. Cheers, Brian |