z/TPF Debugger Enhancements 2016
K.Chalas 310001W047 Visits (8158)
In APAR PJ3641, an enhancement was made for ZDBUG CLEAR in order to allow the clearing of sessions at the port granularity. Before this APAR, two sessions with the same name could be registered on the same IP address as long as they were on different ports; however, you couldn’t clear only one of those sessions with the ZDBUG CLEAR command. The only filter available was to clear by IP address. With this APAR applied, you can clear by a specific IP address and port.
In APAR PJ43689, the ZDDMP command now supports wildcards for the program filter, both on z/TPF and on Toolkit. Past behavior required you to specify the whole program name to use the PGM filter. Now, you can use the wildcard for filtering dumps, for example PGM-Q* or PGM-QD*.
Additionally, as part of the PJ43689 APAR, to reduce confusion, ZDDMP displays (triggered by the ZDDMP DISPLAY command) have changed column names and terminology so as to match the filters used to trigger those displays. For instance, if a column used to be called “Program” but the filter was “PGM”, now the column is called “PGM”. This should reduce confusion and make finding information faster for the interested party.
In APAR PJ43885, an enhancement was made so that dump records would be deleted for active and inactive processors on issuing the ZDDMP DELETE command. Before this APAR, only active processors would delete their dumps, which meant ZDDMP DISPLAY ALL would continue to display the dump records still present on inactive processors. There are cases where deletion will still fail. For instance, if an inactive processor has a different file system mounted on the directory where dump records are stored, the delete will fail because only that processor can access those records.
In APAR PJ44004, an enhancement was made to the debugger so that during a debugger session, a user could specify more Macro Breakpoints at finer granularities. Before this APAR, only one macro breakpoint could be created per macro. So, for the macro MALOC, the user had to carefully decide what to put into the Executable filter. If a user wanted to stop in a program that started with the letter ‘S’ and also in a program that started with the letter ‘Q’, the only possible filter was the wildcard. Now, MALOC (and other macro and macro groups) can have multiple breakpoints set. In the example, one for “S*” and one for “Q*”.
Additionally, as part of the effort to make macro breakpoints work in this fashion, a solution was found for the previously broken Object filter in the Macro Breakpoint wizard in the Toolkit. Before this APAR, the Object filter was functioning incorrectly, treating any input for that filter as if it were always a wildcard. Now, the object filter works in the same fashion as the Executable filter. However, you cannot create macro breakpoints where the only differentiator is the Object filter.
In APAR PJ42752, the System Heap view allows you to monitor your use of system heap storage. All you need to do is add a monitor specifying the token that identifies the system heap storage being allocated. When your application issues tpf_gsysc, the address of this storage area will appear next to the token. You can then select this address, and a rendering of the storage will appear in the System Heap view. You can edit the contents of the storage right from the System Heap view. Once your application releases the storage, the token will still appear in the view, but there will be no address associated with this token. The System Heap view helps you keep track of your use of system heap storage by displaying the address of the system heap storage that is associated with this token all the while your application has access to this storage area.
In addition to APAR PJ43583, the Dump Data Items view requires IBM TPF Toolkit version 4.2.7.