Prev: COBOL/CICS/DB2 - COBOL for MVS and compile option DYNAM -solution from 2006
Next: Still one more Overlapping operands test
From: Pete Dashwood on 17 Dec 2008 17:39 Paul H wrote: > Wow! I have almost no idea what you guy are arguing about (maybe a > little). I do understand that my comment that I want to avoid > anything that seems like assembly language caused most of this. > > I started my career with Autocoder on an IBM 1401, then Honeywell's > Easycoder, then a couple others whose names I can't remember > (something on a Data general computer?) Ah, I have dropped word marks with the best of 'em... : - ) I remember running 1401 Autocoder I wrote, on system 360 in compatibility mode and thinking how wondrous life was... : - ) I used 8086 machine language > to enable my COBOL to access serial ports, Enuf assembler!!! > > I conclude that no COBOL will do what I need. Perhaps you mean "no FREE COBOL"? I don't want to pry into what you are trying to do, but COBOL is a very powerful language. Maybe Clarion (I > already own version 5.5), or RealBasic, if I can find a data base > that stays in my target price range. Funny thing Paul, I was looking at Clarion the other day. Found (to my astonishment) that it supports ActiveX and COM components. This makes it a very powerful tool. You could get or build components to do what you want and "glue" them together with Clarion... RealBasic may also be a good option. (Visual Basic is free from MicroSoft and you can develop it in Visual Studio Express, which is also free...) As for database...I can personally recommend MySQL which is free. MS Access (2000 and above) has also come a long way from its humble (and generally poorly implemented) beginnings. Good luck! Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 17 Dec 2008 17:57 Paul H wrote: > I should have added that in the late 60's the "Journal of the ACM" > had an article that said something to the effect that all processing > could be driven by thorough description of data structures. That's > why I like COBOL so much. By describing data structures, the code > needed to deal with arithmetic or logic can ignore these details. > The programmer is unlikely to scribble on memory outside of his data > division. No wonder more lines of COBOL code (a quarter of a > trillion lines?) are in use today, with billions more written every > year. Not intended as "punishment" (believe whatever you want to...) but: 1. The estimate of 5 billion lines of COBOL a year is suspect, but even if it were true, the lines written in Java alone are around 5 times that. (To be fair, these estimates are just as suspect as the COBOL ones... no-one REALLY knows.) 2. The quarter of a trillion lines of COBOL came from a Gartner report (as Gartner do business with a large COBOL user base it can hardly be seen as unbiased...) that is now over 10 years old. In that time billions of lines of that codebase have been eroded by conversion, replacement, and retirement, and this process proceeds and accellerates every year. The point is that it doesn't matter how many LOC are written in ANY language; what matters is the cost of writing it and whether it can be or needs to be, maintained. > And consider the number of lines of lower level language that > are needed to do what single lines of COBOL do. "string" and > "unstring delimited by" are good examples. I dread the flaming > responses that these comments will cause. Please, just let me > express my opinion without being punished. Paul There are a number of powerful constructs in COBOL and these are just two of them. COBOL's problems were never with the power of the language. This is not a "flaming" response, Paul, just civilized discussion and observation... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: HeyBub on 17 Dec 2008 19:11 Paul H wrote: > And consider the number of lines of lower level language that > are needed to do what single lines of COBOL do. "string" and > "unstring delimited by" are good examples. I dread the flaming > responses that these comments will cause. Please, just let me > express my opinion without being punished. Paul A better example would be floating the currency symbol to the immediate left of the most significant number or check-protecting a field. Trivial. Conversely, computing the hyperbolic arc tangent is pretty tough in COBOL (I've only done it once) - but just one statement in FORTRAN.
From: Paul on 17 Dec 2008 22:44
On 2008-12-16 23:18:09 -0600, "Paul H" <NoSpamphobergNoSpam(a)att.net> said: > Wow! I have almost no idea what you guy are arguing about (maybe a little). > I do understand that my comment that I want to avoid anything that seems > like assembly language caused most of this. > > I started my career with Autocoder on an IBM 1401, then Honeywell's > Easycoder, then a couple others whose names I can't remember (something on a > Data general computer?) I used 8086 machine language to enable my COBOL to > access serial ports, Enuf assembler!!! > > I conclude that no COBOL will do what I need. Maybe Clarion (I already own > version 5.5), or RealBasic, if I can find a data base that stays in my > target price range. <grin> Realbasic comes with a little old database... </grin> I really like RealBasic. :) > > Thanks for your help, everybody. > > Paul > > "Paul H" <NoSpamphobergNoSpam(a)att.net> wrote in message > news:494095a5$0$5502$bbae4d71(a)news.suddenlink.net... > I've been using MicroFocus Net Express for many years, but now I want to > write a small application that would sell for maybe $20.00. MF would charge > a run-time fee to each user, so I need to select a different Compiler. > Where can I find a list of inexpensive compilers, with ratings? Does such a > list exist? TIA, Paul |