Author: Robert Sample
Posted: Thu Apr 20, 2017 11:49 pm (GMT 5.5)
I found this quote dated 12/21/2015 at https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec294331.html :
So you need to either copy the entire load library or don't expect aliases to be associated with their base in the target load library if members are copied.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Thu Apr 20, 2017 11:49 pm (GMT 5.5)
I found this quote dated 12/21/2015 at https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec294331.html :
| Quote: |
| There is another type of alias on z/OS which is also handled differently, and that is an alias of a member of a loadlib. Tests using LOADLIBs with aliases showed that both IEBCOPY and XCOM will copy over aliases for load modules only when the entire loadlib is transferred. No alias relationship is maintained when transferring or copying over individual modules. MVS does not maintain the TTR's integrity when an individual module is relinked or copied or transferred. This is much the same as with source/text/listing members. An alias transfer can only work if its associated base module is also transferred. This is due to the fact that the TTR pointer to the base member will be different on the receiving side. If the base member doesn't exist on the receiving side, there's no way to get a valid TTR pointer to place in the ALIAS directory entry. |
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth