Concatinated datasets

[A T & T Management]

How can one determine where a module is obtained from when the module is in a concatinated dataset list?
So for example you want to load module A and your dataset list is://modules  dd  disp=shr,dsn=hlq1.ds1     has modules qwert
//    dd  disp=shr,dsn=hlq1.ds2                 has modules asdf
//    dd  disp=shr,dsn=hlq2.ds5                 has modules zxcv
So now you would get in return that module A comes from hlq1.ds2

Thanks
Scott

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Steve Austin]

I have have used BLDL for this, it give the concatenation number.

--
This e-mail message has been scanned and cleared by Google Message Security
and the UNICOM Global security systems. This message is for the named
person's use only. If you receive this message in error, please delete it
and notify the sender.

[RCG]

Search order goes from the top (JOBLIB / STEPLIB) and indeed it finds the
module from the first library in the concatenation, if it doesn't find, it
searches next library, if it doesn't find, it looks out in your LNKLST,
LPALST etc and if it finds nowhere, S806 abend will be thrown

Regards,
Ravi

On Fri, Jul 16, 2021 at 7:17 PM A T & T Management <sve...@ameritech.net>
wrote:

[Steve Thompson]

zOS and Contents Supervisor does not throw. RTM will be entered w/ S806. If one does not have error recovery, one’s task will AB normally END [ABEND].

Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks


> On Jul 16, 2021, at 10:00 AM, RCG <rkcgow...@gmail.com> wrote:
>
> Search order goes from the top (JOBLIB / STEPLIB) and indeed it finds the

[Seymour J Metz]

DESERV in new code, BLDL in old code.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of A T & T Management [sve...@AMERITECH.NET]
Sent: Friday, July 16, 2021 9:46 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Concatinated datasets

[Seymour J Metz]

No. What happens depends on the macro and its parameters. Read up on, e.g., ERRET=.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of RCG [rkcgow...@GMAIL.COM]
Sent: Friday, July 16, 2021 9:59 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Radoslaw Skorupka]

W dniu 16.07.2021 o 15:46, A T & T Management pisze:

> How can one determine where a module is obtained from when the module is in a concatinated dataset list?
> So for example you want to load module A and your dataset list is://modules  dd  disp=shr,dsn=hlq1.ds1     has modules qwert
> //    dd  disp=shr,dsn=hlq1.ds2                 has modules asdf
> //    dd  disp=shr,dsn=hlq2.ds5                 has modules zxcv
> So now you would get in return that module A comes from hlq1.ds2

You said "module" so we can assume this is some form of JOBLIB, STEPLIB
or other concatenation.
However the answer is still "it depends" or "there is no universal method".
Of course the order or libraries is important - first duplicate will be
loaded.

But... what is your goal? What problem do you want to solve? The more
details, the better chance to find the answer. It can be as simple as
some small REXX code. Or complex...

