I believe that when a program issues a STOP to chain to another program, it works very similar to the way that the EXEC command does in shell scripts. The original process is terminated and a new one is spawned. Howeer, all of that occurs witin the DBR runtime without recreating a new runtime process because it's effectively a data file to the runtime. STOP'ing to another filename.dbr effectively closes the handle to the current, opens the next one.
In fact, when you run DBR without any parameters, it asks for the filename.dbr to run. When you pass the filename.dbr on the command line, it takes the filename prompt away. So, you can even have DBR processes without ANY parameter indicating what it was running.
So, this effectively means that the original DBR command line is visible via PS AUX (with or without a filename.dbr) but the current filename.dbr may actually be something different. There is no way for PS to know this because it's a data file really, not a command line argument to the program.
The way you could check that out on Linux is using lsof and looking for the filename.dbr that it is has a lock on. There should really only be one per DBR process. The best method of doing this is just use lsof to find all handles of .dbr, Here is an example of a one liner to get a CSV output of process ID, command and file open
lsof -c /dbr/i -Fpcn | grep -iE "((^p.*)|(^c.*)|(^n.*.dbr))" | tr '\n' ',' | sed -e 's/,p/\np/g' | sed -e 's/,$//g' | sed -e 's/^p//g' | sed 's/,[cn]/,/g'
This would produce output such as:
The one caveat to this, lsof is likely to need superuser level access to obtain all the file handles. Your best bet would be to write a script that produces the above and allow it to self-elevate via sudo, make the script owned by root, readable by group/world. Then have a file in /etc/sudoers.d/ that allows sudo access with no passwd to that script. (You can test $EUID under bash for the effective user ID vs $UID actual user ID).