is there a way to determine the dataset that my running z/os assembler program is loaded from? If possible the entire steplib concatenation would be nice, but not necessary.
I presume you mean at runtime from within your software - this is pretty easy to do from a system dump after the fact.
The shortest path is usually BLDL...it searches steplib, lnklst, etc and gives you back a directory entry and an indication of whether the module was found in steplib or not. Now your challenge is just to translate the BLDL output directory entry to a dataset name.
If your module is from STEPLIB, then the first byte of the BLDL output contains a concatenation number...with this information, you'd find the TIOT for your task (PSATOLD->TCBTIO), then the TIOENTRY for STEPLIB, then index into this array by the concatenation number. Now you're at the TIOENTRY for the specific STEPLIB concatenation dataset containing your module, you'd just pick up the JFCB address (or SWA token) and voila - there's your dataset name.
Note that STEPLIB doesn't actually have to be "STEPLIB"...you can use pretty much any DDNAME you want. TSO does this - dynamically allocates the load library, and this gives you DDNAMES of SYS*. This is sometimes called "tasklib" and it presents a few challenges as well.
The specifics are different for modules loaded from LNKLST, LPA, MLPA, etc. Same basic concepts though.
Also note that this method isn't 100% bulletproof in that it doesn't truly tell you where your module came from...rather, it tells you where it is right now, which may not always be the same thing (for instance, imagine someone linking a new copy of your program into a dataset ahead of yours in your STEPLIB concatenation...you were loaded from "A", but this method might tell you "B").
If your executable happens to be a UNIX pathname, then the task is actually a bit simpler, since CSVQUERY will tell you what you want. Indeed, you might want to prefix your BLDL with a call to CSVQUERY to get information like your entry point name and so forth.
Sophisticated subsystems (CICS comes to mind) might do strange things when managing programs, so these techniques might not work as you expect once you drift away from batch or TSO environments. Best bet is to get yourself a dump and walk through some of these chains using IPCS until it becomes clear how to do what you want...the code isn't that much once you figure out what points to what.
Good luck!