Correct the invalid numeric literal.Federated system users, if the error
occurred in a pass-through session, determine what data source is causing
the error (see the Troubleshooting Guide for the failing data sources).
Examine the SQL dialect for that data source to determine which literal
representation rule has been violated, and adjust the failing statement as
needed.

Can you confirm and double-check the data-type of the column being updated?
You imply it is a CLOB but DB2 thinks it is a numeric type.
Can you also confirm the DB2 version & fixpack and operating-system for the server?
A CLOB literal of '59DUE' updates just fine in a CLOB column for me.
What is the codepage and territory of the database?
What is the codepage of the connecting application?

so if you look at the second post i sent about numeric literals... what
you are passing is not a numeric literal.

A *numeric literal* is a character-string whose characters are selected
from the digits 0 through 9, a sign character (+ or -), and the decimal
point. If the literal contains no decimal point, it is an integer. (In this
documentation, the word *integer* appearing in a format represents a
numeric literal of nonzero value that contains no sign and no decimal
point, except when other rules are included with the description of the
format.) The following rules apply:

- If the ARITH(COMPAT) compiler option is in effect, one through 18
digits are allowed. If the ARITH(EXTEND) compiler option is in effect, one
through 31 digits are allowed.
- Only one sign character is allowed. If included, it must be the
leftmost character of the literal. If the literal is unsigned, it is a
positive value.
- Only one decimal point is allowed. If a decimal point is included, it
is treated as an assumed decimal point (that is, as not taking up a
character position in the literal). The decimal point can appear anywhere
within the literal except as the rightmost character.

The value of a numeric literal is the algebraic quantity expressed by the
characters in the literal. The size of a numeric literal is equal to the
number of digits specified by the user.

What is missing in the conversation, is the fact that SQL presented by Vamshikrishana is not the SQL per se, but rather a Unix script, which is transformed by the shell into a SQL, where '59DUE' becomes indeed a numeric rather than a character string, which id SHOULD BE, as the result of applying SUBSTR function to a character (CLOB) value.

If I am not clear in my previous post, the single quotes around '59DUE' will be stripped by the shell, because the whole text is not placed in double quotes. I believe, this SQL has other issues on top of this one, including a value in the SET statement not placed in parenthesis and unbalanced single quotes.

It's always good to first imagine the final result of Shell substitutions and make sure it's a valid SQL. Then you write the script, which will be transformed by the shell into your final format.

This is not an "idea." This is how a single quote is coded inside a character string surrounded by single quotes. The reason this took me so long and the reason you were given so many imperfect advices, including two of my own, is very simple: you did not clearly identify the purpose of this query. As the result, nobody could parse it in order to realize that you were saving an SQL statement, including single quotes, in the CLOB.Tthat's why I was assuming 59DUE was a part of WHERE clause in a subquery. Others, probably, were interpreting it in a different way.

The moment I realized that everything between the second SELECT and the last WHERE was a CLOB value to be inserted, that very moment everything became clear. Unfortunately your description of the issue did not do much to bring this moment closer.

Now, if you don't mind, please mark the appropriate post as "helpful" by clicking the icon in its upper right corner.

Don't forget to do this in future, each time you get help from the members of this community.