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
