DDPUPN004 UPG KEY,ALL.ALL(version)
Article ID: 106198
Updated On:
Products
CA Datacom - DB
CA Datacom
CA Datacom - AD
CA Datacom - Server
Issue/Introduction
Some CA Datacom/DB Data Dictionaries may have had problems from the past which caused upgrade DDUPDATE steps with…
-UPG KEY,ALL.ALL(version)
1500 KEY-USAGE,&
-END
…where version TEST or PROD (or both) fail with error…
**** ERROR **** RETURN CODE = DDPUPN004 INTERNAL ERROR - SEE MESSAGE MANUAL
SYSCONSTRSRC .
ERRORS DETECTED, NO MAINTENANCE APPLIED
In this example, KEY SYSCONSTRSRC is seen in the error message, but it may be a different KEY.
The problem is caused by a broken RELATIONSHIP from either KEY to TABLE or TABLE to KEY.
How to address DDPUPN004 error running DDUPDATE -UPG KEY,ALL,ALL(version)?
-UPG KEY,ALL.ALL(version)
1500 KEY-USAGE,&
-END
…where version TEST or PROD (or both) fail with error…
**** ERROR **** RETURN CODE = DDPUPN004 INTERNAL ERROR - SEE MESSAGE MANUAL
SYSCONSTRSRC .
ERRORS DETECTED, NO MAINTENANCE APPLIED
In this example, KEY SYSCONSTRSRC is seen in the error message, but it may be a different KEY.
The problem is caused by a broken RELATIONSHIP from either KEY to TABLE or TABLE to KEY.
How to address DDPUPN004 error running DDUPDATE -UPG KEY,ALL,ALL(version)?
Environment
z/OS
Resolution
To determine the cause, run the following DDUPDATE or DDUTILTY request for the version:
-DEF PATH,P1
-DEF TRACE,KEY.TABLE,$INTERNAL
-END
-RPT START,KEY,ALL.ALL(version),P1
-RPT INDENT
-END
The report may show one of two things….
1. If the TABLE to KEY relationship is missing but the KEY to TABLE relationship exists, the report will show TBL with “* * nnn” in the report.
For example:
KEY SYSTABAUTH.GRANTEE-KEY
T T001 ATBK2 020
TBL SYSTABAUTH
* *001 000
ENTITY MISSING
If no “* *nnn” in the DD report, the TABLE to KEY relationships do exist.
2. Then, if the relationship from the KEY to TABLE is missing, the report will show only the KEY occurrence and no TBL occurrence.
So, given the results for SYSCONSTRSRC…
KEY SYSCONSTRSRC.SOURCE-KEY
TBL SYSCONSTRSRC
SQL SYSTEM CONSTRAINT SOURCE
SYSADM.SYSCONSTRSRC
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
To determine the versions of that key named SOURCE-KEY, run DDUTLTY /DDUPDATE with:
-RPT INDEX,KEY,SOURCE-KEY
-END
Then run DDUPDATE to delete those KEYs which have broken relationships:
-DEL KEY, SYSCONSTRSRC.SOURCE-KEY(version)
-END
After the orphan KEYs have been deleted, rerun the DDUPDATE:
-UPG AREA,ALL.ALL(version)
1500 URI-REUSE,&
-END
Then run DDCBLD with -HSD RESET.
-DEF PATH,P1
-DEF TRACE,KEY.TABLE,$INTERNAL
-END
-RPT START,KEY,ALL.ALL(version),P1
-RPT INDENT
-END
The report may show one of two things….
1. If the TABLE to KEY relationship is missing but the KEY to TABLE relationship exists, the report will show TBL with “* * nnn” in the report.
For example:
KEY SYSTABAUTH.GRANTEE-KEY
T T001 ATBK2 020
TBL SYSTABAUTH
* *001 000
ENTITY MISSING
If no “* *nnn” in the DD report, the TABLE to KEY relationships do exist.
2. Then, if the relationship from the KEY to TABLE is missing, the report will show only the KEY occurrence and no TBL occurrence.
So, given the results for SYSCONSTRSRC…
KEY SYSCONSTRSRC.SOURCE-KEY
TBL SYSCONSTRSRC
SQL SYSTEM CONSTRAINT SOURCE
SYSADM.SYSCONSTRSRC
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
KEY SYSCONSTRSRC.SOURCE-KEY
SYSADM.CNSKY_015
To determine the versions of that key named SOURCE-KEY, run DDUTLTY /DDUPDATE with:
-RPT INDEX,KEY,SOURCE-KEY
-END
Then run DDUPDATE to delete those KEYs which have broken relationships:
-DEL KEY, SYSCONSTRSRC.SOURCE-KEY(version)
-END
After the orphan KEYs have been deleted, rerun the DDUPDATE:
-UPG AREA,ALL.ALL(version)
1500 URI-REUSE,&
-END
Then run DDCBLD with -HSD RESET.
Feedback
Powered by