Oh, maybe you want be sure the module A comes from library HLQ1.DS2?
What about RACF?
However usually it works the opposite way. I mean you can protect
ICKDSF, but you cannot (and you shouldn't) disallow to run someone's
program named ICKDSF or F1CK, or FORBIDDN, or whatever.


--
Radoslaw Skorupka
Lodz, Poland

[Tom Conley]

Scott,

ALLOC the files to your TSO session, then use DDLIST with the "M member
ddname" command to find the module.

Regards,
Tom Conley

[Charles Mills]

I am not sure that anyone has answered his question.. He understands search order and S806. I *think* what he is asking is this:

I write a program. It loads module A, quite successfully, from DD MODULES. MODULES is in fact a concatenation. Can my program determine programmatically at run time which DSN the module came from?

The BLDL answer comes close. If instead of just loading the module I were to first (or for that matter, later) do a BLDL then I could search the BLDL return list and find that MODULE was located in concatenation +2, and then there are other methods for finding the DSN's that make up the MODULE concatenation list.

But is there any way "after the LOAD"? IOW I have already loaded the module and now I want to learn the source. I don't know. Does CSVQUERY or similar return this info?

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of A T & T Management
Sent: Friday, July 16, 2021 6:47 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Concatinated datasets

How can one determine where a module is obtained from when the module is in a concatinated dataset list?
So for example you want to load module A and your dataset list is://modules dd disp=shr,dsn=hlq1.ds1 has modules qwert
// dd disp=shr,dsn=hlq1.ds2 has modules asdf
// dd disp=shr,dsn=hlq2.ds5 has modules zxcv
So now you would get in return that module A comes from hlq1.ds2

[Bob Bridges]

Wait, am I missing something? I have a REXX that takes a module name and DD
name and searches in the DD to tell me where it first finds that module. Is
that not reliable?

(In my case I use it with SYSPROC, SYSEXEC, ISPCLIB, ISPPLIB and the like.)

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* D'you call life a bad job? Never! We've had our ups and downs, we've
had our struggles, we've always been poor, but it's been worth it, ay, worth
it a hundred times I say when I look 'round at my children. -from _Of Human
Bondage_ by W Somerset Maugham */

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of
Seymour J Metz
Sent: Friday, July 16, 2021 11:01

No. What happens depends on the macro and its parameters. Read up on, e.g.,
ERRET=.

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of
RCG [rkcgow...@GMAIL.COM]
Sent: Friday, July 16, 2021 9:59 AM

Search order goes from the top (JOBLIB / STEPLIB) and indeed it finds the
module from the first library in the concatenation, if it doesn't find, it
searches next library, if it doesn't find, it looks out in your LNKLST,
LPALST etc and if it finds nowhere, S806 abend will be thrown

--- On Fri, Jul 16, 2021 at 7:17 PM A T & T Management

<sve...@ameritech.net> wrote:
> How can one determine where a module is obtained from when the module
> is in a concatinated dataset list?
> So for example you want to load module A and your dataset list
> is:
> //modules dd disp=shr,dsn=hlq1.ds1 has modules qwert
> // dd disp=shr,dsn=hlq1.ds2 has modules asdf
> // dd disp=shr,dsn=hlq2.ds5 has modules zxcv
> So now you would get in return that module A comes from hlq1.ds2

[Seymour J Metz]

The devil is in the details; I can't tell whether the code is reliable without looking at It. What I can say is that there are searches that do not cause an ABEND if the module is not found. The relevant text was "if it finds nowhere, S806 abend will be thrown", which is not true for, e.g., BLDL, DESERV, anything with an ERRET parameter.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Bob Bridges [robhb...@GMAIL.COM]
Sent: Friday, July 16, 2021 6:13 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Bob Bridges]

Oh, that. Ok. I thought you were saying that it might not find the first
module of the correct name -- might skip one DS, or look for the second
occurrence, or something.

---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313

/* You must be prepared to do some serious turning inward toward the life of
the imagination, and that means, I'm afraid, that Geraldo, Keith Obermann,
and Jay Leno must go. Reading takes time, and the glass teat takes too much
of it. -Stephen King advises aspiring writers to read a lot; from _On
Writing_ */

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of
Seymour J Metz
Sent: Friday, July 16, 2021 18:34

The devil is in the details; I can't tell whether the code is reliable
without looking at It. What I can say is that there are searches that do not
cause an ABEND if the module is not found. The relevant text was "if it
finds nowhere, S806 abend will be thrown", which is not true for, e.g.,
BLDL, DESERV, anything with an ERRET parameter.

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of
Bob Bridges [robhb...@GMAIL.COM]
Sent: Friday, July 16, 2021 6:13 PM

Wait, am I missing something? I have a REXX that takes a module name and DD
name and searches in the DD to tell me where it first finds that module. Is
that not reliable?

(In my case I use it with SYSPROC, SYSEXEC, ISPCLIB, ISPPLIB and the like.)

[Lennie Dymoke-Bradshaw]

Charles,

You said " But is there any way "after the LOAD"? ".

I think this is spot on. You have pinpointed where there is a error in thinking. Determining what did happen (several thousand instructions ago) is not reliably possible in this case. Several things could have happened in the intervening period, such as
1. The set of concatenated libraries being changed (i.e. libraries added or removed).
2. The libraries in the concatenated set being altered (i.e. modules being added, removed or changed).

I think the only reliable way to determine which library was used is to ensure the process of returning the module passes that information at the time the module load is performed. At present, I don't think that capability is supplied by LOAD, LINK, etc. Maybe we should request IBM to supply that service.

