Re: Name of a program's library

[Peter Relson]

In general, it is not possible.

For many cases, the approach of mimicking the system's search order and
doing BLDL's with RDJFCB will help.

Here are some (not all) cases that don't work
-- module was located via some DCB associated with an opened DD that is no
longer open
-- module was in MLPA / FLPA

Any approach that tries to do at least the best job it can must account
for
-- all tasklibs
-- steplib/joblib
-- LPA
-- LNKLST

Peter Relson
z/OS Core Technology Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

Just doing blue skying here, but I wonder if it would be possible to enhance FETCH or the LLE(?) to contain the actual DSN/VOLSER of the dataset used. That would only require 44+6 extra bytes of memory. Which I don't think is a big deal in today's environment. Of course, there is backward compatability concern and cost to code and test, so would it have a decent ROI?
________________________________________
From: IBM Mainframe Discussion List [IBM-...@bama.ua.edu] On Behalf Of Peter Relson [rel...@US.IBM.COM]
Sent: Thursday, September 30, 2010 6:41 AM
To: IBM-...@bama.ua.edu
Subject: Re: Name of a program's library

[Bill Fairchild]

An unauthorized program can OPEN a BPAM, BSAM, QSAM, or BDAM DCB to the load library, search the directory without using FIND or BLDL, find the beginning TTR of the needed module, READ/GET that module into virtual storage, CLOSE the DCB, and hours later branch to the module. Of course, there will be no system control blocks built for this module (CDE, etc.) by this unauthorized program. And, to be truly pathological, the data set could have been renamed or deleted before the load module is executed, so even if it was LOADed and managed using only standard system services, the DSN stored in the LLE could be down level.

The best time to save the info would obviously be at the moment the module is LOADed, but the info could not be guaranteed to be correct later when the module executes. If it is so critical that the load module know exactly from where it came, then perhaps the load module should be compiled with some unique identifier in it that is displayed rather than its dubious data set name from whence it maybe came.

Bill Fairchild
Rocket Software

[William M Klein]

Responding to the last note in this thread,

>original message<

Just doing blue skying here, but I wonder if it would be possible to enhance
FETCH or the LLE(?) to contain the actual DSN/VOLSER of the dataset used.
That would only require 44+6 extra bytes of memory. Which I don't think is a
big deal in today's environment. Of course, there is backward compatability
concern and cost to code and test, so would it have a decent ROI?

>end original message

Every time this topic comes up (and it does fairly often), I again remind
people of the existing SHARE requirement:

SSLNGC0313587 New LE Callable Service to get (various) Program Names

A new LE callable service (with capabilities well beyond CEE3GRN) should be

created to obtain various program names. This should include options to
obtain:

- The currently executing program's name

- The name of the program that "activated" (Called, Invoked, whatever) the

currently executing program

- The name of the program at the "top" of the current LE "enclave"

- The name of the program at the "top" of the current LE "thread"

For each of these, sub-options may be required to provide information such
as

- Any "alias" by with the program was entered

- Any "long-name" (with mixed characters) as supported by the Binder

- Any Entry-point name when other than the modules name

Finally, although not necessarily a part of this callable service, it would

also be desirable to be able to obtain the "data set name" (HFS, PDS, PDSE,
LPA

member, or whatever) from which each of these entities was obtained.

* * * * * * *

Once again, I will remind all IBM-MAIN watchers that *IF* this functionality
is really important to you and as IBM doesn't seem to be progressing the
existing SHARE requirement very quickly, that you can (and should) submit an
IBM marketing REQUEST and reference the existing SHARE requirement.

[Fred van der Windt]

> Every time this topic comes up (and it does fairly often), I
> again remind people of the existing SHARE requirement:
>
> SSLNGC0313587 New LE Callable Service to get (various) Program Names
>
> A new LE callable service (with capabilities well beyond
> CEE3GRN) should be
>
> created to obtain various program names. This should include
> options to
> obtain:
>
> - The currently executing program's name
>
> - The name of the program that "activated" (Called,
> Invoked, whatever) the
>
>
> currently executing program
>
> - The name of the program at the "top" of the current LE "enclave"
>
> - The name of the program at the "top" of the current LE "thread"
>
> For each of these, sub-options may be required to provide
> information such as
>
> - Any "alias" by with the program was entered
>
> - Any "long-name" (with mixed characters) as supported by the Binder
>
> - Any Entry-point name when other than the modules name
>
> Finally, although not necessarily a part of this callable
> service, it would
>
> also be desirable to be able to obtain the "data set name"
> (HFS, PDS, PDSE, LPA
>
> member, or whatever) from which each of these entities was obtained.

