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: Robert on 23 Sep 2007 18:32 On Sun, 23 Sep 2007 12:45:06 -0700, Richard <riplin(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. >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. 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. The only way to use indexes in that environment would be to define your methods with ENTRY. >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 used to use indexes frequently, when they were faster. I stopped using them when the speed difference disappeared.
From: Richard on 23 Sep 2007 20:36 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. 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'. > >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. > 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'. > The only way to use indexes in that environment would be to define your methods with > ENTRY. What utter nonsense. > >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. In fact I don't see any 'table load' code in your speed2. > I used to use indexes frequently, when they were faster. I stopped using them when the > speed difference disappeared. So you reverted to 1960s style.
From: Robert on 23 Sep 2007 22:43 On Sun, 23 Sep 2007 17:36:22 -0700, Richard <riplin(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. >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. >> >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. >> 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. >> >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: Rick Smith on 23 Sep 2007 23:09 "Robert" <no(a)e.mail> wrote in message news:6r6ef3hld8tp43o5mdamd8bdblipr2tsnk(a)4ax.com... [snip] > The answer is NO, an index-name is not a data-name, therefore is not GLOBAL. FDIS ISO/IEC 1989:2002, PAGE 104, 8.4.5.1.2 Scope of index-names, "If a data item possessing the global attribute includes a table described with an index-name, that index-name also possesses the global attribute. Therefore, the scope of an index-name is identical to that of the data-name that names the table whose index is named by that index-name."
From: William M. Klein on 23 Sep 2007 23:27
"Robert" <no(a)e.mail> wrote in message news:6r6ef3hld8tp43o5mdamd8bdblipr2tsnk(a)4ax.com... > On Sun, 23 Sep 2007 17:36:22 -0700, Richard <riplin(a)Azonic.co.nz> wrote: <snip> > The answer is NO, an index-name is not a data-name, therefore is not GLOBAL. > I believe that there was an interpreation request on this subject, but I haven't found it quickly. However, the '02 Standard is ABSOLUTELY clear on this when, on page 104, it states, "8.4.5.1.2 Scope of index-names If a data item possessing the global attribute includes a table described with an index-name, that index-name also possesses the global attribute. Therefore, the scope of an index-name is identical to that of the data-name that names the table whose index is named by that index-name." This is NOT identified as a "subsantive change" from the '85 Standard - so at least as far as the '02 Standard goes, it was true in the past and now. -- Bill Klein wmklein <at> ix.netcom.com |