There is a change with V5, and currently the same in V6, whereby the location of the storage allocated by the compiler for indexes/indices is different. Instead of being nicely separate somewhere, they are now located immediately after (subject to slack-bytes) the table which defines them (except, obviously, for LINKAGE SECTION tables, I've not used V5, so don't know where those are allocated).
This means if you let an index "run off" the end of the table, and then use it, you will likely trash the index itself, such that the next time the index is used to refer to something it is referring to... who knows what, certainly not what you may hope. See this discussion: https://www.ibm.com/developerworks/community/forums/html/topic?id=c476d2c9-0d4e-4073-97c5-6384d8f381c0&ps=25 That behaviour is due to change, under a policy to make V5/V6 behave more like V3/V4 in situations where code worked, but relied on the way the V3/V4 compiler implemented something (my paraphrase, don't take it literally). See here, towards the end of the topic: https://www.ibm.com/developerworks/community/forums/html/topic?id=0f54483b-6f83-441d-a5fc-22a3d333dddf&ps=25 For migration to V5/V6 I would recommend the use of SSRANGE for initial program-testing for this reason. On Tuesday, 5 April 2016 01:02:23 UTC+1, Cameron Conacher wrote: > We need up turning off optimization and the program compiled. > We are now seeing some coding issues. We have programs that SET INDEX-ITEM UP > BY +1 where the value would would be larger than the OCCURS clause defined. > Resulting in 0C7. > We do not see this with previous versions if COBOL. > > Sent from my iPhone ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
