Mainframe, MVS and zOS Discussion

Hi,

A job was abended in production. The reason was that COBOL internal table was overlowed. We are not using SSRANGE in production. It is told it is standard. In my last compnay also we were not using SSRANGE in production. Why it is not allowed, what is wrong with this option?

With SSRANGE, the compiler adds code to check table limits -- which potentially means a LOT of code could be added. The V5.1 Performance Tuning Guide manual states on page 25:

A benchmark that makes moderate use of subscripted references to tables slows down by 20% when SSRANGE is specified.

So many sites prohibit SSRANGE in production code due to the performance hit suffered. There is nothing "wrong" with the option -- it does what it is designed to do. The issue is the performance impact of the option.

Thanks. So what is the best way to avoid such abends in production?

So what is the best way to avoid such abends in production?

Nobody ever wants to hear this, but the best way to avoid such abends is to write better code. Have the table size (number of elements) stored in a variable and EVERY time a subscript is set, test to make sure it is within the table limit. This can be tedious and if the code does not already have this in it, there can be a major effort required to add the tests. But since there is nothing in COBOL except SSRANGE to do such testing, this is what has to be done to prevent abends from table overflows.

Robert Sample wrote: ↑Fri Oct 26, 2018 5:30 pmHave the table size (number of elements) stored in a variable and EVERY time a subscript is set, test to make sure it is within the table limit.

This had been a standard at couple of shops I had been to but if a shop has never adopted for this, it can indeed be tedious.