I had a, which now seems quaint, habit of keeping compile listings (which have all sorts of neat information) for my applications. However I have a deep distas

I had a, which now seems quaint, habit of keeping compile listings (which have all sorts of neat information) for my applications. However I have a deep distaste for writing in COBOL. That said, my favorite resource for dealing with COBOL problems was AMBLIST which shows the compile date and other attributes of each object module,whether COBOL, FORTRAN, Assembler or PL/I. There's a number of mainframe source management tools. In VM, XEDIT would automatically generate change records for source files as they were modified. It made a lot of sense to develop under VM and deploy to MVS, z/OS just to have good source control without having to buy source management tools and enforce their use. I strongly suspect IBM does pretty much the same for their mainframe operating system and utility code. The dirty secret is that the code that runs logical partitions is a flavor of VM. COBOL and FORTRAN in the early days had minimal subroutine libraries. Direct calls to the supervisor were made in the compiled code along with building the parameters and handling the results. This does make it more straightforward to see what the object code is doing. PL/I had a comprehensive subroutine library. Later on the subroutine libraries for the various compiler languages were consolidated into Language Environment.