Re: Concatenated datasets

[Peter Relson]

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


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). 

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?


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


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

Re: Concatenated datasets

[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

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

Re: Concatenated datasets

[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.


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

Re: Concatenated datasets

[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

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

Re: Concatenated datasets read information.

[Art Celestini]

At 08:44 PM 9/15/2015, Shmuel Metz (Seymour J.) wrote:
 
>In

Re: Concatenated datasets read information.

[Charles Mills]

> Depending on how often you want to do this (every record?)

Couldn't you just save off DCBTIOT and compare it before (after?) every GET?
If DCBTIOT changed then go through the whole drill below, else not?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Art Celestini
Sent: Wednesday, September 16, 2015 6:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatenated datasets read information.

At 08:44 PM 9/15/2015, Shmuel Metz (Seymour J.) wrote:
 
>In
>

Re: Concatenated datasets read information.

[Shmuel Metz (Seymour J.)]

In <039701d0f08d$2138cd10$63aa6730$@mcn.org>, on 09/16/2015
   at 07:36 AM, Charles Mills  said:

>Couldn't you just save off DCBTIOT and compare it before (after?)
>every GET?

Yes if you've set unlike attributes, not otherwise. Curse OCO!
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Concatenated datasets read information.

[Shmuel Metz (Seymour J.)]

In <20150916131602.7f3503e0...@listserv01.ua.edu>, on 09/16/2015
   at 09:15 AM, Art Celestini  said:

>As Chris Blaicher indicated, find the TIOT entry using DCBTIOT and
>TIOEJFCB will contain an SVA for the JFCB. 

In a concatenation there are multipkle TIOT entries; you need to fiind
the right one. Unless you are using the unlike attributes option,
DCBTIOT points to the first entry. In the general case you need to
know the control block structure, which is no longer available to
normal users.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Concatenated datasets read information.

[Shmuel Metz (Seymour J.)]

In

Re: Concatenated datasets read information.

[Massimo Biancucci]

Thanks to everybody for the ideas.

I don't know exactly what the application programmers need, they asked me
to know if there's a possibility.

I'll investigate deeper to understand if it's a real need and if the
solutions you proposed are applicable.

>From my side it's a bit intriguing to know more . If really needed
maybe IEFDDSRV service could help using the field where zOS stores the
number of EXCP (DevIOEXCPCount), even though I think it could be expensive
from a CPU point of view cause there's the need to check values at every
read record.

Thanks again.
Massimo

2015-09-14 19:03 GMT+02:00 Blaicher, Christopher Y. <cblaic...@syncsort.com>
:

> I don't remember, but is the DCBTIOT pointer updated for each
> concatenation?  If it is, then using the TIOT you can get to the JFCB which
> gives you the DSNAME.
>
> Chris Blaicher
> Technical Architect
> Software Development
> Syncsort Incorporated
> 50 Tice Boulevard, Woodcliff Lake, NJ 07677
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Monday, September 14, 2015 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Concatenated datasets read information.
>
> On 2015-09-14, at 10:18, Chris Hoelscher wrote:
>
> > I do not know if this is a valid solution - but something I have done
> > In the jcl - between each dsn in the dd concatenation, Place a dd *
> > with some literal value like END OF DD 1
> >
> > FILE1 DD DISP=SHR,DSN=MYDSN
> >DD *
> > END OF 1
> >   DD DISP=SHR,DSN=MYDSN2
> > ...
> Good idea.  But, attribute compatibility?
>
> I hate MVS!
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
>
>
> ATTENTION: -
>
> The information contained in this message (including any files transmitted
> with this message) may contain proprietary, trade secret or other
> confidential and/or legally privileged information. Any pricing information
> contained in this message or in any files transmitted with this message is
> always confidential and cannot be shared with any third parties without
> prior written approval from Syncsort. This message is intended to be read
> only by the individual or entity to whom it is addressed or by their
> designee. If the reader of this message is not the intended recipient, you
> are on notice that any use, disclosure, copying or distribution of this
> message, in any form, is strictly prohibited. If you have received this
> message in error, please immediately notify the sender and/or Syncsort and
> destroy all copies of this message in your possession, custody or control.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Concatenated datasets read information.

[Jack J. Woehr]

Massimo Biancucci wrote:

I don't know exactly what the application programmers need, they asked me
to know if there's a possibility.

I'll investigate deeper to understand if it's a real need

There's the lesson! "Never listen to the application programmers until you know what 
they are actually trying to do." :)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Concatenated datasets read information.

[John McKown]

On Tue, Sep 15, 2015 at 9:22 AM, Jack J. Woehr  wrote:

> Massimo Biancucci wrote:
>
>> I don't know exactly what the application programmers need, they asked me
>> to know if there's a possibility.
>>
>> I'll investigate deeper to understand if it's a real need
>>
> There's the lesson! "Never listen to the application programmers until you
> know what they are actually trying to do." :)


​What I ask is usually not "what are you trying to _do_" but "what are you
trying to _accomplish_". Gets around their assumption that what they are
_doing_ is the right thing, if only they could. Never answer the question:
"How do I clean the dishes using a vacuum cleaner?"​ Of course, this goes
against the standard aphorism: "When all you have is a hammer, everything
looks like a nail."



>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: Concatenated datasets read information.

[Bernd Oppolzer]

This sounds like a somehow strange request to me,
because concatenation is designed just to hide the fact that
the data comes from different concatenated files from the
application program. I guess it will be difficult to extract the
current processed DSN from the I/O related MVS control blocks.

If you have such a requirement, I would suggest that you concatenate
the files in advance (DFSORT?) and append a file identifier (1, 2, 3) at 
the end
of every record (fixed record length assumed), then you can read this 
record

identifier from your COBOL program when processing the concatenated file.

Kind regards

Bernd



Am 14.09.2015 um 13:14 schrieb Massimo Biancucci:

Hi everybody,

is there any way to know which concatenated dataset I've read the current
record from ?

To be clear:

FILE1 DD DISP=SHR,DSN=MYDSN1
   DD DISP=SHR,DSN=MYDSN2
   DD DISP=SHR,DSN=MYDSN3

>From a COBOL program:

READ FILE1 INTO MY-RECORD AT END GO E-O-P.

CALL "MYPGM to know the file I've read from".

MYPGM should be assembler I suppose.

I was not able to find anything in TIOT nor JFCB.

Thanks a lot in advance.
Massimo

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



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

Re: Concatenated datasets read information.

[Walt Farrell]

On Mon, 14 Sep 2015 13:14:49 +0200, Massimo Biancucci  wrote:

>Hi everybody,
>
>is there any way to know which concatenated dataset I've read the current
>record from ?
>
>To be clear:
>
>FILE1 DD DISP=SHR,DSN=MYDSN1
>  DD DISP=SHR,DSN=MYDSN2
>  DD DISP=SHR,DSN=MYDSN3
>
>From a COBOL program:
>
>READ FILE1 INTO MY-RECORD AT END GO E-O-P.
>
>CALL "MYPGM to know the file I've read from".
>
>MYPGM should be assembler I suppose.
>
>I was not able to find anything in TIOT nor JFCB.

From COBOL I'm not sure if you can do it. If you were doing the reading in an 
assembler program, then it's possible if I remember correctly. As I recall, 
there's a flag you can set in the DCB that indicates the concatenation may 
contain data sets with different characteristics (block size, primarily), and 
when that flag is set the system will call your EOF (?) exit as it's crossing 
into the next data set in the concatenation. That allows you to do appropriate 
control block adjustments.

(These are all very old memories, as I haven't used that technique in decades.)

-- 
Walt

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

Re: Concatenated datasets read information.

[John McKown]

On Mon, Sep 14, 2015 at 11:01 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 14 Sep 2015 07:54:32 -0700, Lizette Koehler wrote:
>
> >Could you explain what problem you are trying to solve with this
> technique?
> >
> >How does it help your process to know which concatenated  dataset the
> data came from?  Why can you not use multiple DD Statements instead?
> >
> It might be simpler as the OP wishes.  It's possible that records in some
> input data sets,
> identifiable by data set name, require a variation in processing,  The
> technique
> Massimo wishes for spares him the need to know how many such data sets
> exist
> or in what order they appear.
>
> Suppose I have a daily transaction log for each day in a month.  I'd like
> to concatenate
> them and perform some analysis, but the processing for Sundays is slightly
> different.
> Having 31 DDNAMEs, of which the last (as many as 3) might be dummies may
> seem
> needlessly complex.
>
> It's a reasonable wish for an existing facility; perhaps not meriting an
> RfE.
>
>
​That's in interesting, if scary, thought. I was thinking more along the
lines of giving a better error message by printing something like:

RECORD NUMBER 27 IN FILE 3 OF THE INPUT IN MYINPUT IS IN ERROR.
THE ACCOUNT NUMBER BUBBAJOHNSON DOES NOT EXIST.​



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: Concatenated datasets read information.

[Jeremy Nicoll]

On Mon, 14 Sep 2015, at 17:01, Paul Gilmartin wrote:
> On Mon, 14 Sep 2015 07:54:32 -0700, Lizette Koehler wrote:
> 
> >Could you explain what problem you are trying to solve with this technique?
> >
> >How does it help your process to know which concatenated  dataset the data 
> >came from?  Why can you not use multiple DD Statements instead?
> >  
> It might be simpler as the OP wishes.  It's possible that records in some
> input data sets,
> identifiable by data set name, require a variation in processing,  The
> technique
> Massimo wishes for spares him the need to know how many such data sets
> exist
> or in what order they appear.

If there's a way to define a file with one record - same lrecl, blksize
etc as the other files, but 
a line of data that can't exist in any real data file - ie a marker
record then how about 

//FILE1 DD DISP=SHR,DSN=MYDSN1
//  DD DISP=SHR,DSN=MARKER
//  DD DISP=SHR,DSN=MYDSN2
//  DD DISP=SHR,DSN=MARKER
//  DD DISP=SHR,DSN=MYDSN3
//  DD DISP=SHR,DSN=MARKER

etc.  One could have more than one type of marker file - eg one that
precedes weekend data and
one that precedes weekday data etc.


-- 
Jeremy Nicoll - my opinions are my own.

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

Re: Concatenated datasets read information.

[Paul Gilmartin]

On Mon, 14 Sep 2015 07:54:32 -0700, Lizette Koehler wrote:

>Could you explain what problem you are trying to solve with this technique?
>
>How does it help your process to know which concatenated  dataset the data 
>came from?  Why can you not use multiple DD Statements instead?
>  
It might be simpler as the OP wishes.  It's possible that records in some input 
data sets,
identifiable by data set name, require a variation in processing,  The technique
Massimo wishes for spares him the need to know how many such data sets exist
or in what order they appear.

Suppose I have a daily transaction log for each day in a month.  I'd like to 
concatenate
them and perform some analysis, but the processing for Sundays is slightly 
different.
Having 31 DDNAMEs, of which the last (as many as 3) might be dummies may seem
needlessly complex.

It's a reasonable wish for an existing facility; perhaps not meriting an RfE.

>> -Original Message-
>> From: Massimo Biancucci
>> Sent: Monday, September 14, 2015 4:15 AM
>> 
>> is there any way to know which concatenated dataset I've read the current 
>> record
>> from ?
>> 
>> To be clear:
>> 
>> FILE1 DD DISP=SHR,DSN=MYDSN1
>>   DD DISP=SHR,DSN=MYDSN2
>>   DD DISP=SHR,DSN=MYDSN3

-- gil

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

Re: Concatenated datasets read information.

[Chris Hoelscher]

I do not know if this is a valid solution - but something I have done
In the jcl - between each dsn in the dd concatenation,
Place a dd * with some literal value like END OF DD 1

FILE1 DD DISP=SHR,DSN=MYDSN
DD *
END OF 1
   DD DISP=SHR,DSN=MYDSN2
DD *
END OF 2
   DD DISP=SHR,DSN=MYDSN3
DD *
END OF 3

In the program
If input-lit = "end of 1"
Move 2 to which-dd-am-i-on


Now I am certain this is not the approach the OP was looking for - 

I have used this when reading 2 sets of data that build a many-to-many grid - 
but want to read them  in thru 1 DD
I want to know if I am on the first set of data (that is thrown into an 
in-memory table) or the second set of data
Which is compared to that in-memory table

Chris hoelscher
Technology Architect 
Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 714-8615
(502) 476-2538

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, September 14, 2015 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Concatenated datasets read information.

Could you explain what problem you are trying to solve with this technique?

How does it help your process to know which concatenated  dataset the data came 
from?  Why can you not use multiple DD Statements instead?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Massimo Biancucci
> Sent: Monday, September 14, 2015 4:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Concatenated datasets read information.
> 
> Hi everybody,
> 
> is there any way to know which concatenated dataset I've read the 
> current record from ?
> 
> To be clear:
> 
> FILE1 DD DISP=SHR,DSN=MYDSN1
>   DD DISP=SHR,DSN=MYDSN2
>   DD DISP=SHR,DSN=MYDSN3
> 
> From a COBOL program:
> 
> READ FILE1 INTO MY-RECORD AT END GO E-O-P.
> 
> CALL "MYPGM to know the file I've read from".
> 
> MYPGM should be assembler I suppose.
> 
> I was not able to find anything in TIOT nor JFCB.
> 
> Thanks a lot in advance.
> Massimo

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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

Re: Concatenated datasets read information.

[Paul Gilmartin]

On Mon, 14 Sep 2015 11:06:42 -0500, John McKown wrote:
>
>On Mon, Sep 14, 2015 at 11:01 AM, Paul Gilmartin <
>000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>​That's in interesting, if scary, thought. I was thinking more along the
>lines of giving a better error message by printing something like:
>
>RECORD NUMBER 27 IN FILE 3 OF THE INPUT IN MYINPUT IS IN ERROR.
>THE ACCOUNT NUMBER BUBBAJOHNSON DOES NOT EXIST.​
>
Yup.  However: "FILE 3" is underreaching.  Should also show DSNAME/pathname.
HLASM, at least, does this pretty well with its ASMA435I message.  Too many
other utilities cop out with "PATH NAME ... SPECIFIED."  Allocation ought to be
enhanced to load that field with (the last?) 44 characters of the path name,
and the volser with "UNIXfs".

My suggestion was influenced by "awk" where I read everything in the main
data-driven loop and case out filenames.

-- gil

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

Re: Concatenated datasets read information.

[Paul Gilmartin]

On 2015-09-14, at 10:18, Chris Hoelscher wrote:

> I do not know if this is a valid solution - but something I have done
> In the jcl - between each dsn in the dd concatenation,
> Place a dd * with some literal value like END OF DD 1
> 
> FILE1 DD DISP=SHR,DSN=MYDSN
>DD *
> END OF 1
>   DD DISP=SHR,DSN=MYDSN2
> ... 
Good idea.  But, attribute compatibility?

I hate MVS!

-- gil

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

Re: Concatenated datasets read information.

[Blaicher, Christopher Y.]

I don't remember, but is the DCBTIOT pointer updated for each concatenation?  
If it is, then using the TIOT you can get to the JFCB which gives you the 
DSNAME.

Chris Blaicher
Technical Architect
Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, September 14, 2015 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Concatenated datasets read information.

On 2015-09-14, at 10:18, Chris Hoelscher wrote:

> I do not know if this is a valid solution - but something I have done
> In the jcl - between each dsn in the dd concatenation, Place a dd *
> with some literal value like END OF DD 1
>
> FILE1 DD DISP=SHR,DSN=MYDSN
>DD *
> END OF 1
>   DD DISP=SHR,DSN=MYDSN2
> ...
Good idea.  But, attribute compatibility?

I hate MVS!

-- gil

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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