When debugging an IBM i application, the debugger needs to know the job where the application will be running or is running before the debug session starts. If for example your main application starts different jobs for different tasks, you don't always know the job numbers of these jobs. To debug a program running under a known specific user profile, you can use the service entry point support to debug such a job. Refer to service entry point support for more details.Debugging IBM i applications by using service entry points
If all application jobs are running under the same generic user profile, setting a service entry point would start the debugger for the next job entering the system, not a specific one.
The Dynamic Attach feature works like this:
Create a new IBM® i: Debug dynamic job configuration from the Debug configurations dialog. See the help for Dynamic Attach configuration for more details. Here you enter a unique key to identify the application you want to debug, for example, the transaction identification for a specific transaction. You also enter the command to resume your application if one is required.
After you press Debug in the Configurations dialog, the debugger will wait on Data Queue Q5BTEMP/DYNAMICATT for that key. When your application reaches the point where you want to debug, it or its helper program will hold the application if necessary, and write the key and the number of the job you want to debug into the debugger data queue Q5BTEMP/DYNAMICATT. Once this key entry is available, the debugger reads it and gets the associated job number to start a debug session for this job.
When the debugger is ready, the provided command to resume the application will be issued to let your application continue running. If no resume command is provided, the debugger will attach to the job specified through the data queue interface.
The following is an example scenario.
Your application submits batch jobs to run programs. These jobs are all running under the same user profile. The submitted programs take a unique id as a parameter. You want to debug the job for a specific id. Your main application has an interprocess mechanism to get that id. To debug the job, you create an IBM i: Debug dynamic job configuration, specify the id as the key and enter the command to resume your held program. Then you run your application using the specified id. Your main application checks the id before it submits the job. If the id is the one you want to debug, it submits that job on hold, and writes the job number to the debug data queue. Your application also has a data file to remember the id and its corresponding job number for all jobs written to the debug data queue. To release the held program, take the id, find the job in the data file, and release the job.