A lot of this information is available via CEETBCK and CEEYEPAF. But I too would appreciate a convenient way to retrieve the dataset name a module was loaded from...

Fred!
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

[john gilmore]

This topic is a recurrent one.

Bill Fairchild is only the most recent poster to make it clear clear 1) that this question does not always have an answer and 2) that when it does have an answer that answer may be ambiguous, obsolete/non-current, or wrong.

It is important that these limitations be understood: no general solution to the problem of determining the name of the library from which a load module or program object was brought into storage is possible. Moreover, if this information were crucial in some situation it would be easy for a knowledgeable and disingenuous person to trick any mechanism provided for obtaining it.

These important things said, there are situations in which such information is routinely useful.

I, for example, often need to know, during an assembly, the name of the data set to which the assembler is writing SYSADATA output; and the HLASM provides a mechanism for me to obtain it: the system variable symbol &SYSADATA_DSN contains this DSN.

Similar local and specific mechanisms are easy to provide in other environments, and where it is at all appropriate to do so they should be provided. One obvious question to ask is

Will the sky fall if the information this mechanism provides is unavailable or wrong?

If the answer to this question is yes, then such a mechanism should not be provided.

John Gilmore Ashland, MA 01721-1817 USA

[Tony Harminc]

On 30 September 2010 07:52, McKown, John <John....@healthmarkets.com> wrote:
> Just doing blue skying here, but I wonder if it would be possible to enhance FETCH or the LLE(?) to contain the actual DSN/VOLSER of the dataset used. That would only require 44+6 extra bytes of memory.

UNIX files...?

Tony H.

[Tom Marchant]

On Thu, 30 Sep 2010 06:52:22 -0500, McKown, John wrote:

>Just doing blue skying here, but I wonder if it would be possible
>to enhance FETCH or the LLE(?) to contain the actual DSN/VOLSER
>of the dataset used.

I suppose that might be possible if the data set was loaded from LNKLST.
It would be __much__ more difficult if the program that issued the LOAD
passed an open DCB to use.

--
Tom Marchant

[McKown, John]

OUCH - totally forgot. And UNIX program names can be very long as well as the path to them. RATS!
________________________________________
From: IBM Mainframe Discussion List [IBM-...@bama.ua.edu] On Behalf Of Tony Harminc [to...@HARMINC.NET]
Sent: Thursday, September 30, 2010 9:15 AM

To: IBM-...@bama.ua.edu
Subject: Re: Name of a program's library

On 30 September 2010 07:52, McKown, John <John....@healthmarkets.com> wrote:

[Mike Schwab]

Include a hand entered or compiler timestamp and slightly modify the
low end value (zap) after copying to other load modules?

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[Peter Relson]

>I wonder if it would be possible to enhance FETCH or the LLE(?)
>to contain the actual DSN/VOLSER of the dataset used. That would
>only require 44+6 extra bytes of memory. Which I don't think
>is a big deal in today's environment.

Possible, sure? Gonna happen? Not too likely.

The control block size increase might or might not be problematic, but the
more pressing point is whether you think the customer is going to be
willing to sacrifice the cycles it takes to determine this information.

The information that is fairly easily (i.e., quickly) accessible is the
data from the DEB about the data set (UCB address and "CCHH").

[Rick Fochtman]

--------------------------------<snip>---------------------------------

>>I wonder if it would be possible to enhance FETCH or the LLE(?)
>>to contain the actual DSN/VOLSER of the dataset used. That would
>>only require 44+6 extra bytes of memory. Which I don't think
>>is a big deal in today's environment.
>>
>>
>
>Possible, sure? Gonna happen? Not too likely.
>
>The control block size increase might or might not be problematic, but the
>more pressing point is whether you think the customer is going to be
>willing to sacrifice the cycles it takes to determine this information.
>
>The information that is fairly easily (i.e., quickly) accessible is the
>data from the DEB about the data set (UCB address and "CCHH").
>
>

------------------------------<unsnip>-------------------------------
Not to mention one other aspect: can you present a good BUSINESS case
for it? Does the customer need it to support his core business?

