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: Alistair on 22 Sep 2007 17:56 On 22 Sep, 20:35, Robert <n...(a)e.mail> wrote: > On Sat, 22 Sep 2007 05:52:35 -0700, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > >On 22 Sep, 06:22, Robert <n...(a)e.mail> wrote: > >> On Fri, 21 Sep 2007 09:52:17 -0700, Alistair <alist...(a)ld50macca.demon.co.uk> wrote: > >> >I do wish you hadn't tugged my chain by bringing Evolution into the > >> >argument. Especially as you don't appear to have much knowledge of how > >> >Evolution works. > > >> >Comments below: > > >> >On 21 Sep, 01:16, Robert <n...(a)e.mail> wrote: > >> >> On Thu, 20 Sep 2007 08:07:13 -0600, Howard Brazee <how...(a)brazee.net> wrote: > >> >> >On Wed, 19 Sep 2007 21:51:48 -0500, Robert <n...(a)e.mail> wrote: > > >> >> This is about evolution versus revolution. The evolutionary approach is to change one > >> >> thing, give it enough time to succeed or fail (testing) before moving on to the next > >> >> change. > > >> >Evolution is about incremental implementation of a multitude of > >> >changes simultaneously (or even all at once). > > >> Wrong, it's about one change at a time. Recommended reading: Notes on the Synthesis of > >> Form, by Alexander. It talks about how to design a teakettle, but is really about system > >> development in the abstract. > > >So, a bad analogy (Evolution) is being justified as applicable to > >programming based upon a book telling me how to design a kettle? Again > >you have failed. Evolution happens on many fronts simultaneously. A > >successful evolution in one factor may result in the carriage of a > >multitude of factors to the improved evolutionary form. Only some of > >those improvements will be beneficial and many will be detrimental. > >You can take the human as an example of the 'ultimate' evolved > >organism on the planet. There is no form factor that the human has > >that can be said to be the sole reason as to why we have become so > >successful. However, other factors can be shown to be barely adequate > >or even detrimental to human success: fallen arches; poor spinal > >strucure; poor vision.... > > >Evolution may appear to be one change at a time to a naive observer > >but, in fact, there are many changes occuring all of the time. > > Here's more about Alexander's ideas, from the blog of a Swedish programmer, Peter > Lindberg: > > Christopher Alexander's OOPSLA '96 keynote is quite fascinating. Software patterns capture > proven ideas in a convenient format, and surely you hear the idea that if you're savvy > about patterns and use them frequently, your software will be well-architected. (One of > the early papers on patterns, by Kent Beck and Ralph Johnson, was titled Patterns Generate > Architectures; I guess I should re-read that one.) In the keynote, Alexander says that his > idea of pattern languages goes well beyond that: it was intended to generate "living > structure [and] coherent wholes", even when applied by laymen. > > Alexander mentions that he, after having worked for a while with pattern languages, found > out that they didn't succeed: > > [T]he buildings generated [by people using the patterns] were okay, but not profound. > [---] I [...] realized that whatever was going wrong wasn't going to be corrected by writing > a few more patterns or making [them] a little bit better. There seemed to be something > more fundamental that was missing from the pattern language. > > At about the same time I began to notice a deeper level of structure and a small > number (fifteen) of geometric properties that appeared to exist recursively in space > whenever buildings had life. These fifteen properties seemed to define a more fundamental > kind of stuff; similar to the patterns we had defined earlier, but more condensed, more > essential - some kind of stuff that all good patterns were made of. > > These were simple ideas. [P]roperties like "boundaries" which will not only delineate > but connect the inside to the outside, or "positive space," as when you look at a Matisse > cutout and see that the space between the colored paper is not amorphous but also has > form. > > These fifteen principles seem hard to swallow, but an immense amount of work has gone into > them. For instance, Alexander has conducted experiments to verify that the presence of the > fifteen principles in an object is empirically testable. People have been shown two > objects and asked which of them makes them feel "more whole" or "more alive". He writes: > "it turns out that there is quite a striking statistical agreement, 80-90%, very strong, > as strong a level of agreement as one gets in any experiments in social science." In > addition, he has written a series of four books about this, titled The Nature of Order: An > Essay on the Art of Building and The Nature of the Universe. (The books have a website.) > > So, it doesn't seem to be mere aesthetic principles. And the following claim (also from > the keynote) is stunning: > > Compared to the pattern language that you've seen in A Pattern Language [Amazon.com] > these generative schemes are much more like what you call code. They are generative > processes which are defined by sets of instructions that produce or generate designs. They > are, in fact, systems of instructions which allow unfolding to occur in space in just the > way that I was talking about a minute ago [...], and are therefore more capable of producing > living structure. The published pattern language by comparison is static. The new > generative languages are dynamic and, like software, interact with context, to allow > people to generate an infinite variety of possible results - but, in this case, with a > built-in guarantee of well-formed results. The design that is created is guaranteed, ahead > of time, to be coherent, useful, and to have living structure. > > He talks about paradigms and how the major players of the old paradigm aren't the major > players of the new paradigm. He says that architects may never realize this and suggests > that programmers should become the new architects, by creating software that embodies > these patterns and generative languages to support builders: > > What I am proposing here is [...] a view of programming as the natural genetic > infrastructure of a living world which you/we are capable of creating, managing, making > available, and which could then have the result that a living structure in our towns, > houses, work places, cities, becomes an attainable thing. That would be remarkable. It > would turn the world around, and make living structure the norm again [...] > > http://tesugen.com/archives/03/06/patternkeynote2 > > As I understand it, Alexander is supporting Pete's idea that design should be self-aware, > recursive, what some call 'interactive'. The Pattern Languages he finds inferior are > analogous to waterfall Cobol, being 'static', pretending the designer is capable of > anticipating every turn of events that will occur during the creation of a system. > > > > > > >> >> The resolutionary approach is to change everything at once, for example to a new > >> >> language. > > >> >> Evolution is inherentely safe; > > >> >Except for those who get left behind or out-competed or even those > >> >blind evolutionary off-shoots which end up in dead-ends. > > >> Dead-end, left behind and out-competed depend on your definition of success, or which > >> third party measure you choose to believe. I know poor people who live happy, rewarding > >> lives. > > >I'm poor, unhappy and lead a life that is largely unfulfilling. A > >generalised example does not prove your case. That is an argument that > >has raged elsewhere in this newsgroup. > > >> >> revolution is inherently prone to failure. Evolution is the > >> >> preferred approach. The problem is it may be too slow to keep up with environmental > >> >> changes, either because the environment is changing rapidly or because resistance to > >> >> change slows evolution to a crawl. With Cobol, the latter is the case. Institutionalized > >> >> foot dragging (standards) slowed Cobol's evolution so much that it was doomed to failure, > >> >> to fall behind even a moderate pace of environment change. The only alternative, albeit an > >> >> undesirable one, was a revolutionary change to another language: Java. > > >> >You clearly don't have any idea why Cobol became so yesteryear and > >> >java became the new fashion accessory. > > >> Conventional answer: Object Oriented. Wait a minute, Cobol has that. > > >QED. > > >> >> This could have been prevented by allowing Cobol to change at a normal rate. True > >> >> conservatives would have seen that, and thereby conserved Cobol. > > >> >Then which version of the myriad Cobols would be the one true cobol? > > >> There's only One True Cobol -- The ANS/ISO Standard. > > >And all the other evolutionary forms of cobol have satisfied your > >requirements for change and yet you persist in denigrating cobol for > >its' failure to adapt and change. > > Practitioners rejected changes to the language spec. They prefer to write Cobol in a style > that hasn't changed in 20 years. Also, the changes were too little, too late. We didn't > see foot-dragging when C++ was created in 1979. > > >> >> What about the ones who destroyed Cobol with excessive resistance to change? > > >> >Resistance to change was not what killed Cobol. > > >> It's the easiest to talk about. Cobolers don't want to discuss the real reason -- lousy > >> code. > > >It has already been observed by others that it is easier to write > >cruddy code in Java than in Cobol. I believe that, with the wrong > >attitude and poor application, it is possible to write cruddy code in > >any computing language (with the possible excepetion of Befunge where > >it could be argued that any program which executes is a success). > > Authors of cruddy Java KNOW they're writing crud; it takes a conscious effort. Authors of > cruddy Cobol THINK they're writing good code. > > When I once wrote cruddy Cobol for a magazine article, the effort was more difficult than > I expected. Numbered paragraphs and perform thru were easy. The hard part was cruddy > structure and logic, for instance the bloat of redundant code.- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - I lost the will to live after the first paragraph. Crud is still crud, whether you know that you are writing crud or not.
From: Richard on 22 Sep 2007 18:30 On Sep 23, 5:27 am, Robert <n...(a)e.mail> wrote: > >> >With 'indexed by' each index is local to the table and to the level. > >> >If an index is used outside its designated scope the compiler will (or > >> >should) give an error. Thus indexes are much less likely to be > >> >corrupted. > > >> If you were consistant, you'd make the same argument for variables containing table > >> sizes. > > >How do you get the compiler to complain about that ? > > By using the limit index to load the table, the compiler will complain if it's on another > table. You seem to be on a different planet on this question. With Standard Cobol the _compiler_ will complain if an index is used for some purpose other than referencing the correct table and level. The index is 'local' to what it is indexing. Variables holding the occurs limit will not cause compiler messages. Nor will using a subscript in the 'wrong' table. > >> The problem can be avoided by placing the subscripts AND limits in the structure holding > >> the table. For example: > > >> 01 big-table. > >> 05 d1-sub binary pic s9(09). > >> 05 d1-limit binary pic s9(09). > >> 05 d1 occurs 1000. > >> 10 d2-sub binary pic s9(09). > >> 10 d2-limit binary pic s9(09). > >> 10 d2 occurs 100. > >> 15 stuff .... > > >How do you get the compiler to give an error when the 'wrong' > >subscript is used ? Just putting the variable in the same structure > >does nothing at all for safety. No errors or warnings. > > >'indexed by' _does_ give a compiler error when wrongly used. > >It isn't in the same league. Please do learn Cobol before attempting > >to guess about it. > > You're trying to turn Cobol into a strongly typed language. The STRONG attribute of OO > Cobol provides that. It's too late for legacy Cobol. I'm not doing _anything_ to Cobol. I am attempting to overcome your ignorance on the subject. You came into this argument claiming that the only difference between index and subscript was speed, and this was no longer true. We are discovering how limited you knowledge and understanding is.
From: Richard on 22 Sep 2007 18:47 On Sep 22, 6:33 pm, Robert <n...(a)e.mail> wrote: > On Fri, 21 Sep 2007 21:19:15 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >On Sep 22, 3:15 pm, Robert <n...(a)e.mail> wrote: > >> On Thu, 20 Sep 2007 18:27:53 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > > >> >Robert wrote: > >> >> On Thu, 20 Sep 2007 16:53:29 -0600, LX-i <lxi0...(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" ? > > >> Multiplication speed is a function of CPUs, not compilers. A timing test program could > >> show different relative speeds, even though it was not recompiled. > > >The only reason that on your system the subscripts are as fast as > >indexes is that the _optimizer_ in the compiler has removed the > >recalculation of the address, just as it does with indexes. > > >Putting in a faster processor will improve the speed of all operations > >and will not, by itself, have subscripts catch up to indexes. > > >If a compiler does not optimize the reuse of subscripts then they > >will still be slower. > > That's easy to check, by compiling with optimization off. It's unrealistic, though, > because optimization is on for real-world programs. You seem to be labouring under yet another misapprehension, that indexes are 'addresses'. Thus you confuse what is really happening. Index values may just be occurance numbers, ie same as subscript. The number of multiplys and optimization may be just the same. Your whole thesis is just uninformed guesswork. > >> >> > 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. > > >> Valid points. > > >So then, you will agree that there are reasons for using indexes that > >include speed and safety. > > Yes, if the programmer is dumb enough to use the wrong type for subscripts. There is no 'wrong type' for subscripts as long as they are numeric integer. It may be that the system they use, or was used originally when the system was written, did not have COMP-5 or an equivalent. > >> >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. > > >> Unless the compiler has been 'liberalized' to permit that misuse. I just learned here it's > >> a common extension. I never thought to try it. > > >It may be an extension in some compilers, notably IBM ones. MF may > >allow that extension if the appropriate flags are on, or can be off > >for safety. Fujitsu does not have that extension. > > It appears to be on by default for MF. The default for OSVS is NOOSVS, but I don't know if that affects index usage. > They mention the "OSVS standard", as though IBM > were in the business of writing standards. IBM _are_ in the business of writing standards. However, that is not relevant here as MF are merely acknowledging the standard IBM way for OSVS. They are not saying it is an ISO, or any other standards body, standard, only an IBM one. > >> >Indexes are required for SEARCH. > > >> Only the binary version. One can say VARYING on a serial 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 ? > > >> The modern feature of my argument is that multiply is no longer slow. Indexes would never > >> have been invented if multiply were as fast as load in the Good Old Days. > > >No, Robert, the reason that subscripts are, on _some_ systems, at > >best, as fast as indexes is because of the optimizer. Multiply is > >still not as fast as load.
From: Robert on 22 Sep 2007 18:53 On Sat, 22 Sep 2007 15:30:07 -0400, "Charles Hottel" <chottel(a)earthlink.net> wrote: >"Robert" <no(a)e.mail> wrote in message >news:3kcaf394t2qabq20kh2beeu413ujua7gp6(a)4ax.com... >> On Sat, 22 Sep 2007 03:20:19 -0600, Jeff Campbell <n8wxs(a)arrl.net> wrote: >> >>>Robert wrote: >>>> On Fri, 21 Sep 2007 11:09:16 GMT, "William M. Klein" >>>> <wmklein(a)nospam.netcom.com> wrote: >>>> >>>>> "Robert" <no(a)e.mail> wrote in message >>>>> news:i3j6f3pa7ucignv34t4oklno0ht8jh2c5p(a)4ax.com... >>>>>> On Fri, 21 Sep 2007 04:21:35 GMT, "William M. Klein" >>>>>> <wmklein(a)nospam.netcom.com> wrote: >>>>>> >>>>> <snip> >>>>>> I and Richard posted facts showing speed is the same. We have not seen >>>>>> facts >>>>>> from >>>>>> mainframe-land,except a five year old study. Just post some facts and >>>>>> skip the >>>>>> ad homina. >>>>> I do NOT have personal access to an Enterprise V3.4 COBOL compiler - >>>>> and I do >>>>> believe what IBM says about its performance (and don't believe that you >>>>> know how >>>>> they implement all their syntax -> machine code). HOWEVER, >>>>> >>>>> If you create a source program that you think tests subscripts vs >>>>> indexes >>>>> (whether it is comprehensive or not), then I think some CLC person >>>>> might compile >>>>> and run it for you. >>>>> >>>>> Therefore, please create and post a sample program that cleanly >>>>> compiles with >>>>> the Micro Focus directives: >>>>> NOMF DIALECT(ENTCOBOL) FLAGAS(S) >>>>> >>>>> If you are not using a current-enough version of Server Express to >>>>> include >>>>> support for the DIALECT directive, then use: >>>>> NOMF ENTCOBOL FLAG(ENTCOBOL) FLAGAS(S) ARITHMETIC(ENTCOBOL) >>>>> PERFORM-TYPE(ENTCOBOL) >>>> >>>> That's not necessary. The code I posted is Standard-compliant except for >>>> comp-5, which we >>>> all know IBM can handle. >>> >>>No, it wasn't. Such things as mixed sectioned, non-sectioned code; exit >>>section statements not in separate paragraphs; linkage section declared >>>without a using clause in the procedure division. I could go on. >> >> Those things were in the first test, named speed1. The subscript v. index >> test, named >> speed2, does not have them. >> >> The current '02 Standard does not prohibit any of the things you >> mentioned. Especially, it >> does not require exit section to be in a separate paragraph, nor under a >> paragraph name. >> >>>>> If you post such a program and no one else in CLC compiles and runs it >>>>> (and >>>>> posts the results) I will find someone who can and will. >>>> >>>> Any volunteers? >> > >Speed1 is the only program I saw posted. When did you post it? I just >searched Google groups for "speed2" and got no hits. I TOLD them these damned computer things would never work, but they wouldn't listen. :) Here it is again. If your compiler doesn't support exit perform cycle, just take it out. * ------ Speed of subscript v. index ------------------------------------------------------ * Findings * Index 23 * Subscript 23 * Subscript comp-5 23 * Index 1 23 * Subscript 1 18 * Subscript 1 comp-5 18 $SET SOURCEFORMAT"FREE" $SET NOBOUND $SET OPT"2" $SET NOTRUNC $SET IBMCOMP $SET NOCHECK $SET ALIGN"8" identification division. program-id. Speed2. author. Robert Wxagner. data division. working-storage section. 01 test-data. 05 comp5-number comp-5 pic s9(09) sync. 05 binary-number binary pic s9(09) sync. 05 display-number pic 9(09). 05 packed-number comp-3 pic s9(09). 05 s-subscript binary pic s9(09) sync. 05 test-byte pic x(01). 01 misaligned-area. 05 array-element occurs 4096 indexed x-index. 10 misaligned-number comp-5 pic s9(09). 10 to-cause-misalignment pic x(01). 05 byte-element occurs 4096 indexed x-index-1 pic x. 01 timer-variables. 05 test-name pic x(30). 05 repeat-factor value 100000000 binary pic s9(09). 05 current-date-structure. 10 pic x(08). 10 time-now-hhmmsshh. 15 hours pic 9(02). 15 minutes pic 9(02). 15 secs pic 9(02). 15 hundredths pic v9(02). 10 pic x(05). 05 time-now pic 9(06)v99. 05 time-start pic 9(06)v99. 05 timer-overhead value zero pic 9(06)v99. 05 elapsed-time pic s9(06)v99. 05 elapsed-time-display. 10 elapsed-time-edited pic z(05). procedure division. initialize test-data, misaligned-area move 'Null test' to test-name perform timer-on perform timer-on perform repeat-factor times exit perform cycle end-perform perform timer-off compute timer-overhead = (time-now - time-start) move 'Index' to test-name set x-index to 1000 perform timer-on perform repeat-factor times if x-index = 1000 set x-index up by 1 else set x-index down by 1 end-if move array-element (x-index) to test-byte exit perform cycle end-perform perform timer-off move 'Subscript' to test-name move 1000 to s-subscript perform timer-on perform repeat-factor times if s-subscript = 1000 add 1 to s-subscript else subtract 1 from s-subscript end-if move array-element (s-subscript) to test-byte exit perform cycle end-perform perform timer-off move 'Subscript comp-5' to test-name move 1000 to comp5-number perform timer-on perform repeat-factor times if comp5-number = 1000 add 1 to comp5-number else subtract 1 from comp5-number end-if move array-element (comp5-number) to test-byte exit perform cycle end-perform perform timer-off move 'Index 1' to test-name set x-index-1 to 1000 perform timer-on perform repeat-factor times if x-index-1 = 1000 set x-index-1 up by 1 else set x-index-1 down by 1 end-if move byte-element (x-index-1) to test-byte exit perform cycle end-perform perform timer-off move 'Subscript 1' to test-name move 1000 to s-subscript perform timer-on perform repeat-factor times if s-subscript = 1000 add 1 to s-subscript else subtract 1 from s-subscript end-if move byte-element (s-subscript) to test-byte exit perform cycle end-perform perform timer-off move 'Subscript 1 comp-5' to test-name move 1000 to comp5-number perform timer-on perform repeat-factor times if comp5-number = 1000 add 1 to comp5-number else subtract 1 from comp5-number end-if move byte-element (comp5-number) to test-byte exit perform cycle end-perform perform timer-off goback . timer-on. perform read-the-time move time-now to time-start . timer-off. perform read-the-time compute elapsed-time rounded = ((time-now - time-start) * 100000000 / repeat-factor) - timer-overhead if elapsed-time not greater than zero move 'error' to elapsed-time-display else compute elapsed-time-edited rounded = elapsed-time * 10 end-if display test-name elapsed-time-display . read-the-time. accept time-now-hhmmsshh from time *> move function current-date to current-date-structure compute time-now = ((((hours * 60) + minutes) * 60) + secs) + hundredths .
From: William M. Klein on 22 Sep 2007 19:21
You are saying that you can use OCCURS 1 and use the 2nd index for the 3rd "subscript"? -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:rcaaf39qe71qrsheefckgphp5mnco9i58l(a)4ax.com... > On Sat, 22 Sep 2007 06:23:22 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >>Have you tried it with "1". I don't think that either IBM or MF will compile >>that clean (but I could be mistaken). > > I've used OCCURS 1 on IBM and MF. It works. > > On second thought, only b, the second dimension, needs OCCURS 1. The third > dimension, c, > can be anything. > |