Re: IEBPTPCH (was: Read a PDS ...)

[Jesse 1 Robinson]

This thread seems to have left OP in the dust. Ability to recover data in an 
altered PDS, apart from any funky DCB parameters, depends entirely on whether 
the killer job specified a member name. If so, that member may not be readable, 
but the rest of the PDS should be OK once DCB is corrected. 

If no member was specified in the killer job, then the directory is toast. 
There is no clean recovery from that, but a program that reads block by block 
might be able to extract data not overlaid by the killer job. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Friday, June 17, 2016 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEBPTPCH (was: Read a PDS ...)

There's several problems. The OP wanted to convert a PDS to a flat file for  
examining program calls. With PDS or STARTools or superc this in not required. 
 
In the process of examining the PDS he corrupted the DCB. There is no backup. 
Using DITTO a necessary pgm was recovered.
 
XMIT converts a PDS to a flat file 80/3120 that is a special invocation of 
IEBCOPY unload and not useful for much other than RECEIVE. 
 
First need to fix the original PDS DCB which can be accomplished with
IEFBR14
 
//DD1  DD DSN=Original,  DCB=(DSORG=PO,LRECL=80,BLKSIZE=original),DISP=MOD
 
Then do IEBCOPY of original to new PDS or use PDS command to examine or list 
members. There is a fixpds command but wouldn't do this until the DCB is 
corrected.
 
Source control may maintained with SCLM or 3rd party software.
 
 
In a message dated 6/17/2016 6:16:09 P.M. Central Daylight Time, 
000433f07816-dmarc-requ...@listserv.ua.edu writes:

There  might be existing tools that are better approaches to the problem.
Someone  here lately mentioned Startool, and I think of SuperC  SRCHFOR.

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

Re: IEBPTPCH (was: Read a PDS ...)

[Edward Finnell]

There's several problems. The OP wanted to convert a PDS to a flat file for 
 examining program calls. With PDS or STARTools or superc this in not 
required. 
 
In the process of examining the PDS he corrupted the DCB. There is no  
backup. Using DITTO a necessary pgm was recovered.
 
XMIT converts a PDS to a flat file 80/3120 that is a special invocation of  
IEBCOPY unload and not useful for much other than RECEIVE. 
 
First need to fix the original PDS DCB which can be accomplished with  
IEFBR14
 
//DD1  DD DSN=Original,  DCB=(DSORG=PO,LRECL=80,BLKSIZE=original),DISP=MOD
 
Then do IEBCOPY of original to new PDS or use PDS command to examine or  
list members. There is a fixpds command but wouldn't do this until the DCB is  
corrected.
 
Source control may maintained with SCLM or 3rd party software.
 
 
In a message dated 6/17/2016 6:16:09 P.M. Central Daylight Time,  
000433f07816-dmarc-requ...@listserv.ua.edu writes:

There  might be existing tools that are better approaches to the problem.
Someone  here lately mentioned Startool, and I think of SuperC  SRCHFOR.



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

Re: IEBPTPCH (was: Read a PDS ...)

[Paul Gilmartin]

On Fri, 17 Jun 2016 22:39:43 +, J R wrote:

>"Are you changing the requirement ex post facto?"
>
>I don't think so. The OP wanted to read all the members of a program source 
>library, one after another, as if concatenated within a single sequential 
>dataset.
> 
I'll stand corrected.  I do recall such a statement.  But it might yet
be overspecification:

https://www.usenix.org/legacy/event/evt06/tech/full_papers/mcgaley/mcgaley_html/node21.html

There might be existing tools that are better approaches to the problem.
Someone here lately mentioned Startool, and I think of SuperC SRCHFOR.

-- gil

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

Re: IEBPTPCH (was: Read a PDS ...)

[Jesse 1 Robinson]

StarTool can do the job very nicely. There is a FIND function that searches for 
a (qualified) character string and (optionally) builds a member list of just 
those that contain the search argument. 

