Reason:
The system versions of the RDT and FDT are stored in load modules as well as in the security file. From time to time, CA Top Secret adds new fields to the system FDT and new resource classes to the system RDT. These are distributed through APARs to the software. When a new version of system table is sensed, a “synchronization process” is initiated.
As new FDTNAMEs are added to the system FDT, it is possible that the new system name conflicts with a previously defined user FDTNAME. In such case, the user FDTNAME is renamed to UFLDhhhh (where “hhhh” is the hexadecimal representation of the FDTCODE assigned to the original user defined field).
As new RESCLASS's are added to the system RDT, it is possible that the new system name conflicts with a previously defined user RESCLASS. In such case, the user RESCLASS is renamed to USERhhhh (where “hhhh” is the hexadecimal representation of the RESCODE assigned to the original user defined resource class).
Action:
If programs or products on your system made use of “oldname1”, all affected ACID field references will now point to “newname1”: you will have to re‑administer “oldname1” with its new system‑supplied definition; or you will have to alter the programs or products so that they reference “newname1” instead.
For FDT definitions, the DISPLAY attribute supplies the text which labels the field value during TSS LIST and WHOHAS commands. Because the default DISPLAY attribute is the FDTNAME, users may believe that their field definitions are intact after synchronization, when in fact they have been altered. To avoid such display anomalies, you may wish to issue:
TSS REP(FDT) FDTNAME(newname1) DISPLAY(oldname1_O)
so that the field will display as:
oldname1_O = value
and thus distinguish your old administration from your new administration.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|