Re: PDS/E Cobol

[Wayne Bickerdike]

Won't FTP GET work? Just direct into the PDSE.

On Sat, Sep 17, 2016 at 7:27 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 16 Sep 2016 08:18:14 -0500, Tom Marchant 
> wrote:
>
> >On Fri, 16 Sep 2016 02:39:15 +, Jesse 1 Robinson wrote:
> >
> >>I don't think an 'interim' data set will solve the problem.
> >>
> >>DSN(A) --> DSN(B) --> DSN(C)
> >>
> >>Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem
> of crossing sysplex boundaries on one copy or the other.
> >>
> >>The transfer needs to be 'DSN free'.
> >
> If DSN(B) is an unloaded PDSE (PDSU) it's simply a PS data set and
> GRS handles serialization of those better than of PDSE.
>
> >Right. Program objects support new things that cannot be included in a
> load module. For any such program object, you can't copy it to a PDS. You
> can copy it to a Unix file, but that doesn't really help thbe situation.
> >
> Perhaps.  If the UNIX library is NFS mounted to both A and B, the NFS
> server does serialization correctly.  But will all information be
> preserved?
> As an experiment, I linked a load module from a PDSE to a UNIX file
> with:
> INCLUDE -ATTR,-ALIASES,SYSLIB(...)
>
> The SYSPRINT ENTRY POINT AND ALIAS SUMMARY shows the original
> aliases.  A UNIX directory listing shows a program object with multiple
> hard links for the aliases.  I don't know whether executing it by one
> of the alias names will begin execution at the intended entry point.
>
> But when I link that UNIX program object into a PDSE with a similar
> INCLUDE command, all the original aliases are restored and appear
> in the PDSE directory.
>
> -- gil
>
>
> >--
> >Tom Marchant
> >
> >--
> >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
>



-- 
Wayne V. Bickerdike

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

Re: PDS/E Cobol

[Paul Gilmartin]

On Fri, 16 Sep 2016 08:18:14 -0500, Tom Marchant  
wrote:

>On Fri, 16 Sep 2016 02:39:15 +, Jesse 1 Robinson wrote:
>
>>I don't think an 'interim' data set will solve the problem. 
>>
>>DSN(A) --> DSN(B) --> DSN(C)
>>
>>Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem of 
>>crossing sysplex boundaries on one copy or the other. 
>>
>>The transfer needs to be 'DSN free'.
>
If DSN(B) is an unloaded PDSE (PDSU) it's simply a PS data set and
GRS handles serialization of those better than of PDSE.

>Right. Program objects support new things that cannot be included in a load 
>module. For any such program object, you can't copy it to a PDS. You can copy 
>it to a Unix file, but that doesn't really help thbe situation.
>
Perhaps.  If the UNIX library is NFS mounted to both A and B, the NFS
server does serialization correctly.  But will all information be preserved?
As an experiment, I linked a load module from a PDSE to a UNIX file
with:
INCLUDE -ATTR,-ALIASES,SYSLIB(...)

The SYSPRINT ENTRY POINT AND ALIAS SUMMARY shows the original
aliases.  A UNIX directory listing shows a program object with multiple
hard links for the aliases.  I don't know whether executing it by one
of the alias names will begin execution at the intended entry point.

But when I link that UNIX program object into a PDSE with a similar
INCLUDE command, all the original aliases are restored and appear
in the PDSE directory.

-- gil


>-- 
>Tom Marchant
>
>--
>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: PDS/E Cobol

[Tom Marchant]

On Thu, 15 Sep 2016 18:14:29 -0400, Edward Finnell wrote:

>I'd use XMIT to ODSN
>FTP ODSN to secondary LRECL 80 BLKSIZE 3120
>RECEIVE ODSN  * It will have SPACE and DCB of the original

If the systems have an NJE connection, ODSN isn't necessary.

-- 
Tom Marchant

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

Re: [EXTERNAL] Re: PDS/E Cobol

[Dyck, Lionel B. (TRA)]