Lennie Dymoke-Bradshaw
https://rsclweb.com
‘Dance like no one is watching. Encrypt like everyone is.’

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Charles Mills
Sent: 16 July 2021 18:00
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Michael Stein]

On Fri, Jul 16, 2021 at 06:13:13PM -0400, Bob Bridges wrote:
> Wait, am I missing something? I have a REXX that takes a module name and DD
> name and searches in the DD to tell me where it first finds that module. Is
> that not reliable?

It may be reliable for where a future fetch would find the module but it
doesn't tell you where a module already in storage came from.

Perhaps it was loaded with DCB= from some other file which isn't
open or allocated anymore?

Perhaps it is duplicated in the concatenation and someone did something
funky with the DE= operand Z (concatenation) value and loaded the 2nd one
(bit of a problem to get the rest of the BLDL info needed).

Perhaps it's the result of an IDENTIFY.

Or something else?

[Charles Mills]

Yeah, it is one of those problems that seems like it should have a simple
answer "what DSN was this module loaded from? How hard is that?" but in
reality has unlimited subtleties.

If you care, I think you have to use BLDL and keep track yourself.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On

Behalf Of Michael Stein
Sent: Friday, July 16, 2021 6:36 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Paul Gilmartin]

On Fri, 16 Jul 2021 18:59:03 -0700, Charles Mills wrote:

>Yeah, it is one of those problems that seems like it should have a simple
>answer "what DSN was this module loaded from? How hard is that?" but in
>reality has unlimited subtleties.
>

Sounds like an RFE candidate. CSV should preserve the needed information
and provide an API to access it.

What about LPA? Original data set and member?

What should happen if the program object is replaced in the interim?
Ideally, PDSE should keep a connection to the original instance until
CSV DELETE, so very little. FETCHOPT(NOPRIME) requires something
like that.

It's possible (PGM=HEWLKD) to create an executable in storage
directly from SYSLIN, never creating a program object on DASD.

An authorized program can IDENTIFY an entry point in storage which has
not been fetched from a program object.

How should program objects fetched from UNIX files be reported?

-- gil

[Greg Price]

On 7/18/2021 3:32 AM, Paul Gilmartin wrote:
> On Fri, 16 Jul 2021 18:59:03 -0700, Charles Mills wrote:
>
>> Yeah, it is one of those problems that seems like it should have a simple
>> answer "what DSN was this module loaded from? How hard is that?" but in
>> reality has unlimited subtleties.
>>
> Sounds like an RFE candidate. CSV should preserve the needed information
> and provide an API to access it.
>
> What about LPA? Original data set and member?
>
> What should happen if the program object is replaced in the interim?

Yeah, but...

CSVQUERY gives you access to all that.

The only thing you can't find out is which library in the LPALST a
specific module in PLPA came from. With some poetic license (assume that
the LPALST libraries are cataloged and have not changed since CLPA time)
then you can search that yourself.

Also, GETMAINed chunks of storage which are subsequently declared as a
program to the system have no information about from whence they came.

If the provider is AOSL then you know it came from the program loader
and was not fetched directly from a data set.

For UNIX a pointer to the path name is available. If the UNIX program
has been replaced or deleted since then then I guess you can't go look
at it any more. For PDS/PDSE then you can compare the TTR (MLT) with the
TTR (MLT) in the PDS/PDSE to verify if it is the same if you really want
to obsess about it.

But most of the time you just want to know where it came from (whether
or not it is current, because presumably it was current at fetch time)
so most of that extra stuff can be ignored. Program size is also a good
ad hoc test for program level matching.

Cheers,
Greg

[Mario Bezzi]

Greg that's very interesting.. Could you please point me at the doc
which explains how to get there? I have been reading the description of
the CSVQUERY services, but while I see an OUTPATHNAM option, I can't
find anything about the source loadlib for a regular load module.

Thank you!
mario

On 7/18/21 4:12 PM, Greg Price wrote:
> Yeah, but...
>
> CSVQUERY gives you access to all that.

[Seymour J Metz]

> HEWLKD

Where is that EP documented.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________

From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>
Sent: Saturday, July 17, 2021 1:32 PM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Paul Gilmartin]

On Mon, 19 Jul 2021 14:12:21 +0000, Seymour J Metz wrote:

