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
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
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
) (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:3
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
ce.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 sec
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
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 pr
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 p
nal 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 Koehl
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
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
to: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.
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.
14 matches
Mail list logo