DC170013 CA ADS ABEND. NO PDE FOUND DURING #LOAD OF APPLICATION MINOR CODE 04
Article ID: 31990
Updated On:
Products
Issue/Introduction
The usual cause is that the user was set to the wrong DICTNAME, and not the DICTNAME where the application load module resides.
Items to check include the following:
Use either OCF or IDMSBCF, issuing command “DISPLAY USER xxxx” to display the User’s privileges.
DIS USER ABCUSER2
*+ CREATE USER "ABCUSER2"
*+ USER IS ACTIVE
*+ DESCRIPTION 'IDMS PROGRAMMER'
*+ NAME 'JANE DOE'
*+ PASSWORD NOT ASSIGNED
*+ PROFILE ABCPROF
*+ WITHIN GROUP TECHIES
*+ WITHIN GROUP DMLO-USER
*+ HOLDS SYSADMIN PRIVILEGES
*+ HOLDS SIGNON PRIVILEGES ON SYSTEM SYST1850
*+ HOLDS SIGNON PRIVILEGES ON SYSTEM SYST1900
*+ HOLDS EXECUTE PRIVILEGES ON ACTIVITY DEFAULT.ACT_001
What DICTNAME showed in DCUF SHO PROFILE immediately after signon.
Which IDMS SYSTEM is the user is signing on to?
A User with SYSADMIN should issue in OCF:
"CONNECT TO SYSTEM;"
“DISPLAY PRIVILEGES ON SYSTEM SYSTnnnn”
It will show all of the GRANT SIGNON.
For the User having the problem, there may be a SYSTEM PROFILE that was assigned when the GRANT was done and it could be overriding the DICTNAME specified in the USER PROFILE. Although the USER PROFILE gets processed first, if you also have a SYSTEM PROFILE, it will override any attributes that they have in common.
Another reason could be that user issued a DCUF to another dictionary and forgot to reset back to this dictionary.
References:
CA IDMS Security Administration, Chapter 5: Signon Processing, Building the Session Profile
CA IDMS System Tasks and Operations, Chapter 10. System Profiles
Environment
Component:
Feedback
