Corruption of COBOL.
in [Cobol]
|
Prev: 182966 Constantly updated Free COmputer and business portal 94
Next: Traditional COBOL environment
From: Pete Dashwood on 9 Feb 2010 21:57 SkippyPB wrote: > On Mon, 8 Feb 2010 13:39:37 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> SkippyPB wrote: >>> On Sun, 7 Feb 2010 13:05:03 +1300, "Pete Dashwood" >>> <dashwood(a)removethis.enternet.co.nz> wrote: >>> >>>> Fred Mobach wrote: >>>>> Pete Dashwood wrote: >>>>> >>>>>> Alistair wrote: >>>>>>> On Feb 5, 10:32 am, "Pete Dashwood" >>>>>>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>>>>>> Sure. But don't try and rewrite Shakespeare in English, either. >>>>>>>> >>>>>>> >>>>>>> I can't resist: >>>>>>> >>>>>>> 2 B / not 2 B? >>>>>> >>>>>> LOL! >>>>>> >>>>>> I guess it is only a matterof time before someone with more time >>>>>> on their hands than they should have, produces a TXT version of >>>>>> the works of Shakespeare. >>>>>> >>>>>> If it would get kids to read the original, I wouldn't complain. >>>>>> :-) >>>>> >>>>> If via >>>>> lynx -dump >>>>> to TXT reformatted HTML will do you can have a look at >>>>> http://shakespeare.mit.edu/ >>>> >>>> When I was a teenager I had the Complete works of Shakespeare (and >>>> a few others of my favourite authors, Kipling, Poe, and Edgar Rice >>>> Burroughs (many people don't realize he wrote a lot more than >>>> "Tarzan") in book form, of course, and spent many happy hours >>>> engrossed in them. Over the years, with travelling and moving (not >>>> to mention pilferage from storage warehouses) these have been lost >>>> and I keep thinking I must replace them, but never get round to it. >>>> From time to time, I get the urge for Shakespeare and I recently >>>> bought the RSC production of King Lear, on DVD. It came with a >>>> bound transcript, and, although it is not my favourite Shakespeare >>>> play (and is pretty heavy going in places) I did enjoy it. >>>> >>>> Thank you so much for this link, Fred. I have bookmarked it and >>>> will be using it. >>>> >>>> Pete. >>> >>> As a kid I wasn't into Shakespeare so much but I did read everything >>> Edgar Allen Poe wrote and I read a lot of non-Tarzan books that >>> Edgar Rice Burroughs wrote as well. I also, at age 10 or 11, read >>> the original Mary Shelley book Frankenstein and Bram Stoker's >>> Dracula. Both had what I can only describe as a rich language. I >>> admit I had strange reading habits as a kid. No idea where they >>> came from. I also was into reading Sir Arthur Conan Doyle's >>> Sherlock Holmes' books and a lot of science fiction by the authors >>> of the day. >> >> Yep, all great stuff and I did the same at around the same age. >> >> I wonder if what we read at an early age can shape us? >> >> I guess it can if we agree with it or are delighted by it. Or maybe >> the rich world of fiction is just a good escape for people at any >> age. >> >> I'd like to think any flaws in my current character were not the >> result of reading the authors you mention... :-) >> >> Of course, if I can blame my faults on Poe or Shakespeare, that >> would be a really good cop out... :-) >> >> Pete. > > Well Mr. Poe was an Opium addict :) Nevermore, nevermore. I never heard of that. He certainly was adicted to alcohol and on ONE occasion tried to suicide from an overdose of Laudunum (an opiate commonly used in Victorian times for sleeping problems)... sure you're not thinking of Samuel Taylor Coleridge? Xanadu is definitely tripping and there are parts of the Ancient Mariner which look like they were influenced by substance abuse... "The very deeps did rot Oh, Christ! That ever this should be Yea... slimy things did crawl with legs Upon the slimy sea." Pete -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 9 Feb 2010 21:59 Michael Wojcik wrote: > Pete Dashwood wrote: >> Alistair wrote: >>> On Feb 5, 10:32 am, "Pete Dashwood" >>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>> Sure. But don't try and rewrite Shakespeare in English, either. >>>> >>> I can't resist: >>> >>> 2 B / not 2 B? >> >> LOL! >> >> I guess it is only a matterof time before someone with more time on >> their hands than they should have, produces a TXT version of the >> works of Shakespeare. > > If it hasn't happened already. It'd be less work than the Lolcat > Bible,[1] after all, especially since it can be almost entirely > automated. > > There have long been filters for translating English prose to (and > sometimes from) various dialects, such as B1FF. I have a Thunderbird > extension installed that will encode/decode 1337-speak, etc. (I > installed it for Rot-13 and other marginally more useful things.) > > > > [1] http://lolcatbible.com/ Sad to say Michael, none of the above made any sense to me and I never heard of any of the references, bar Thunderbird. I'm obviously leading a deprived life... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 9 Feb 2010 22:15 john(a)wexfordpress.com wrote: > On Feb 5, 5:32 am, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> I really enjoyed your post John. >> >> I couldn't let it go without comment, though :-) >> >> see below... >> >> j...(a)wexfordpress.com wrote: >>> Many of the posts to this groups involve translating COBOL from >>> brand x to brand y. >> >> And there are other subtleties like moving from indexed files to >> relational >> databases. >> >> You may wonder why people would want to do that. >> >>> And many code snippets would make no sense whatever to >>> a programmer skilled in COBOL 85 or earlier. >> >> I am a programmer skilled in COBOL 85 or earlier. I first used COBOL >> 59 on a >> tape based system in 1967. >> >> The new stuff makes perfect sense to me. >> >> I think what you wanted to say was that it wouldn't make sense to "a >> programmer skilled in COBOL 85 or earlier" WHO HAD NOT BOTHERED TO >> EXPAND >> HIS SKILL SET AND BELIEVED THAT EVERYTHING HE WANTED TO DO HE COULD >> DO in >> COBOL 85 or earlier? >> >> Yes, I've met a few of those. They seem to have limited horizons. >> >>> I submit that >>> this new language isn't really COBOL. >> >> Object Oriented COBOL is CERTAINLY COBOL and has been endorsed as >> such by >> that august body the ANSI. >> >>> It isn't readable by most >>> programmers and isn't portable. >> >> I have OO COBOL components running across 7 different platforms >> (mainframe >> and Client/Server) on the Web and on the desktop. I have it >> interacting with >> modern languages like C#, Java and C++. How can it NOT be >> "portable"? If you >> mean the source code is not portable, you might be right, but in the >> world >> of objects the source code of an object is irrelevant. If I can write >> "COBOL" on one platform and know that what I've written can be >> distributed >> to every platform that is connected to the World Wide Web, I don't >> see that >> portability is a stumbling block. >> >> "Not readable by most programmers"? I think you mean Procedural COBOL >> Programmers. As these are less than 4% of the programmers in the >> world, I am >> struggling with your use of "most". MOST programmers in the world >> can't read >> COBOL or understand the subtleties of it. Neither do they need to. >> >>> It may >>> be useful, it may be fun, but it reminds me of the old hotrodders >>> dictum "jack up the horn and build a car >>> around it." I question whether even the horn has been kept. >> >> Certainly the horn has been kept, along with a few other more >> important >> parts, but the car is no longer a model T. (Sadly, it is not a >> Ferrari >> either, but that is a different discussion). >> >> >> >>> My general advice is to write in the 85 standard, the last standard >>> that looked like COBOL, and avoid >>> proprietary extensions as much as possible. >> >> Sound advice, for people limiting themselves to Procedural COBOL. >> >> Unfortunately, the world at large voted with its feet and moved on, >> some >> time ago. There is a new paradigm that simply works better for most >> things. (COBOL 85 is still very good for batch processing, but the >> days of batch >> processing may be numbered...) There are still pockets of standard >> COBOL >> but most sites are seeking to remove it long term. >> >> They are not doing this because of spite against COBOL. They are not >> doing >> it even because they can't do what they need to in (modern OO) >> COBOL. They >> are doing it because COBOL costs too much, and there are MUCH >> cheaper (and >> in many ways better) alternatives available. >> >> At this point I might as well go back to the earlier point about >> people >> moving to Relational Databases. If you benchmark a well written >> system using >> indexed files, for performance against a functionally equivalent >> Relational >> Database, there is a fighting chance that the indexed files will win. >> >> But it isn't technology that decides. It is cost. It is easier to >> get people >> who can write Stored SQL procedures than it is to get COBOL guys. >> But much >> more importantly, moving to the RDB environment "opens " the data >> resource. >> Now it can be easily shared by spreadsheets and desktop DB systems. >> Need a >> report? Instead of taking 3 days to get a COBOL guy to design, code >> debug >> and deliver it, you can have it generated by standard software like >> Crystal >> Reports or StimulSoft or even ACCESS Reports, in minutes, using a >> graphic >> interface that lets you drag and drop fields, control breaks, >> literals, and >> totals wherever you want them, instead of the tedium of counting >> fillers in >> a printline. Instead of the corporate data asset being locked up >> behind the >> mysterious veil of COBOL programming, it is open and available to >> anyone >> authorised to access it. >> >>> If some proprietary >>> extensions for reading/writing to gui's are necessary then isolate >>> them as a subprogram or copy files. >> >> Bob Wolfe has already responded to this, and his company's products >> are >> excellent. >> >> There are many excellent products you can bolt on to COBOL to >> enhance its >> usefulness, but it remains COBOL. >> >> There is a very large question mark over its long term future. Like >> I said >> before, it simply costs too much and it isn't capable enough, >> compared to >> other products that are now available. >> >> I am strongly committed to NOT throwing COBOL away and am offering >> solutions >> that can extend the life of useful code, but I have no illusions >> that there >> will be a long term viability for it. (please >> visit:http://primacomputing.co.nz/cobol21) >> >> Long term, the goal has to be to move to a world of Objects and >> Layers, >> where your existing COBOL code can work with other objects written >> in other >> languages on the desktop and (increasingly) the web. >> >> Object Orientation can do this easily and seamlessly; Procedural >> code can't. (Fortunately, it is possible to "wrap" existng >> procedural code so that it >> can. This is a viable way to bring existing code into the "New >> Technology".) >> >>> Writing to COBOL 85 means never having to say "it won't run on my >>> new company's compiler." >> >> Assuming the new company HAS a compiler. >> >>> COBOL should be >>> portable, readable, modifiable by any skilled COBOL programmer and >>> suitable for solving business problems. >> >> Why? >> >> New languages are portable, readable, modifiable by even a moderately >> skilled programmer and have thousands of prewritten components that >> immediately solve business problems. Not only that, but most of them >> are >> FREE. >> >> You can't say that about COBOL. >> >> >> >>> As a fellow who once shook hands with Grace Murray Hopper I say: >>> "Don't try to rewrite Shakespeare >>> in Esperanto." >> >> Sure. But don't try and rewrite Shakespeare in English, either. >> >> Pete. >> >> -- >> "I used to write COBOL...now I can do anything." > > Cobol is free. Fujitsu offers a free compiler. It is a student edition that does not support SQL or a number of other thngs. If you go to Fujitsu, (currently, Alchemy in the US) and ask for a COBOL compiler they will sell you "NetCOBOL for .NET which generates CLR code for the .Net environment. You will pay thousands of dollars for it, and the same again for ongoing maintenance. It is far from FREE. You can download C# and start generating CLR code for the .Net environment, including SQL and some additional functions that are C# specific like Linq, for absolutely zippo, free, gratis, and for nothing. >Open Cobol runs on > Linux and with some fuss and feathers under MSWindows. Yes, Open COBOL is shaping up to be a viable COBOL and there are already a few tentative commercial applications using it. But it doesn't support OO and cannot be taken seriously for MODERN development unless it does. > Ditto for Tiny > Cobol. So that argument does not hold water. OK. There ARE some versions of COBOL that are free. They are not currently in widespread commercial use. > > John Culleton > COBOL since 1968 Pete Dashwood COBOL since 1967 -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 9 Feb 2010 22:34 James J. Gavan wrote: > john(a)wexfordpress.com wrote: >> >> Cobol is free. Fujitsu offers a free compiler. Open Cobol runs on >> Linux and with some fuss and feathers under MSWindows. Ditto for Tiny >> Cobol. So that argument does not hold water. >> >> John Culleton >> COBOL since 1968 >> > By and large COBOL is NOT free. IBM - how much for a compiler; are > there on-going costs ? Unisys - same questions. (Not being in the > mainframe world I just don't know the answers). > > Yes there is/was a free version of Fujitsu, but I don't think it is > the one Pete Dashwood and others are actually using today ? Can't speak for others Jimmy, but I am (occassionally) using Version 6, the last one I bought and registered. The FREE one is version 3, but I can't imagine anyone seriously using that as the basis for a commercial business. I believe the current version is V10 but I dropped off this particular treadmill and stopped paying maintenance when I realised there was very little functional difference between V6 and v5 and between v5 and v4, and the support that this payment was supposed to entitle me to was so bad it wasn't worth paying for. It was shortly after that that I moved to C# and the whole thing became academic. > > So in addition to sticking your head in the mud with a 1985 mindset, > developers are now recommended to use the 'freebies' only - but be > extremely careful, even some of those have features beyond COBOL 85, > which you mustn't use. > > Let's take this from another angle. While there are government > standards applied by most countries, the auto-industry more or less > arrives at a set of self-imposed rules, ('features' would perhaps be > a better word); it's good for business anyway. There was a time when > auto indicators were those little thinggies that popped up to > indicate you wanted to turn left or right. They enhanced those by > giving them colour and today we have the inbuilt indicators. > > As well as wanting to make money, the particular auto maker Company X, > whose vehicles I like, also can see the advantage to consumers of > adding features which are not yet part of the given 'Auto Industry > Self-Imposed Features'. So taking a hypothetical, my brand new car > has the following - which according to you I should ignore :- > > - I can run on gasoline, ethanol, natural gas or electricity > - light features, that in an emergency would light up a football field > - rare, but like Agent 007 - I can take it submarining > > So because the 'others' don't as yet have these features, I should not > use them on the spanking new car I just bought ? > > In technology there is, and has to be progression, to meet consumer > needs. Like Michael Jackson wanted to be a cryogenic you are > recommending that we only use something (COBOL 85) which was defined > THIRTY-FIVE YEARS ago. Well of course you will counter, use other > stuff, perhaps Java, direct calls to Windoes APIs. Somehow, even > though you spoke to her once, I don't think our Gracie would agree. > > I doubt she mentioned to you, some of the early machinations in > COBOL's inception. One company, (a clue, the word 'Blue' fits), for > whatever reason, wanted a specific feature made 'Confidential'. > Gracie didn't like that and along with a buddy 'suggested' to the > Canadian representative that he should 'accidentally' publish the > feature - it happened - 'Confidentiality' was gonzo !. No, I didn't > dream that up - I got an e-mail from her 'buddy'. > > The other thing you should remember is that neither Java nor C# have > either ANSI or ISO imprimaturs. (Sun gave up on getting Java ISO- > approved after they saw the BS that was involved). So far as we are > concerned we have individual compiler vendors putting in their two > cents, initially via ANSI (J4 now PL22.4), and then going through the > rigmarole of ISO. Remember our compiler vendors are COMPETITORS for > the same product. Observing the players at the J4 June/July 2000 > meeting at Newbury, I asked the question, "How do the Micro Focus and > IBM representatives get on". Back came the answer, "They get on very > well socially, but remember they are representing competitors". > > I sure can't prove it, but looking at some of the features, > (extensions to you), which M/F introduced, I just wonder why they > never became part of COBOL. As Bill Klein once pointed out, having > seen a feature which looked like it had solid approval, M/F > introduced it, only to find that J4 dickered with it after the event, > possibly making the M/F approach invalid. > > Pure conjecture on my part - J4 saw the necessity for changing > something already established, or what M/F suggested as a new feature > just wasn't worth the effort - OR - just pure Competitor human > vindictiveness ? Don't kid yourself it couldn't happen. I've seen > some several instances of vindictiveness creep into commerce in my > career. > As a closing shot, your approach requires using the full shebang of a > program's format, to which PECD reacts with, 'COBOL is too verbose'. Not quite. I think it is too verbose when using OO, IN COMPARISON TO OTHER OO LANGUAGES. It is a subtle, but very important qualifier. > M/F introduced the feature 'Get rid of the red tape'. Accepting that > you probably abhor the thought of COBOL having OO, at this point in > time I am writing a class to handle Dates and Times in COBOL; yes it > uses the ACCEPT FROM and DATE FUNCTIONS, but you not need to be > conversant with them, their use is in my methods (source). Boyo, boyo > do I use that 'exclude red tape'. Assuming PECD produced a Fujitsu > version of my DateAndTime class, once he sees it, I can guarantee his > code will be at least twice as large as mine ! Other vendors just > didn't somehow see the advantage of getting rid of red tape. > At this point I don't anticipate duplicating your code, Jimmy. I have date components that do everything I want, and the .Net Framework has Classes that would do anything I overlooked. As for Red Tape, most COBOL purists (and I suspect that John is one) will say that it destroys the readability of COBOL, which has traditionally been one of its major advantages. They are probably right. But it is academic to me as I don't care about it. It was important when source code was everything. For me, at least, it isn't any more. All that matters is functionality and a documented interface to it. Pete. -- "I used to write COBOL...now I can do anything."
From: Richard on 10 Feb 2010 00:54
On Feb 10, 4:34 pm, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote: > James J. Gavan wrote: > > j...(a)wexfordpress.com wrote: > > >> Cobol is free. Fujitsu offers a free compiler. Open Cobol runs on > >> Linux and with some fuss and feathers under MSWindows. Ditto for Tiny > >> Cobol. So that argument does not hold water. > > >> John Culleton > >> COBOL since 1968 > > > By and large COBOL is NOT free. IBM - how much for a compiler; are > > there on-going costs ? Unisys - same questions. (Not being in the > > mainframe world I just don't know the answers). > > > Yes there is/was a free version of Fujitsu, but I don't think it is > > the one Pete Dashwood and others are actually using today ? > > Can't speak for others Jimmy, but I am (occassionally) using Version 6, the > last one I bought and registered. The FREE one is version 3, but I can't > imagine anyone seriously using that as the basis for a commercial business. They are not allowed to use it as the basis for a commercial venture. The free version 3 is restricted to be for student and academic use. > I believe the current version is V10 but I dropped off this particular > treadmill and stopped paying maintenance when I realised there was very > little functional difference between V6 and v5 and between v5 and v4, and > the support that this payment was supposed to entitle me to was so bad it > wasn't worth paying for. It was shortly after that that I moved to C# and > the whole thing became academic. > > > > > > > So in addition to sticking your head in the mud with a 1985 mindset, > > developers are now recommended to use the 'freebies' only - but be > > extremely careful, even some of those have features beyond COBOL 85, > > which you mustn't use. > > > Let's take this from another angle. While there are government > > standards applied by most countries, the auto-industry more or less > > arrives at a set of self-imposed rules, ('features' would perhaps be > > a better word); it's good for business anyway. There was a time when > > auto indicators were those little thinggies that popped up to > > indicate you wanted to turn left or right. They enhanced those by > > giving them colour and today we have the inbuilt indicators. > > > As well as wanting to make money, the particular auto maker Company X, > > whose vehicles I like, also can see the advantage to consumers of > > adding features which are not yet part of the given 'Auto Industry > > Self-Imposed Features'. So taking a hypothetical, my brand new car > > has the following - which according to you I should ignore :- > > > - I can run on gasoline, ethanol, natural gas or electricity > > - light features, that in an emergency would light up a football field > > - rare, but like Agent 007 - I can take it submarining > > > So because the 'others' don't as yet have these features, I should not > > use them on the spanking new car I just bought ? > > > In technology there is, and has to be progression, to meet consumer > > needs. Like Michael Jackson wanted to be a cryogenic you are > > recommending that we only use something (COBOL 85) which was defined > > THIRTY-FIVE YEARS ago. Well of course you will counter, use other > > stuff, perhaps Java, direct calls to Windoes APIs. Somehow, even > > though you spoke to her once, I don't think our Gracie would agree. > > > I doubt she mentioned to you, some of the early machinations in > > COBOL's inception. One company, (a clue, the word 'Blue' fits), for > > whatever reason, wanted a specific feature made 'Confidential'. > > Gracie didn't like that and along with a buddy 'suggested' to the > > Canadian representative that he should 'accidentally' publish the > > feature - it happened - 'Confidentiality' was gonzo !. No, I didn't > > dream that up - I got an e-mail from her 'buddy'. > > > The other thing you should remember is that neither Java nor C# have > > either ANSI or ISO imprimaturs. (Sun gave up on getting Java ISO- > > approved after they saw the BS that was involved). So far as we are > > concerned we have individual compiler vendors putting in their two > > cents, initially via ANSI (J4 now PL22.4), and then going through the > > rigmarole of ISO. Remember our compiler vendors are COMPETITORS for > > the same product. Observing the players at the J4 June/July 2000 > > meeting at Newbury, I asked the question, "How do the Micro Focus and > > IBM representatives get on". Back came the answer, "They get on very > > well socially, but remember they are representing competitors". > > > I sure can't prove it, but looking at some of the features, > > (extensions to you), which M/F introduced, I just wonder why they > > never became part of COBOL. As Bill Klein once pointed out, having > > seen a feature which looked like it had solid approval, M/F > > introduced it, only to find that J4 dickered with it after the event, > > possibly making the M/F approach invalid. > > > Pure conjecture on my part - J4 saw the necessity for changing > > something already established, or what M/F suggested as a new feature > > just wasn't worth the effort - OR - just pure Competitor human > > vindictiveness ? Don't kid yourself it couldn't happen. I've seen > > some several instances of vindictiveness creep into commerce in my > > career. > > As a closing shot, your approach requires using the full shebang of a > > program's format, to which PECD reacts with, 'COBOL is too verbose'. > > Not quite. I think it is too verbose when using OO, IN COMPARISON TO OTHER > OO LANGUAGES. > > It is a subtle, but very important qualifier. > > > M/F introduced the feature 'Get rid of the red tape'. Accepting that > > you probably abhor the thought of COBOL having OO, at this point in > > time I am writing a class to handle Dates and Times in COBOL; yes it > > uses the ACCEPT FROM and DATE FUNCTIONS, but you not need to be > > conversant with them, their use is in my methods (source). Boyo, boyo > > do I use that 'exclude red tape'. Assuming PECD produced a Fujitsu > > version of my DateAndTime class, once he sees it, I can guarantee his > > code will be at least twice as large as mine ! Other vendors just > > didn't somehow see the advantage of getting rid of red tape. > > At this point I don't anticipate duplicating your code, Jimmy. I have date > components that do everything I want, and the .Net Framework has Classes > that would do anything I overlooked. > > As for Red Tape, most COBOL purists (and I suspect that John is one) will > say that it destroys the readability of COBOL, which has traditionally been > one of its major advantages. They are probably right. But it is academic to > me as I don't care about it. It was important when source code was > everything. For me, at least, it isn't any more. All that matters is > functionality and a documented interface to it. > > Pete. > -- > "I used to write COBOL...now I can do anything." |