Corruption of COBOL.
in [Cobol]
|
Prev: 182966 Constantly updated Free COmputer and business portal 94
Next: Traditional COBOL environment
From: Michael Wojcik on 8 Feb 2010 11:32 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/ -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
From: SkippyPB on 8 Feb 2010 11:58 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. Regards, -- //// (o o) -oOO--(_)--OOo- "An oral contract isn't worth the paper it's written on." -- Sam Goldman ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: john on 9 Feb 2010 10:38 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. 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
From: Alistair on 9 Feb 2010 11:27 On Feb 6, 3:35 pm, Fred Mobach <f...(a)mobach.nl> 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 athttp://shakespeare.mit.edu/ > -- > Fred Mobach - f...(a)mobach.nl > website :https://fred.mobach.nl > .... In God we trust .... > .. The rest we monitor ..- Hide quoted text - > > - Show quoted text - Sorry, when I said TXT I really meant that dreadful abbreviated language they use in mobile phones.
From: James J. Gavan on 9 Feb 2010 16:21
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 ? 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'. 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. Jimmy, Calgary AB |