There is also a COMBINE function that strings all members into one data stream 
with or without delimiters.

I don't remember if the CBT version has these functions. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, June 17, 2016 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEBPTPCH (was: Read a PDS ...)

On Fri, 17 Jun 2016 22:04:33 +, Jesse 1 Robinson wrote:

>If 'card image' is defined as FB-80, then yes it is, but the data is full of 
>control info used to rebuild the PDS members. If 'card image' means literally 
>a one for one representation of the original data, then no. Frankly I had lost 
>track of what OP needed. 
> 
And if the original data aren't F 80, there's no solution.

IIRC, OP wanted to search a PDS (of unstated attributes) for references to (a 
)certain load module(s).

>-Original Message-
>From:  J R
>Sent: Friday, June 17, 2016 3:00 PM
>
>But not the original card images. I thought there are control data at the 
>beginning of each record which staggers the original card images progressively 
>through the dataset. 
> 
Are you changing the requirement ex post facto?  It also can't be created on an 
029 keypunch without using the MULT PCH key, nor with ISPF Edit without using 
HEX ON.

>> Actuallly, FB;80;3120.  It is.
>> 
>>>> On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
>>>> ...  XMIT with corresponding RECEIVE is a very handy way to flatten out 
>>>> and later re-inflate a PDS.
>>
>> But perhaps not legible enough to suit the OP's objective.
>> 
What I said.

-- gil


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

Re: IEBPTPCH (was: Read a PDS ...)

[J R]

"Are you changing the requirement ex post facto?"

I don't think so. The OP wanted to read all the members of a program source 
library, one after another, as if concatenated within a single sequential 
dataset.

Of course, I could be wrong.

Sent from my iPhone

On Jun 17, 2016, at 18:29, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu>
 wrote:

On Fri, 17 Jun 2016 22:04:33 +, Jesse 1 Robinson wrote:

If 'card image' is defined as FB-80, then yes it is, but the data is full of 
control info used to rebuild the PDS members. If 'card image' means literally a 
one for one representation of the original data, then no. Frankly I had lost 
track of what OP needed.

And if the original data aren't F 80, there's no solution.

IIRC, OP wanted to search a PDS (of unstated attributes) for references
to (a )certain load module(s).

-Original Message-
From:  J R
Sent: Friday, June 17, 2016 3:00 PM

But not the original card images. I thought there are control data at the 
beginning of each record which staggers the original card images progressively 
through the dataset.

Are you changing the requirement ex post facto?  It also can't be
created on an 029 keypunch without using the MULT PCH key,
nor with ISPF Edit without using HEX ON.

Actuallly, FB;80;3120.  It is.

On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
...  XMIT with corresponding RECEIVE is a very handy way to flatten out and 
later re-inflate a PDS.

But perhaps not legible enough to suit the OP's objective.



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

Re: IEBPTPCH (was: Read a PDS ...)

[Paul Gilmartin]

On Fri, 17 Jun 2016 22:04:33 +, Jesse 1 Robinson wrote:

>If 'card image' is defined as FB-80, then yes it is, but the data is full of 
>control info used to rebuild the PDS members. If 'card image' means literally 
>a one for one representation of the original data, then no. Frankly I had lost 
>track of what OP needed. 
> 
And if the original data aren't F 80, there's no solution.

IIRC, OP wanted to search a PDS (of unstated attributes) for references
to (a )certain load module(s).

>-Original Message-
>From:  J R
>Sent: Friday, June 17, 2016 3:00 PM
>
>But not the original card images. I thought there are control data at the 
>beginning of each record which staggers the original card images progressively 
>through the dataset. 
> 
Are you changing the requirement ex post facto?  It also can't be
created on an 029 keypunch without using the MULT PCH key,
nor with ISPF Edit without using HEX ON.

>> Actuallly, FB;80;3120.  It is.
>> 
 On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
 ...  XMIT with corresponding RECEIVE is a very handy way to flatten out 
 and later re-inflate a PDS.