You need to DFDSS or FDR dump the PDSE then transfer it and then restore it to 
guarantee integrity.

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, September 16, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PDS/E Cobol

On Fri, 16 Sep 2016 02:39:15 +, Jesse 1 Robinson wrote:

>I don't think an 'interim' data set will solve the problem. 
>
>DSN(A) --> DSN(B) --> DSN(C)
>
>Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem of 
>crossing sysplex boundaries on one copy or the other. 
>
>The transfer needs to be 'DSN free'.

Right. Program objects support new things that cannot be included in a load 
module. For any such program object, you can't copy it to a PDS. You can copy 
it to a Unix file, but that doesn't really help thbe situation.

--
Tom Marchant

--
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: PDS/E Cobol

[Tom Marchant]

On Fri, 16 Sep 2016 02:39:15 +, Jesse 1 Robinson wrote:

>I don't think an 'interim' data set will solve the problem. 
>
>DSN(A) --> DSN(B) --> DSN(C)
>
>Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem of 
>crossing sysplex boundaries on one copy or the other. 
>
>The transfer needs to be 'DSN free'.

Right. Program objects support new things that cannot be included in a load 
module. For any such program object, you can't copy it to a PDS. You can copy 
it to a Unix file, but that doesn't really help thbe situation.

-- 
Tom Marchant

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

Re: PDS/E Cobol

[Jesse 1 Robinson]

I don't think an 'interim' data set will solve the problem. 

DSN(A) --> DSN(B) --> DSN(C)

Whether DSN(B) belongs to SYSA or SYSC, there is still the same problem of 
crossing sysplex boundaries on one copy or the other. 

The transfer needs to be 'DSN free'. Something like FTP or XMIT/RECEIVE or 
Connect:Direct straight from SYSA to SYSC. Or maybe BDT if anyone still uses 
it. The bottom line is that the concurrent sharing of PDSE load (program 
object) libraries across sysplex boundaries is deadly. I see this as the 
biggest obstacle for those shops that historically share PO load libraries 
across boundaries: the entire migration/promotion process has to be 
reconstructed before COBOL V5+ is implemented. 

.
.
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: Thursday, September 15, 2016 3:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PDS/E Cobol

I'm with Lizette here.
 
I'd use XMIT to ODSN
FTP ODSN to secondary LRECL 80 BLKSIZE 3120 RECEIVE ODSN  * It will have SPACE 
and DCB of the original
 
 
In a message dated 9/15/2016 3:26:47 P.M. Central Daylight Time, 
stars...@mindspring.com writes:

I would  probably use an interim dataset so that there is no potential for 
PDS/E  Corruption

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

Re: PDS/E Cobol

[Edward Finnell]

I'm with Lizette here.
 
I'd use XMIT to ODSN
FTP ODSN to secondary LRECL 80 BLKSIZE 3120
RECEIVE ODSN  * It will have SPACE and DCB of the original
 
 
In a message dated 9/15/2016 3:26:47 P.M. Central Daylight Time,  
stars...@mindspring.com writes:

I would  probably use an interim dataset so that there is no potential for 
PDS/E  Corruption

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

Re: PDS/E Cobol

[Gibney, Dave]

Actually, FTP of a member from z/OS to z/OS were none of the datasets are 
physically shared should work just fine.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Thursday, September 15, 2016 1:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> I would probably use an interim dataset so that there is no potential for
> PDS/E Corruption.
> 
> OP did not indicate the environment or more specifics that Shared Dasd, FTP.
> Sounds like they have a process that uses FTP to move programs from one
> system to another but using Shared Dasd.  I would consider using an interim
> dataset to keep PDS/E Corruption to a minimal chance.
> 
> Copy from Original library to interim file FTP interim File Copy from Interim
> file to Production Library
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Paul Gilmartin
> > Sent: Thursday, September 15, 2016 10:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PDS/E Cobol
> >
> > On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> >
> > >You can use normal utilities to copy a PDS/E member to another place.
> > >
> > >TRSMAIN,
> > >TSO XMIT/RECEIVE
> > >IEBCOPY Unload
> > >
> > May require parallel sysplex.  But no need to unload; can IEBCOPY from
> > PDSE to PDSE.
> >
> > >DFDSS Dump/RESTORE
> > >
> > >If you are using PDS/E Generations, there are some challenges with that.
> >
> > -- 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: PDS/E Cobol

