View code generated by the IBM Enterprise COBOL compiler
I recently started doing some work with COBOL, where I previously only did work in the z / OS Assembler on the Mainframe.
I know COBOL will be translated to Mainframe machine code, but I am wondering if the generated code can be seen?
I want to use this to better understand COBOL approaches.
For example, if I were to compile a COBOL program, I would like to see the assembly that arises from the compilation. Is something like this possible?
source to share
Relenting, just because of this: "I want to use this to better understand the Cobol side job."
The simple answer is that there is a compiler option LIST for Enterprise COBOL on z / OS. LIST will provide what is known as a "pseudo-assembler" in your compilation listing (and some other helpful material for understanding the executable program). Another compiler option, OFFSET, shows the offset from the start of the program of the code generated for each COBOL verb. LIST (which essentially already has an offset) and OFFSET are mutually exclusive. Therefore you need to specify LIST and NOOFFSET.
Compiler options can be specified in PARM EXEC PGM = for the compiler. Since PARM is limited to 100 characters, compiler options can also be specified in the dataset with DDName SYSOPTF (which in turn uses the compiler option to indicate its use).
A third way to specify compiler options is to include them in the source code of the program using PROCESS or (more generally, since this is shorter) CBL statement.
You probably have a "panel" for compiling your programs. This may have a field to allow you to specify parameters.
However, keep two things in mind: when installing the compiler, it is possible to "pin" compiler options (which means they cannot be changed by the application programmer); when installing the compiler, it is possible to prevent the use of PROCESS / CBL instructions.
The reason for this is standardization. There are compiler options that affect code generation, and using different code generation options on the same system can lead to undesirable consequences. Even on different systems, different code generation options may be undesirable if programmers tend to expect "normal" options.
It is unlikely that parameters based on listing alone will be nailed, but if you are not allowed to specify parameters, you may need to make a special request. This is not common, but you may be out of luck. It's not my fault if it doesn't work for you.
The options for this compiler and how to specify them are described in the version-specific Enterprise COBOL Programming Guide. There you will also find the pseudo-assembler documentation (note that it appears in the document as "pseudo-assembler", "pseudo-assembler" and "pseudo-assembler", for no good reason).
When you see the pseudo assembler, you will see that it is not in the same format as the Assembler statement (I never found out why, but as far as I know, it has been that way for over 40 years). The pseudo-assembler line will also contain machine code in the same format as you are already familiar with assembler output.
Don't expect to see a compiled COBOL program similar to the Assembler program you would write. Enterprise COBOL adheres to the language standard (1985) with IBM Extensions. The answer to the question "why does it do this is likely to be" because, with the exception of optimizations (see below).
What you see will depend a lot on the version of your compiler, because in the summer of 2013, IBM introduced V5 with completely new code generation and optimizations. Prior to V4.2, the code generator reverted to "ESA", which meant that over 600 machine instructions entered from the ESA were not available for Enterprise COBOL programs and extended registers. The same COBOL program compiled with V4.2 and with V6.1 (latest version at the time of writing) will differ markedly, not only due to different instructions, but also due to the fact that the structure of the COBOL executable program has been changed ...
Then there is opiomization. Since V4.2, there was one level of optimization possible, and the optimized code was usually "recognizable". With V5 +, there are three levels of optimization (you get a zero level without a query) and the optimization is much more extreme, including, well, extreme things. If you have V5 + and want to know a little more about what's going on, use OPT (0) to understand what's going on, and then pay attention to the effects of OPT (1) and OPT (2) (and implement, with increased compilation time, how much work was spent on optimization).
There really isn't much of the official documentation of the interior. Search engineering will show some things. IBM Compiler Cafe: COBOL Cafe Forum - IBM is a good place if you want to learn more about the internals of V5 + as there are multiple developers working there. For up to V4.2 it might be as good here as any other to ask additional specific questions.
source to share