They guys on the RDz product team have done an excellent job of getting new features into the product in the latest release of RDz. Already, the product had great support for viewing performance hierarchies, and showing dependencies of copy books. Version 8.5 really builds on the program analysis capabilities of the product with the new program control flow diagram and data elements view.
I was teaching this past week, and it occurred to me just exactly what these new features add up to. If you are a System Z developer who has to manage code left over by a now retired co-worker, or manage code by someone who has not touched the source in 15 years, this amounts to an archaeological dig. Its ancient code that no one knows about, or who wrote it (if no comments are present), and has no idea what all it affects. The first part of analyzing such code is to see what it is comprised of, what copybooks it calls, and what other files it touches.
Program Call Hierarchy
This feature has been around for a while. The "Open Perform Hierarchy" gives you a visual display of the perform chain. It shows you a tree view of the various calls from the perspective of the performer, or the performee. Visually, you can also see the type of of call based on the icon. If it is part of a conditional statement, it will show a yellow flag. If its part of a loop, it will show with a blue circular arrow. What is really exciting about this, is that if you expand down further, it can show you areas of possible program fall through (displayed in red). Now, these are not certain fall through, but only possible fall through, as the code may legitimately call an abend routine.
Program Control Flow Diagram
The Control flow diagram is the newest feature, and might be your first tool you pull out of the tool bag to begin your 'dig'. This diagram is available from the context menu of the editor "Show In > Program Control Flow".
The diagram is navigable, meaning that if you click on it, it will show that paragraph line in the editor view. This is like giving an archaeologist a blueprint of the ruins he is investigating. This diagram can also be saved off as a bitmap (as I just did with this diagram). Such a diagram can give you a great high level overview of what the program is doing. Also, any sections of code that are not used (i.e. dead code), will not have any lines connected. There are other methods of showing dead code as I'll explain below. Needless to say, this is NOT something you can do with ISPF.
Data Element View
Next, you might want to see what data the COBOL file will affect. This too is new with RDz 8.5. Within your COBOL file, from the context menu (right click to get to it), select "Show In > Data Elements". This gives you a spreadsheet like view of the various data variables, file descriptors, paragraphs, and mnemonics. Each column in the view is sortable, and you can control which columns are visible from the properties menu. Another cool feature of this view is the ability to filter out elements with the filter field at the top right.
This feature has been around for a while, and is fairly basic. It does require that your SYSLIB concatenation in your associated property group is properly stated, but will open a variable in a paragraph to its declaration either in the current source member, or in another copybook. For you Java developers out there, a SYSLIB concatenation is analogous to a class path. This method is good for deep down analysis.
Sometimes you just want to see sections of code, and not all the 'fluff'. From the context menu select "Filter View", and the select the type of data you wish to see. For example, perhaps you wish to just look at the code documentation otherwise known as the comments. This is great if its there, but if not, you can select an Outline view of the data which collapses down the paragraphs to a single line. If you are working with DB2 or CICS, perhaps you only care about the EXEC statements. Subsequently, you can filter down to just the EXEC statements.
Find Dead Code
This last one is another new RDz 8.5 feature. From the context menu, select "Source - Identify Unreachable Code". The dead code will then be highlighted in red for you. This is a great way to cull out unused code and make your source more manageable, and more meaningful. It also can help you avoid looking at dead code, when you are just trying to find the source of a bug (hint: it won't be in the dead code).
Labels: mainframe, rational, systemz