>> HEWLKD

>Where is that EP documented.
>

My typo. HEWLKED. Mentioned sparsely in Program Management User's Guide.
Strangely, more extensive mentions in SMP/E material.

Accepts in SYSLIN concatenated:
o Object (SYSPUNCH) files
o Load Modules.

Does not accept:
o Commands
o GOFF objects
o Program Objects.

Feels obsolescent.

________________________________________
From: Paul Gilmartin

Sent: Saturday, July 17, 2021 1:32 PM

...

It's possible (PGM=HEWLKD) to create an executable in storage
directly from SYSLIN, never creating a program object on DASD.

[Seymour J Metz]

HEWLKED is the Linkage Editor; it creates load modules on SYSLMOD; I don''t know of any way to make it direct its output to storage.

Were you thinking of the loader? HEWLD, HEWLDI, HEWLDIA, HEWLDRGO, IEWBLDGO , IEWLDRGO or LOADER?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f0781...@LISTSERV.UA.EDU>

Sent: Monday, July 19, 2021 11:52 AM

To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Concatinated datasets

[Rob Schramm]

Seems like Scott should tell us the Why. If you were just trying to
validate the correct module.. maybe signature would do it?

Rob

[A T & T Management]

Good morning all!
Just wanted to find out what the dataset name is from where a module is loaded from.  Now when in this case I say module I also say that it can be a parmlib entry in a concatenated PDS as well.
Scott

[Greg Price]

On 7/19/2021 3:43 AM, Mario Bezzi wrote:
> Greg that's very interesting.. Could you please point me at the doc
> which explains how to get there? I have been reading the description of
> the CSVQUERY services, but while I see an OUTPATHNAM option, I can't
> find anything about the source loadlib for a regular load module.

That precise facility is not documented as such... (AFAIK)

I'd recommend you get HCL Z Asset Optimizer (aka ZAO) where its Usage
Monitor component has done all that work for you. If your site runs IBM
Z Software Asset Management then that will also do it.

Basically, the plan is to ascertain the DD, and then chase the relevant
control blocks to determine the data set name.

CSVQUERY OUTPDATA often contains a DD name for load modules, and a
pointer of interest for program objects. I don't know what an FMD is,
but I imagine it is a Fetched Module Descriptor.

Cheers,
Greg

[Peter Relson]

<snip>

How can one determine where a module is obtained from when the module is
in a concatinated dataset list?
So for example you want to load module A and your dataset list is:
//modules dd disp=shr,dsn=hlq1.ds1 has modules qwert
// dd disp=shr,dsn=hlq1.ds2 has modules asdf
// dd disp=shr,dsn=hlq2.ds5 has modules zxcv
So now you would get in return that module A comes from hlq1.ds2

</snip>

As has been mentioned, BLDL and DESERV are the answers to the question of
"which numbered data set in this concatenation has A?".
Finding the data set name itself is more involved (perhaps using a service
such as RDJFCB).

<snip>But is there any way "after the LOAD"? IOW I have already loaded the

module and now I want to learn the source. I don't know. Does CSVQUERY or
similar return this info?

</snip>

z/OS itself does not, and will not, do anything to capture this
information as a general approach when it does the LOAD because z/OS has
no need for it and there would be negative performance ramifications of
locating the information.

Relying on the intentionally undocumented contents of CSVQUERY's OUTPDATA
is unwise. That parameter is provided so that the returned data can be
input to other services which are in synch with the implementation.

If you'd like a hint of something we might document in the future, with
data available today, it's the 8 byte data set key (CSVQUERY OUTDSKEY
keyword).
That consists of a 4-byte UCB address and the CCHH of the data set extent
(this is information retrieved from the DEB for the concatenation as
identified by BLDL/DESERV). It is possible to work with that data along
with additional info (such as the VTOC, I think) and determine the name of
the data set.

But the OP's use case is not limited to modules. Thus any CSVQUERY
information is not helpful in general. So doing it yourself via
BLDL/DESERV against the opened concatenation or using the approach Tom
Conley mentioned would work. I'd guess that many sites already have some
tool that can "locate" within an "opened DD" a member and tell you the
data set name in which the member lives.

Peter Relson
z/OS Core Technology Design