CMOD V850 : ARSLOAD & SQLCODE=-302

[jmimi]

Hi,
During ARSLOAD, we have the following  DB2 Message error (in the ARSSOCKD stc):

ARS0013E MYDOCWEB DB Error: ?DB2 FOR OS/390??ODBC DRIVER??DSN09015?  356      
DSNT408I SQLCODE = -302, ERROR:  THE VALUE OF INPUT VARIABLE OR              
PARAMETER                 NUMBER 3 IS INVALID OR TOO LARGE FOR THE            
TARGET COLUMN OR THE TARGET             VALUE                                
                                          DSNT418I SQLSTATE   = 22003        
SQLSTATE RETURN CODE                                 DSNT415I SQLERRP        
   = DSNXRIHB SQL PROCEDURE DETECTING ERROR                                  
DSNT416I SQLERRD    = -385  0  0  -1  0  0 SQL DIAGNOSTIC INFORMATION        
           DSNT416I SQLERRD    = X'FFFFFE7F'  X'00000000'  X'00000000'        
  X'FFFFFFFF'                  X'00000000'  X'00000000' SQL                  
DIAGNOSTIC INFORMATION                      ERRLOC=1:13:2 -- SQLSTATE=        
22003, SQLCODE=-302, File=arsseg.c, Line=4065                                
ARS0088E MYDOCWEB Application Group Failed Load: Name(PHER) LoadId(  357      
7689-1-0-2FAA-15522-15522) File(/ars/rec/tmp/PHER.M0TS.MCCGLAUH.              
SYSUT2.STD1.120718.0929120000524389.ARD)                                      

The problem is that we don't have the table name.
Do you have any idea ?

For information, Z/OS 1.11 & CMOD V8.5.0
Thanks for your help,
Regards,
Jean-Michel

[jmimi]

It seems to be in the ARSSEG table...
In the 3rd column (START_DATE) ? like the message says...

[Greg Ira]

I don't think it's your ARSSEG table.  It's likely the table for your application group PHER.  Whatever index value you are attempting to insert into column 3 doesn't match what's defined for the column.  I see this is only the second load to that group, was something changed or modified before this load but after the original?

[jmimi]

Our DB2 Admin has identified the SQL order with APPTUNE.
An the SQLCODE=-302 comes from this instruction:

INSERT                                                                 
INTO     ARSUSER.ARSSEG(agid, table_name, start_date, stop_date,       
         post_date, closed_date, reimported_date, last_update,         
         last_backup, last_stats, mask, ins_rows, upd_rows, del_rows, 
         mod_rows, max_rows, database_name)                           
VALUES   (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)     

Any idea ?
Thanks for your help !

[jmimi]

Problem solved !
I exported, dropped, created (table + indexes) and imported datas for the arsseg table.
And... No more problem !...

I didn't see this item in migrations documents (from 8.4.0 to 8.5.0)...
I hope there isn't any other surprise... ;-))

Regards

[Greg Ira]

Glad you got it corrected.  Just as an FYI we ran into something similar soon after migrating to V8.5.  For reasons unknown one of our application group tables up and decided to change the datatype for one of the columns and any subsequent loads or queries failed with an SQLCODE=-301.  We had to do the same thing you did and recreate the table.