Hi Guys,

Thank you for your quick responses! Let me try to respond to each (I had responded immediately then my response was eaten by the Resource Center because it timed out then I didn?t feel like rewriting everything):

Bill,

We had debated using this modname() trick, however the end result is the same as JBNAM in that it returns the name of the main method (we have issues where we have numbers at the first part of the dbr name which means we can't use it as the name of the main method).

Jerry,

Our current solution uses CMDLN however the complexity involved in the parsing of this command line broke our original implementation. I argue that it was broken from the beginning as it did not support all possible valid permutations to DBR/DBS (this only uncovered itself when the full path to the DBR was passed instead of using Logicals and the "Naked" remote debugger port switch), but that is neither here nor there, the lesson is more comprehensive test cases are needed.

While we can fix it we're looking for something built into the base class library, if this had been C# this most likely would have been the correct API to use:

    https://msdn.microsoft.com/en-us/library/system.appdomain.friendlyname.aspx

        This is only if you're not doing something exotic where you're spinning up your own app domains within the same executable in which case the correct solution would be:

    https://msdn.microsoft.com/en-us/library/system.diagnostics.process.processname.aspx

Basically we need DBL Equivalents to the above.

But Ace why can't we p/invoke these? I do not believe p/invoke will return what I want, beyond the performance penalty of spinning up the .NET Framework, ProcessName is most likely going to return dbr.exe/dbs.exe which is not what we need.

Long story short we went down the path of correcting our parser code we wrote; but it?d be really slick to utilize something built into the API and delete a bunch of our code and have it "just work" the next time.