Fighting my way through a 600 line block of code at the moment. It is S0C4 abending for no meaningfull or sensible reason.
Insert a WTO 100s of lines above where it abends and it runs, remove the WTO line and it abends again. Add a few more WTO lines in the code for debugging 100s of lines below where it abends, abends S0C4 again on a branch to a label. Take random WTOs out, add a few random ones in, it works again. Have checked the WTO macro code and it doesn’t do any fancy boundary alignment so it seems to be the number of bytes in the code size ????, its certainly nowhere near a 4K assembled size yet though. And abend/no-abend can be flicked just using the WTO macro, there are no actual code logic changes being done to stop the abends.
All the abends occur on B (branch) to a LABEL in the code, not on jumps to addresses (it doesn’t get that far) which the assembler should be able to work out. Started putting “DS 0F” fields directly above some of the labels that seemed to fix some, “CNOP 0,4” as the first instruction at the label does not improve the situation. So basically a ‘goto fred’ (no pun intended) will abend even though it assembles cleanly and the assembler knows where fred is.
Also have dicovered just adding a few extra lines of code nowhere near where it abends will make it S0C4 abend on a branch instruction as well.
It’s almost as if the assembler is optomising the code and moving the branch target addresses off fullword boundaries despite everything I can think off to force them there (I shouldn’t need to force them there though, thats the assemblers job).
I suppose it could be trying to jump to an address out of range but the assembler should say so at assemble time if that was the case ???. And if that was the case inserting extra code in the way of WTOs should make it worse not better.
Will move some data areas around and see if that makes a difference, although if I ever figure this out most of the data areas will be split off into a seperate DSECT anyway.
Will keep banging my head on the table for a while.
And eventually, as the bulk of the code will probably end up in a seperate CSECT will have to fight the battle all over again.
