DSNU283I -RD10 043 10:56:25.69 DSNUULVA - LOB ERROR

Document ID : KB000048129
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Our DB2 support is trying to unload data rows with XML data into a PDS dataset. The unload job running under ACID ZICDFS and is getting the following error:


DSNU283I  -RD10 043 10:56:25.69 DSNUULVA - LOB ERROR                          
     SQLCODE = -452                                                          
     SQLERRM = CDFS.ITST.UNLOAD.XML.TEST.LOB(EM4V2T28) 13                    
     SQLSTATE= 428A1                                                         
     SQLERRP = DSNOLFRV                                                      
     SQLERRD = 00000064 00000000 00000000 FFFFFFFF 00000000 00000000

The DB2 started task output is showing the following violation and abend:


IEC150I                                                                       
913-38,IFG0194E,RD10DBM1,RD10DBM1,SYS07218,5712,US1046,CDFS.ITST.UNLOAD.XML.TEST.LOB(EM4V2T6M)                                                              
                                                                             
IEA995I SYMPTOM DUMP OUTPUT  937                                              
                                                                             
SYSTEM COMPLETION CODE=913  REASON CODE=00000038  

User is receiving a security violation for the PDS member even though they are authorized through a TSS PERMIT.

Solution:

Run a TSSUTIL EVENT(VIOL) DATE(yyddd) TIME(hhmmss,hhmmss) LONG security violation report to determine what FACILITY the security violation occurred in. 'yyddd' is the Julian date and 'hhmmss,hhmmss is the timeframe from about 10 minutes before the error and 10 minutes after the error.

Issue a TSS MODIFY FAC(facilityname) for the FACILITY where the security violation occurred for the user.

Once you have the output for the command, make sure the RES attribute is specified and not NORES.

If you don't have the RES attribute set, issue a TSS MODIFY FAC(facilityname=RES).

A recycle of the DB2 started task is required for the RES attribute to go into effect.

If that resolves the problem, please put FAC(facilityname=RES) in your CA Top Secret parameter file to make the change permanent.

TSS MODIFY commands are only temporary. They go away once CA Top Secret is recycled (or the system is IPL'd).

Please see the CA Top Secret Control Options Guide for more details about the RES attribute.