Hello to all,
I experience difficulty with diagnostic information DB2_TOKEN_STRING. As described, this diagnostic variable contains the message replacement data for a given message.
For testing purposes I wrote a RPG program in which DB2 throws message id SQL0204. This message uses 3 variables of type *char with length *vary.
Here are my problems:
1) First strange thing is that DB2_TOKEN_COUNT is set to 2 (not 3).
2) In DB2_TOKEN_STRING I can see the 3 values as one string but I don't know how to tokenize them. As described, the tokens should be delimited by a hex 'FF' value, so there should be 3 (or at least DB2_TOKEN_COUNT) hex'FF' values but my program finds only 1 hex'FF' value. The program loops DB2_TOKEN_COUNT times, and on every iteration it does a scan function for hex 'FF' on DB2_TOKEN_STRING with the corrected start position.
Thanks for any help.
ScottForstie 110000AUM611 Posts
Re: DB2_TOKEN_STRING2012-06-01T13:05:28ZThis is the accepted answer. This is the accepted answer.Hi,
I suggest you open a PMR so that we can examine your scenario.
I wrote my own quick test and the results were correct.
Regards, Scott Forstie
create procedure qgpl.message_test1(
out num_tokens integer,
out token_stream varchar(1000),
out gsqlcode integer,
out gsqlstate char(5),
out messagetxt varchar(1000))
DECLARE VAR1 integer;
declare exit handler for sqlexception
get stacked diagnostics condition 1 gsqlcode = DB2_RETURNED_SQLCODE,
gsqlstate = RETURNED_SQLSTATE, messagetxt = MESSAGE_TEXT, num_tokens = DB2_TOKEN_COUNT, token_stream = DB2_TOKEN_STRING;
SET gsqlcode = 0;
SET gsqlstate = '00000';
SET num_tokens = -1;
SET token_stream = 'not set';
SELECT COLUMN1 into VAR1 FROM QTEMP.TABLE_THAT_DOESNT_EXIST;
> call qgpl.message_test1(?,?,?,?,?)
Return Code = 0
Output Parameter #1 = 2
Output Parameter #2 = QTEMP.TABLE_THAT_DOESNT_EXISTFILE
Output Parameter #3 = -204
Output Parameter #4 = 42704
Output Parameter #5 = TABLE_THAT_DOESNT_EXIST in QTEMP type *FILE not found.
zipperle 060001JMVS2 Posts
Re: DB2_TOKEN_STRING2012-06-05T09:00:42ZThis is the accepted answer. This is the accepted answer.
- ScottForstie 110000AUM6
thanks for the replay.
In IBM i every sql error has its respective message id in message file QSQLMSG.
For sql error -204 there is message id SQL0204.
This message expects 3 substitutions variables: &1(table name), &3(object type), &2(library name).
In order to send/resend a given message to the user/display/log etc. the programmer needs the correct substitutions variables. So the message can be sent, for example, the the previous program call entry by using api QMHSNDPM.
The substitutions variables can be found in SQLERRMC in the SQLCA. SQERRMC has only a length of 70 bytes. Maybe this could not be enough.
Therefore I thought that the information in DB2_TOKEN_STRING would be the same as SQLERRMC in SQLCA.
Maybe I am wrong with my thoughts and the meaning of DB2_TOKEN_STRING is another….
IBM DB2 people say that programmers should better use the informations of the diagnostic area instead of SQLCA.