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 05:07 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.
From: Robert on 23 Sep 2007 05:16 On Sun, 23 Sep 2007 01:57:20 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >On Sep 23, 2:19 pm, Robert <n...(a)e.mail> wrote: >> On Sat, 22 Sep 2007 23:21:02 GMT, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: >> >> >You are saying that you can use OCCURS 1 and use the 2nd index for the 3rd >> >"subscript"? >> >> Yes. >> >> 01 big-table. >> 05 occurs 1000 indexed a. >> 10 occurs 1 indexed b. >> 15 stuff occurs 1 indexed c pic x(10). >> >> set a to 500 >> set b to 1 >> set c to 1 >> >> move stuff (a c b) to ... > >Report that as a bug in your compiler. > >In Fujitsu it correctly warns that this is wrong. Fujitsu doesn't have the IBM extension. If bounds checking is off, this will compile and run: set a to 1 set b to 2 set c to 3 move stuff (a c b) to ...
From: Richard on 23 Sep 2007 05:38 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: > > >> >> >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. > > There's an easy way to tell -- set a USAGE INDEX data item to the index, redefine as > integer and display it. > > I'll wager 100US it shows the offset from the beginning of the table on my compiler, yours > or any other being shipped today. > > >Your whole thesis is just uninformed guesswork. > > Let's get informed, shall we? > > > > >> >> >> > 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. > > The 02 Standard allows one to define native types with BINARY-SHORT and BINARY-LONG. No > more non-Standard comp-5. > > > > >> >> >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. > >> 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'. > (Thou Shalt write clunky code). Why not > provide a filter that errors when it detects violations? Something like lint built into > the compiler preprocessor. The meta language could even be written into the Cobol > Standard. > > Mainframers would love that, because it would guarantee shop standards are NEVER upgraded. Denigrating mainframers again then. > >> >> >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. In any case indexes are not just about speed, if you haven't noticed yet.
From: Richard on 23 Sep 2007 05:44 On Sep 23, 9:16 pm, Robert <n...(a)e.mail> wrote: > On Sun, 23 Sep 2007 01:57:20 -0700, Richard <rip...(a)Azonic.co.nz> wrote: > >On Sep 23, 2:19 pm, Robert <n...(a)e.mail> wrote: > >> On Sat, 22 Sep 2007 23:21:02 GMT, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > > >> >You are saying that you can use OCCURS 1 and use the 2nd index for the 3rd > >> >"subscript"? > > >> Yes. > > >> 01 big-table. > >> 05 occurs 1000 indexed a. > >> 10 occurs 1 indexed b. > >> 15 stuff occurs 1 indexed c pic x(10). > > >> set a to 500 > >> set b to 1 > >> set c to 1 > > >> move stuff (a c b) to ... > > >Report that as a bug in your compiler. > > >In Fujitsu it correctly warns that this is wrong. > > Fujitsu doesn't have the IBM extension. > If bounds checking is off, this will compile and run: > > set a to 1 > set b to 2 > set c to 3 > > move stuff (a c b) to ... That won't compile in Fujitsu or any compiler that is set to compile standard cobol. The bound check is only done at run-time, if you turn it off it won't happen.
From: William M. Klein on 23 Sep 2007 08:58
"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. -- Bill Klein wmklein <at> ix.netcom.com |