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 22 Sep 2007 22:02 On Sat, 22 Sep 2007 15:30:20 -0700, Richard <riplin(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.
From: Robert on 22 Sep 2007 22:19 On Sat, 22 Sep 2007 23:21:02 GMT, "William M. Klein" <wmklein(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 ...
From: Robert on 22 Sep 2007 23:00 On Sat, 22 Sep 2007 15:47:26 -0700, Richard <riplin(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. >> 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' (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. >> >> >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.
From: William M. Klein on 22 Sep 2007 23:49 Robert, If you think that MF "supports" this, then you were probably running with a low-level of the WARNING directives (and/or you don't care about WARNING messages). The following is the listing that I get for your code: * Micro Focus Net Express V5.0 revision 000 22-Sep-07 22:44 Page 1 * "C:\Documents and Settings\WMK\My Documents\MyPgms\Ind1.CBL" * Options: NOLIST NOASMLIST OMF(OBJ) GNT(.\) OBJ(.\) wb3 COBIDY(DEBUG) WB3 WB * warning(3) List() CSI ANIM EDITOR(MF2) ENSUITE(3) OPT(1) NOGNT * INT(DEBUG\Ind1.int) 1 Identification Division. 2 Program-Id. Ind1. 3 Data Division. 4 Working-Storage Section. 5 01 big-table. 6 05 occurs 1000 indexed a. 7 10 occurs 1 indexed b. 8 15 stuff occurs 1 indexed c pic x(10). 9 01 Recv Pic X(10). 10 Procedure Division. 11 set a to 500 12 set b to 1 13 set c to 1 14 15 move stuff (a c b) to Recv * 399-W*************** ( 0)** ** Index-name belongs to different table * 399-W***************** ( 1)** ** Index-name belongs to different table 16 Stop Run 17 . * Micro Focus Net Express V5.0 revision 000 Compiler * Last message on page: 1 * Total Messages: 2 * Unrecoverable : 0 Severe : 0 * Errors : 0 Warnings: 2 * Informational : 0 Flags : 0 -- Bill Klein wmklein <at> ix.netcom.com "Robert" <no(a)e.mail> wrote in message news:0bibf3hv0t8q989mhuqocrkdb6kukt18j5(a)4ax.com... > On Sat, 22 Sep 2007 23:21:02 GMT, "William M. Klein" > <wmklein(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 ... > >
From: Richard on 23 Sep 2007 04:57
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. |