On Fri, 16 Sep 2016 08:18:14 -0500, Tom Marchant <[email protected]>
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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