>>
>> But perhaps not legible enough to suit the OP's objective.
>> 
What I said.

-- gil

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

Re: IEBPTPCH (was: Read a PDS ...)

[Jesse 1 Robinson]

If 'card image' is defined as FB-80, then yes it is, but the data is full of 
control info used to rebuild the PDS members. If 'card image' means literally a 
one for one representation of the original data, then no. Frankly I had lost 
track of what OP needed. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Friday, June 17, 2016 3:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEBPTPCH (was: Read a PDS ...)

But not the original card images. I thought there are control data at the 
beginning of each record which staggers the original card images progressively 
through the dataset. 

Sent from my iPhone

> On Jun 17, 2016, at 17:55, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Fri, 17 Jun 2016 21:45:03 +, J R wrote:
>> 
>> Yes, but is the intermediate flat file card-image?  
>> I think not!  
> Actuallly, FB;80;3120.  It is.
> 
>>> On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
>>> ...  XMIT with corresponding RECEIVE is a very handy way to flatten out and 
>>> later re-inflate a PDS.
> But perhaps not legible enough to suit the OP's objective.
> 
> -- gil

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

Re: IEBPTPCH (was: Read a PDS ...)

[J R]

But not the original card images. I thought there are control data at the 
beginning of each record which staggers the original card images progressively 
through the dataset. 

Sent from my iPhone

> On Jun 17, 2016, at 17:55, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Fri, 17 Jun 2016 21:45:03 +, J R wrote:
>> 
>> Yes, but is the intermediate flat file card-image?  
>> I think not!  
> Actuallly, FB;80;3120.  It is.
> 
>>> On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
>>> ...  XMIT with corresponding RECEIVE is a very handy way to flatten out and 
>>> later re-inflate a PDS.
> But perhaps not legible enough to suit the OP's objective.
> 
> -- gil
> 
> 

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

Re: IEBPTPCH (was: Read a PDS ...)

[Paul Gilmartin]

On Fri, 17 Jun 2016 21:45:03 +, J R wrote:

>Yes, but is the intermediate flat file card-image?  
>I think not!  
> 
Actuallly, FB;80;3120.  It is.

>> On Jun 17, 2016, at 16:58, Jesse 1 Robinson wrote:
>> ...  XMIT with corresponding RECEIVE is a very handy way to flatten out and 
>> later re-inflate a PDS. 
>>  
But perhaps not legible enough to suit the OP's objective.

-- gil

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

Re: IEBPTPCH (was: Read a PDS ...)

[J R]

Yes, but is the intermediate flat file card-image?  
I think not!  

Sent from my iPhone

> On Jun 17, 2016, at 16:58, Jesse 1 Robinson  wrote:
> 
> ...  XMIT with corresponding RECEIVE is a very handy way to flatten out and 
> later re-inflate a PDS. 
> 
> .
> .
> .

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

Re: IEBPTPCH (was: Read a PDS ...)

[Martin Packer]

This is what customers use with AMATERSE to FTP their WLM Service
Definition TLIB to ECUREP for me.

Nice and reliable.

Cheers, Martin

Sent from my iPad

