Transferring Datasets with Aliases with CA XCOM
Article ID: 56067
Updated On:
Products
Issue/Introduction
Background Information about Aliases
There are differences in the way MVS handles aliases for datasets and members of a dataset. Aliases for a dataset are kept in the DASD catalog and changes made to the members of the dataset show up when the dataset is accessed using the alias.
However, aliases for members of a dataset (PDS) are kept using the TTR (i.e. if B is an alias for member A, they both have the same TTR). However, if member A or alias B is edited and saved, the updated member will have a new TTR while the non-updated member retains the old TTR. The new TTR is not propagated to the alias related member, therefore the relationship is broken. MVS applications, including XCOM and IBM Utilities, can have problems processing members of a dataset after this happens.
For example, if member A is updated and saved, when A is viewed, the updates will show up, but when alias B is viewed, the updates will not show up since the TTR is pointing to the location of the original copy. But MVS has not severed the alias relationship and member B still shows up as an ALIAS when the directory is displayed for this dataset. However, its TTR is pointing to a non-existent member.
However, if it is ALIAS B that was edited and saved, MVS will sever the ALIAS relationship between members A & B, and member B will become a real member of this dataset. A display of the directory of this dataset will no longer show member B as an alias. A transfer of this file will result in both members A & B showing up on the target destination as two separate and distinct members.
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.
Environment
Component: XCMVS
Resolution
How XCOM Handles Aliases
XCOM on z/OS sends the directory information for an ALIAS in the XCOMLIB record to the partner. If the partner is also z/OS, that information will be interpreted properly and the ALIAS information is propagated to the partner. If the partner is not z/OS, the ALIAS is treated as an empty member since XCOM does not retransfer the member using the ALIAS name. ALIASes have no meaning for partners other than z/OS.
When the aliases are in a load library, XCOM looks for the corresponding BASE member for each alias. It also verifies that the TTR values match for the ALIAS and the BASE. If the BASE member has been updated since the ALIAS was created, the TTR's won't match, and thus the ALIAS member is no longer valid. In this case, XCOM issues error message XCOMM0380E MEMBER NOT FOUND FOR ALIAS TTR to identify the invalid ALIAS, and continues the transfer without that particular ALIAS.
If you receive the message, XCOMM0380E MEMBER NOT FOUND for ALIAS TTR, check to make sure that the real module and the ALIAS have the same TTR address. If they don't, this is corruption. In this case, XCOM issues the message and ignores the bad one and continues with the transfer. XCOM functions the same way IEBCOPY does in this instance.
Feedback