Rick

[Etienne Thijsse]

Thanks, Eileen, for showing me the way. I have been able to create a C
program that calls a few assembler modules to do the BLDL call to get the
STEPLIB concatenation nr, and then the RDJFCB call to get the dataset name.
It was a bit complicated because the C program is 31 bit and RDJFCB must use
24-bit addresses, so I've had to create my own version of __malloc24(), which
C functions don't work in 31 bit mode eventhough that fact is not
documented :-(.

So now a submitted program can find out the name of its own library by
looking at STEPLIB. The next thing to do is figure out how the program can do
the same when called from TSO using the CALL 'HLQ.LIB(PROG)' command. Any
ideas?

Thanks,

Etienne

[Binyamin Dissen]

On Wed, 6 Oct 2010 09:18:41 -0500 Etienne Thijsse <e.th...@CHELLO.NL> wrote:

:>Thanks, Eileen, for showing me the way. I have been able to create a C

:>program that calls a few assembler modules to do the BLDL call to get the
:>STEPLIB concatenation nr, and then the RDJFCB call to get the dataset name.
:>It was a bit complicated because the C program is 31 bit and RDJFCB must use
:>24-bit addresses, so I've had to create my own version of __malloc24(), which
:>C functions don't work in 31 bit mode eventhough that fact is not
:>documented :-(.
:>
:>So now a submitted program can find out the name of its own library by
:>looking at STEPLIB. The next thing to do is figure out how the program can do
:>the same when called from TSO using the CALL 'HLQ.LIB(PROG)' command. Any
:>ideas?

Instead of STEPLIB, look at the DCB address in TCBJLB. If called via

CALL *(PROG)

you will need to run the TCB chain and if not there, check Linklist.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Barkow, Eileen]

I do not know the DDNAME that TSO CALL uses for the pgmlib allocation, but these
routines may be used to find all of the PDS' allocated to the TSO address space.

***routine LOCDEBS locates the DEB for all datasets allocated to the region and saves the addresses in a table along with the DDNAME corresponding to the DEB (obtained from the TIOT).
** the DCBs and corresponding TIOT entries are retrieved to find the DDNAME of the dataset..
**it is particularly interested in ddname=sysproc.

**later. routine SRCHSDEB is called for each saved DEB address to get the DCB'S for BLDL.

LOCDEBS DS 0H GET LIST OF DDNS
USING *,LINKREG
STM 14,12,SAVELINK+12
L 1,=A(DDNTAB)
ST 1,LASTTAB
MVI 0(1),X'FF'
MVI TEMPSW,X'00'
L 1,16 CVT
L 1,0(1) ADDR OF TCB POINTER
L 1,4(1) ADDR TCB
LR TCBREG,1
USING TCB,TCBREG
USING DEBBASIC,DEBREG
L TIOTREG,TCBTIO TIOT
ST TIOTREG,TIOTADDR
ST TIOTREG,BEGTIOT
LA TIOTREG,TIOTOFF(TIOTREG)
L JSCBREG,TCBJSCB
USING IEZJSCB,JSCBREG

L 1,TCBDEB DEB
DROP JSCBREG,TCBREG

LR DEBREG,1
ICM DEBREG,8,=X'00'

LTR DEBREG,DEBREG
BZ ENDLDEB

ST DEBREG,DEBADDR
B LOCDCB
NEWDEBQ DS 0H

NEWDEBAD DS 0H
L DEBREG,DEBDEBAD NEXT DEB
CLM DEBREG,7,=XL3'000000' ANY DEB
BE ENDLDEB
CLM DEBREG,1,=X'FF' INVALID ADDR
BE NEWDEBQA
ST DEBREG,DEBADDR
B LOCDCB
NEWDEBQA DS 0H
B NEWDEBAD
LOCDCB DS 0H
L DCBREG,DEBDCBAD ADDR DCB
USING IHADCB,DCBREG
TM DCBDSORG,DCBDSGPO PARTITONED DATA SET?
BNO NEWDEBQ NO..NEXT DEB ENTRY
TM DCBOFLG,DCBOFOPN DATA SET OPEN?
BO SETTIOT YES...
MVC WORKDDN,DCBDDNAM SAVE DD NAME
B SETTAB
SETTIOT DS 0H
LH 0,DCBTIOT OFFSET IN TIOT FOR THIS DCB
L 1,BEGTIOT BEG OF TIOT
AR 1,0 TIOT ADDR FOR THIS ENTRY
LR TIOTREG,1
USING XIOT,TIOTREG
MVC WORKDDN,XIOEDDNM DDN
B SETTAB YES
SETTAB DS 0H STORE DDN IN LIST
USING TABSECT,1
L 1,LASTTAB
MVC DDNDSNAM,WORKDDN
ST DEBREG,DDNDEB
ST TIOTREG,DDNTIOT
DROP 1
LA 1,TABL(1)
ST 1,LASTTAB

MVI 0(1),X'FF'
CLI TEMPSW,X'00'
BNE ENDLDEB
B NEWDEBQ
CHKSPROC DS 0H CHECK IF DEB FOR SYSPROC FOUND
L 1,=A(DDNTAB)
USING TABSECT,1
COMPPROC DS 0H
CLI 0(1),X'FF'
BE GETSPROC
CLC DDNDSNAM,=CL8'SYSPROC'
BE ENDLDEB
LA 1,TABL(1)
B COMPPROC
DROP 1
GETSPROC DS 0H ASSUME SYSPROC ALLOCATED
OPEN (SYSPROC,INPUT)
LTR 15,15
BNZ ENDLDEB
LA DCBREG,SYSPROC
L DEBREG,DCBDEBAD
MVI TEMPSW,X'FF'
MVC WORKDDN,=CL8'SYSPROC'
B SETTIOT
ENDLDEB DS 0H
LA 1,SYSPROC
TM DCBOFLGS-IHADCB(1),DCBOFOPN SYSPROC OPENED?
BNO ENDLDEBC
CLOSE SYSPROC
ENDLDEBC DS 0H
LM 14,12,SAVELINK+12
BR RET
LASTTAB DS F
SYSPROC DCB DDNAME=SYSPROC,DSORG=PO,MACRF=(R)
TEMPSW DS X
LTORG

***** for each DEB located in routine LOCDEBS, get the DCB for PDS datasets only and issue BLDL to see if ***module is in it.
SRCHSDEB DS 0H
USING *,LINKREG
STM 14,12,SAVELINK+12
NI TSOSW,255-TSOFILE
L 15,CURDDN
USING TABSECT,15
L DEBREG,DDNDEB
USING DEBBASIC,DEBREG
L DCBREG,DEBDCBAD ADDR DCB
USING IHADCB,DCBREG
TM DCBDSORG,DCBDSGPO PARTITONED DATA SET?
BNO ENDSJSCB NO..RETURN
MVC WORKDDN,DDNDSNAM
ST DCBREG,DCBADDR DCB
MVC BLDLNUM,=H'1' 1 ENTRY
MVC BLDLLEN,=AL2(BLDLELEN) LEN OF EACH ENTRY
MVC BLDLNAME,WORKPROG
LR 2,DCBREG
LA 0,BLDLLIST
BLDL (2),(0)
LTR 15,15
BNZ ENDSJSCB
OI TSOSW,TSOFILE
NI TSOSW,255-SRCMOD
TM DCBRECFM,DCBRECU UNDEFINED RECFM
BO ENDSJSCB ASSUME LOAD MODULE
* TM DCBRECFM,DCBRECF FIXED BLOCK FILE
* BNO ENDSJSCB ASSUME SOURCE MODULE
OI TSOSW,SRCMOD
B ENDSJSCB
ENDSJSCB DS 0H
LM 14,12,SAVELINK+12
BR RET
LTORG
DROP LINKREG,15,DEBREG,DCBREG

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Binyamin Dissen
Sent: Wednesday, October 06, 2010 10:34 AM
To: IBM-...@bama.ua.edu
Subject: Re: Name of a program's library

[Shmuel Metz , Seymour J.]

In
<A826B9FD78356242A9D95...@DOITTMAIL03.doitt.nycnet>,
on 10/08/2010

at 10:39 AM, "Barkow, Eileen" <EBa...@DOITT.NYC.GOV> said:

>I do not know the DDNAME that TSO CALL uses for the pgmlib
>allocation,

Generated and returned by DYNALLOC.

>***routine LOCDEBS locates the DEB for all datasets allocated to the
>region

No; it finds the DEB's for all open datasets in the current task.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)