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 12:02 On Sun, 23 Sep 2007 02:07:44 -0700, Richard <riplin(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. 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.
From: Robert on 23 Sep 2007 13:12 On Sun, 23 Sep 2007 02:38:14 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >On Sep 23, 3:00 pm, Robert <n...(a)e.mail> wrote: >> On Sat, 22 Sep 2007 15:47:26 -0700, Richard <rip...(a)Azonic.co.nz> wrote: >> >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: >> >> >> >> >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. >> >> Yeahbut, another default is MF, meaning (on). It's an MF extension. > >In my MF manual it has, in the section: Indexing: > >"""An index described for some other table can be used instead >provided the two tables have elements of the same size.""" This is >marked OSVS VSC2. It is _NOT_ a MF extension (is isn't marked MF) so >the MF option won't control it. The online manual says the extension applies under these dialects: OSVS, VSC2 and MF. It is in section 2.6.5.3 of Language Reference at http://supportline.microfocus.com/supportline/documentation/books/sx22sp1/lrpubb.htm However, the default DIALECT is ANS85, not MF. >> >> 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. >> >> Every application shop has house 'standards' > >So, what was your point ? IBM has 'standard' features in all its >various compilers, this has nothing to do with 'shop standards' or the >'ANS'02 standard'. When IBM and application shops use the word standard, their intent is to avoid responsibility for their choices by implying consensus. They want the reader to believe many companies do things the same way. Dictionaary definition: conforming to or constituting a standard of measurement or value; or of the usual or regularized or accepted kind; "windows of standard width"; "standard sizes"; "the standard fixtures"; "standard brands"; "standard operating procedure" We all know that's a lie. Company programming standards are all different from each other. Sometimes, two departments within the same company have differing standards. In reality, there is no "usual or regularized or accepted" programming style. Cobol shop standards are prescriptive, regarded as 'laws' that can never be broken. In shops using other languages, local standards (if any) are less formal. They are regarded as descriptive of community norms. The difference is that Cobol standards prohibit progress, whereas others avoid common mistakes. >> >> >> >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. >> >> Your own test results prove you wrong. > >No. Wrong. The tests show that the optimizer is able to keep the >result of calculating the address from the subscript for use several >times and thus only do one multiply, which is much the same as the >index where the varying recalculates and it is used several times. > >It hasn't magically re-engineered my CPU to make the multiply >instruction as fast as as load instruction, as you wrongly assert, it >has made the number of multiplys fewer than you expected. You wouldn't say that if you had actually read the code I posted here (twice). I too ran into that optimization problem. I solved it by putting, inside the loop, code to make the optimizer think the subscript or index is changing. As a result, multiply (and store) instructions were not optimized out, as you claim. Here's a sample: move 'Subscript' to test-name move 1000 to s-subscript 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 end-perform
From: Robert on 23 Sep 2007 13:27 On Sun, 23 Sep 2007 12:58:07 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >"Richard" <riplin(a)Azonic.co.nz> wrote in message >news:1190540294.311738.188670(a)y42g2000hsy.googlegroups.com... ><snip> >>> Yeahbut, another default is MF, meaning (on). It's an MF extension. >> >> In my MF manual it has, in the section: Indexing: >> >> """An index described for some other table can be used instead >> provided the two tables have elements of the same size.""" This is >> marked OSVS VSC2. It is _NOT_ a MF extension (is isn't marked MF) so >> the MF option won't control it. > >Looks like a dox error to me. WhenI compile with > NOOSVS NOVSC2 Dialect(MF) > >or even just > FLAG(MF) FLAGAS(S) > >then this DOES accept the extension (of using an idnex from another table). > >MF has always had "some" problems (and I know this as someone who once had to >maintain their LRM) with figuring out exactly when/how to document "MF" >extensions. > >The directives such as OSVS and VSC2 *mostly* control reserved words and not >syntax. As this extension does NOT require any additional reserved words, it >can exist with NOOSVS and NOVSC2. In GENERAL, MF accepts as a "valid" >(supported?) syntax extension any syntax that is allowed with the current >reserved words turned on. There are VEERY few things that get flagged when >FLAG(MF) is turned on. I think the explanation is that dialect options are not primary ones. Each turns on a long list of other options. For instance, OSVS turns on NOANS85, APOST, AREACHECK, ARITHMETIC"OSVS", etc. There are lists of them in the User's Guide, Directives for Compiler, Dialect. I can't find a low level option that applies specifically to indexes on other tables.
From: Richard on 23 Sep 2007 14:29 On Sep 24, 5:12 am, Robert <n...(a)e.mail> wrote: > On Sun, 23 Sep 2007 02:38:14 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >On Sep 23, 3:00 pm, Robert <n...(a)e.mail> wrote: > >> On Sat, 22 Sep 2007 15:47:26 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >> >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: > > >> >> >> >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. > > >> Yeahbut, another default is MF, meaning (on). It's an MF extension. > > >In my MF manual it has, in the section: Indexing: > > >"""An index described for some other table can be used instead > >provided the two tables have elements of the same size.""" This is > >marked OSVS VSC2. It is _NOT_ a MF extension (is isn't marked MF) so > >the MF option won't control it. > > The online manual says the extension applies under these dialects: OSVS, VSC2 and MF. > It is in section 2.6.5.3 of Language Reference at http://supportline.microfocus.com/supportline/documentation/books/sx2... > > However, the default DIALECT is ANS85, not MF. > > >> >> 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. > > >> Every application shop has house 'standards' > > >So, what was your point ? IBM has 'standard' features in all its > >various compilers, this has nothing to do with 'shop standards' or the > >'ANS'02 standard'. > > When IBM and application shops use the word standard, their intent is to avoid > responsibility for their choices by implying consensus. They want the reader to believe > many companies do things the same way. It was marked as "OSVS standard". How many other companies have OSVS as a product ? > Dictionaary definition: > conforming to or constituting a standard of measurement or value; or of the usual or > regularized or accepted kind; "windows of standard width"; "standard sizes"; "the standard > fixtures"; "standard brands"; "standard operating procedure" > > We all know that's a lie. Company programming standards are all different from each other. > Sometimes, two departments within the same company have differing standards. In reality, > there is no "usual or regularized or accepted" programming style. They are marked: "XYZ Accounting System standard", and do not pretend to apply worldwide. This is just another of your bizzare hate rants. > Cobol shop standards are prescriptive, regarded as 'laws' that can never be broken. In > shops using other languages, local standards (if any) are less formal. They are regarded > as descriptive of community norms. The difference is that Cobol standards prohibit > progress, whereas others avoid common mistakes. > > > > >> >> >> >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. > > >> Your own test results prove you wrong. > > >No. Wrong. The tests show that the optimizer is able to keep the > >result of calculating the address from the subscript for use several > >times and thus only do one multiply, which is much the same as the > >index where the varying recalculates and it is used several times. > > >It hasn't magically re-engineered my CPU to make the multiply > >instruction as fast as as load instruction, as you wrongly assert, it > >has made the number of multiplys fewer than you expected. > > You wouldn't say that if you had actually read the code I posted here (twice). > I too ran into that optimization problem. I solved it by putting, inside the loop, code > to make the optimizer think the subscript or index is changing. As a result, multiply (and > store) instructions were not optimized out, as you claim. Here's a sample: I had read the code, but it is only your assertion that you had beat the optimizer. It may be that it specifically notices the add 1 and increments the address rather than remultiply. > move 'Subscript' to test-name > move 1000 to s-subscript > 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 > end-perform I any case the index code is just the same so it only has to recalculate the address once per loop in both cases. Regardless of any of that your claim was that _my_ results showed that "multiplu is as fast as load" when I know for a fact that my CPU has had no magic applied that changed the relative speed of the instruction set.
From: Richard on 23 Sep 2007 15:45
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. 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. 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. |