OnDemand User Group
Support Forums => z/OS Server => Topic started by: jmimi on July 18, 2012, 05:27:20 AM
-
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
-
It seems to be in the ARSSEG table...
In the 3rd column (START_DATE) ? like the message says...
-
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?
-
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 !
-
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
-
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.