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: Richard on 23 Sep 2007 23:45 On Sep 24, 2:43 pm, Robert <n...(a)e.mail> wrote: > On Sun, 23 Sep 2007 17:36:22 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >On Sep 24, 10:32 am, Robert <n...(a)e.mail> wrote: > >> On Sun, 23 Sep 2007 12:45:06 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >> >On Sep 24, 4:02 am, Robert <n...(a)e.mail> wrote: > >> >> On Sun, 23 Sep 2007 02:07:44 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >> >> >On Sep 23, 2:02 pm, Robert <n...(a)e.mail> wrote: > >> >> >> On Sat, 22 Sep 2007 15:30:20 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >> >> >> >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. > > >> >> >> Since you couldn't understand my prose answer, I'll paint a picture with an example. > > >> >> >> 01 big-table. > >> >> >> 05 table-entry occurs 1000000 indexed x-big x-big-limit. > >> >> >> .. stuff .. > > >> >> >> load-table. > >> >> >> set x-big-limit to 0 > >> >> >> perform until end-of-input > >> >> >> set x-big-limit up by 1 > >> >> >> move input-data to stuff (x-big-limit) <- this is it > >> >> >> perform read-next-input > >> >> >> end-perform. > > >> >> >> search-table. > >> >> >> set x-big to 1 > >> >> >> search table-entry > >> >> >> when x-big > x-big-limit > >> >> >> .. not found .. > >> >> >> when my-stuff = table-stuff (x-big) > >> >> >> .. found .. > >> >> >> end-search. > > >> >> >So you have converted to using indexes. > > >> >> >Your original appeared to be referencing variables, not indexed bys. I > >> >> >don't know why you thought I needed to consider these to be > >> >> >'consistent', or more specifically I wasn't inconsistent in not > >> >> >mentioning them at all. > > >> >> >>>> If you were consistant, you'd make the same argument for variables containing > >> >> >>>> table sizes. > > >> >> You want the compiler to detect an incorrect subscript/index when READING the table. Your > >> >> inconsistancy is not using the same technique when WRITING to the same table. > > >> >As I never wrote to the table or posted code that did so, your claim > >> >that I was 'inconsistent' is just blather to deflect from the issue. > > >> You had to load the table before reading it. I was pointing out that your solution ignored > >> half the table references. > > >I wasn't providing a 'solution', I was doing a benchmark and > >illustrating features of the language. > > Your argument for index had nothing to do with the benchmark. It was about type and locale > safety, about the compiler detecting programming errors. Did you miss the bit: "and illustrating features of the language.". I didn't even present any programs so I don't know how your psychic abilities managed to view it and determine what was 'missing' and what I did 'inconsistently'. > >I could also point out that you didn't load your tables in the code > >that you provided so, it too, wasn't a 'solution'. > > I was measuring speed, not safety. And I was measuring speed and pointing out features. > >> >Actually in your original you had written: > > >> >RP>With 'indexed by' each index is local to the table and to the > >> >level. > >> >RP>If an index is used outside its designated scope the compiler will > >> >(or > >> >RP>should) give an error. Thus indexes are much less likely to be > >> >RP>corrupted. > > >> >>> If you were consistant, you'd make the same argument for variables containing > >> >>> table sizes. > > >> >>> 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 .... > > >> >Indicating that you thought this made the subscript _usage_ 'local' to > >> >the table. > > >> It does make the subscript and limit local to the table in another context -- that of > >> passing the table to another program. You can't pass indexes through a CALL, nor can you > >> pass them through GLOBAL or EXTERNAL. > > >GLOBAL works fine, where did you get the idea that this wouldn't work. > > From the '02 Standard, which says: > > 13.16.25 GLOBAL clause > The GLOBAL clause specifies that a constant-name, a data-name, a file-name, a report-name, > or a screen-name is a global name. A global name is available to every program contained > within the program that declares it. > > An index-name is obviously a user-defined word, but is it a data-name? > > 13.16.25.3 General rules > 1) A constant-name, data-name, file-name, report-name, or screen-name described using a > GLOBAL clause is a global name. All data-names subordinate to a global name are global > names. All condition-names associated with a global name are global names. > > Now we know that not everything subordinate to a global name is global, only data-names > and condition-names are global. Are index-names considered data-names? > > 8.3.1.1.1 User-defined words > A user-defined word is a COBOL word that is supplied by the user to satisfy the format of > a clause or statement. > The types of user-defined words are: > - alphabet-name > - cd-name (obsolete element) > - class-name (for object orientation) > - class-name (for truth value proposition) > - compilation-variable-name > - condition-name > - constant-name > - data-name > - file-name > - function-prototype-name > - index-name > - interface-name > ..... > > The answer is NO, an index-name is not a data-name, therefore is not GLOBAL. > > You should complain to Fujitsu. Tell them they're not following the Standard. > > Bill Klein: am I right? > > >> If the table were loaded by one method-like function and accessed by another, as it would > >> be in the do-it-yourself-OO style you advocate, indexes would be a Big Problem. You > >> wouldn't be able to pass the limit between the two methods. The lookup method wouldn't be > >> able to return the found entry except by converting the index to a subscript. > > >GLOBAL works fine. As 'GLOBAL' in a set of nested programs is roughly > >(given limitation of single object) how an object shares its protected > >data with its methods then that is an appropriate mechanism. > > >The lookup method should be returning the data items, not an index or > >subscript. The whole point (or one of them) of OO is to hide the > >grubby implementation details, such as 'the index of the lookuped > >item'. > > In an OO environment, you're right. I was referring to traditional Cobol, where it's > common to call one program that returns an array, typically rows from a database, then > call a second program that flags matching entries, then call a third program that plops > them on the screen or something. In that environment, you could well be looking for a > single row, which could be returned as a subscript. You just changed that because originally you said: "as it would be in the do-it-yourself-OO style you advocate" In any case what is the problem with passing the limit ? A few seconds thought would have told you that passing it as a number would require a single SET, or could be used in varying from by -1 until zero without penalty. > >> The only way to use indexes in that environment would be to define your methods with > >> ENTRY. > > >What utter nonsense. > > It's called reducto ad absurdum. It's nonsense because GLOBAL can be used. It can be used with MF too. For EXTERNAL MF has EXTINDEX but this is not recommended. > >> >You then changed to talking about another subject, presumably you > >> >realized what happened (or is supposed to) with indexes. > > >> >> When using indexes, you need two per table -- one for reading, the other holding the size > >> >> (limit). The arguments for the second are the same as you used for the first -- an integer > >> >> could be sized too small, could be an inefficient type, etc. Most important, > >> >> inconsistantly using an integer for the limit will cause a type conversion every time you > >> >> compare the two. > > >> >I am so pleased that you have finally caught onto the issue and are > >> >now recommending indexes. However, your claim that I was > >> >'inconsistent' is nonsense because I never said anything either way > >> >about variables holding limits. > > >> You should have. You forgot about half the problem. > > >I didn't 'forget' anything. You are simply trying to manufacture > >denigration. > > I won't argue that point because you're the EXPERT on denigration.
From: Howard Brazee on 24 Sep 2007 11:39 On Sat, 22 Sep 2007 11:48:29 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >>> Even "a very multi-faceted person?" ;-) .... >> It is worse than I imagined, I though he was only "two faced" ;-) >> >If I had two, I wouldn't be using the one I am. I've been trying to get ahead in my job, but haven't considered the possibility of getting a face along with that head.
From: Howard Brazee on 24 Sep 2007 11:49 On Sat, 22 Sep 2007 23:18:51 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >>>Give me an example of conservatives changing fast enough to save >>>something? >> >> The United States. It's government hasn't been revolutionalized in ~250 >> years. > >Illegal immigration will achieve it without the need for a revolution :-) That will help change it - but probably not as much as the much more hated immigration of people from poor Roman Catholic countries a century ago.
From: Howard Brazee on 24 Sep 2007 12:16 On Sun, 23 Sep 2007 02:38:14 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >> Mainframers would love that, because it would guarantee shop standards are NEVER upgraded. > >Denigrating mainframers again then. That's always an effective way to convince us. Of something.
From: Howard Brazee on 24 Sep 2007 12:22
On Fri, 21 Sep 2007 17:38:23 -0600, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com> wrote: >PICTURE has its usefulness, but even having never worked with it's >predecessors, I don't understand why it seemed to have caused the >obsolescence of it's alternatives (SIZE and CLASS, I guess). PICTURE is >useful for DISPLAY items. I dare say that it's not so useful for >COMPUTATIONAL items. Specifically when interacting with other languages. I >guess that's why we now have POINTER, BINARY-CHAR, BINARY-SHORT, BINARY-LONG >and the like (no PICTURE allowed!!)... > >I guess PICTURE S9(4) COMP does make it easier to know the maximum possible >value of the field. But it also limits its usefulness. Not worth it, in my >opinion. I think it makes it easier to remember the decimal nature of CoBOL numbers. I expect our overflow rules are less efficient than that of languages that don't think in decimal - but they are closer to our business needs. |