On Fri, 16 Sep 2016 08:18:14 -0500, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>On Fri, 16 Sep 2016 02:39:15 +0000, 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

Reply via email to