Resolving errors with Ideal users created by DDUPDATE

Products

• Ideal

Issue/Introduction

After applying the CARS2110 maintenance–which includes Solution SO15825, titled "USERS WITH NO AUTHORITY IN SYSTEM SHOW AS UPDATE"–certain Ideal users received an error message:

IDADSVCS01E - Insufficient level of authorization for the requested function

Another message could be:

IDADSLSP06E - SYS xxx not valid, SYSTEM short id is not defined

The users were previously authorized to Ideal systems using DDUPDATE to grant different access levels, but displaying the user in Ideal showed no access to the system.

Another user was unable to run their login member, and they had to first issue a SEL SYS xxx command before running the member.

Recycling the CICS region and the MUF had no effect.

What is the cause of this error, and how do we correct it?

 

Environment

Component : IDEAL

Cause

Ideal users who have a system authorization created using DDUPDATE with an invalid 1003 DATA transaction are successfully added to the system, but because the 1003 DATA transaction was not defined correctly, users are not granted the correct level of access to the desired system.

Resolution

Ideal users can be authorized to Ideal systems either through online panels or through batch DDUPDATE transactions. This article does not apply to users who were authorized through online panels, but only through DDUPDATE processing.

Applying Solution SO15825, titled "USERS WITH NO AUTHORITY IN SYSTEM SHOW AS UPDATE," corrected a problem with certain Ideal users who received Update access to Ideal systems where they were supposed to have no access. Another result of applying this solution is that some users who were previously authorized (through DDUPDATE) before this solution now showed no access afterward. The Ideal system was shown on the DISPLAY USER screen, but there was no display of the access attributes that should have been in place.

First, here is an explanation of how users are added through DDUPDATE.

When you define user access levels added through Datadictionary, you are required to have a set of transactions with these records:

• -UPD ... This identifies the user to whom the system access is added
• 1003 RELT ... This creates a relationship from the user to the Ideal system using the long system name
• 1003 DATA ... This defines the access level to the above Ideal system for the user
• 1003 RELT ... This creates another relationship from the user to another Ideal system
• 1003 DATA ... This defines the access level for the above system
• . . .  <repeat for every system the user needs>
• -END

Here is an example set of transactions to grant access to the Ideal system called ACCOUNT-MGMT:

-UPD PERSON,JOE-SMITH    (PROD)
1003 RELT,SYSTEM,ACCOUNT-MGMT (PROD),PER-SYS-ACCESS  
1003 DATA,$IDY
-END

The format for the 1003 DATA transaction is defined specifically as the three-character literal string "$ID" (shown in the blue highlight above) followed by the one-character hex value containing bit settings for the different access possibilities (shown as "Y" in the yellow highlight above). $ID is not a system short name here, it is a required literal string. The four-byte value for this data field is stored in the Datadictionary relationship record. For more details about this process, you can refer to the documentation section "Using Batch to Maintain Ideal for Datacom User Definitions" in the Datacom Tools. Note that if the 1003 DATA value does not have "$ID" in the first three characters, Ideal will not recognize this as an authorization level, and the user will have no access to this system, regardless of what was specified in the fourth character. 

In terms of the application processing not working as expected, a similar process takes place. When the user issues a command to run a program for an application, Ideal would check the system to find the relationship record, and then extract the data to see what authority the user had to run programs or display panels, etc. In this case, if Ideal does not find the $ID value in the data field, it determines that the user does not have access to run the program, and issues an application error message if there is one.

To correct this problem for a few users, it is easy to modify the user online using standard procedures. However, if there are many users, it might be easier to update them all through a batch process. Attached to this article is a .txt file that contains JCL to:

• List the users that have invalid 1003 DATA values
• Create a file that is reworked using SORT to create DDUPDATE transactions
• Run the DDUPDATE program to disconnect the user from the "bad" relationship, and then add the correct relationship

There are other steps to produce reports and print the intermediate files if desired, and take a backup of the Datadictionary before making the updates. In addition, this JCL is designed to be able to use either SQL to list the problem users, or Dataquery if SQL is not installed.

To use this JCL, we recommend that you first run the job with the RUNTYPE set to REPORT, to be able to determine the scope of the problem. Then, you can either restrict the number of records processed or select up to four users that you want to manually verify before running the job against your entire system. 

Some customers have reported more than 30,000 records were added incorrectly due to a programming error for several years. These were easily corrected with the result that the application errors are no longer seen.

Additional Information

As always, please contact Broadcom support for Datacom if you have further questions.