Accessed 18th Element from an Array of 15 Elements?

[Aseem_Forum]

Hi,

In an COBOL Internal Table, I've declared table of length 15 but I have given a reference to 18th element in my program and there was no error. How is that possible?

[Robert Sample]

Enterprise COBOL has an SSRANGE option used during the compile. If this option is used, subscripts and indexes are checked to ensure they stay within the range of the table. If this option is not used during the compile, there is no check made at run time -- EVER -- for valid values of subscripts or indexes. Failing to use SSRANGE and having a subscript go out of the table range is a VERY common cause of S0C4 (storage) ABENDS.

[William Collins]

COBOL puts a heavy emphasis on the coder getting it right.

If you don't check that you only access within the bounds of your table, then it is not likely that your program is a very robust one.

As Robert has pointed out, these days there is SSRANGE, (partial) saviour of many a lazy coder.

Another area you'll be shocked about is the parameter-passing between CALL ... USING ... and PROCEDURE DIVISION USING ...

COBOL is an old language. It was written in the days before "absolve-laziness" was hard-coded into compilers.

[Aseem_Forum]

oh...o got it. But then if it is so why SSRANGE is not made a default option for compiling?

[Aseem_Forum]

Another area you'll be shocked about is the parameter-passing between CALL ... USING ... and PROCEDURE DIVISION USING ...

Thanks William, can you please elaborate on it more?

[William Collins]

Ask the people who installed COBOL at your site. It can be, it is site-dependant. Many sites prefer it as the defualt, either through installation or by the default compile options provided through the panels to compile programs.

However, there are three arguments against it, for me: it encourages laziness; there is a performance penalty; I prefer compile options to be the same through all stages of the cycle, whereas mostly SSRANGE does not go into Production (performance penalty). SSRANGE can be turned off at run-time (at least before V5.1, it is unclear to me with V5.1) but there is still a performance hit when running it turned off.

Just seen your next one.

Well, parameters are not checked, in any way at all, between CALL and PROCEDURE DIVISION. No way. No checking at all. All down to the programmer to ensure that they are coded correctly. For someone trained in other languages, that can seem unusuall, but we've managed to cope with it all along.

[Aseem_Forum]

Thanks William.