0

is it possible to get the the path where the program was called from? I call the program on z/Os like this call 'MCOE.XXXXXXXX.C.LOAD(args)' 'hi there'

My intention is to get the MCOE.XXXXXXXX.C.LOAD dataset in called program without specifying this path as a parameter. Thanks! PetrS

Petr Sedláček
  • 25
  • 3
  • How about `argv[0]`? – Filipe Gonçalves Apr 21 '15 at 13:51
  • Hi Filipe, argv[0] contains only program name. In my case "args". – Petr Sedláček Apr 21 '15 at 14:38
  • What is the problem you are trying to solve? I understand you want the name of the library from which your program was loaded, but *why*? – cschneid Apr 21 '15 at 22:12
  • I'm thinking about getting the library name to identify later the whole program environment like MCOE.XXXXXXXX.C.PARMLIB for example. – Petr Sedláček Apr 22 '15 at 06:42
  • 1
    I suspect you need the CSVINFO interface documented in the Assembler Services Guide. Since this doesn't sound like a requirement but seems to fall into the "nice to have" category, I'd think a bit harder about how nice it is to have. – cschneid Apr 22 '15 at 11:26
  • Hi cschneid, Another example sounds more like a requirement is to add this library under ISPLLIB using LIBDEF command to invoke another load module called by ISPF. Thanks for the tip. I'll look closer to CSVINFO. – Petr Sedláček Apr 22 '15 at 14:48

1 Answers1

0

This is a non-trivial exercise, but it can generally be done.

You'd start by using CSVINFO to get some information about your program, and then the trick is to emulate the search z/OS would have done to find your module...private/task library, STEPLIB/JOBLIB, (M)LPA search, LNKLST, etc - once you know the load module name definitely (your "args" program name might be an alias, or something the caller setup with an IDENTIFY macro), you can get a lot of this with BLDL, assuming you know which DCB to use.

Once you figure out the DDNAME and concatenation number (after all, there might be 10 libraries in your STEPLIB!), you'd scan the allocation data structures to get the actual dataset name. Typically, this is done by traversing the data structures in memory (PSATOLD->TCBTIO, then indexing into the TIOT till you find the entry you want...the matching TIOT entry will have a pointer to the JFCB - or a SWA manager token - that you can use to get the JFCB, and the JFCB has the dataset name and all the other details you want).

In the case of a fetch from LNKLST, you have extra work to figure out exactly which dataset in the LNKLST concatenation you were fetched from. Again, possible but it requires a bit of finesse.

If your program happens to be in (M)LPA, I'm not sure you can reliably retrieve the original dataset name it was fetched from - this might be the worst case, although there are no doubt a variety of other potential challenges, such as dealing with UNIX Services executable pathnames.

Good luck if you decide to give it a try!

Valerie R
  • 1,769
  • 9
  • 29
  • I don't know the first thing about z/Os but my god, this sounds awful. – Jonathon Reinhart Jun 11 '15 at 01:27
  • 1
    To someone who lives in the mainframe world, it's not a big deal...not that much different than, say, a kernel developer writing device drivers on some other platforms. The sad thing is that serious mainframe developers are a dying breed and thee doesn't seem to be a next generation coming up behind them. – Valerie R Jun 15 '15 at 19:33