[Lizette Koehler]

I would probably use an interim dataset so that there is no potential for PDS/E 
Corruption.

OP did not indicate the environment or more specifics that Shared Dasd, FTP.  
Sounds like they have a process that uses FTP to move programs from one system 
to another but using Shared Dasd.  I would consider using an interim dataset to 
keep PDS/E Corruption to a minimal chance.

Copy from Original library to interim file
FTP interim File
Copy from Interim file to Production Library


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, September 15, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> 
> >You can use normal utilities to copy a PDS/E member to another place.
> >
> >TRSMAIN,
> >TSO XMIT/RECEIVE
> >IEBCOPY Unload
> >
> May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE to
> PDSE.
> 
> >DFDSS Dump/RESTORE
> >
> >If you are using PDS/E Generations, there are some challenges with that.
> 
> -- gil

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

Re: PDS/E Cobol

[Gibney, Dave]

You can't update a PDS/E from one Lpar and expect the updates to be seen from 
another Lpar unless you are sharing in at least a basic Sysplex. A mixed set of 
Monoplexs like mine need not apply. And if the update is in anyway 
bidirectional, you will experience a corrupted PDS/E

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Thursday, September 15, 2016 10:48 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PDS/E Cobol
> 
> On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:
> 
> >You can use normal utilities to copy a PDS/E member to another place.
> >
> >TRSMAIN,
> >TSO XMIT/RECEIVE
> >IEBCOPY Unload
> >
> May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE
> to PDSE.
> 
> >DFDSS Dump/RESTORE
> >
> >If you are using PDS/E Generations, there are some challenges with that.
> 
> -- 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: PDS/E Cobol

[Jousma, David]

I think the requirement was separate sysplex's.  So, don’t copy pdse to pdse 
unless you want a mess.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, September 15, 2016 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E Cobol

On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:

>You can use normal utilities to copy a PDS/E member to another place.
>
>TRSMAIN,
>TSO XMIT/RECEIVE
>IEBCOPY Unload
>
May require parallel sysplex.  But no need to unload; can IEBCOPY from PDSE to 
PDSE.

>DFDSS Dump/RESTORE
>
>If you are using PDS/E Generations, there are some challenges with that.

-- gil

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: PDS/E Cobol

[Paul Gilmartin]

On Thu, 15 Sep 2016 10:26:53 -0700, Lizette Koehler  wrote:

>You can use normal utilities to copy a PDS/E member to another place.
>
>TRSMAIN,
>TSO XMIT/RECEIVE
>IEBCOPY Unload
>
May require parallel sysplex.  But no need to unload; can IEBCOPY from
PDSE to PDSE.

>DFDSS Dump/RESTORE
>
>If you are using PDS/E Generations, there are some challenges with that.

-- gil

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

Re: PDS/E Cobol

[Lizette Koehler]

You can use normal utilities to copy a PDS/E member to another place.

TRSMAIN,
TSO XMIT/RECEIVE
IEBCOPY Unload
DFDSS Dump/RESTORE

If you are using PDS/E Generations, there are some challenges with that.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: Thursday, September 15, 2016 10:17 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDS/E Cobol
> 
> I know there has been a lot on here about the new versions of Cobol and PDS/E.
> I need some understanding, please.  We have a development lpar (SYSPLEX)
> sharing dasd with production lpar SYSPLEX.  Will we be able to FTP the
> development load mod to the production lpar?
> 
> Thank you.
> 

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

PDS/E Cobol

[Lopez, Sharon]

I know there has been a lot on here about the new versions of Cobol and PDS/E.  
I need some understanding, please.  We have a development lpar (SYSPLEX) 
sharing dasd with production lpar SYSPLEX.  Will we be able to FTP the 
development load mod to the production lpar?

Thank you.



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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