Mainframe, MVS and zOS Discussion

This is also an interview question - When we use index and when we use subscript?

I think without Index we can not use SEARCH/SEARCH ALL -- but apart from this what are other differences or necessities which might bound us to use only index and not a subscript?

SEARCH/SEARCH ALL requires an index. For the most part, using a subscript or index otherwise doesn't really matter. An index represents an offset into the table whereas a subscript represents an occurrence but there's not a whole lot of difference forcing you to pick one or the other.

Robert Sample wrote:An index represents an offset into the table whereas a subscript represents an occurrence

Is there a way to calculate the offset for the gven index in cobol table?

Yes. The first table entry will be at offset zero. Add the length of the table entry to that zero and you will have the offset for the second table entry; add the length again to get the offset for the third table entry and so forth. The data map output from the compiler will give you the exact length of a table entry.

Ok got it. I've read some weired way of calculating it and was confused.

Thanks.

You don't have to worry about calulating it. The compiler does it for you. By the time you are able to locate an index in a dump, you'll be comfortable with how it was calculated.

William Collins wrote:You don't have to worry about calulating it. The compiler does it for you. By the time you are able to locate an index in a dump, you'll be comfortable with how it was calculated.

Can you please guide how to understand the dump? I hardly understand anything there.

For a COBOL programmer, the key parts of the dump are the information about the offset in the program where the ABEND occurred (which gives you the statement that has the problem -- use the OFFSET or LIST compiler output to find the line with the offset or closest match to the offset and that's the line where the program stopped working), and the storage dump.  If you haven't noticed, the compiler generates a variety of output that shows the BL (base locator) cells and offsets for each variable; there will be one BL cell per 4096 bytes of WORKING-STORAGE (BLL cells are used for LINKAGE SECTION).  You can then see exactly what was in memory when the program stopped working.

Robert Sample wrote:For a COBOL programmer, the key parts of the dump are the information about the offset in the program where the ABEND occurred (which gives you the statement that has the problem -- use the OFFSET or LIST compiler output to find the line with the offset or closest match to the offset and that's the line where the program stopped working), and the storage dump.  If you haven't noticed, the compiler generates a variety of output that shows the BL (base locator) cells and offsets for each variable; there will be one BL cell per 4096 bytes of WORKING-STORAGE (BLL cells are used for LINKAGE SECTION).  You can then see exactly what was in memory when the program stopped working.

Thanks. with OFFSET and LIST why sometimes it gives only the closet match and not the exact match? Is there a way we can locate the exact line of code for the problem?

In most cases an exact match will be found.  However there are some storage overlays that can cause the system to use a wrong address so it may not have an exact match in the compiler output.

The OFFSET compiler option will give the displacement of the first instruction generated by the compiler for the line of code.

The LIST compiler option lists all the generated instructions.

An offset from an abend can be found exactly in the LIST output, except for the important case Robert mentioned and its cousins. Accidental overlay of your executable statements or a wild branch into the "middle" of one of them are good bets when the offset from the abend does not match exactly to an instruction on the LIST output. Also, always check that the instruction shown is the one listed. You can overlay storage and have it fail whilst the failing instruction appears exactly at the start of an original instruction in the code.

OFFSET and LIST are mutually exclusive. You can't use them both in the same compile.

William Collins wrote:The OFFSET compiler option will give the displacement of the first instruction generated by the compiler for the line of code.

The LIST compiler option lists all the generated instructions.

An offset from an abend can be found exactly in the LIST output, except for the important case Robert mentioned and its cousins. Accidental overlay of your executable statements or a wild branch into the "middle" of one of them are good bets when the offset from the abend does not match exactly to an instruction on the LIST output. Also, always check that the instruction shown is the one listed. You can overlay storage and have it fail whilst the failing instruction appears exactly at the start of an original instruction in the code.

OFFSET and LIST are mutually exclusive. You can't use them both in the same compile.

Thanks for the explanation. Thanks for the last statement, that OFFSET and LIST are mutually exclusive. I'll have to read why are they mutually exclusive. I do not know this as of now.

OFFSET and LIST are two different types of output listing for the part which relates to generated code. The LIST output includes an offset for each generated instruction. The OFFSET output only shows the offset of the first instruction generated for the line of COBOL in question.

The LIST output is much longer. The OFFSET output is much less detailed.

Thanks. There are GnuCOBOL Compilers, do they also behave same? How can we check that?