> On 17 Jun 2016, at 21:57, Jesse 1 Robinson 
wrote:
>
> Don't overlook Alan Field's recently posted usermod that removes the
hard-coded 3120 block size. But yes, XMIT with corresponding RECEIVE is a
very handy way to flatten out and later re-inflate a PDS.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Cieri, Anthony
> Sent: Friday, June 17, 2016 12:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: IEBPTPCH (was: Read a PDS ...)
>
>The TSO Transmit command provide a very reliable (and reversible)
method of converting a PDS (or PDSE ) into a sequential dataset!!
>
>Ex:XMIT NODE.DUMMY DA('SYS1.PARMLIB') OUTDS
('SYS1.PARMLIB.TEMP.SEQ')
>
>The OUTDS will be allocated with DCB parameters of LRECL=80 RECFM=FB
DSORG=PS and BLKSIZE=3120.
>
>Tony
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Staller, Allan
> Sent: Friday, June 17, 2016 1:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEBPTPCH (was: Read a PDS ...)
>
> Thx
>
> 
> Caution: From a retiree out of the game for 12 months
> //job etc etc
> //exec pgm=ikjeft01
> //systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't
remember //systsin DD *
> Printds hlq.your.PDS.   or pdse
>
>
> <>
> Would you be willing to share?
>
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of saul anthony babonas
> Sent: Thursday, June 16, 2016 11:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IEBPTPCH (was: Read a PDS ...)
>
> I've been following this discussion with some belated interest. Years ago
I cooked up something dirt simple to turn a PDS into a SD file using the
TSO print command. It wasn't very elegant but it got the job done at low
cost.
> <>
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: IEBPTPCH (was: Read a PDS ...)

[Jesse 1 Robinson]

Don't overlook Alan Field's recently posted usermod that removes the hard-coded 
3120 block size. But yes, XMIT with corresponding RECEIVE is a very handy way 
to flatten out and later re-inflate a PDS. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cieri, Anthony
Sent: Friday, June 17, 2016 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEBPTPCH (was: Read a PDS ...)

The TSO Transmit command provide a very reliable (and reversible) 
method of converting a PDS (or PDSE ) into a sequential dataset!!

Ex: XMIT NODE.DUMMY DA('SYS1.PARMLIB') 
OUTDS('SYS1.PARMLIB.TEMP.SEQ')

The OUTDS will be allocated with DCB parameters of LRECL=80 RECFM=FB 
DSORG=PS and BLKSIZE=3120.

Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Friday, June 17, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Thx


Caution: From a retiree out of the game for 12 months
//job etc etc
//exec pgm=ikjeft01
//systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't remember 
//systsin DD *
 Printds hlq.your.PDS.   or pdse


<>
Would you be willing to share?

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.
<>


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

Re: IEBPTPCH (was: Read a PDS ...)

[Cieri, Anthony]

The TSO Transmit command provide a very reliable (and reversible) 
method of converting a PDS (or PDSE ) into a sequential dataset!!

Ex: XMIT NODE.DUMMY DA('SYS1.PARMLIB') 
OUTDS('SYS1.PARMLIB.TEMP.SEQ')

The OUTDS will be allocated with DCB parameters of LRECL=80 RECFM=FB 
DSORG=PS and BLKSIZE=3120.

Tony


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Staller, Allan
Sent: Friday, June 17, 2016 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Thx


Caution: From a retiree out of the game for 12 months
//job etc etc
//exec pgm=ikjeft01
//systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't remember 
//systsin DD *
 Printds hlq.your.PDS.   or pdse


<>
Would you be willing to share?

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.
<>

This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

--
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: IEBPTPCH (was: Read a PDS ...)

[Staller, Allan]

Thx


Caution: From a retiree out of the game for 12 months
//job etc etc
//exec pgm=ikjeft01
//systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't remember 
//systsin DD *
 Printds hlq.your.PDS.   or pdse


<>
Would you be willing to share?

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.
<>

This email – including attachments – may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

Caution: From a retiree out of the game for 12 months
//job etc etc
//exec pgm=ikjeft01
//systsprt DD dsn=your.output,disp=(new),dcb=lrecl=I don't remember
//systsin DD *
 Printds hlq.your.PDS.   or pdse



Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone


 Original message 
From: "Staller, Allan" 
Date: 6/17/2016 5:42 AM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Would you be willing to share?


From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.


This email ? including attachments ? may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

--
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: IEBPTPCH (was: Read a PDS ...)

[Staller, Allan]

Would you be willing to share?


From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of saul anthony babonas
Sent: Thursday, June 16, 2016 11:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.


