I (Charles Mills) can guess the DD name after the fact because I can look at the allocation messages in the JOB output.
My program does not know the DD name at run time. I (CM) assume it is still allocated because the vendor product has no way of knowing whether my program intends to load additional modules that are part of my solution (it doesn't). My product was written with the general idea that it would be run as a jobstep program. Some customers choose to wrap another vendor tool around it. That complicates my life, but is not fatal. The vendor tool has no specific relation to the problem I am trying to solve today, or rather, the feature I am considering implementing (it just complicates it). I am trying to give customers the option of parametizing my program's behavior based on what library the program was loaded from. The customer(s) are used to obtaining different program behavior (versions and customization) by installing multiple instances of a product in different load libraries - I am sure most readers of this forum have used a similar technique. My product replaces the products the customer is now using. I would like to have different behavior based on a centralized parameter file, not on disparate installations. But we need to accommodate the customer culture. I would like to *offer* different behaviors based on different load libraries. I would like to the customer to be *able* to say "if you find yourself loaded from this library do this; if from that library, do that." I hear you, Chris. The private library problem may not be solvable. I don't need a complete solution. It's an additional option for the customer. Assuming I can do a decent job, I will offer customers the option, even if it is not the solution in every situation. The feature is not fundamental to the product; it's not worth adding a whole lot of complexity to do a 98% job rather than a 90% job. I may have to say "this particular option is largely incompatible with vendor product X, under which all load libraries appear to this product to be named 'private.load.library'." Thanks again, Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Monday, August 15, 2005 7:22 AM To: [email protected] Subject: Re: How tell name of originating load library? > ALSO ... It looks like private libraries (LOAD from specified DCB) may > be an issue in some cases. The DD name appears to be a SYSnnnnn name > from dynamic allocation so it's essentially unknown. Any suggestions or > clues on how one could get from entry point name to load library name in > that situation? I am slightly confused. If you know the DDNAME, assuming the DDNAME is still allocated and to the same library/libraries (one of the gotchas I alluded to earlier) then you can just point a DCB (DSORG=PO,MACRF=E) at it, OPEN it for INPUT and bang away with BLDL. Getting the DSNAME is then a relatively simple task. Perhaps I am missing something? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
