Writing an IDF profile

You can write a profile macro for IDF to change the display colors, PF key assignments, default open windows, set predefined breakpoints for a given program, or perform other functions.

You do not need to have a profile macro, and if you do have one it can be as simple or exotic as you like. One example is to get the name of the program that is being debugged, use it coupled with the CMS NAMEFIND command to get information about that program, and automatically set a number of breakpoints that apply to it.

Regardless of what uses you have planned for it, the profile must be written in the REXX language.

z/VM: The profile must have a file type of ASM and can reside on any accessed disk.
z/OS: The profile must be a member of the partitioned data sets (PDSs) allocated to the ASM DD name.
z/VSE: The profile must reside in a member of a sublibrary in the active PROC chain.

The default file name is PROFILE, but you can specify another file name with the PROFILE option. It is invoked by IDF just before the first display is presented (for more specific information about when the profile is executed, see When the PROFILE is executed.) The default ADDRESS environment when your profile begins execution is ASM. IDF does not examine the return code from your profile.

To change IDF parameters, use the SET command. You can examine the current settings with the EXTRACT command. You can issue any IDF command from within your profile (though some may not make sense at that point) and you can invoke IDF macros from within your profile.

Here is an example of a simple profile:

Figure 1. Example of a simple PROFILE

/* PROFILE ASM */
'set color wryg'
'regs'
'disasm'
'dump'
'dumpmode'
exit

This profile begins by changing the display color assignments. It then opens the Current Registers window, the Disassembly window and the Dump window, inverts the default dump mode (symbolic or unformatted), and exits.

When you issue an IDF command in your profile, it behaves exactly as if you had pressed that PF key.

Warning: Be careful when executing CMS commands from within your profile. If you are debugging a user-area program, and your profile invokes another program that runs in the user area, it will destroy your debugging environment. The same care should be taken with routines that run in the transient area.