This email – including attachments – may contain confidential information. If 
you are not the intended recipient, do not copy, distribute or act on it. 
Instead, notify the sender immediately and delete the message.

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

Re: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

Sequential disk



Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone


 Original message 
From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Date: 6/16/2016 9:54 PM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

On Fri, 17 Jun 2016 04:26:41 +, saul anthony babonas wrote:

>I've been following this discussion with some belated interest. Years ago I 
>cooked up something dirt simple to turn a PDS into a SD file using the TSO 
>print command. It wasn't very elegant but it got the job done at low cost.
>
SD?  Like a USB flash card?

> Original message 
>From: Edward Gould
>Date: 6/16/2016 9:19 PM (GMT-08:00)
>
>There are many peculiarities with IEBPTPCH. Like it doesn�t output in member 
>sequence (I vaguely remember that it is TTR sequence (but could be wrong).
>
Indeed.  While testing, I created a member, AAA* so it would be first.  It
appeared last.  Optimize seek movement.  First read the directory.  Sort
in TTR order.  FIND each member.  Great idea if you're the only job
using the device.

>The control card format is anything but intuitive I am iffy here but IIRC you 
>must specify maxflds (why I have no clue) I hated the damn program myself as I 
>had to relearn the control cards  all the time.
>
IEBGENER has something similar.  I guessed it's to know how much working
storage to GETMAIN.  I just used a big number and suitable REGION.

It should have stayed in the 20th Century.  Today, I think I'd NFS mount my
PDS on Solaris and use "pax".

But IEBGENER will create aliases.  I don't think it would work to NFS mount
on Solaris and use "ln".

-- gil

--
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: IEBPTPCH (was: Read a PDS ...)

[Paul Gilmartin]

On Fri, 17 Jun 2016 04:26:41 +, saul anthony babonas wrote:

>I've been following this discussion with some belated interest. Years ago I 
>cooked up something dirt simple to turn a PDS into a SD file using the TSO 
>print command. It wasn't very elegant but it got the job done at low cost.
>
SD?  Like a USB flash card?

> Original message 
>From: Edward Gould
>Date: 6/16/2016 9:19 PM (GMT-08:00)
>
>There are many peculiarities with IEBPTPCH. Like it doesn�t output in member 
>sequence (I vaguely remember that it is TTR sequence (but could be wrong).
>
Indeed.  While testing, I created a member, AAA* so it would be first.  It
appeared last.  Optimize seek movement.  First read the directory.  Sort
in TTR order.  FIND each member.  Great idea if you're the only job
using the device.

>The control card format is anything but intuitive I am iffy here but IIRC you 
>must specify maxflds (why I have no clue) I hated the damn program myself as I 
>had to relearn the control cards  all the time.
>
IEBGENER has something similar.  I guessed it's to know how much working
storage to GETMAIN.  I just used a big number and suitable REGION.

It should have stayed in the 20th Century.  Today, I think I'd NFS mount my
PDS on Solaris and use "pax".

But IEBGENER will create aliases.  I don't think it would work to NFS mount
on Solaris and use "ln".

-- gil

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

Re: IEBPTPCH (was: Read a PDS ...)

[saul anthony babonas]

I've been following this discussion with some belated interest. Years ago I 
cooked up something dirt simple to turn a PDS into a SD file using the TSO 
print command. It wasn't very elegant but it got the job done at low cost.



Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone


 Original message 
From: Edward Gould 
Date: 6/16/2016 9:19 PM (GMT-08:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBPTPCH (was: Read a PDS ...)

Paul:

There are many peculiarities with IEBPTPCH. Like it doesn’t output in member 
sequence (I vaguely remember that it is TTR sequence (but could be wrong).
The control card format is anything but intuitive I am iffy here but IIRC you 
must specify maxflds (why I have no clue) I hated the damn program myself as I 
had to relearn the control cards  all the time.
IEHMOVE was another PITA. The only reason to use IEHMOVE (Memory is shady here 
people) is that it allocated the output file for you.
Ed
> On Jun 14, 2016, at 7:59 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Tue, 14 Jun 2016 18:03:02 -0500, wrote:
>
>> I'm not sure why you'd think it may have problems punching/printing PDS 
>> members that happen to contain JCL which happens to contain IEBPTPCH 
>> commands. It's all just data to IEBPTPCH.
>>
> OK.  I tried it.  Members appear to be separated by lines of the form "MEMBER 
> NAME  ".
> (Is this documented?)  What happens if such a line appears in SYSUT1?  I got:
>
> MEMBER NAME  AAAWTF control line
>  Line before   data line
> MEMBER NAME  FOOBAR data line (but how does it know?)
>  Line afterdata line
>
>> It is documented, you could consider giving it a whirl with something else 
>> and lettings us know.
>>
> Wherein I find gems such as:
>
>Both the output data set and the message data set can be written to the
>system output device if it is a printer.
>
> What does that mean?  If it's not a printer, can only one of them be written 
> to it?
>
>If the member card entry is not used, the entire data cell will be printed.
>
> How long has it been since IBM marketed a data cell?  (I'll submit an RCF on 
> that.)
>
> How does one restore a PDS from IEBPTPCH output?  It's probably somewhere.
> I haven't found it.
>
> (Is this good old IBM documentation or sloppy new IBM documentation?)
>
> -- gil
>
> --
> 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

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

Re: IEBPTPCH (was: Read a PDS ...)

[Edward Gould]

Paul:

There are many peculiarities with IEBPTPCH. Like it doesn’t output in member 
sequence (I vaguely remember that it is TTR sequence (but could be wrong).
The control card format is anything but intuitive I am iffy here but IIRC you 
must specify maxflds (why I have no clue) I hated the damn program myself as I 
had to relearn the control cards  all the time. 
IEHMOVE was another PITA. The only reason to use IEHMOVE (Memory is shady here 
people) is that it allocated the output file for you.
Ed
> On Jun 14, 2016, at 7:59 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Tue, 14 Jun 2016 18:03:02 -0500, wrote:
> 
>> I'm not sure why you'd think it may have problems punching/printing PDS 
>> members that happen to contain JCL which happens to contain IEBPTPCH 
>> commands. It's all just data to IEBPTPCH.
>> 
> OK.  I tried it.  Members appear to be separated by lines of the form "MEMBER 
> NAME  ".
> (Is this documented?)  What happens if such a line appears in SYSUT1?  I got:
> 
> MEMBER NAME  AAAWTF control line
>  Line before   data line
> MEMBER NAME  FOOBAR data line (but how does it know?)
>  Line afterdata line
> 
>> It is documented, you could consider giving it a whirl with something else 
>> and lettings us know. 
>> 
> Wherein I find gems such as:
> 
>Both the output data set and the message data set can be written to the
>system output device if it is a printer.
> 
> What does that mean?  If it's not a printer, can only one of them be written 
> to it?
> 
>If the member card entry is not used, the entire data cell will be printed.
> 
> How long has it been since IBM marketed a data cell?  (I'll submit an RCF on 
> that.)
> 
> How does one restore a PDS from IEBPTPCH output?  It's probably somewhere.
> I haven't found it.
> 
> (Is this good old IBM documentation or sloppy new IBM documentation?)
> 
> -- gil
> 
> --
> 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

IEBPTPCH (was: Read a PDS ...)

[Bill Woodger]

Sorry, missed this. I recently sat on a bacon-slicer, so I'm getting a little 
behind with everything...

I suspect, but don't know, that the only recent updates to the "manual" have 
been to add the word PDSE.

SYSUT1 members containing data which looks like the data "label" that is 
generated are unproblematic for IEBPTPCH. It's just data.

Then processing the output is a different potential issue. You may have noted 
that 73-80 are blank, which can aid in identification of those generated 
against those members which have "line numbers", but not those which are 
already blank.

However, since I use it for COBOL programs and for JCL (the first being no 
possible problem, the second only a problem if someone has "data" which happens 
to match the format, possible, but not happened yet) I've not encountered a 
problem.

To get stuff then into a PDS, you basically changed the MEMBER card to an 
IEBUPDTE command. I've only ever done it with "add" and only ever to a separate 
PDS, either an "empty" PDS or one guaranteed not to have  conflict of members, 
but it would be possible to try to get more exciting with it and use some of 
the other IEBUPDTE options. Having seen "damaged" PDSs and members with 
unintended updates, I just like to be very careful and systematic. Call me the 
Tortoise of screwi... updating PDSs. Tortoises also do backups. And use IEBCOPY 
to return, updated, data from whence it came.

I have found it extremely useful for program sources and JCL.

There is something about * and ** being used as markers, but I've never seen 
them and never bothered/needed to check why not. Maybe it's on the print output 
(which I don't use)?

I don't know if "library services" existed when I started using this, but if 
they did, I didn't know about them, and just jumped with the first thing I 
found that did what I needed. Perhaps I should "modernise" the approach, but 
I've just not found a need. Yet.

On Wednesday, 15 June 2016 02:59:40 UTC+2, Paul Gilmartin  wrote:
> On Tue, 14 Jun 2016 18:03:02 -0500, wrote:
> 
> >I'm not sure why you'd think it may have problems punching/printing PDS 
> >members that happen to contain JCL which happens to contain IEBPTPCH 
> >commands. It's all just data to IEBPTPCH.
> >
> OK.  I tried it.  Members appear to be separated by lines of the form "MEMBER 
> NAME  ".
> (Is this documented?)  What happens if such a line appears in SYSUT1?  I got:
> 
> MEMBER NAME  AAAWTF control line
>   Line before   data line
> MEMBER NAME  FOOBAR data line (but how does it know?)
>   Line afterdata line
> 
> >It is documented, you could consider giving it a whirl with something else 
> >and lettings us know. 
> >
> Wherein I find gems such as:
> 
> Both the output data set and the message data set can be written to the
> system output device if it is a printer.
> 
> What does that mean?  If it's not a printer, can only one of them be written 
> to it?
> 
> If the member card entry is not used, the entire data cell will be 
> printed.
> 
> How long has it been since IBM marketed a data cell?  (I'll submit an RCF on 
> that.)
> 
> How does one restore a PDS from IEBPTPCH output?  It's probably somewhere.
> I haven't found it.
> 
> (Is this good old IBM documentation or sloppy new IBM documentation?)
> 
> -- gil
> 
> --
> 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

IEBPTPCH (was: Read a PDS ...)

[Paul Gilmartin]

On Tue, 14 Jun 2016 18:03:02 -0500, wrote:

>I'm not sure why you'd think it may have problems punching/printing PDS 
>members that happen to contain JCL which happens to contain IEBPTPCH commands. 
>It's all just data to IEBPTPCH.
>
OK.  I tried it.  Members appear to be separated by lines of the form "MEMBER 
NAME  ".
(Is this documented?)  What happens if such a line appears in SYSUT1?  I got:

MEMBER NAME  AAAWTF control line
  Line before   data line
MEMBER NAME  FOOBAR data line (but how does it know?)
  Line afterdata line

>It is documented, you could consider giving it a whirl with something else and 
>lettings us know. 
>
Wherein I find gems such as:

Both the output data set and the message data set can be written to the
system output device if it is a printer.

What does that mean?  If it's not a printer, can only one of them be written to 
it?

If the member card entry is not used, the entire data cell will be printed.

How long has it been since IBM marketed a data cell?  (I'll submit an RCF on 
that.)

How does one restore a PDS from IEBPTPCH output?  It's probably somewhere.
I haven't found it.

(Is this good old IBM documentation or sloppy new IBM documentation?)

-- gil

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