First I would like to wish everyone a merry Xmas and a very happy new year for 2016.
Recently I have had a few problems raised that have actually started out being reported by the user as a compiler problem. Where as they were actually run-time problems. So I thought for my final blog entry for 2015 I would make some suggestions on how you can identify more accurately what component your failure may actually be in. Now these suggestions are not a definitive way of defining your applications failure as either a compiler or a run-time problem but they should help you at least identify the more obvious differences so thereby increasing your chances of getting your problem analysed and corrected quickly by the correct support team.
Obviously many compiler problems will be experienced at run-time. For example the COBOL for VSE/ESA compiler is quite stable so the chances of a failure being experienced during compilation are rather small. But since the code generated by the compiler is not actually executed until run-time this is where a compiler problem is most likely to be experienced. The thing that makes identifying the correct component difficult is that run-time failures will also only show up at execution time. So how do you at least attempt to identify which component your problem should at least initially be raised against?
When you get a run-time failure with a LE z/VSE dump and trace-back report you can usually identify the program statement number in the program that experienced the failure from this report so long as the correct compiler options were set. But obviously just because the code that failed was generated by the compiler does not automatically mean the compiler must have done something wrong. There are a lot of various reasons why the problem could be at a completely different part of your program and not cause any failures until a certain field/variable is used or an indexed table/array is referenced. The simplest and fastest method to first eliminate a compiler problem is to review carefully the assembler code prior to and including the instruction that failed with the language statement that was coded. If you are executing a MOVE for example, does the compiler code include an instruction that would accomplish a move (eg MVC)? Does the base-locator (BLW etc) reported in the assembler listing match with the area(s) being used in the move statement? If your code is different to a MOVE then check if the field types being referenced or changed in the statement match the code that has been generated. For example if packed decimal is being used are the instructions generated correct for working with packed decimal? If none of these issues are present then the chances are you do not have a compiler problem so the issue should be reported to the LE z/VSE support team.
Remember to always provide a complete compiler (with assembler listing) and linkedit map, a current system SDL along with any other LE or system dumps and logs (console or CICS) to help the support team have access to all the documentation they may need. They can also check your compiler listing to see if the problem is a compiler issue and then transfer the call to the appropriate support team for you.
All the best to everyone for 2016 and happy holidays!!