COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
in [Cobol]
|
Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Anonymous on 20 Sep 2007 21:06 In article <5lghicF83hgvU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > ><docdwarf(a)panix.com> wrote in message news:fctv68$h53$1(a)reader1.panix.com... >> In article <LJidnU64f4e7-2_bnZ2dnUVZ_hqdnZ2d(a)golden.net>, >> donald tees <donaldtees(a)execulink.com> wrote: >>>docdwarf(a)panix.com wrote: >> >> [snip] >> >>>> This is one of the reasons I've coded >> >> [snip] >> >>>> ... or reasonable facsimiles thereof. When data volume goes a certain >>>> amount beyond program design then it's time to have a coder look at >>>> it... >>>> if only to say 'Oh, we're not limited to 32K tables any more, let's bump >>>> this baby up a few!'. >>> >>>Probably a good example for two reasons ... it shows a "semi-micro" >>>example that *is* within a program, yet is still an algorithmic >>>difference. >>> >>>I think most such differences, though, take place well before you get >>>into the middle of a single program. They take place at the design level. >> >> There's the rub, Mr Tees... at 'design level' one of my questions (if I'm >> on-site for it or allowed to ask any) is 'what is the expected data >> flow?'; I've heard - from Corner-Office Idiots, usually - 'That's a >> goooood question... why do you think that is important?' and had to >> explain that a system is designed using different criteria depending on >> the amount of data running through it, just as one chooses a vehicle using >> different criteria depending on the amount of stuff one wishes to move >> around in it. >> >> If the system gets used then the amount of data going through it may >> increase... and, similarly to a vehicle, one will have to decide at which >> point one puts aside the old three-speed Humber with handlebar-basket - >> which was most suitable for moving one'sself around during one's earlier >> years - and replaces it with a vehicle which can carry one'sself, one's >> spouse and (n) children... perhaps a motorscooter (which in some places, >> eg Southeast Asian countries, are made to carry all that and more), >> perhaps an automobile of some sort, perhaps a van, etc. >> > >Computer systems, not being modes of transport, can be designed generically >from day one and expanded as the need arises without necessarily having to >make major code changes. It's called "scalability". Computer systems, in that they move data about, are most certainly modes of transport. Some quantities of data can be dealt with in a manner which satisfies the needs and budgets of an organisation by an simple file-editor, some by a spreadsheet, some by a small database package and some need full-blown Oracle or DB2 installations. 'Scalability' is not, I believe, a synonym for 'one solution fits all situations'. DD
From: Anonymous on 20 Sep 2007 21:09 In article <0a06f39ptn9oek7j16r07hr4cogk0qv8t2(a)4ax.com>, Robert <no(a)e.mail> wrote: [snip] >Dinosaurs became extinct >because they were >incapable or unwilling to change .. except for a 'radical faction' that >morphed into birds >and an old school we now call crocodilians. Not too many things are capable of changing fast enough to meet the environmental variations induced by a meteorite (or comet) about ten miles across (estimated) slamming into the Yucatan Peninsula, as far as I know. DD
From: Anonymous on 20 Sep 2007 21:12 In article <rc36f3li41dj7tl8e0f4sdkbf0shmn219e(a)4ax.com>, Robert <no(a)e.mail> wrote: >On Thu, 20 Sep 2007 14:16:24 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <bhm3f3lhlko53ia8rbjg536gjqc95s344e(a)4ax.com>, >>Robert <no(a)e.mail> wrote: >> >>[snip] >> >>>Management found >>>it easier to >>>change the language than do battle with the Cobol bureaucracy. >> >>Mr Wagner, this is confusing... how can a computer programming establish a >>bureaucracy rather than the Management which employs it? > >That's easy. Management doesn't get involved with 'technical stuff'. [snip] >That's not management support, that's management throwing >up its hands. Oh, I see... so you believe that Manatement doesn't Do Its Job; now it becomes more clear. Well, some might say that they deserve what they get, then. DD
From: Richard on 20 Sep 2007 21:27 Robert wrote: > On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0007(a)netscape.net> wrote: > > > >You've shown that what used to be significant overhead with subscripts > >is now gone in one particular environment. > > It's gone on all platforms, or soon will be. Geez, Robert, is this some magic that will replace everyone's compilers with brand new ones. Are you walking the streets crying "New compilers for old" ? > > But, the completeness of > >being able to define an array with (an) index(es) of its' very own > >appeals to some people, who will continue to do it. Using an index > >isn't 1970's COBOL. > > That's true. Indexes were introduced 'recently' in the '74 Standard ... To replace subscripts. You want to revert to 1960s style. > I SAID most Cobol programmers will continue using indexes. Just because subscripts have sometimes 'caught up' (or maybe will do) does not make subscripts better, or even as good as indexes. Subscripts may be miscoded with inadequate size or poor usage. Indexes cannot be. Subscripts can be slow. Indexes are always as fast as can be. Subscripts can be corrupted by using the wrong one, there is no check. Indexes are 'local', they are tied to a table, in fact tied to an occurs level, the compiler will tell the programmer when they are wrongly used. Indexes are required for SEARCH. So why are you trying to persuade people to revert to 1960s techniques ? Why do you think you are 'modern' when you are simply uninformed ? > Every obsolete technology has > its defenders. If you want to hear an uproar, just wait till the FCC pulls the plug on > analog TV and second generation (900 MHz) cell phones next year. Defenders will predict > the downfall of Western Civilization.
From: Pete Dashwood on 20 Sep 2007 21:41
"SkippyPB" <swiegand(a)nospam.neo.rr.com> wrote in message news:kr35f3tscp8cmbt8me0h6l6ap9gh6nebbt(a)4ax.com... > On Wed, 19 Sep 2007 21:51:48 -0500, Robert <no(a)e.mail> wrote: <snip> > That is one of the most ridiculous things I've heard..Java replacing > Cobol. > > It was estimated in 1997 that 300 billion lines of code existed > worldwide, 80% were in Cobol. > > It was estimated in 1999 that over 50% of mission-critical > applications still being coded in Cobol. > > It was estimated in 2002 that there were ~2 million Cobol programmers, > ~1 million Java, ~1 million C++. > > It was estimated in 2004-05 that 15% of new applications developed in > Cobol, 80% include extensions into legacy programs > Sorry, Steve. The Gartner estimates have been discredited many times in many places. They have even contradicted their own estimates and revised them. They have very little credibility, given that Gartner have many customers who are (or were) COBOL shops. Just as an experiment, try GOOGLing "Java Programming" and "COBOL programming" Java= 148,000,000 hits COBOL= 2,400,000 hits While this PROVES nothing, it is an indicator. If there were twice the number of COBOL prgrammers that there are Java, then it is extremely unlikely that there would be 70 times the number of posts on Java that there are on COBOL. (You could argue that Java is 70 times more complex and needs more posts :-) but that s a pretty feeble defence :-)) > It is estimated that it costs $25 per line to replace Cobol. > To replace a Cobol program with Java or C/C++, may cost $100 million. > You must know that is just nonsense. Replacement costs are quantifiable and available. Using automated tools it costs nothing like $100 million per program or even per system, on average (depending on the system, of course.) > Ease of maintenance makes Cobol language of choice for vertical > markets. Companies do not want to invest in changing to a new > language. No, that's true for many companies. But neither do they want to continue paying for hand carved computer code when they no longer have to. There are options available now that simply weren;t available in COBOL's heyday. Ease of maintenance is only important while you are maintaining source code. Component based systems use encapsulated functionality that ISN'T maintained (in the traditional sense, at least) so "readability" is much less important. (I have live production systems using components I don't even have the source code for, so I COULDN'T maintain them, even if I wanted to. It has never been a problem.) Source code is no longer king; objects are what matters. > > (Note: estimates curtesy of Gartner Group). > > Cobol is successful because it works in both horizontal and vertical > software markets. COBOL WAS successful because it was the only game in town and computing was centralized to a central mainframe. The advent of the network spelled the beginning of the end for COBOL. The general acceptance of the OO pardigm and component based systems (by everybody EXCEPT COBOL shops) meant that systems can be developed in more timely and responsive ways (without using the SDLC/Waterfall methodology) and the power of the network can be unleashed (parallel processing, load levelling, remote procedures, component reuse, SOA) > > A Vertical Software Market: > Cost many millions to produce, custom made for specified company, > encapsulate all business rules, and only a limited number of > copies may be in use; > Low profile, very high per copy replacement cost, and very long > lifespan Yes, a fair description. However, many companies are moving to a package solution for their vertical niche and getting out of software development themselves. > > A Horizontal Software Market: > May still cost many millions to produce, but thousands or millions > of copies will be in use > High profile, low per copy replacement cost, short life span. Again, a fair description. However, the network is replacing the millions of copies. Component re-use and web based systems mean there is no need for a copy on every desktop. SOA allows a "single copy" to run anywhere on the Intranet (or even across the Internet, for multinational corporations). The idea of "Software As A Service" (SaaS), a logical extension of SOA and Web Services, is currently in its infancy but gaining acceptance. Industry is tired of having to spend millions supporting it's own IT when that is not the business it is in. (There is also still some brooding resentment for all the years of havng to go cap-in-hand to the Priests of COBOL in order to get IT support, and being met with scornful and "take it or leave it" attitudes. Fortunately, the managers who suffered this are now coming to retirement so it is less about that than it was. Nevertheless, I have had conversations with people who would gladly implement ANY solution that meant they could close down their COBOL shop, because of the way they were treated by IT in the past.) COBOL system development is becoming more and more economically non-viable, compared to other options now available. Cheap offshore outsourcing delayed it for a while, but that is also revealing itself to have problems, and the prices are increasing. It isn't so much about Java replacing COBOL (although many companies see that as a step in the right direction; at least it gets them into the OO paradigm, with the consequent benefits and interoperability, and there are very good tools to automate much of the process and refactor COBOL functionality), as it is about writing and maintaining Procedural code in a world that has mostly rejected this paradigm. It is much easier to step up to web based operation from a Java platform than from a COBOL one. It is perceived as being much easier to provide Web Services from Java than it is from COBOL; (personally, I don't agree with that one, but it makes me a pebble, and the landslide has already started (the pebbles don't get to vote... :-))). Generally, the world has moved on. The place for COBOL now is in batch processing (on a centralized mainframe, for example) and propping up legacy until it exceeds its "use by" date, is not economic to extend, and must be replaced. Only a very brave (or myopic) CIO would advocate continuing development in COBOL. > > > Java is falling out of favor in many industries in favor the newer > .NET and Mono. Yes, it is. I am a registered Sun developer and get their regular Java newsletters and tech notes. I noticed yesterday that in the latest one they are changing some of the functionality in Java to bring it more into line with the way C# works. (C# is enjoying popularity because it is the language of choice for DotNET and Mono. I think there is some concern that some (many?) Java programmers are moving to C# (it is an easy transition). Again, it comes down to options and interoperabilty. If I can write something and know it can run on Unix, Linux, and Windows without re-compiling and without paying a fortune for an appropriate compiler, or having to pay run time fees for anything I distribute, why wouldn't I do that? (C# usage, according to MicroSoft (:-)...add grain of salt) increased by 54% in the last year. C# and Ruby on Rails are currently the "hottest" languages and most rapidly expanding, for those who care about fashion :-)) Personally, I don't, but I have come to enjoy coding in C# and everything is MUCH easier than than it was in COBOL. (By this I mean that support is better, you can do much more with much less code, the IDE (in my case VS 2005, but I intend to download the Beta of VS 2008 as soon as I finish my current project) is a dream and saves a large amount of time and effort, the facilities of the DotNET Framework Class Library are easily accessible, but most importantly for me, I can run all of my legacy OO COBOL from C# without problem. Whether or not Java is replacing COBOL isn't what's important. What's important is WHY COBOL is being replaced, by Java or anything else. Pete. -- "I used to write COBOL...now I can do anything." |